Design memo: why Wiz Kids collects no personal data at all

Design memos document real decisions in Wiz Kids and the research behind them.

Wiz Kids holds no child's name, email, birthday, photo, or location — not encrypted, not hashed, absent. Identity is a class code plus a generated pseudonym (BlueTiger42); the mapping to a real child lives on the teacher's roster, which we never see. The architecture page explains the pattern for evaluators; this memo records the decision — including what it cost and the arguments we had with ourselves.

The reasoning, compressed

Every privacy promise is a liability held open: data that exists can breach, be subpoenaed, be sold in a bankruptcy, be repurposed by a future owner with different values. The re-identification literature (Sweeney; Narayanan & Shmatikov) taught us that "anonymized-ish" doesn't hold, and the edtech breach record keeps teaching everyone the rest. For a children's product, we wanted the stronger property: make the worst case boring. Our worst-case breach discloses that some pseudonymous wizard is good at spreadsheets. That's not risk management; it's risk deletion — and it's also just minimisation law taken at its word rather than its minimum.

What it cost us — the honest ledger

The decision was not free, and the memo exists partly to record that we knew:

• No password-reset email. The single biggest UX price. Teachers get printed one-time recovery codes; students get picture-secrets the teacher can reset from the roster. Losing everything is genuinely possible in a way "click forgot password" products don't have. We pay it because the email address is the master key that links a person across the internet — the one field that unravels the whole property.
• Features excluded on principle: child-to-child messaging, public user-generated content, photo avatars — each would create either personal data or an unmoderatable channel. Some of these would be fun. They're out.
• No growth machinery. No email list, no re-engagement campaigns, no behavioral ad audiences, no "insights" upsell to schools. The commercial cost is real and permanent.
• Parent visibility routes through teachers, who hold the only mapping. Slower, more human, occasionally annoying.

The objection we took most seriously

"You'll rebuild it later anyway — every startup does." The pull is real: growth wants emails, investors want engagement funnels, support wants to identify users. Our answer is structural: the zero-PII property is load-bearing in the product's public commitments (our privacy inventory enumerates every field; this library's vendor-evaluation pages tell schools to check claims like ours in devtools), so reneging isn't a quiet schema migration — it's a public reversal of the thing we told schools to verify. We built the accountability trap on purpose and then stood in it.

Why we'd argue it generalizes

We hold a stake here, so calibrate accordingly — but the argument isn't really about us: a children's product whose business requires the data your procurement checklist worries about has a conflict no policy prose resolves. The question worth normalizing in procurement is not "how do you protect children's data?" but "why do you have it?" — a question with a checkable answer.

References

• Sweeney, L. (2000). Simple demographics often identify people uniquely. CMU Data Privacy Working Paper 3.
• Narayanan, A., & Shmatikov, V. (2008). Robust de-anonymization of large sparse datasets. IEEE S&P.
• GDPR Art. 5(1)(c); COPPA §312.7; UK Age Appropriate Design Code standard 8; Australian Privacy Principle 3 — minimisation as mandate, the legal floor this decision exceeds.

© 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.