simse Cookie and Tracking Notice

Effective date: 20 August 2026

This notice covers the simse websites — simse.dev, the developer portal at platform.simse.dev, and the status page. It says exactly what we store in your browser and why.

This notice is the authoritative statement of what simse stores in your browser. Where another simse document summarises cookies or browser storage, it is a summary of this notice; if the two differ, this notice governs and we correct the other one.

It covers what our own code writes. It does not itemise the small housekeeping entries the web framework our pages are built on writes for itself — remembering your scroll position between pages, for instance. Those carry no identifier, are never sent to us, and go when you close the tab.

The short version. We set four cookies, and every one of them is needed to run the service: to keep you signed in, to protect the sign-in flow, and to record your cookie choice. We run no advertising, no cross-site tracking, no analytics cookie and no tracking pixel. Two third parties can run scripts on our sites: Stripe's payment library, on the pages where you pay, and — only if you allow analytics — Cloudflare Web Analytics on simse.dev, which sets no cookie (Section 2). We also keep a handful of preferences in your browser's local storage. Those are not cookies, and your browser never sends them to us on its own; the app reads one of them — your assistant settings — and sends it with your prompts. Section 3 lists them all.

Schedule A — Entity particulars

These are the only blanks in this notice. Everything else is decided. Each is completed at publication, together with the effective date above.

Wherever this notice says "we", "us" or "simse", it means the entity named at A-1. Our privacy contact is privacy@telor.dev.

1. The cookies we set

All four are first-party cookies on simse.dev and its subdomains.

All four — session, refresh, g_oauth_state and cookie_consent — are strictly necessary: the service does not work without them, so we do not ask for consent to set them.

We previously set a fifth, plan_intent, which remembered which plan you had clicked so the choice survived sign-up. It was a convenience rather than a necessity, which meant it was not exempt from consent — so we removed it rather than ask you to accept a cookie for a pre-selected plan card. Nothing replaced it.

HttpOnly means scripts on the page cannot read the cookie. Secure means it travels only over HTTPS. SameSite=Lax means the browser does not attach it to cross-site requests that could act on your behalf.

Blocking or clearing session and refresh signs you out, and you will not be able to sign back in while they are blocked.

We do not set a cookie that identifies you across other websites, and we do not combine any of these with data from anyone else.

2. The third parties that load on our sites

Stripe. On the checkout page and the billing-settings page, we load Stripe's payment library so your card details go straight to Stripe and never touch our servers. Stripe sets its own cookies from those pages, for fraud prevention and to keep the payment form working. Those cookies are Stripe's, set under Stripe's own privacy policy, and they are set only on the pages where you are paying.

Cloudflare Web Analytics — only if you allow it. Cloudflare carries every request to our sites. If you allow analytics in the cookie banner on simse.dev (Section 4), Cloudflare adds its Web Analytics script to the simse.dev pages it serves you. The script is loaded from static.cloudflareinsights.com. It measures how long each page took to load and reports those timings, with the page's address and the address of the page you came from, to Cloudflare at /cdn-cgi/rum on the same site. We use the result to see, in aggregate, which pages are visited, where visitors arrive from, and how quickly pages load. It sets no cookie and writes nothing to your browser's storage. Cloudflare states that it collects only timing metrics and does not track individual visitors across the sites it serves.

It does not run:

• until you have allowed analytics, and not at all if you do not;
• if your browser sends a Global Privacy Control signal, whatever you chose;
• on the checkout and billing-settings pages, where Stripe's payment library loads — those pages carry no third-party script but Stripe's; or
• on platform.simse.dev or the status page, which do not ask for analytics consent.

A rule at Cloudflare's edge enforces this. It switches the script off for every page request that does not carry your current "allow" answer, and for every request to a payment page, so the script is never delivered in those cases, rather than delivered and then held back. If you move to a payment page without a full page load, the payment form reloads the page before Stripe's library loads, so the script is gone before the card fields appear.

Cloudflare Zaraz is switched off. Zaraz is Cloudflare's loader for other vendors' tags. It ran on our pages until 27 September 2026 without loading any tag (Section 10). We switched it off rather than ask you to consent to a tool we do not use.

Nothing else. The pages of simse.dev and platform.simse.dev are served with a content security policy — a header that tells your browser what it is allowed to load, and blocks the rest. It works one way for frames and images and a different way for scripts, and the difference is worth stating rather than rounding off.

Frames and images are restricted by origin, and the browser enforces that list. On simse.dev a frame may come only from our own pages, from api.simse.dev, or from Stripe's payment origins; an image only from our own pages, from our media CDN at cdn.simse.dev, from api.simse.dev, or inline in the page itself. On platform.simse.dev the corresponding lists hold no third-party origin at all. Nothing outside those lists can open a frame or load an image on either site.

Scripts are restricted by trust rather than by origin. Every script we ship carries a one-time token generated fresh for each page load, and a browser that implements this part of the standard runs no script that lacks one — so a script tag injected into our HTML by someone else does not execute. Browsers that do not implement it fall back to allowing scripts from our own origin, which is weaker but not open. Scripts that our own code then loads deliberately inherit that trust, which is how Stripe's payment library loads at all. One party can add a script that runs without our code loading it: Cloudflare, which delivers the page. When you have allowed analytics, it adds its Web Analytics script after the page leaves our servers and gives it a token the page's policy accepts, which is how that script runs. The limit of that design, stated plainly: it stops a script smuggled into the page, and it does not by itself stop our own code from loading a script from a new origin. What keeps that from happening is the code we write and review, not the header — and today Stripe's payment library and, if you have allowed analytics, Cloudflare Web Analytics, both named above, are the only third-party scripts that load anywhere on our sites.

The status page sends the same kind of header, and it loads nothing from anywhere else: no third-party script, no third-party frame, no third-party image, no font network. It sets no cookie of its own, and the only thing our code keeps in your browser there is the shared theme preference in Section 3 (alongside the framework housekeeping noted at the top of this notice).

Our fonts are served from our own domain on every surface, not from a font network.

There is no Google Analytics, no advertising tag, no social-network button, no session-replay recorder and no error-reporting script on any simse page.

3. What we store in your browser besides cookies

Some settings are kept in your browser's local storage rather than in a cookie. Local storage is never attached to a request — the browser does not send it to us on its own. One entry is sent by the app itself: simse:chat-settings. The app reads it and sends what it holds with your prompts, because those are settings for the answer you are asking for. Where the same setting also exists on your account, it is stored there separately and this copy is only a local mirror.

Clearing your browser's site data for simse.dev removes all of these. Nothing in the table is needed to keep your account working; you lose only the local preference.

4. The cookie banner

On your first visit to simse.dev we show a cookie banner. It records your answer in the cookie_consent cookie, across two categories:

• Functional — cookies that remember a preference. This category is empty: we set no functional cookie.
• Analytics — Cloudflare Web Analytics (Section 2). It uses no cookie. It is in the banner because it runs in your browser, and we run it only with your permission.

Nothing in either category runs until you have answered, and "Essential only" is offered as prominently as "Accept all". Your answer applies to simse.dev; platform.simse.dev and the status page run neither category.

If we change what a category covers, we ask again. Your answer is recorded with the version of these categories it was given under. An answer given under an earlier version is not permission for what a category covers now, so the banner asks again. The current version is 2, from 27 September 2026, when Analytics came to cover Cloudflare Web Analytics. Answers given before that date are not relied on for anything.

We did set one functional cookie, plan_intent, and it was not gated on your answer to the banner — it was written on a click whatever you had chosen. Rather than put a consent gate in front of a cookie that only pre-selected a plan card, we removed it. Nothing replaced it.

One thing this section does not cover, and Section 3 does: the preferences we keep in your browser's local storage are not cookies and are outside the two categories above. We do not ask for consent before writing them either. The browser does not attach local storage to requests; the one entry the app sends us, your assistant settings, travels with your prompts as part of them (Section 3). None of them records where you went or what you looked at, so they cannot report on you, but you should know they are there rather than infer from this section that your browser holds only the four cookies above.

What we commit to: nothing in the analytics or the functional category runs, and no cookie in either is set, unless you have allowed that category. Before we add anything to either category we will update this notice and ask you again.

To change or withdraw your answer, use "Cookie settings". It re-opens the same chooser the banner showed you, with your current answer selected, and the new answer replaces the old one immediately. If you withdraw analytics, the page reloads so that the script stops at once rather than on the next page you open. "Cookie settings" is in two places, so that it is one click from wherever you are:

• in the footer of every public page, under Legal; and
• signed in, under Account → Privacy → Cookies.

Deleting the cookie_consent cookie in your browser also works — the banner then asks again on your next visit — but that was the only route we offered until 20 August 2026, and it was not a fair one. Withdrawing consent has to be as easy as giving it, and clicking a button in a banner is not comparable to finding a named cookie in browser settings. The footer link is the fix, and we are naming the gap rather than quietly closing it.

5. Do we measure anything?

Yes — on our servers, and, if you allow it, in your browser through Cloudflare Web Analytics. Neither uses a cookie.

We record product and usage events on our servers — which API calls a request made, how much of your plan you have used, and aggregate product behaviour. That happens on our side of the connection, from requests you make while signed in. None of these events is collected by code running on your device.

The analytics service and the warehouse behind it are ours and run in our own cluster. One third party holds a copy, and we would rather name it than let that sentence imply otherwise: the warehouse is backed up off-site to Cloudflare object storage, so Cloudflare holds a copy of these events, as our backup provider. That is a storage destination only — Cloudflare does not query, analyse or otherwise use the data — and Cloudflare is a contracted sub-processor, listed in the Sub-processors list. No advertising network, analytics vendor or data broker receives these events, and we send them to no one else.

In your browser, only with your permission. If you allow analytics, Cloudflare Web Analytics reports the page you opened, the page you came from and how quickly it loaded (Section 2). That goes to Cloudflare, not into our warehouse, and we see it only as aggregate figures — page views, referring sites and load times — in Cloudflare's dashboard. Cloudflare holds those measurements for us under its data processing addendum, for the look-back period its Web Analytics service provides, and we do not copy them out of it.

What we keep and for how long is in the Privacy Policy, not here.

6. Email

Our emails carry no tracking pixel and no click-tracking that we add. We do not put an invisible image in a message to see whether you opened it.

7. Previews and sandboxes

Inside the preview pane, a preview is sandboxed. When you open a preview of something built in simse, it runs in the pane in a sandboxed frame on a separate, opaque origin. Your simse cookies are not sent to it — our gateway strips the entire Cookie header before the request reaches the sandbox — and the frame has no cookie store, no local storage and no indexed database of its own. Code running in a preview inside the pane cannot read your session.

Opened directly in a tab, it is sandboxed too. A preview's address is a page on api.simse.dev, and every response from it now tells your browser to treat the page as a sandbox on an opaque origin, wherever it is loaded. Code in a preview opened in its own tab therefore cannot send requests that your browser signs with your session cookie. Until 28 September 2026 that was not so: a preview opened directly was an ordinary page on api.simse.dev, whose code could send requests as you, and until 27 September the preview pane had an "open in new tab" link that did exactly that (Section 10).

8. Do Not Track and Global Privacy Control

We do not sell personal information. We do not share it for cross-context behavioural advertising or targeted advertising. We set no advertising cookie and no analytics cookie.

So a Do Not Track header, or a Global Privacy Control signal, has no sale and no sharing on our sites to opt out of. Every cookie we set is strictly necessary (Section 1), so there is no non-essential cookie for either signal to suppress.

We do not check either signal before writing the browser-storage keys in Section 3, and those are not strictly necessary — they are preferences, and the service works without them. We are naming that rather than leaving you to infer from the paragraph above that nothing else is written. What makes them harmless is not that we asked: it is that none records where you went or what you looked at. The browser never attaches local storage to a request. The one entry the app does send, your assistant settings, travels with your prompts (Section 3) and is handled as part of them — the AI Transparency Notice says where they go.

Global Privacy Control switches Cloudflare Web Analytics off. If your browser sends it, the script does not run on any page, whatever you chose in the banner. Do Not Track does not have that effect: the standard was abandoned before it was finished and no law we are subject to requires it to be honoured. Use the banner, or Global Privacy Control, instead.

If we ever set storage that reports on your behaviour, we will honour these signals for it, and we will say so here before that storage ships.

9. Controlling cookies yourself

Every major browser lets you see, block and delete cookies, and lets you clear a single site's storage. Those controls work on our sites the same as anywhere else. Two consequences worth knowing:

• Blocking cookies for simse.dev means you cannot sign in.
• Clearing site data signs you out and resets the local preferences in Section 3. It does not touch anything held on your account.

10. Changes

If we add a cookie, add a third-party script, or change what one of them does, we update this notice before the change ships and record it below.

11. Contact

Questions about this notice, or about anything stored in your browser by simse: privacy@telor.dev.

Related documents: the Privacy Policy, the Sub-processors list, and the AI Transparency Notice.