Design memo: why we sign children out after 45 idle minutes

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

This feature began as a bug report from a classroom. A student came back to a computer that looked signed in, clicked a lesson, and got dumped to the class-code screen with no explanation — their session had quietly expired server-side while the page still showed their wizard. The fix could have been a longer session. We went the other way, and the reasoning is worth documenting because "how long should a child's login live?" is a question every classroom product answers, mostly by not thinking about it.

The premise: classroom computers are shared by default

Consumer software assumes one person per device and optimizes for never logging you out — sessions that live for months are the industry norm because friction costs engagement. Classrooms invert every one of those assumptions: the next user of this machine is not you, arrives within hours, and is a child. A lingering session on a shared device is an open door with the previous child's name on it — anything done through it (progress spent, work altered, in any richer product messages sent) is done as them. The zero-PII architecture caps the damage in our case — a stale Wiz Kids session exposes a pseudonym's game progress, not an identity — but the habit children form on our product transfers to their email, their documents, everything. We're often the first login of a child's life; defaults teach.

The design details that matter

• 45 idle minutes — comfortably longer than any lesson activity (no child mid-task gets cut), comfortably shorter than a lunch period plus the next class arriving. Activity resets it; it's an idle timer, not a shift clock.
• The sign-out explains itself. The child returns to a friendly note: "You were away a while, so we signed you out to keep your wizard safe — smart wizards never stay signed in on a shared computer." This is a standing rule of ours: surprising system behavior must be explained in-fiction, at the moment it's met. Security that behaves mysteriously trains children that computers are capricious; security that explains itself trains the reasoning.
• Graceful everywhere: the same path handles expiry mid-lesson and returning stale tabs — never a dead-end error, always the explained landing.
• A one-click "I'm done — switch wizard!" button makes deliberate sign-out effortless, because the deeper goal is children signing out themselves; the timer is the backstop, not the lesson.

The mechanic became curriculum

The best part came later: the auto-signout turned out to be a teachable artifact. Our safety realm now includes a lesson built directly on it — sessions as doors, why apps close them ("so a stranger at the same computer can't be YOU"), why you close them yourself on shared machines, one-wizard-one-login, and what to do when you find someone else's account open (close the door without reading the diary). Children learn the concept from a behavior they've already personally experienced — the UK Children's Code's high-privacy-defaults philosophy, made legible to a nine-year-old by the product enacting it in front of them.

The trade-off, priced

The cost is real: a child returning after 50 minutes re-enters a class code and picture-secret — perhaps 20 seconds, a few times a week. Against it: every stale-session risk on every shared machine, and the daily rehearsal of the sign-out habit. In a single-user consumer product this trade might land elsewhere; on shared classroom hardware with children, we think 20 seconds is among the cheapest security anyone buys. (For evaluators: "what happens to an idle child session on a shared computer?" is a genuinely revealing vendor question — many products' honest answer is "nothing, for months.")

References

• UK ICO (2020). Age Appropriate Design Code — standards on default settings and children's best interests, the regulatory articulation of defaults-as-teaching.
• OWASP Application Security Verification Standard — session-timeout guidance for shared-environment applications (the security-engineering baseline).
• The in-product lesson this memo describes: the Closed Door (sessions & shared computers), Wizard Safety realm.

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