Cookies and local storage
None on the marketing site, one in the workbench
Most cookie notices run long because there are a dozen trackers to account for. Ours is short because there genuinely are none — and being short is the reason to lay every item out, so you can check it yourself.
1The short version#
| Where | Cookies | Analytics / tracking | Local storage |
|---|---|---|---|
| Marketing site octoryn.studio | None at all | None | None |
| Workbench studio.octoryn.app | One, to keep you signed in | None | One item: interface language |
| Mobile apps | No cookies used | None | Sign-in token held in the OS keychain |
| Share pages /s/… | None | None | None |
No advertising cookies, no third-party pixels, no cross-site tracking, no profiling. Not out of restraint — none of it exists in the code.
2The marketing site: no cookies#
The site you are reading is entirely static. It sets no cookies and reads none.
- No analytics. No Google Analytics, Google Tag Manager, Plausible, Umami, Fathom, PostHog, Mixpanel, Segment, Hotjar or Sentry. Not one.
- No third-party scripts, iframes or tracking pixels.
- Fonts are self-hosted. The brand typeface is served from our own origin rather than Google Fonts, which would mean every visitor making a request to a third party.
- No forms, no lead capture, no newsletter box. The only outbound links on the page are the buttons that go to the workbench.
- No social widgets or share buttons.
There is one piece of JavaScript
“Zero client framework” is not the same as “zero script”, so to be precise: the site has exactly one client-side script, which opens and closes the navigation menu. It reads and writes no storage, makes no network requests and identifies nobody. There is also a block of structured data for search engines, which is static text and does not execute.
You can check this yourself
Open your browser's developer tools, go to the Network tab and reload: every request goes to this site's own domain and none to a third party, and no response carries a Set-Cookie header. Under Application or Storage, the cookie list is empty.
3The workbench: one necessary cookie#
Once you sign in, the workbench sets a cookie so you stay signed in across reloads and navigation. That is the only one.
| Name | Purpose | Contents | Lifetime |
|---|---|---|---|
| studio_session | Keeping you signed in. This one is strictly necessary — without it you cannot use the product | A random token. No email address, no name, nothing readable. The server stores only its hash | 30 days, extended each time it is used. Ends immediately when you sign out or change your password |
- Marked HttpOnly, so scripts on the page cannot read it — which limits what a script injection could steal.
- Marked SameSite=Lax, so requests originating from other sites do not carry it.
- It is a server-side session rather than a self-contained token, which is why “sign out everywhere” takes effect at once instead of waiting for a token to expire.
This cookie is not used for analytics, advertising or cross-site tracking. The session record behind it holds no IP address and no user-agent either — see section 4 of the privacy policy.
4Browser local storage#
| Key | What it holds | Why |
|---|---|---|
| octoryn.lang | The interface language you chose (Chinese or English) | So it is still that language next time. A language code and nothing else |
That is the entire list for the workbench. It lives in your own browser and is never sent to the server. Clearing your browser data removes it and the interface returns to its default language.
The marketing site uses neither localStorage nor sessionStorage — that language preference exists only in the workbench. On this site the language is decided by the URL (/ for Chinese, /en/ for English).
5The mobile apps#
The mobile apps use no cookies. The sign-in token is held in the operating system's secure store — the iOS keychain or the Android keystore — rather than ordinary app storage, deliberately: ordinary storage is far easier to read off a rooted or jailbroken device. Requests carry it in a standard authorisation header.
There is no analytics, crash reporting or advertising SDK in either app. If you enable push notifications the device gets a push token; what it is used for and how to remove it are in section 2 of the privacy policy.
6What the delivery network sees#
Even where we record nothing ourselves, your requests still travel through infrastructure that sees connection details in order to route and protect them. That is worth stating rather than glossing over.
| Who | Where in the path | What they see |
|---|---|---|
| Cloudflare | CDN and DNS for the marketing site | The request's IP address, user-agent and path — what any CDN sees in order to forward a request. As currently configured, Cloudflare sets no cookies for visitors; we checked the live response headers. It does send a network error reporting header, which reports failed requests back to Cloudflare and successful ones not at all |
| Amazon Web Services | The workbench and media delivery | Connection-level information. We have not enabled access logging (see section 3 of the privacy policy), so no per-request record is kept on our side |
Cloudflare does set its own security cookies when features such as bot management or access challenges are enabled. We have not enabled those. If that changes, this page is updated first.
7Why there is no cookie banner#
Because there is nothing to choose between. A consent banner exists so you can refuse the non-essential cookies — and the marketing site sets none at all, while the workbench's single cookie is what signing in consists of. Refusing it would mean refusing to log in. A banner here would only add a click for every visitor.
That is our reading of the position, not legal advice
Exactly when strictly necessary cookies need consent varies by jurisdiction, and we have not had this reviewed (see section 13 of the privacy policy). What this page states is which cookies we actually set, why, and why on that basis we see nothing for a banner to ask about.
8If this ever changes#
This is the page most likely to go stale: the moment anyone adds an analytics snippet it becomes untrue. So the order is written down here —
- This page changes first; the feature ships second. In the other order the page is decoration.
- If what is introduced is non-essential — a cookie or third-party analytics — a way to decline it ships with it, rather than it being on by default.
- Changes are reflected in the version and date at the top of the page.
If you find this page disagrees with what your browser is actually doing, tell us: [email protected]. A wrong statement here is a bug and should be reported as one.