feat: make Chrome a room appliance rather than somebody's browser

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]>

docs/browser.md

@@ -0,0 +1,118 @@
+# The classroom browser
+
+A classroom computer is a shared appliance, not somebody's laptop. There
+is **one local Chrome profile**, owned by the room. Teachers sign into
+*websites*; nobody signs into *Chrome*.
+
+## Policies
+
+All of these are in
+`/etc/opt/chrome/policies/managed/ekklesia-classroom.json`, and every
+name was checked against the strings of the installed Chrome 152 binary
+with deliberately invalid names as a control.
+
+| Policy | Value | Why |
+| --- | --- | --- |
+| `BrowserSignin` | `0` | Chrome never asks who is using it |
+| `SyncDisabled` | `true` | Explicit, though `BrowserSignin: 0` implies it |
+| `SigninInterceptionEnabled` | `false` | No "this account is managed" bubble |
+| `BrowserAddPersonEnabled` | `false` | No new Chrome profiles |
+| `BrowserGuestModeEnabled` | `false` | Removes the Guest entry point from the profile menu |
+| `ProfilePickerOnStartupAvailability` | `1` | No profile picker at startup |
+| `PasswordManagerEnabled` | `false` | No offers to save passwords |
+| `PasswordLeakDetectionEnabled` | `false` | No leak warnings |
+| `BackgroundModeEnabled` | `false` | Closing the last window really ends the session |
+| `CookiesSessionOnlyForUrls` | `["[*.]wonderink.org"]` | Wonder Ink should not outlive a teacher |
+| `DefaultBrowserSettingEnabled` | `false` | No default-browser prompt |
+| `PromotionalTabsEnabled` | `false` | No welcome tabs |
+| `MetricsReportingEnabled` | `false` | — |
+| `ShowHomeButton` | `true` | One obvious way back |
+| `HomepageLocation` | Wonder Ink | — |
+| `HomepageIsNewTabPage` | `false` | — |
+
+`BrowserGuestModeEnabled: false` is the answer to "other profile
+switching entry points". Guest mode is the one that survives
+`BrowserAddPersonEnabled: false`, and disabling it is the supported
+mechanism — no UI hacks. Guest mode is **not** used as the browsing
+model: the room needs one persistent profile so the church YouTube login
+survives.
+
+None of this touches website logins. Wonder Ink, Google and YouTube
+sign-ins are ordinary site sessions and are unaffected by
+`BrowserSignin: 0`, which governs signing in to the *browser*.
+
+## What the policies do not remove
+
+The avatar button stays in the toolbar. Verified by screenshotting
+Chrome with these policies applied and comparing against Chrome without
+them: the button is in the same place either way.
+
+What changes is what is behind it. Sign-in, adding a profile and Guest
+mode are all disabled by policy, so the menu has nothing left that
+creates or switches a profile. Chrome 152 has no policy that removes the
+button itself — `ProfileSwitcherEnabled` and similar names do not exist,
+checked against the binary — and hiding it would mean the UI hacks this
+is meant to avoid.
+
+Worth a look at the endpoint: open that menu once and confirm it offers
+nothing actionable.
+
+## Wonder Ink between teachers — NOT YET VERIFIED
+
+The intent: teacher A signs in, uses the room, Chrome closes, teacher B
+opens Chrome and Wonder Ink is signed out — while YouTube stays signed
+into the church account.
+
+`CookiesSessionOnlyForUrls` with `[*.]wonderink.org` is the official
+policy for that, and that pattern covers `app.wonderink.org` and every
+other subdomain. **Whether it is sufficient has not been established.**
+
+It could not be tested here. Confirming it needs a real Wonder Ink
+login, which this machine does not have, and three attempts to prove the
+mechanism against a local test site were inconclusive — the positive
+control never worked, so the negative results mean nothing. Rather than
+report a guess as a result: unverified.
+
+Two things must be checked at the endpoint before anyone relies on it.
+
+### 1. Is the session in cookies at all?
+
+`CookiesSessionOnlyForUrls` clears **cookies**. A single-page app like
+Wonder Ink may keep its token in `localStorage` instead, which that
+policy does not promise to touch.
+
+Sign in, then in DevTools (F12) → Application:
+
+- **Cookies** under `https://app.wonderink.org` — is there a session or
+  auth cookie?
+- **Local Storage** and **IndexedDB** for the same origin — is there a
+  token there?
+
+Then the real test: close every Chrome window, confirm the process is
+gone (`pgrep -x chrome` returns nothing), reopen, and see whether Wonder
+Ink is still signed in.
+
+If it is still signed in, the session is not in cookies, and **there is
+no per-site Chrome policy that clears localStorage on exit**.
+`ClearBrowsingDataOnExitList` and `BrowsingDataLifetime` both exist in
+Chrome 152 but are global, not per-site — and blanket clearing is
+exactly what must not happen here, because it would take YouTube with
+it. That case needs a small classroom-owned cleanup instead, which has
+deliberately not been built on speculation.
+
+### 2. If Wonder Ink login is "Sign in with Google"
+
+`app.wonderink.org` loads Google Identity Services
+(`accounts.google.com/gsi/client`), so Google sign-in is at least
+offered.
+
+If teachers sign into Wonder Ink *through Google*, clearing
+`wonderink.org` will sign them out of Wonder Ink — but the Google
+session at `accounts.google.com` is deliberately kept, because that is
+what keeps YouTube Premium signed in. The next teacher could then be one
+click from re-entering the previous teacher's Wonder Ink account.
+
+These two requirements genuinely conflict, and which one applies depends
+on how teachers actually sign in. Worth knowing before Sunday. If
+teachers use Wonder Ink email-and-password accounts, there is no
+conflict at all.

docs/testing.md

@@ -69,6 +69,13 @@ into separate layer-shell windows.
 - [ ] After a reboot, no "Restore pages? Chrome didn't shut down
       correctly" bubble
 - [ ] Chrome does not offer to save passwords
+- [ ] Chrome shows no way to sign into the browser itself
+- [ ] No "Add profile" and no Guest entry in the profile menu
+- [ ] No profile picker at startup
+- [ ] Wonder Ink signs in normally during a session
+- [ ] After closing Chrome fully and reopening, Wonder Ink is signed out
+      (see browser.md — this is the unverified one)
+- [ ] YouTube is still signed into the church account after that
 - [ ] `chrome://policy` lists PasswordManagerEnabled as an applied
       managed policy
 - [ ] Website logins still persist across a reboot