From an instructor running a shared lab: "Students rotate through the same machines. With no accounts, one student’s viewed-components and exam history bleed into the next session. How are we meant to run this?"
You have correctly identified the trade we made. The demonstration build stores everything in per-browser localStorage because the alternative is accounts and a server, and this build promises neither — that is what lets you evaluate it without a privacy or security review. The cost is exactly what you describe: on a shared machine, progress belongs to the browser profile, not the human.
Patterns that work in shared labs today, in order of preference: per-student OS logins (each gets an isolated browser profile automatically — most managed classrooms already have this); per-student browser profiles where OS logins are shared; or session-scoped work in a private window when persistence between sessions is not needed for that lesson. Clearing site data between rotations is the blunt fallback — it resets everything, including exam history.
For a cohort where individual records matter institutionally, that is the point where the contracted deployment is the right tool: progress and exam results post to your LMS/LRS inside your boundary, identity comes from your SSO rather than from us, and the shared-machine problem disappears because the machine is no longer the record. See the SCORM/xAPI thread for the shape of that.
This board is read-only — TaskFlight has no accounts and stores nothing on a server, so replies live on GitHub Discussions, where the conversation is public and moderated. Prefer email? Same address as always; useful questions get added to this board with identifying details removed.