Zero-PII architecture: how identity without personal data works

Position note: this page describes an architecture we build and advocate — read it as an engineering explainer with an acknowledged stake, checked against the same standard we apply to vendors: every claim is verifiable against our published inventory.

Edtech privacy debates usually argue about promises: who data is shared with, how it's secured, when it's deleted. This page is about the move that makes most of those arguments unnecessary: designing the system so the personal data never exists in it. Not minimized, not encrypted, not hashed — absent. A breach of what isn't there discloses nothing; a subpoena for it returns nothing; a bankruptcy can't sell it; an AI pipeline can't train on it.

Why "protected" is weaker than "absent"

Re-identification research put the empirical floor under this argument decades ago: Latanya Sweeney showed (2000) that ~87% of Americans are uniquely identified by just ZIP code, birth date and sex; Narayanan and Shmatikov (2008) de-anonymized "anonymous" Netflix histories against public data. The lesson generalizes: rich data about identifiable people resists safe handling — every promise layered on top (access controls, encryption, contracts) reduces risk multiplicatively but never to zero, and children's data deserves the zero. Regulators have converged on the same direction from the legal side: data minimization is a mandate, not a virtue — COPPA's §312.7, GDPR's Article 5(1)(c), the UK Children's Code's minimisation standard, Australia's APP 3. Zero-PII is minimization taken to its logical conclusion.

The pattern, piece by piece

Identity = class code + generated pseudonym. A teacher creates a class and receives a short code (like MAPLE-42). The system generates each student a pseudonymous identity (BlueTiger42) — generated, not chosen, so no child encodes their real name, and no free-text field exists to leak one.

The roster lives offline. The mapping from BlueTiger42 to an actual child exists in exactly one place: the teacher's paper (or locally-held) roster. The service cannot produce the mapping because it never had it — which converts "we won't disclose" into "we can't."

Authentication without recoverable secrets-about-people. Students authenticate with picture-sequence secrets (age-appropriate, nothing personal encoded); teachers with username + password + one-time printed recovery codes. No email anywhere means no password-reset email, which is the one real UX cost of the pattern — paid deliberately, because an email address is the master key that links a person across the entire internet.

No shadow identifiers. The discipline that separates real zero-PII from marketing zero-PII: no third-party analytics or ad SDKs (each one imports persistent identifiers — COPPA counts them as personal information), no device fingerprinting, no IP retention in application data, and no hashed identifiers — a hashed email is a pseudonym pretending to be nothing, and it fails the honesty test (the hashed-emails myth).

What remains is game state. Skill progress, stars, streaks, review schedules — pseudonymous records that let a child continue on any device and let a teacher see who needs help. The worst-case breach disclosure: some animal named wizard is good at spreadsheets.

The honest costs

Symmetry demands the trade-offs be listed: lost credentials need human paths (teacher resets a student's secret from the roster; printed recovery codes for teachers — lose those and account recovery is genuinely hard, by design). Some features are excluded on principle — child-to-child messaging, user-generated public content, photo avatars: each would either create personal data or an unmoderatable channel. Parent visibility routes through the teacher, who holds the mapping. And the vendor gives up data leverage — no email list, no behavioral profiles, no "insights" product. We'd argue that last cost is the point: a children's product whose business requires the data your checklist worries about has a conflict no policy wording resolves.

Questions this pattern answers well

Run the eleven questions against it: the inventory (Q1) is enumerable in a sentence; school consent (COPPA) has almost nothing to attach to; offshore-hosting concerns (APP 8, Victoria's IPP 9) shrink when nothing personal crosses the border; deletion (Q8) is genuinely complete because nothing links records to a person elsewhere; and the breach paragraph (Q11) is one line. The pattern doesn't make a vendor trustworthy — it makes trust less necessary, which is the stronger property.

In practice (for evaluators)

Test the claim structurally: ask a zero-PII claimant "what happens when a teacher forgets their password?" — the honest architecture has a slightly awkward answer (printed codes); a smooth "we email you a reset link" reveals the email they claimed not to have.
Ask for the complete inventory, not the policy — a real one fits on a page and enumerates every field (ours).
Check the runtime: open devtools on the product's pages; third-party requests are shadow identifiers regardless of policy prose.

References

Sweeney, L. (2000). Simple demographics often identify people uniquely. Carnegie Mellon, Data Privacy Working Paper 3.
Narayanan, A., & Shmatikov, V. (2008). Robust de-anonymization of large sparse datasets. IEEE Symposium on Security and Privacy.
Article 29 Working Party (2014). Opinion 05/2014 on Anonymisation Techniques — pseudonymisation is not anonymisation.
GDPR Art. 5(1)(c); COPPA Rule §312.7; UK ICO Age Appropriate Design Code (2020), standard 8; Australian Privacy Principle 3.

© Glu IO Pty. Ltd. — Wiz Kids (wiz.kids). Link freely; republication requires permission — see terms. Found an error in our reading of the research? We correct fast: tell any teacher piloting Wiz Kids.