Version: draft-2026-08-25 · Status: ⚠️ DRAFT — not reviewed by a lawyer
The studio sets one cookie, and it is the one that keeps you signed in. There is no advertising cookie, no analytics cookie and no third-party script on the page that could set one.
That is why there is no consent banner. Under the ePrivacy Directive and KVKK, storage that is strictly necessary to provide a service the user explicitly asked for does not require consent — and being signed in is the service.
If that ever stops being true, a banner appears before the cookie does.
| Name | Type | What it does | Expires | Consent? |
|---|---|---|---|---|
cm_refresh | Cookie, HttpOnly, Secure, SameSite=Lax, Path=/v1/auth | The refresh token. It is what lets a reload keep you signed in | 30 days, rotating on each use | Not required — strictly necessary |
cm.device | localStorage | A random id for this browser. Used by one anti-abuse check | Until you clear site data | Not required — strictly necessary (fraud prevention) |
cm.lang | localStorage | Which language you picked | Until you clear site data | Not required — a stored preference |
Nothing else. No _ga, no _fbp, no pixel.
HttpOnly means script on the page cannot read it, so an XSS cannot steal a long-lived credential. Path=/v1/auth means it is only sent to the four endpoints that need it rather than on every API call. It rotates on every use, and presenting a spent one revokes every session for that account — that is what a stolen token looks like.
The short-lived access token is deliberately not in a cookie. It lives in the page's memory and disappears when the tab closes.
A random value we generate, not a fingerprint. It is not derived from your screen size, your fonts or canvas rendering, and clearing site data clears it.
It answers one question: has this browser already opened several accounts. A fingerprint would answer the same question and also identify you across sites you never agreed to be linked across, which is not a trade worth making for a signup check.
Self-hosted fonts, self-hosted three.js, self-hosted media. No Google Fonts request, no CDN, no embedded player, no social widget — so no third party ever sees a request from your browser, with or without a cookie.
The landing page sets no cookie at all.
Your browser can block cookies for this site. The refresh cookie is the one that matters: blocking it means signing in again on every page load, because there is nothing to restore the session from.
Clearing localStorage resets the language preference and the device id. That is harmless — a new device id simply looks like a new browser to the anti-abuse check.
Adding an analytics or advertising cookie would need consent, which would mean a banner, which would mean this document changes first. The version string at the top is how you can tell.
given that it is fraud prevention rather than session management?
localStorage need a mention in thecookie policy at all, or only in the privacy policy?