ekklesiaandClaude Opus 5
0b2f99a853
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]>