Last updated: October 6, 2026. A practical overview of how CanaryVaults uses cookies, session state, and related browser storage across public and authenticated flows.
Analytics are off unless you accept them on this device.
This page is written as an operator-facing summary rather than a long legal document so users can understand why storage exists in the first place.
Three first-party cookies keep you signed in: canaryvaults_session, canaryvaults_session_token, and canaryvaults_session_refresh. All are HttpOnly and Secure, live at most 7 days, and are strictly necessary: the app cannot keep a session without them.
Some localStorage keys preserve interface choices such as tabs, toggles, or the last-used view so the product feels continuous. They never leave your browser except as part of the pages they configure.
If you accept in the cookie banner, a random ID (canaryvaults:analytics-session-id) and a design test group (canaryvaults:experiment:ui_v1) are kept in localStorage, and page and button events are sent with that ID to our own /api/analytics endpoint. Vercel, which hosts the site, also counts each page view in its Web Analytics: the page address with its query string removed (campaign tags such as utm_source are kept), the site that linked you here, your country, browser and device type. Vercel Web Analytics sets no cookie and stores nothing on your device; Vercel tells a repeat visit apart with a hash of the request that it discards after 24 hours. Until you accept, and after you decline, no event is sent, nothing is counted and neither value is stored. No advertising or cross-site tracking scripts are loaded, and no analytics cookies are set.
Browser storage is only one part of the trust picture. Privacy, security, and support pages explain the rest of the product expectations.
