Cookie policy

A cookie is a small piece of text a website asks your browser to store and send back on your next request. This document covers cookies and anything comparable, including data kept in your browser’s local storage, which is not a cookie but is storage on your device and is treated the same way here.

It sits beside the privacy policy, which describes everything else we hold and why. Where the two overlap, they say the same thing on purpose.

Five cookies, and one entry in local storage. That is the whole list. Two of the five appear only if you do the particular thing they are for, so most of the time there are fewer than five on your machine and never more.

• The session cookie. Set by our authentication provider, Supabase, when you sign in. It is what tells the server on your next request that you are still you. Its name begins sb- and ends -auth-token. Without it there is no way to stay signed in from one page to the next, so it is strictly necessary in the literal sense of the phrase.
• The refresh cookie. Set alongside it and by the same provider. Access tokens are deliberately short-lived, so this is what lets the server quietly renew yours instead of signing you out every hour. It carries the same name prefix and is written back on every navigation that renews it.
• The current workspace cookie, ws. Ours. It holds the identifier of the workspace you last switched to, so that opening the product puts you back where you were. It is written only when you switch workspace or create one, it holds an identifier and nothing else, and it is read on the server to decide which workspace to load. If you belong to one workspace it never changes.
• The dismissed-checklist cookie, setup-dismissed- followed by a workspace identifier. Ours, and written only if you press the button that hides the “still to set up” list on your dashboard. It holds the single value 1. It is a cookie rather than something kept in your browser alone because the page is drawn on the server: without it on the request, the server would draw the list you just hid and the page would remove it a moment later, which is a worse experience than never offering the button.
• The connection cookie, social_oauth_nonce. Ours, set only at the moment you send yourself to Instagram, TikTok or another network to connect an account, and deleted the moment you come back, whether or not it worked. It holds one random value with no meaning outside that round trip, it is sent only to the address that handles the return, and it is what proves the account being connected is being connected by you, in this browser, rather than by somebody who copied a link. It lasts ten minutes.
• Your theme preference, in local storage. The value is light, dark or nothing. It is written by your browser and read by your browser, and it is never sent to us: it exists so a dark-theme page does not flash white before it loads. We could not read it if we wanted to, because it is never attached to a request.

Every cookie above is set only for people signing in, and the last two only for people who press a particular button while signed in. Reading the public pages of this site sets nothing at all.

The session cookie expires within hours and is renewed while you are using the service. The refresh cookie lasts longer, which is what keeps you signed in between visits, and it is invalidated the moment you sign out. The workspace cookie lasts a year unless you change workspace or clear it, and so does the dismissed-checklist cookie, which is what makes a list you hid stay hidden. The connection cookie lasts ten minutes and is normally gone in less than one: it is deleted as soon as you return from the network you were sent to.

Signing out clears the authentication cookies immediately, on the server as well as in your browser: the session behind them is revoked rather than merely forgotten.

Consent is required for storage that is not strictly necessary for a service you asked for. Every item in section 2 is necessary in that sense, and the longer list makes the case better rather than worse: two of them are how you stay signed in, one is which workspace you are looking at, one carries out an instruction you gave by pressing a button, one protects the connection you asked us to make, and the last never leaves your device. None of them profiles you, follows you to another site, or is shared with anybody.

So there is nothing here to consent to, and a banner asking you to accept cookies we are allowed to set regardless would be theatre. If that ever changes, the banner arrives in the same release as the cookie, and this section is rewritten to say what the new one does.

There is no analytics cookie, no advertising pixel, no tag manager, no session recorder, no chat widget and no social embed on this service. That is not an oversight we intend to fix quietly: it is a property of the product, and it is one of the few compliance answers here that is unambiguously simple.

Payment is handled by Stripe. If you open a payment or billing page hosted by Stripe, Stripe sets its own cookies under its own policy, on its own domain, for fraud prevention. That happens on Stripe’s pages rather than ours, and Stripe is a controller in its own right for it.

Every browser can block or delete cookies, and you can do that here without asking us. The consequence is worth stating plainly: blocking the two authentication cookies makes signing in impossible, because there is no other way for the server to recognise you on the next request. Blocking the connection cookie makes connecting a social account fail, on purpose: we would rather refuse than attach an account we cannot prove you asked for. Blocking only the workspace cookie is harmless and simply means you land on your first workspace each time, and blocking the dismissed-checklist cookie only means the setup list comes back.

Clearing local storage resets your theme to whatever your operating system prefers.

If the list in section 2 changes, this document changes with it and the date at the top moves. We will not add a tracking cookie and describe it here afterwards.

Questions about any of this go to hello@crestnote.com, the same address the privacy policy gives.