Cookies and Browser Storage
Every cookie and storage entry, and why there is no consent banner.
Effective date: 4 September 2026 Last revised: 4 September 2026
This is the companion to section 10 of the Privacy Policy. It exists because "do we need a cookie banner" is a question that deserves a worked answer rather than a sentence, and because the honest answer has two halves that are easy to conflate.
The two halves, kept apart
1. CourseLite's own code sets no cookie, and CourseLite's API reads none.
Verified rather than assumed. There is no Set-Cookie header anywhere in functions/, no document.cookie anywhere in src/, and no route that reads a cookie header. The API authenticates with a bearer token that our own JavaScript attaches to each request. This is why the API can safely answer Access-Control-Allow-Origin: * — there are no credentials for a browser to attach automatically, so cross-site request forgery is structurally inapplicable rather than defended against. (It is also why introducing cookie authentication would be a change of threat model rather than a convenience — CLAUDE.md rule 22.)
2. A cookie is nevertheless set on courselite.org.
Clerk's sign-in library, which runs inside our page, sets a session cookie on our own domain so that you stay signed in between page loads. We chose to ship that library, so it is our disclosure to make even though we do not write the cookie ourselves.
Saying only the first half would be technically true and misleading. Both are below.
1. Cookies
| Cookie | Set by | Where | What it is for | Roughly how long |
|---|---|---|---|---|
__session | Clerk's library, running in our page | courselite.org — a first-party cookie | Keeps you signed in. It carries the short-lived session token our API verifies | A session token's lifetime; refreshed while you are using the app |
__client | Clerk | Clerk's own sign-in domain | Identifies your browser to Clerk so it can issue session tokens. Marked Secure and HttpOnly, so no script can read it | Clerk's own period |
| Cloudflare's security cookies | Cloudflare | courselite.org | Bot and abuse protection, including the Turnstile challenge that can appear at sign-up | Cloudflare's own periods |
| Stripe's cookies | Stripe | Stripe's own checkout and portal pages, not ours | Running checkout, and Stripe's own fraud prevention | Stripe's own periods |
| Google's cookies | Google's own pages — the sign-in screen and the file picker | Signing you in to Google and running the picker | Google's own periods |
Names and lifetimes for `__session` and `__client` are from Clerk's published documentation on 2026-09-03. Exact attributes are Clerk's to change; what is ours is the decision to ship it and the duty to say so.
There is no cookie for analytics, advertising, attribution, personalisation or cross-site tracking, first-party or third-party. There is no advertising network, no ad SDK, no attribution provider, no data broker and no third-party analytics SDK anywhere in this product. That is verifiable from the subprocessor list, which is generated by reading the code.
2. Browser storage, which is not cookies
None of the following is ever sent to a server automatically the way a cookie is. It stays on your device, and another website cannot read it.
| Where | What | How long |
|---|---|---|
localStorage | A random analytics session id, created with crypto.randomUUID() | Until you clear site data |
localStorage | The chat mode you last picked, per course | Until you clear site data |
localStorage | That you dismissed the onboarding checklist | Until you clear site data |
localStorage | Your best time in the Match and Memory flashcard modes, per set. The screen says "on this device" because that is where it lives — it is not an account fact and it is not on our servers. *Where you got to in a set is on our servers*, and that is described in the privacy policy §3.6 | Until you clear site data |
sessionStorage | Your current chat conversation, per course. For the chat on a course page and beside an assignment, this is the only place it exists. Chats in the course workspace are also saved on our servers — the last 10 per course — which changed on 2026-09-04; see the privacy policy §3.6 | Until you close the tab |
sessionStorage | Whether a panel is open, whether the extension was detected, dismissed banners, the page you came from | Until you close the tab |
chrome.storage.local (extension) | A file you exported yourself, held until it is read; and the sign-in session the extension's Clerk library caches | Until read / until you sign out |
indexedDB (extension) | A random installation id, used for anti-abuse | Until you remove the extension or clear its data |
The analytics session id is random, and that is load-bearing. It is not derived from your machine: not a hash of your device, your fonts, your canvas rendering, your audio stack, your WebGL, your battery, your screen geometry, your history, or your installed extensions. None of those is collected, by design and not by omission (CLAUDE.md rule 17). If you clear your site data you become a new visitor to us, and that is the intended behaviour rather than a hole somebody forgot to plug. Once you are signed in, events are attributed to your account and this id is not sent at all.
3. The extension's cookies permission
The CourseLite browser extension declares Chrome's cookies permission, and Chrome shows that on the install dialog, so it deserves a straight explanation.
What it is for. Reading one cookie, on courselite.org only: the sign-in cookie our own website already set. That is what makes signing in on the website also sign you in in the extension, instead of asking you to do it twice, and what makes signing out take effect in both.
Who uses it. The sign-in library (@clerk/chrome-extension), through Clerk's supported syncHost mechanism. Our own code calls chrome.cookies exactly zero times.
What it cannot reach. Any cookie belonging to any other site — your university, your Canvas, your email, your bank. A cookie read requires a host permission for that URL, and the only host permissions this extension holds are for courselite.org, Clerk's sign-in host, and Google's API hosts. It holds no host permission for any Canvas domain at all. The browser enforces this; it is not a promise about our code's good behaviour.
4. The determination: why there is no consent banner
Setting out the reasoning rather than the conclusion, so a lawyer can disagree with a step rather than with a verdict.
- Every cookie in section 1 is strictly necessary or is set on somebody else's page.
__sessionand__clientdo one thing: keep you signed in to a service you asked to sign in to. Cloudflare's are security. Stripe's and Google's are set on Stripe's and Google's own pages, under their policies, when you go there. - Everything in section 2 is local preference or local state, stored on your device, not transmitted automatically, and not readable by anyone else.
- Nothing anywhere is advertising, profiling, or cross-site tracking. There is no such code in the product to consent to.
- Under the regimes that gate storage access on consent — the ePrivacy Directive as implemented across the EU/EEA and the UK PECR — the usual exemption is for storage strictly necessary to provide a service the user explicitly requested. Our reading is that everything above falls inside that exemption or belongs to a third party's own page.
- Therefore no consent banner is proposed. A banner whose only real option is "Accept" teaches people to click past banners, and the next one they click past will be one that mattered.
This is our reasoning and not a legal conclusion. It has not been reviewed by a lawyer, and step 4 in particular is exactly the kind of step that turns on a jurisdiction.
The weakest link, named rather than hidden. It is step 4, and specifically the analytics session id in
localStorage. That id is not required to deliver the product; it is required to count a logged-out visit. A regulator looking at this determination would push on exactly that, and we would rather point at it ourselves than let you find it. If the answer turns out to be that it needs consent, the fix is small and already known: do not create the id until consent is given, and count fewer logged-out visits.
5. Controlling it yourself
- Clear site data in your browser for courselite.org. You will be signed out, and the analytics session id and stored preferences will be gone. The product still works; you sign in again.
- Block cookies for courselite.org and you cannot stay signed in, because the session cookie is how staying signed in works.
- Remove the extension and its installation id and cached session go with it.
- Revoke Google access at Third-party apps & services at any time.
None of these deletes what CourseLite stores on the server. That is deleting your account, which is a different thing.
6. Contact
| Questions about this page | support@courselite.org |
| Everything else | support@courselite.org |