# 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.