Privacy
The course keeps your work so that you find it again on any device you sign in from. This page says exactly what that means, because a product that stores a person’s work owes them a plain account of it rather than a policy written to be survivable.
encryptorium.com/privacy covers the marketing site and the free book. It does not cover this course, and this page does not cover those.
What is held, and why
Your GitHub account. Signing in with GitHub gives the course three things: your numeric GitHub account id, your username, and your display name if you have one. The numeric id is what every stored row is keyed on, because a GitHub username can be changed and the old one can then be claimed by somebody else; keying on the username would eventually hand one person’s work to another. The username and the display name are used to greet you and to label an export. No email address is requested and none is stored. No repository, organisation or private-profile access is requested.
Your work. The course stores what you write and what the tests make of it:
| What | Why it exists |
|---|---|
| The source of any exercise file you edit | So you find your own code again |
| The source of any printed listing you edit | The same |
| Which functions your test runs passed, failed, or were blocked on | The progress the dashboard reports |
| Which chapters you have marked as read | The reading half of the same dashboard |
| A count of runs and passes per calendar day | The streak |
| Which chapters you selected | So the journey follows your selection |
| What you write in an exercise’s answer box, and whether you revealed its worked answer | So your answer is still there when you come back |
| Whether you told us you are here to read rather than to write | So the course leads with your reading and stops pulling in chapters for code you are not writing |
That is the whole of it. There is no tracking of what you read, how long you spent, where you scrolled, or which pages you opened. Chapter completion is either measured from a real test verdict or declared by you pressing a button; nothing is inferred from behaviour.
Your code runs in your browser, not on our servers. Python executes inside your own tab, in a WebAssembly sandbox. Nothing you write is executed anywhere else, and nothing you write is read by anyone else: there is no sharing, no publishing, and no route that serves one account’s rows to another.
Where it is processed
| Service | What it handles |
|---|---|
| Vercel | Hosting, and standard server logs (address, URL, timestamp, user agent) |
| Neon (now part of Databricks) | The database holding the rows above |
| GitHub | Sign-in, at the moment you sign in |
| Resend | Waitlist sign-ups, forwarded as mail and not stored |
The course also loads Vercel Web Analytics and Speed Insights, which measure aggregate page views and page performance. Neither uses cookies, and neither can be tied to an individual visitor.
Where the data physically sits, stated honestly. The database and the course’s server code are both in the United States, in Amazon’s us-east-1 region in Northern Virginia, and that is where your rows are written. It would be wrong to tell you they never leave it. Vercel documents that its backups are “globally replicated for resiliency against regional disasters” and that “our core database and data plane is a globally replicated database”; selecting a region for the course’s server code does not move static files, which Vercel deploys to every region, and its routing layer runs everywhere regardless. Neon publishes no data-residency commitment at all: its regions page does not use the word.
So if you are in the EEA or the UK, your data is transferred to the United States, and the protection for that is contractual rather than geographic. That is the ordinary arrangement and it is worth naming rather than implying. Vercel’s data processing addendum and the Databricks addendum that now covers Neon both incorporate the European Commission’s Standard Contractual Clauses (Decision 2021/914), with the UK Addendum and a Swiss variant. Resend’s addendum does the same. Those are the documents that govern the transfers, and they are public.
One cookie is set, lab_session. It holds your GitHub account id, username and display name, signed so it cannot be altered, and it lasts thirty days. It is not an analytics cookie and it is not shared with anyone.
The waitlist
The form on the public pages takes an email address and forwards it to us as mail through Resend. It is not written to the database and it is not added to a mailing list. Ask us to delete it and we will, at contact@encryptorium.com.
How long it is kept
Your work is kept while you use the course. An account that has not written anything for 24 months is deleted in full, without notice, because the alternative is holding a stranger’s abandoned work indefinitely.
You can delete everything yourself at any time, from your account page, and it is immediate.
Taking a copy, and deleting it
Both are on your account page and neither needs to go through us.
Export gives you a JSON file with every row the course holds for you, each with the time it was last written.
Delete removes every row, permanently, and there is no copy kept afterwards. It does not sign you out and it does not close your GitHub account; you can carry on working and the course will start recording again from empty.
Limits on what you can store
Each stored value is capped at 64 KB and each account at 8 MB, which is several times what working through the whole book produces. If a save is refused, the reason says so and your text stays on screen; nothing is silently dropped.
Changes, and how to reach us
This page is dated by the version of the site you are reading. Questions, corrections, or a request we handle by hand: contact@encryptorium.com.