Privacy by Design: The Principles We Build From
Why GDPR was our starting point, not a retrofit.
Lesson Commons was designed against EU data-protection law first. We did this not because we expected most of our users to be in the EU, but because the GDPR is the strictest mainstream framework available — build to it, and FERPA, COPPA, and most other regimes fall inside the lines. The alternative, building to the loosest applicable law and patching upward, produces software that treats privacy as a liability to manage rather than a property to design in.
Three principles do most of the work.
1. Data minimisation is the default, not the exception
The cheapest data to protect is the data you never collect. We start every feature by asking what the minimum personal data is that makes it work, and we collect only that. We do not collect geolocation, device fingerprints, browser fingerprints, or persistent advertising identifiers. We do not store raw IP addresses. Where a feature needs a network signal — for example, detecting account sharing — we use a salted, one-way hash that cannot be reversed back to an address, and we delete even that on a fixed schedule.
This is GDPR Article 5(1)(c) taken literally: adequate, relevant, and limited to what is necessary. It is also simply good engineering. Data you do not hold cannot be breached, subpoenaed, or mishandled.
2. The school is the controller; we are the processor
In GDPR terms, the data controller decides why and how personal data is processed; the data processor acts on the controller’s instructions. For student data, the school or teacher is the controller — they decide to run a class, what to assign, which students participate. Lesson Commons is the processor: we hold and process that data on their instruction and for their purposes, not ours.
This is not a labelling exercise. It dictates real boundaries. We do not repurpose student data for our own analytics, we do not sell or share it, and we do not train anything on it. Teachers accept a data processing agreement that states these limits plainly, in their own language, and the platform ships separate privacy policies for teachers and for students rather than one document that serves neither.
3. Don’t collect a child’s identity to teach them
The single most consequential privacy decision in the product is how students log in. Most platforms begin with a registration form: name, email, password, email verification. For minors that form is a compliance problem — collecting a child’s email address generally triggers parental-consent requirements under COPPA in the US and heightened obligations under the GDPR and national rules such as Spain’s LOPDGDD.
So we removed it. The teacher adds each student under a short display name (full legal names are flagged and discouraged) and the system auto-generates a six-character access code. To sign in, the student enters two codes — the teacher’s code and their own access code; there is no name to type, no email, no password, and no account-creation flow. The privacy notice appears on first visit in the student’s own language, and after one click they are working. Because we never ask for the email, we never have to defend collecting it. The friction we removed for teachers and the consent burden we removed for parents are the same decision viewed from two sides. We wrote about the onboarding experience in From Access Code to Working in Under a Minute.
Where this leads
These principles are not slogans; they have consequences you can inspect. The companion notes describe two of them: exactly what student activity we collect and what we refuse to, and how data subject rights — access, export, and erasure — are implemented as working features rather than promises in a policy.
This note is adapted from Lesson Commons’ internal architecture decision records. It describes design intent and current implementation; it is not legal advice. Schools remain responsible for their own data-protection obligations as controllers.
This document was written with the assistance of Claude (Anthropic). The author defined the purpose, audience, and main ideas, directed the editorial approach, and edited the final text.