Cookie Policy
The one cookie Selyf sets, what it's for, and why there's no cookie consent banner.
This page lists every cookie Selyf actually sets — verified against the code, not a generic template. There is exactly one.
The one cookie this product sets
| Name | Purpose | Duration | Type |
|---|---|---|---|
| mailai_session | Keeps you signed in. Holds your encrypted session (account id, login time, a CSRF token) — no Gmail content, ever. | 7 days, fixed from login | Strictly necessary — required |
Set with httpOnly (inaccessible to page JavaScript), SameSite=Lax, and Secure in production. It expires 7 days after login regardless of activity — it is never silently extended by continued use.
No other cookie exists
There is no analytics cookie, no advertising cookie, and no third-party tracking cookie anywhere in this product. Specifically:
- PostHog, the product-analytics provider, runs entirely server-side. Your browser never loads a PostHog script and never talks to PostHog directly — every event is sent from Selyf's own API server, after the fact. PostHog has no opportunity to set a cookie in your browser, because it never runs there.
- Before you sign in, product-usage events (like a page view) use a temporary random identifier that exists only in memory, in your current browser tab. It is never written to a cookie, to localStorage, or to any other browser storage — closing the tab or reloading the page loses it completely. After you sign in, events use your internal account id instead, so no separate tracking identifier is needed at all.
- There is no Vercel Analytics cookie, no Google Analytics, and no CAPTCHA/anti-bot cookie (Cloudflare is DNS-only for this domain — see Subprocessors — it never runs in the traffic path and sets nothing).
- Sentry, the error-tracking provider, runs entirely server-side too — the same as PostHog above. There is no Sentry script, no Sentry SDK, and no Sentry cookie of any kind in your browser; it only ever receives a stack trace and your internal account id, sent from Selyf's own API server after a genuine server failure.
Why there's no cookie consent banner
A consent banner exists to ask permission before setting a cookie that isn't strictly necessary — most commonly an analytics or advertising cookie that identifies you across visits. Under the ePrivacy Directive and CNIL's own guidance, a cookie that is strictly necessary for a service the user explicitly requested (like staying signed in) is exempt from consent — only the "strictly necessary" cookie above exists, and it is set only once you actually sign in with Google, an action you took yourself.
Concretely, none of the conditions that would require a consent banner apply here:
- No non-essential cookie is ever set — there is nothing to ask consent for.
- No persistent cross-visit identifier is stored in your browser at all, cookie or otherwise — the pre-login analytics id is memory-only and never survives a reload.
- The one real cookie (
mailai_session) is set only as a direct result of you signing in — the exact case the strictly-necessary exemption covers.
We'd rather document this plainly than add a banner that asks for consent this product doesn't need — a banner with no real choice behind it is worse for you, not more transparent.
Questions
If anything here changes — a new analytics vendor, a new cookie of any kind — this page will be updated, and this section will describe when a consent banner becomes necessary. Until then, questions about this page can go through Contact.