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. We don’t count page views at the moment. If we switch on our own page counter, it will store nothing on your device, and we will give you a way to opt out first.

What we do keep on your device is a short list of first-party storage items, named in full in section 3 (the website) and section 4 (the iPhone app). They are there to keep you signed in, to keep your journal readable when your connection drops, and to remember the settings and choices you made. On the website, every one of them is readable only by emotivault.com. None of it leaves your device except when the app syncs your entries and settings to your own account, or, only if you have turned on the safety check, when text you write in the demo or sandbox is sent once to our crisis check.

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

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.

3. What we store on your device: the website

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_supabase_auth-code-verifier A one-time random code created when you ask for a sign-in link or a password reset, so that the link only works in the browser that asked for it. It is just a random code, with nothing about you in it. Deleted when sign-in completes, or replaced by your next attempt.
• 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 18 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_screening_consent Only on the demo and the sandbox. If you press “I agree, turn it on” on the safety-check bar, this records that you agreed, which version of the wording you agreed to, and when, so we remember your choice and never send anything you haven’t agreed to. It holds nothing you wrote. Pressing “Turn off” deletes it. Until you turn the safety check off.
• 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 your browser, not on our servers. The one exception is the safety check, and only if you turn it on: each entry you then save or send is checked once for signs of 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. If you have turned on the safety check, text you write here is also sent once to it, 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. What we store on your device: the iPhone app

The iPhone app sets no cookies and does no tracking of any kind. It has no advertising identifier, no analytics or crash-reporting SDK, and nothing that follows you across other apps or websites, which is why it never asks for Apple’s tracking permission. It keeps only these on your phone:

• Your sign-in session is kept in the iOS Keychain, encrypted by iOS. It stays on this device only (it isn’t carried over to a new phone) and can be read only while your phone is unlocked. Until you sign out, or the session expires.
• ev_draft_entry A journal entry you have started but not saved, so it isn’t lost if you switch tabs. It never leaves your phone, and it is cleared as soon as the entry saves. Until the entry is saved or cleared.
• ev_prefs Your preferences: Aurelia’s tone, whether she uses your first name, whether she offers gentle support when you sound low, and the theme you chose on the web. They are also saved to your account, so they follow you between devices. Until you change them.
• ev_mood_today Today’s mood check-in, so the marker stays lit if you leave and come back. One day, then overwritten.

Deleting your account clears all of these from the phone. Nothing here is used for tracking.

5. Page counting, if we switch it on

Page counting is switched off today. We would like to know which pages people read, but 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 if we switch it on, the counter will be ours, built to hold nothing. Before we switch it on, we will add a simple way to opt out and update this page. This is how it works:

• No cookie, no local storage, no session storage, no device or advertising identifier. Nothing is written to your device at all.
• 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, because 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.
• Sign-ups would be counted the same way: a signup_started event when someone starts signing up, and signup_completed or signin_completed when they finish. These would be counts with no identifier attached.

Because it stores nothing on your device, we don’t believe the consent rule in section 6 applies to it. We will still give you a way to opt out. It is processing of personal data in the moments before the IP address is hashed away, so UK GDPR applies to it; we would rely on legitimate interests, and the design above is what keeps the balance on the right side.

Crash reporting is also switched off. If we switch it on, reports go to our own server, not a third party, and store nothing on your device. The privacy policy explains what a report would contain.

6. 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, app 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, its one-time code verifier, ev_session, and the iPhone app’s Keychain 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 iPhone app’s unsaved draft (ev_draft_entry) protects your writing in the same way.
• 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.
• The safety-check choice (ev_screening_consent) records a consent you gave, so that we can honour it. Remembering a consent choice is a standard example of strictly necessary storage.
• 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.

Page counting and crash reporting are switched off, so they raise no question today. If we switch page counting on, it will write nothing to your device and read nothing from it beyond what your browser sends with every request, so we don’t believe it needs consent under regulation 6. We will add an opt-out before we switch it on anyway. 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.

7. 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 or app.
• 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”.

8. Clearing what we store

Everything listed in sections 3 and 4 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. In the iPhone app, signing out removes your sign-in session.
• Your browser’s site-data controls: in Chrome, Safari, Firefox and Edge, clearing site data for emotivault.com removes every website 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, on the website and in the iPhone app.

9. Contact

Questions about anything on this page, or about something you found in your browser or app 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.