No banner. Here’s why.

1. The short version

EmotiVault sets no cookies. It loads no third-party scripts — no Google Analytics, no Meta pixel, no advertising or session-replay SDK, no chat widget. Our fonts are served from our own domain rather than fetched from Google. Our page-view counter is written by us, runs on our own server, and stores nothing on your device.

What we do keep on your device is a short list of first-party browser-storage items, named in full in section 3. They are there to keep you signed in, to keep your journal readable when your connection drops, and to remember the settings you chose. Every one of them is readable only by emotivault.com and never leaves your browser except when the app itself syncs your entries to your own account, or when text you write in the demo or sandbox is sent once to our safety check — see section 3.

That combination is why you are not being asked to click “accept”. The reasoning is set out in section 5, and the conditions that would force us to add a banner are in section 6.

2. Cookies

We set none. Not one, on any page, signed in or out. Your sign-in session is held in your browser’s local storage rather than a cookie (see ev_supabase_auth below).

One boundary worth being precise about: if you subscribe to Premium, the payment itself happens on Stripe’s own checkout page at checkout.stripe.com. That is Stripe’s site, not ours, and Stripe sets its own cookies there under its own policy — including cookies it uses for fraud prevention. We never see them, and they are not set on emotivault.com. The same applies if you sign in with Google or Apple: those sign-in screens are theirs.

3. What we store on your device

All of the following are browser storage on the emotivault.com origin. Nothing here is shared with any other site, and none of it contains an advertising identifier, a device fingerprint, or any value that could follow you anywhere else.

Strictly necessary — the app does not work without these

• ev_supabase_auth Your sign-in session as issued by our authentication provider: an access token, a refresh token, the expiry, and your account id and email address. Without it you are signed out on every page load. Until you sign out, or the refresh token expires.
• ev_session A small cached copy of your display name, public handle, plan tier and account start date, so a page can render your signed-in view on first paint instead of flashing a signed-out shell while the session is confirmed. Cleared when you sign out.
• ev_entries Your journal entries, held on the device so the app stays readable and writable when the network drops and so an entry you are part-way through is never lost. This is the offline-first half of the journal; the same entries also sync to your account. Until you sign out or delete your data.
• ev_entries_owner The account id that the cache above belongs to. This is a safety guard, not a convenience: if a different account signs in on the same browser, the cache is wiped rather than uploaded into the wrong person’s vault. Lives and dies with ev_entries.
• ev_age_block If a date of birth under 16 is declared at sign-up, we record the declared age and the date it was declared, so the age gate stays closed on a reload instead of handing the same visitor a fresh attempt. No date of birth is stored. Until cleared.
• ev_v2_legacy_cleaned A single timestamp recording that we cleared leftover keys from the previous version of EmotiVault once, so the cleanup does not run on every page load. Indefinite. One value, no personal data.

Set because you chose something

These exist only after a deliberate action by you, inside an account you asked us to run. None is used for tracking, profiling or measurement of any kind.

• ev_prefs Aurelia’s tone, whether she uses your first name, whether the quiet acknowledgement after a run of hard days appears, and your visual theme. Until changed, or until you sign out.
• ev_onboarding The answers you gave during onboarding, held on the device between finishing onboarding and your account being created — the account does not exist yet, so there is nowhere else to put them. Written into your account and deleted from the device as soon as sign-up completes. Minutes, in the normal case.
• ev_mood_today Today’s date and the mood you tapped on the dashboard, so the marker stays lit if you leave and come back. It is replaced the next day. One day, then overwritten.
• ev_support_seen The date you were last shown the low-stretch acknowledgement, so that being noticed once does not become being told repeatedly that you seem low. 21 days.
• ev_known_usernames Handles claimed in this browser, used for a local duplicate check while you pick yours. Until cleared.
• ev_checkout_intent Written only if you press a Premium button before you have an account: which plan you chose (monthly or yearly) and when. Once your account is set up it is read once, to open the checkout you asked for, and deleted. It holds no payment details — those never touch this site. Deleted on first use, and ignored after one hour.

Demo, sandbox and try-it surfaces

These belong to the signed-out pages where you can try the product on sample data. What you type into them is kept in the browser, not on our servers. The one exception is the safety check: text you write in the demo or sandbox is sent once to be screened for distress, so that real help can be shown if it is needed. It is not stored.

• ev_demo_entries ev_sandbox_entries ev_demo_idea_votes ev_demo_idea_submitted ev_demo_echo_reacts ev_demo_echo_survey ev_demo_echo_notify What you wrote, voted for or reacted to while exploring the demo, so the demo behaves like a real app rather than resetting under you. These are the one exception to “stays in your browser”: text you write in the demo or sandbox is also sent once to our safety check, so we can show real help if you need it. It is not stored there. Until cleared.

Session storage — gone when you close the tab

• ev_api_up A single 1 or 0 recording whether our API answered, so a page can show an honest “can’t reach Aurelia” state instead of hanging.
• ev_demo_theme The theme you picked while trying the demo, deliberately kept out of your real account preferences.

4. How we count page views without storing anything

We do want to know which pages people read. We do not want a third party to know. On a mental-health product the pages someone visits are themselves sensitive — a person sitting on a crisis page at 3am is a disclosure, and handing that to an advertising company’s analytics SDK would be indefensible whatever the consent banner said.

So the counter is ours, and it is built to hold nothing:

• No cookie, no local storage, no session storage, no device or advertising identifier. Nothing is written to your device at all — which is the specific fact that keeps it outside the consent rules described below.
• No user id is attached, even when you are signed in. A page view from a signed-in member and one from a stranger are the same row.
• Your IP address is never stored. Our server hashes it together with a salt that is thrown away and regenerated every day, so two visits on the same day can be told apart but the same person on two different days cannot be linked. Yesterday’s salt no longer exists anywhere, so yesterday’s rows cannot be re-identified even by us, even with the database in hand.
• Query strings and URL fragments are stripped before anything is sent — password-reset and magic-link callbacks carry live tokens in both. Any part of a URL that looks like an identifier is replaced, so a journal entry becomes /journal/:id and never a permanent link between a person and one memory.
• We keep the referring site’s host name (google.com), never the full referring URL, because the path on that site can carry the search terms that brought you here.
• We record a two-letter country and whether the device is mobile or desktop. The user-agent string itself is discarded.

Because nothing is stored on or read from your device, this is not a “storage and access” activity at all. It is still processing of personal data in the moments before the IP address is hashed away, and UK GDPR still applies to it — we rely on legitimate interests for that, and the design above is what keeps the balance on the right side.

5. Why there is no consent banner

The rule that produces cookie banners in the UK is regulation 6 of the Privacy and Electronic Communications Regulations 2003 (PECR). It is broader than its nickname suggests: it covers storing any information on your device, or reading information already there — local storage, session storage and device fingerprinting are all in scope, not only cookies. So the fact that we set no cookies is not, on its own, an answer.

Regulation 6 requires consent unless the storage or access is either (a) solely for carrying out a communication over a network, or (b) strictly necessary to provide a service the user has explicitly requested. Our position, item by item:

• The sign-in session and its cache (ev_supabase_auth, ev_session) are the textbook case for the exemption. You asked to sign in; keeping you signed in is the service.
• The offline journal cache (ev_entries, ev_entries_owner) is the service. EmotiVault is an offline-first journal: without a local copy, opening your vault on a train with no signal shows you nothing, and an entry interrupted by a dropped connection is lost. The owner stamp beside it is a security control protecting one user’s writing from another’s account.
• The age gate (ev_age_block) is necessary to provide sign-up lawfully at all, and holds a declared age rather than a date of birth.
• Demo and sandbox storage exists only on pages you navigated to in order to try the product, and holds only what you typed there.

We will be straight about where this is less clear-cut. The ICO reads “strictly necessary” narrowly: it means essential to deliver what the user asked for, not merely useful to us, and the ICO’s guidance on storage and access technologies treats personalisation and preference storage as generally outside the exemption. Our preference items (ev_prefs, ev_mood_today, ev_support_seen, ev_known_usernames) sit close to that line. We rely on the exemption for them because each one records a choice you actively made, inside an account you asked us to run, and is read back only to honour that choice — and because none of them measures, profiles or follows anybody. A cautious reading would put at least ev_prefs in the consent-needed column. We think the better view is that a setting you deliberately chose is part of the service you requested, and we would rather write that down than claim a certainty that is not there.

The analytics is a separate question and an easier one. Because it writes nothing to your device and reads nothing from it, regulation 6 is not engaged at all — there is nothing to consent to. That is a design decision with a cost (we know less about our own visitors than a competitor using an off-the-shelf tracker does) and we think it is the right trade for this product.

Conclusion: no consent banner is required for EmotiVault as it is built today. This is not a loophole we found; it is the consequence of not loading anyone else’s code. Our content security policy backs it up at the browser level — scripts may load only from our own origin, and the only outbound connections the browser is permitted to make are to our own database and our own API. A third-party tracker could not silently appear on this site even if someone tried to add one.

6. What would change this

We would have to ask for consent — with a real banner offering a genuine, equally easy “reject” — before doing any of the following, and we would update this page first:

• Adding any third-party script: an analytics or product-analytics SDK, a session-replay or heatmap tool, an advertising or conversion pixel, an embedded chat widget, an A/B-testing service.
• Adding any advertising or marketing cookie, or any identifier that could follow you to another site.
• Storing anything on your device for a purpose that is not delivering the service you asked for — measurement, attribution, or personalisation you did not choose.
• Loading fonts, images or embeds from a third-party domain, which would expose your IP address and the page you are reading to that domain.

If you ever see a consent banner on EmotiVault, it means one of those happened. The honest reading of a banner-free site is not “they forgot”.

7. Clearing what we store

Everything listed in section 3 is under your control and none of it is needed to keep your account: your entries live in your account, and the device copy is a cache.

• Sign out — clears the session, the journal cache and your preferences from this browser.
• Your browser’s site-data controls — in Chrome, Safari, Firefox and Edge, clearing site data for emotivault.com removes every item above at once. Browser settings that block storage entirely will keep the site usable but sign you out on each page load.
• Delete your account — erases the server-side data as well as the device copy.

8. Contact

Questions about anything on this page, or about something you found in your browser storage that is not listed here: support@emotivault.com. If we have missed a key, we want to know — this page is meant to be complete, and an incomplete inventory is a false statement rather than a small omission.

The wider picture — what we hold in your account, who processes it and the rights you have over it — is in the privacy policy.