This notice explains what happens to personal data when a parent or child uses BrainLevelz, and when a school administrator or teacher uses the school dashboard. The data controller is VMtechy.com, contactable at nathan@vmtechy.com.
A child cannot sign themselves up. Only a signed-in parent account can create a child's login (username + PIN), from the Parent Dashboard. This is deliberate: it means a child's account only ever exists because their parent set it up, which is BrainLevelz's basis for parental consent to processing that child's data: there's no separate consent flow to design around because the parent is the one performing the account-creation action itself. A school join code only links a parent's own account to a school; it does not let a school create child accounts directly.
| Who | Data | Why |
|---|---|---|
| Parent | Email address, password (stored hashed, never in plain text), display name, which school (if any) they're linked to | To operate the account and dashboard |
| Child | Username, PIN (never stored as typed, see "How a child's PIN is protected" below), display name, chosen avatar (an emoji), quiz progress (XP, streaks, per-topic scores, badges earned, last ~20 quiz results, which reward tiers have been marked given) | To run the revision app and show progress to their parent |
| Anyone in a Compete match | Their child's display name, avatar, and live score are visible to every other family in that same match while it's running (and in the final standings), one of two places data is visible outside a single family, by design, since it's a shared multiplayer round (homework, below, is the other) | To show a live leaderboard |
| A child whose school sets homework | Their written homework answers and any photos they submit of their work, plus their display name, are visible to the one teacher who set that homework, for pupils in that teacher's own class only, never to any other teacher, and never alongside the school's own aggregate report (see the DPA for the school-facing version of this boundary). Separately, so that a teacher can build a class in the first place, a teacher at the school can see a list of that school's pupils: display name, username and avatar only, never anyone's answers, scores or progress | So a teacher can set and mark schoolwork |
| Everyone | Standard technical data any web request carries (IP address, browser type), used only transiently to serve the page and isn't stored in the app's own database | Basic web operation |
We don't run analytics, ad tracking, or any third-party script beyond the Supabase client itself and Google Fonts (loading the app's typefaces from Google's font CDN sends the visitor's IP to Google, the same as any site using Google Fonts). No data is sold or used for advertising.
A child's PIN is never stored as the four-to-six digits they type. It's combined with their username into a longer string before being handed to Supabase Auth's standard password hashing (the same mechanism protecting parent passwords), so what's actually stored is a cryptographic hash, not the PIN itself. That said, a short numeric PIN is a deterrent suited to "keep a sibling out," not a high-security credential. See the README's security notes for the full reasoning.
All app data lives in a Supabase project (Postgres database, authentication, and file storage), which acts as our data processor. Row Level Security (enforced by the database itself, not just the app's code) restricts a parent's account to only ever reading or writing their own family's data.
Today, data is kept until someone deletes it: there's no automatic expiry. Concretely:
Under UK GDPR (and equivalents elsewhere), a parent can, on behalf of themselves or their child:
If what the app collects or does with data changes, this page will be updated and the "last updated" date at the top will change accordingly.
VMtechy.com · nathan@vmtechy.com