diff --git a/config/chrome/policies/managed/ekklesia-classroom.json b/config/chrome/policies/managed/ekklesia-classroom.json index 2efd01b..eacb8e2 100644 --- a/config/chrome/policies/managed/ekklesia-classroom.json +++ b/config/chrome/policies/managed/ekklesia-classroom.json @@ -3,15 +3,22 @@ "PromotionalTabsEnabled": false, "MetricsReportingEnabled": false, + "BrowserSignin": 0, "SyncDisabled": true, "SigninInterceptionEnabled": false, + "BrowserAddPersonEnabled": false, + "BrowserGuestModeEnabled": false, "ProfilePickerOnStartupAvailability": 1, "PasswordManagerEnabled": false, "PasswordLeakDetectionEnabled": false, "BackgroundModeEnabled": false, + "CookiesSessionOnlyForUrls": [ + "[*.]wonderink.org" + ], + "ShowHomeButton": true, "HomepageIsNewTabPage": false, "HomepageLocation": "https://app.wonderink.org/" diff --git a/docs/browser.md b/docs/browser.md new file mode 100644 index 0000000..d8377cb --- /dev/null +++ b/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. diff --git a/docs/testing.md b/docs/testing.md index 1132d09..4a6e7dd 100644 --- a/docs/testing.md +++ b/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