Framework chrome: trusted code, position+secret authentication, input suspension - the shell's own UI

[lannbot]

Provisional plan — recorded 2026-08-16 from the chrome design discussion. Every ruling here is provisional until the prototype has been user-tested; user testing of the chrome prototype is the conversion checkpoint (per explicit direction). Related: #5 (anti-spoofing line, ruling table), #6 (powerbox UX), #16 (app execution model); prototype in spikes/todomvc (chrome strip + consent sheet over the three guests).

Rulings (provisional)

• Chrome is trusted shell code, not a component. It is the reference monitor's face — TCB by definition; sandboxing it buys nothing and costs the deliberately-narrow app surface. Plain trusted Preact (in-family, proven small) + normal DOM, shipped with the framework release. The "shell is just an app with more grants" symmetry is rejected. Exception, named: third-party chrome-ish things (a storage backend's config panel) are apps — own sandboxed region, own grants, launched from chrome, never rendered as chrome.
• Style never authenticates; position and secrets do. Apps can copy any CSS, so the design system is shared freely with apps (coherent product, no security cost). Trust anchors instead:
  • Position: apps render only inside their frame rectangle (the root() grant is the geometry contract); chrome renders only outside it. Trusted may overlay untrusted (consent sheets over a dimmed app); never the reverse. Fullscreen/PiP/popups stay withheld (App-frame sandboxing: a ruling table per sandbox flag and CSP directive; residual channels; anti-spoofing chrome #5 table) because they break the rectangle.
  • A persistent strip apps can never paint: petname, capability-in-use indicators (mic-light analogy), audit entry point, and a kill/suspend affordance the app cannot intercept.
  • A user-chosen personalization secret in every real prompt Dropped 2026-08-16 (directive + analysis; see the secrets-vs-decisions comment): it defends only at a moment the secret-entry rules eliminate, and the SiteKey literature says it fails there anyway.
  • Untrusted-string discipline inside chrome: petnames are primary identity; app-supplied text is always quoted, length-clamped, styled as foreign — never interpolated into chrome's own sentence structure.
• Chrome owns input and lifecycle, not just pixels. The shell owns event delivery (the runner queue), so modal chrome = pause the app's queue — the app cannot observe or race the user's interaction with a prompt. Routing already belongs to the shell (route()/on-route in the spike WIT). Trap/death screens are chrome-rendered (fed by the future diagnostics channel). Later: launcher/switcher/multi-app = N app regions, each with its own root grant and queue.

Non-goals (stated, not discovered)

• Defending against spoofed browser chrome (URL bar) — that is the home-origin trust statement's territory (Home origin contract: required headers, MIME, service-worker scope - and an origin conformance checker #2/Release integrity: content-addressed assets, the tiny mutable bootstrap, signed manifests, third-party monitoring #3).
• Shoulder-surfing/screenshot capture of the personalization secret by humans or other software on the device.

Prototype (spike scope)

Chrome strip above the app rectangle (petname + guest/backend indicators + kill), one fake consent sheet showing the personalization secret, and event-queue suspension while the sheet is open — validated against all three guests. The spike strip is vanilla DOM (framework ruling says Preact; the spike shell predates that plumbing).

Open sub-questions

• Modal event policy: queue-and-deliver-on-dismiss (prototype behavior) vs drop vs deliver-with-a-"was-suspended" marker.
• A11y variant of the personalization secret (moot: secret dropped 2026-08-16).
• Secret lifecycle: per-device vs synced; recovery on re-enrollment (moot: secret dropped 2026-08-16).
• Kill semantics: real instance teardown needs a deltic embedder API check (drop references vs explicit terminate).
• Mobile geometry: safe-area insets, strip height budget, iOS URL-bar collapse interactions.
• When multi-app arrives: strip-per-region vs global strip with focus indication.

[lannbot]

Prototype live (commit ca9b16d): https://polymorph-components.github.io/polymorph-apps/spike-todomvc/ — strip + simulated consent sheet over all three guests, verified at mobile viewport (including against the live Preact guest: event fired during the open sheet stays queued, delivers on Allow).

What it demonstrates concretely:

• Position anchor: the strip and sheet render strictly outside #app; the app's root() grant is the entire rectangle it can paint.
• Personalization secret: generated once into shell localStorage (🔭 cobalt-grove-style emoji+phrase), shown in every real prompt; no app capability can read it.
• Input suspension: the Runner gained pause()/resume() — a gate crossed before each guest invocation — so modal chrome means the app cannot observe or race the prompt. Current policy is queue-and-deliver-on-dismiss (first open sub-question).
• Kill: pause-forever + DOM removal; real instance teardown remains the deltic embedder-API sub-question.
• Untrusted-string discipline: the app name renders quoted/styled-as-foreign inside chrome copy.

Reminder per the issue header: all of this is provisional until user-tested — the prototype exists precisely to be put in front of users; the rulings convert (or don't) on what that shows.

[lannbot]

Interaction-emergence experiment landed (commit 5a09493, live): chrome interactions are revealed by the strip sliding down, exposing the interaction surface above it.

The design does double duty, per the experiment's framing:

• Provenance: the prompt visibly grows out of the trusted pixel region rather than appearing anywhere on screen — the position anchor made kinetic.
• Arming delay: the slide (700 ms, inside the ≤1 s budget) is an enforced input-protection window — controls render disabled (dimmed, then brighten on arm) and a press started while disabled produces no click, defeating baited mis-taps (an app training rapid taps at the position where a chrome control is about to appear).

Enforcement details worth pinning:

• The timer is the enforcement; the animation is its visible form. Arming is a setTimeout(ARM_MS), never transitionend — so prefers-reduced-motion removes the motion but never the delay, and the protection can't be shortened by animation tampering.
• Kill moved behind the same pattern with a confirm step (Suspend/Cancel), so every chrome interaction flows through one openDrawer primitive: pause queue → slide → arm → act → resume.
• Verified live at mobile viewport: baited clicks on Allow and Suspend during the animation do nothing; app events during an open drawer stay queued; delivery on Allow; kill permanent after arm.

Prior-art lineage: Firefox's security-dialog delay and Android's tapjacking touch-filtering — with the delay made legible as motion instead of felt as latency. That legibility claim is exactly what user testing should probe (does the slide read as "the system is protecting this" or as jank?), alongside the open question of whether 700 ms is the right point on the annoyance/protection curve for repeat interactions (pickers) vs rare ones (permission grants).

[lannbot]

Secret entry: the decisions-vs-secrets asymmetry (recorded 2026-08-16; provisional per the header)

The asymmetry that dictates the rules. A consent dialog's asset is the decision, and a decision is only real if made in real chrome — a pixel-perfect fake inside the app rectangle can't mint a grant; worst case is priming/habituation (the arming delay blunts the reflex-tap variant). A password dialog's asset is the input itself: the fake IS the attack, and authenticating-the-surface at typing time is a burden users measurably cannot carry (Schechter et al. 2007, The Emperor's New Security Indicators: users proceed even when their personalization image is absent). Any design that depends on the user noticing something missing at the moment of typing is already dead.

Rules (provisional):

1. The drawer's vocabulary excludes secret input, absolutely. Buttons, pickers, confirmations only. This converts a positional judgment ("is this dialog really chrome?") into a teachable absolute: the system never asks you to type a secret in a slide-down; anything that does is fake. Absolutes survive habituation; vigilance doesn't.
2. Secret entry only in the dedicated identity surface — trusted chrome, not a sandboxed app (it touches raw key material; Key lifecycle: disposable device keys, recoverable data root (recovery phrase / WebAuthn PRF), last-device loss #11's territory: recovery phrases, enrollment). Full content-region takeover, entered via chrome-side gesture: apps may request it, and the request renders as an ordinary consent drawer whose sole affirmative action is "Open Identity" — navigation, never inline entry (the secure-attention-sequence pattern).
3. Prefer flows where nobody types. Passkeys/WebAuthn dialogs are OS-level chrome that page content cannot fake — the framework's own identity should be passkey-first for phishing resistance, not just key hygiene (Key lifecycle: disposable device keys, recoverable data root (recovery phrase / WebAuthn PRF), last-device loss #11). For app logins to external services: the credential powerbox — the user picks ("use my Foo login here", Permission model: linking as enforcement - deny-by-unlink, prompt-on-first-use, revocation semantics, durable grants #6) and the proxied-fetch layer injects the credential into the granted destination's requests (Network capabilities: per-destination grants, the app manifest, proxied fetch and the audit log, exfiltration stance #7), so the app authenticates without ever reading the secret.

The exfiltration barrier, honestly scoped: a pure-local app that phishes a password holds a secret it cannot ship — confinement makes the phish pointless, which the open web cannot say. But the attack shape is "password field + network grant," which is also the shape of every legitimate login bridge — so the barrier's inevitable holes get shaped: credential-injection as the standard tier, raw-credential-reading apps as a rare, separately-prompted scary tier with the audit log watching.

Personalization secret: dropped (directive; body amended, prototype updated in b30653e). It defended only at the moment rule 1 eliminates, the SiteKey result says it fails there anyway, and it carried real costs: false assurance, an unsolved a11y variant, and a secret-lifecycle/sync question. The strip remains ambient corroboration (app petname / "⛨ Identity" while the identity surface is open) — corroboration, not defense.

Cross-links: #11 (identity surface, passkey-first, recovery), #6 (credential powerbox), #7 (credential-injecting proxied fetch, audit log).

[lannbot]

The config-panel exception, executed (PR #24, second commit; verified live in the browser demo against real Dropbox). #22's provisional ruling names one exception to "chrome is trusted shell code": "third-party chrome-ish things (a storage backend's config panel) are apps — own sandboxed region, own grants, launched from chrome, never rendered as chrome." That is now real in spikes/demo, and it turned out to be the first place the framework's capability story is visible in UI rather than asserted in prose.

The shape

chrome (page JS, trusted)          panel component (sandboxed, per provider)
  Storage… button                    guest-panel-s3       — dom/events/shell ONLY
  dialog frame + provider tabs         renders: "pure component: cannot reach the network"
  #panel-region (the grant) ────────►  guest-panel-dropbox — + oauth-broker
  carries the returned config                                + fetch scoped to api.dropboxapi.com
  blob to engine.init-store

• The panel mounts through the same curated-DOM surface machinery as the app (createBackend/createSurface; the dialog region is its root() grant). Position marks the boundary, not style — the region is inset and labeled "sandboxed panel", per the Framework chrome: trusted code, position+secret authentication, input suspension - the shell's own UI #22 anti-spoofing line.
• Chrome brokers OAuth. Navigation, popups, and redirect handling are chrome capabilities a sandboxed panel must not hold, so the panel calls oauth-broker.authorize(app-key) and chrome runs the entire PKCE ceremony (S256 challenge, popup, postMessage relay through the redirect, code exchange) and returns only tokens. The panel never sees the ceremony; app guests never see any of it. This is the powerbox shape at the provider boundary: the sensitive authority stays outside the sandbox, and what crosses in is exactly the capability.
• The fetch import IS the per-destination grant (Network capabilities: per-destination grants, the app manifest, proxied fetch and the audit log, exfiltration stance #7): chrome's shim refuses any host but api.dropboxapi.com with a WIT err (not a trap — a panel is entitled to render a denied egress). Verified both directions in-page: example.com → fetch: host not granted to this panel; the granted host → a real response. The S3 panel gets no fetch import at all, so the System services: schema-authority data services, computed capability profiles, the egress-reachability badge #21 pure-vs-egress profile contrast is one tab-switch apart in the same dialog.

Findings that bear on the chrome design

• A status surface that mixes ambient telemetry with consequential one-shot messages needs priority, not last-writer-wins. The demo's 4 s stats() tick was erasing exactly the messages the beats exist to produce (pull outcomes, the revocation guarantee note) within one frame. Fixed here with 12 s sticky statuses; the framework's strip will need a real story for this (capability-in-use indicators vs transient consent/audit results compete for the same pixels).
• Panel teardown is the same open question Framework chrome: trusted code, position+secret authentication, input suspension - the shell's own UI #22 lists for app kill. Switching provider tabs clears the region and drops references, but there is no explicit instance-terminate API in the deltic embedder — release is by GC, not by contract. Worth resolving alongside the kill affordance.
• The panel protocol that fell out — seed(config-json) → run() → on-event pump → poll outcome() (none = live, some("") = cancelled, some(json) = completed) — is deliberately dumb, and the interesting property is that chrome never inspects the config blob: it carries provider-opaque bytes from panel to engine. That keeps chrome free of provider knowledge, which is what makes "any provider can ship a panel" more than a slogan. Whether the framework wants that opacity (vs a typed capability the consent UI can explain) is a real open question for Permission model: linking as enforcement - deny-by-unlink, prompt-on-first-use, revocation semantics, durable grants #6/Network capabilities: per-destination grants, the app manifest, proxied fetch and the audit log, exfiltration stance #7: an opaque blob is exactly what a compound prompt cannot describe.

Not addressed here (deliberate): the panel renders inside chrome's dialog rather than in its own app region with the strip; consent-sheet event-queue suspension is untouched; and the panel is trusted with credentials the user typed into it — the framework will want the powerbox picker shape (chrome collects secrets, panel never sees them) for providers whose config is a credential. That trade is worth deciding before this pattern generalizes.

[lannbot]

The shell needs a scheduling primitive, not a convention — recorded from the demo work (PR #24), where the same bug shape appeared three times in one session and the third one was fatal.

The pattern

Chrome (here: the demo host) drives a component-backed engine through a serialized call path — one background chain, plus per-app runner.call queues. Every caller that fires work on a timer or a click appends to those chains unconditionally. The failure is not exotic: whenever the work outlives the interval that schedules it, the queue diverges.

Three instances, all in spikes/demo/host/demo.ts:

1. Duplicate Save & connect — storage setup takes ~20 s against a consumer API, so "click it again" is the natural user response; the second run re-minted container links and republished pickup objects underneath the first.
2. Boot-time setup racing a user-initiated one — same body, two entry points, no interlock.
3. Every periodic driver — app poll (400 ms × 3 panes), reconciliation pulls (2.5 s), auto bucket-sync (4 s), stats (4 s) — against work that routinely runs 1–3 s/op on consumer storage. Measured against a 1.5 s/op proxy: 180 ticks in 3 minutes that the old code would have queued, one per second, forever. The queue itself is the leak; user input lands behind hundreds of pending engine calls. Sluggish, then wedged, then the tab dies — reported from the outside as "memory leak, locks up after a couple of minutes".

Each fix is three lines. That is exactly why this belongs in the shell: three lines that every caller must remember, forever, or the app dies in a way that looks like a runtime bug.

Why it lands on #22 specifically

This issue already rules that chrome owns input and lifecycle, not just pixels — the shell owns the runner queue, and modal chrome works by pausing it. Once the shell owns the queue, the shell owns its backpressure. Leaving admission control to callers contradicts the ruling that made the queue chrome's property in the first place.

It also answers #22's open sub-question ("modal event policy: queue-and-deliver-on-dismiss vs drop vs deliver-with-a-marker") in a more useful form: the choice is a property of the work, not a global policy. Two kinds, and the shell should make callers name which they mean:

• Transactions (user intent: a task add, a grant, a revocation) — must queue, must not be dropped, must be ordered.
• Refreshes (reconciliation pulls, stats ticks, revision polls, auto-sync) — must be skipped when their predecessor is still running. A refresh whose value has been superseded has no reason to run; queueing it is strictly wrong, not merely wasteful.

A shell that only offers "enqueue" forces every refresh to be modeled as a transaction, which is what diverges.

Proposed shape

• single-flight(key, f) — at most one in flight per key; a second call while one runs is refused synchronously, not queued (placement matters: a guard checked inside the serialized job always finds the previous run finished, so it must be claimed at call time — this cost me a debugging cycle).
• periodic(name, every, f) — timer-driven refresh with skip-if-running built in, so the cadence is a ceiling on frequency rather than a promise of one run per tick.
• submit(f) — the ordered transaction path (today's enqueue).
• Backpressure telemetry as a first-class surface: queue depth and per-driver skip counts. The demo exposes __demo.health(); the framework's persistent strip is the natural home for the "this app is falling behind" signal, next to the capability-in-use indicators. A shell that can suspend an app should also be able to show that it is saturated — and the kill affordance already specified here is the escalation.

Related and already recorded: the status-surface priority finding (ambient telemetry erasing consequential one-shot messages) in the earlier comment on this issue; both are the same underlying gap — the shell provides a mechanism (a queue, a status line) and leaves a policy (admission, priority) to every caller.

Not this: the residual browser-only memory growth found alongside it is a separate matter, bounded away from the engine (same composite under Deno with live subscriptions is flat over 90 s) and pointing at the deltic browser port layer.