A classroom computer is shared. There is one local Chrome profile owned
by the room, teachers sign into websites, and nobody signs into Chrome.
BrowserSignin=0 stops Chrome asking who is using it, with SyncDisabled
set explicitly alongside it so the intent is in the file rather than
implied. BrowserAddPersonEnabled=false stops new profiles and
ProfilePickerOnStartupAvailability=1 stops the picker.
BrowserGuestModeEnabled=false is the answer to the other profile
switching entry point. Guest is the one that survives disabling add
person, and turning it off is the supported mechanism rather than hiding
UI. Guest is not the browsing model: the room needs one persistent
profile so the church YouTube login survives.
CookiesSessionOnlyForUrls scoped to [*.]wonderink.org, which covers
app.wonderink.org and every other subdomain, so a teacher's Wonder Ink
session does not outlive them. BackgroundModeEnabled was already false,
which is what lets a session actually end.
Every policy name was checked against the strings of the installed
Chrome 152 binary, with deliberately invalid names as a control so the
check is known to discriminate.
Two things are recorded honestly in docs/browser.md rather than claimed.
The avatar button stays in the toolbar — screenshotted with and without
these policies, it is in the same place either way; what changes is that
nothing behind it can create or switch a profile, and no Chrome 152
policy removes the button. And whether session-only cookies actually
sign Wonder Ink out is unverified: it needs a real Wonder Ink login,
which this machine does not have, and three attempts to prove the
mechanism against a local site were inconclusive because the positive
control never worked. The endpoint procedure to settle it, including how
to tell a cookie session from a localStorage one, is written down.
Co-Authored-By: Claude Opus 5 <[email protected]>
