[HackTuah]

What (Linear SCR-448, input to the slice 54 security review)

Web pages' content scripts could still write Kotiko's settings, because Chrome and Firefox give them storage.local by default. A subverted content script could:

• turn Kotiko off, pause sites or hide languages;
• edit the pages' word list;
• plant an add job, which the queue would look up with the learner's own service, spending lookups and changing their list;
• change the base languages and trigger a sync that pushes them to the learner's own server.

Nothing reached a new destination, since slice 28 already bound those, but the learner's settings and list weren't protected.

Research (primary sources, 2026-10-06)

• Chrome: storage.local.setAccessLevel works only from Chrome 140 (MDN browser-compat-data, crbug 40949182); slice 11's "102+" was for session only.
• Firefox: setAccessLevel isn't implemented at all (bug 1724754).
• So the fix can't rely on locking storage.local.

Design

• A trusted copy the background owns: extension/lib/settings.js, rows in IndexedDB.
  • storage.local becomes a mirror: the background writes the trusted copy first, then the mirror.
  • On every storage.onChanged and at each start, the mirror is compared with the trusted copy. Changed values go back, removed keys are restored, and unknown keys are deleted. The comparison sorts object keys, so it doesn't loop.
• Pages change settings only through page-only messages (settings.set, settings.restore).
  • settings.set works on an allowlist, each key with its shape and size checked.
  • Where requests go (lookup service, addresses, keys) is not on it; only the existing bound-route paths change those.
• Content scripts write nothing. The word card's "Don't swap this word" is a neverSwap message for one word at a time.
• storage.sync: on Chrome 140+ it's locked to trusted contexts and accepted. Elsewhere this browser keeps its own copy and never takes ui from sync. Trade-off: on Firefox and older Chrome, base and interface languages no longer follow between devices automatically (in the CHANGELOG and the security requirements).
• Migration: an existing install's settings and queue are taken over once, so nothing is lost.
  • A planted 0.2 token on a new install now drops every adopted setting and route, not only the server route.
  • A pre-28 hidden hosted lookup address is dropped; addresses the learner typed and can see are kept.

Tests

• test/bg/settings.test.mjs (18) covers each attack, and 16 of 17 originals failed on the old code; the 17th was made deterministic and then failed too. It also covers:
  • Chrome versus Firefox sync handling;
  • pages can still set, merge, add and remove;
  • disallowed keys and bad shapes are refused;
  • backup restore never sets addresses;
  • upgrade paths;
  • the Connect OpenRouter result surviving a content-script rewrite.
• test/unit/settings.test.mjs covers the store itself.
• e2e privacy.spec.mjs: from the real content-script world in Chromium, everything planted is put back, nothing loops, a planted job spends no lookup, and storage.sync.set is refused.
• The screenshot scripts in test/visual/ now seed through the background. Store screenshots were regenerated and checked by eye; the content is unchanged, so the PNGs aren't recommitted.

Lead review

I checked:

• settings.set and settings.restore are from: ["page"];
• the allowlist has no destination keys;
• restoreSettings → Backup.settingsPatch keeps the current provider and addresses, with only the model (same provider) and the data-keeping preference coming from the file;
• neverSwap is the only content-script write, one word at a time.

Not closed, documented

• A content script can still add "don't swap" words, which are visible in Settings.
• Other open pages may flicker briefly on a planted value before the heal; nothing is saved or sent.
• Three older visual scripts (popup, dashboard, popover) stop partway on main too. That's unrelated, and it's a separate follow-up.

Checked (after merging main)

• npm run lint: 0 errors. npm run coverage: 1972 tests, 94.25 % lines, 84.98 % branches; settings.js 100 % / 99 %.
• npm run perf: all ok; two new budgets are about 20 ms each against 50.
• npx playwright test: 101 passed, 4 skipped.
• check-old-name, check-base-neutral, bestpractices-links, sync-extension, sync-privacy, reuse and DCO all pass.

🤖 Generated with Claude Code