Spike: app-frame CSP without a dedicated origin — srcdoc + <meta> is network-dead, SWs never see sandboxed navigations, process-isolation matrix

[lannbot]

Spike, executed 2026-09-05. Code (~330 lines: server.ts, frame-script.js, run.ts) lives at /tmp/opencode/sandbox-frame-spike/ on the machine that ran it — a tempdir, not archived; the JSON result files are there too. Everything below is measured with Playwright 1.57 driving Chromium 143.0.7499.4 (full build, new headless; the headless shell is noted where it differed) and Firefox 144.0.2.

The question

The brainstorm behind this ("design B": app wasm inside the frame, real DOM behind WebIDL-mirror imports, frame realm network-dead by platform means) was rejected on the premise that it needs a dedicated sandbox origin — too high a bar for turnkey static self-hosting. The spike asks what the frame's confinement actually requires from the host, by testing four ways of giving the app frame a default-src 'none'-class CSP that differs from the visor's:

1. a real same-origin URL (/_sandbox/frame.html) whose response the bootstrap SW synthesizes, header CSP attached (spec reading: sandboxed-frame navigations are routed through HTTP fetch → SW matching);
2. the same URL served statically with a <meta> CSP, no header (a host with no header control);
3. today's srcdoc frame plus a <meta> CSP — CSP policies compose (every policy must pass), so the inherited visor policy is tightened, not replaced;
4. srcdoc with nothing (control — the inheritance problem NOTES names).

Plus: does the embedder's frame-src stop child-initiated self-navigation; is 'wasm-unsafe-eval' needed via <meta>; and is the frame in its own process (spin test: the frame busy-loops 2 s, the embedder measures its max timer gap).

Setup

Deno server on port 0. Embedder page / carries the visor-shaped policy default-src 'self'; script-src 'self' 'unsafe-inline' 'wasm-unsafe-eval'; connect-src 'self'; frame-src http://localhost:PORT/_sandbox/frame.html (path-scoped). Frame CSP under test: default-src 'none'; script-src 'sha256-<probe>' ['wasm-unsafe-eval']; style-src 'unsafe-inline'. The probe inside the frame tries, with a per-run token in every path: fetch, WebSocket, sendBeacon, <img src>, CSS url(), blob Worker, window.open, storage/cookie/IDB access, RTCPeerConnection construction, WebAssembly.compile on bytes received by postMessage, and a getBoundingClientRect read. The server logs every request path, so "blocked" means the request never left the browser, not "JS saw an error".

Results

Confinement (identical in Chromium and Firefox)

frame shape	who served it	requests reaching server	storage/cookie/IDB	wasm.compile w/ 'wasm-unsafe-eval'	w/o
real URL, sandbox=allow-scripts, SW registered	static file, SW bypassed	0	throw	ok	CompileError
real URL, no SW, <meta> CSP	static	0	throw	ok	—
srcdoc + <meta> CSP	visor bundle	0	throw	ok	—
srcdoc, no meta (control)	visor bundle	3 (fetch, sendBeacon, <img>)	throw	—	—

• Service workers never see a sandboxed (opaque-origin) frame's navigation. Both engines: source=static, fromServiceWorker=false. Controls: the same URL in an unsandboxed frame, or with allow-same-origin, is served by the SW. So "the verifying SW attaches the header" is dead — a real-URL skeleton would be served raw by the origin, outside Release integrity: content-addressed assets, the tiny mutable bootstrap, signed manifests, third-party monitoring #3's verified set, and its CSP would be whatever the host sends. That is a regression against today's visor-shipped srcdoc loader, independent of the self-hosting bar.
• <meta http-equiv=Content-Security-Policy> is fully enforced for everything tested, including 'wasm-unsafe-eval' (its absence yields CompileError: ... blocked by CSP in both engines).
• srcdoc + <meta> is network-dead. The inherited connect-src 'self' no longer matters because the added policy also has to pass. Zero requests reached the server; wasm compiles (the visor's own policy carries 'wasm-unsafe-eval' for polyengine, and the meta repeats it). The loader stays inline in the visor's bundle, i.e. inside Release integrity: content-addressed assets, the tiny mutable bootstrap, signed manifests, third-party monitoring #3's verified set. No new URL, no header control, no second domain.
• The control confirms NOTES' inheritance concern is real, not theoretical: fetch rejected in JS (CORS, opaque origin) but the request was sent, as were the beacon and the image. Under the current frame, the applier's URL validation is the only thing standing between an app string and the network.
• RTCPeerConnection constructs and opens a data channel under default-src 'none' in both engines (no webrtc directive ships anywhere; MDN compat data has no entry). Irrelevant when only framework code runs in the frame; disqualifying for any app-JS-in-frame tier.
• Sandbox without allow-same-origin also gave: window.open → null (Chromium) / throws InvalidAccessError (Firefox); navigator.serviceWorker access throws SecurityError in Chromium; blob Worker blocked by worker-src (Firefox constructs then errors asynchronously). sendBeacon returns true in Chromium and is then blocked — don't read its return value as evidence.

Self-navigation: embedder frame-src governs child-initiated navigations

attempt (from inside the frame)	Chromium	Firefox
location.href = http://127.0.0.1:PORT/other.html (cross-origin)	blocked, frame-src violation at embedder	same
location.href = http://localhost:PORT/other.html (same origin, other path)	blocked (path-scoped source works)	same
<a href=…> + .click()	blocked	same
srcdoc+meta frame, cross-origin	blocked via embedder's default-src 'self' fallback	same

/other.html was never requested in any row. Difference in aftermath: Chromium replaces the frame's document (second load event, probe stops answering); Firefox leaves the original document running. Either way the embedder gets a securitypolicyviolation event naming frame-src, which is the kill trigger. Ruling for #5: frame-src (path-scoped for a real URL; the default-src 'self' fallback already covers srcdoc) + kill-on-violation closes the self-navigation channel on both engines.

Process isolation (spin test, 2 s busy-loop in the frame; embedder max timer gap)

frame shape	Chromium full, default flags	Chromium headless shell	Firefox, Fission forced on	Firefox as Playwright ships
same-site real URL, sandboxed	27–388 ms, own iframe target	2001 ms	2001 ms	2000 ms
cross-site real URL	26–64 ms, own target	2001 ms	41 ms	2001 ms
srcdoc, sandboxed	24–88 ms, own target (about:srcdoc)	2001 ms	2004 ms	2000 ms

• Chromium: IsolateSandboxedIframes is default-on in 143 and applies to srcdoc too — with site isolation active, today's frame shape is already out of process, and removing the <iframe> is a preemptive kill. The headless shell runs without site isolation (all three shapes wedged the embedder) — an artifact of that binary, not a browser fact; --site-per-process alone restored isolation for all three. Android's partial site isolation is the open cell (not measured).
• Firefox: only cross-site frames get a process. No sandboxed-iframe isolation exists, so a srcdoc (or same-origin) frame shares the visor's process and thread; a spinning app wedges the tab. This is App guests run in workers: per-app blast zone, preemptive kill #45's territory: in Firefox, honest kill needs either a worker or a cross-site frame origin.
• (Noise: layoutRead came back 0 in a few OOPIF runs — measured before first layout; timing artifact, not a CSP effect.)

What this means

1. The dedicated sandbox origin is not required for confinement. Confinement = import set (primary) + a frame whose own CSP is default-src 'none'. srcdoc + one <meta> tag delivers the latter on the visor's own terms — visor-shipped loader, SW-verified, no host header, no DNS. The self-hosting objection to B goes away; what remains of B is the placement question (wasm inside the frame with DOM imports bound to real objects), which this spike did not touch.
2. Do it regardless of B. Even under the current op-protocol design, the meta CSP turns the applier's URL validation from sole defense into defense-in-depth: the control row shows what an applier bug leaks today. ~One line in visor/frame/frame.html. Rulings for App-frame sandboxing: a ruling table per sandbox flag and CSP directive; residual channels; anti-spoofing chrome #5 become "backstopped by the frame's own policy", which is what App execution model: no app JS - components drive a curated DOM surface, the UI frame runs only framework code #16 wanted the table demoted to.
3. The SW-synthesizes-headers idea is dead in both engines, and any real-URL skeleton is outside Release integrity: content-addressed assets, the tiny mutable bootstrap, signed manifests, third-party monitoring #3's verification — one more reason to prefer srcdoc for the loader.
4. A second domain buys exactly one thing: process isolation in Firefox (and app↔app separation if per-app labels, e.g. base32(HMAC(user-secret, app-id)) under a wildcard). In Chromium desktop the srcdoc frame already has its own process. This is a responsiveness/side-channel tier for the Home origin contract: required headers, MIME, service-worker scope - and an origin conformance checker #2 checker to report, not a confinement tier — and App guests run in workers: per-app blast zone, preemptive kill #45's worker split remains the engine-independent answer to a spinning app.

Not tested / open

• polyengine instantiating inside the frame with DOM imports bound locally and the rest proxied over a MessagePort (the actual B placement).
• Android Chromium site-isolation behaviour for srcdoc frames.
• 'self' matching semantics for a real-URL opaque frame (avoided by hash-listing the loader).
• Whether <meta> CSP timing (applies from parse point) matters for a loader we control entirely — it should not, the meta is the first child of <head>.

Refs: #5 (ruling table), #16 (execution model), #45 (workers / kill), #4 (origin topology), #3 (release integrity).

[lannbot]

Follow-up (2026-09-05): can a SW inside the sandbox frame see the navigation? No — a sandboxed frame cannot register one. Measured (swreg.ts in the spike dir), navigator.serviceWorker.register('/sw.js', { scope: '/_sandbox/' }) from a sandbox="allow-scripts" srcdoc frame:

• Chromium 143: SecurityError: Failed to read the 'serviceWorker' property from 'Navigator': Service worker is disabled because the context is sandboxed and lacks the 'allow-same-origin' flag.
• Firefox 144: SecurityError: ServiceWorkerContainer.register: Scope URL is not same-origin with Client (an opaque origin is same-origin with nothing).

The only frames that can hold a SW are real-origin ones: allow-same-origin on the visor's origin (no sandbox — storage, cookies, and the intercepting SW is the visor's own registration, i.e. control 1c above) or a dedicated origin with allow-same-origin (the requirement this spike set out to avoid, plus real per-origin storage shared by every app on it). So the SW route is closed from both sides, and srcdoc + <meta> stands as the only header-free, visor-shipped shape.

[lannbot]

Spike 2 (2026-09-05): polyengine instantiated inside the srcdoc + <meta> frame — the B placement, validated

Code at /tmp/opencode/frame-placement-spike/ (frame-runtime.ts, server.ts, run.ts, RESULTS.md; tempdir, not archived). Implemented by a coder subagent against a written dispatch; gates re-run independently by me. Playwright 1.57, Chromium 143.0.7499.4 (full build) and Firefox 144.0.2.

What was built

The demo-app guest (examples/todomvc/guest, world demo-app: imports polyvisor:surface/{dom,events,shell} + polyvisor:tasks/tasks@0.1.0, all tasks functions WIT async func) is instantiated by @polyengine/runtime@0.5.1 inside a sandbox="allow-scripts" srcdoc iframe whose <meta> CSP is default-src 'none'; script-src 'sha256-…' 'wasm-unsafe-eval' [blob:]; style-src 'unsafe-inline'; img-src data:. The embedder page's header CSP is default-src 'self'; script-src 'self' 'sha256-<same hash>' 'wasm-unsafe-eval' [blob:]; connect-src 'self'; … — no 'unsafe-inline' for scripts, no 'unsafe-eval', anywhere (header verified with curl).

• Surface imports bound to the frame's real DOM, same realm, synchronously: createDirectBackend(document.body, …) + createSurface — the existing code from visor/surface/, unchanged, no op protocol, no port.
• tasks import is a request/response proxy over a MessagePort transferred in by the parent; the parent runs an in-memory tasks implementation standing in for the runtime SharedWorker. Every method returns a Promise; the guest waits on it.
• Everything variable — plan, wasm bytes, the port, route — arrives via one postMessage after load. The srcdoc itself is a build-time constant.

Results — 9/9 assertions, both engines, both delivery modes

assertion	Chromium	Firefox
frame posted mounted	pass	pass
.todoapp present in the frame's real DOM	pass	pass
real keystroke → li "buy milk" rendered	pass	pass
parent-side add("buy milk") received over the port	pass	pass
≥1 items round trip (guest re-rendered from the reply)	pass	pass
zero securitypolicyviolation (parent and frame — frame relays its own)	pass	pass
server saw no paths beyond the 5 static ones	pass	pass
silent 500 ms after iframe.remove()	pass	pass
(Firefox) no JSPI pref needed	—	pass

Tasks call counts every run: {items: 2, add: 1}.

Delivery cost — inline-under-hash vs blob: module

Frame runtime bundle (polyengine embedder + visor/surface direct backend + runner, deno bundle --minify): 186,462 B raw / 55,975 B gzip.

engine	mode	srcdoc bytes	append→mounted (ms, 3 runs)	wasm compile (ms)	polyengine instantiate() (ms)	run() (ms)
Chromium	inline	194,369	95 / 52 / 43	2.9 / 2.8 / 1.5	30 / 9 / 6	9 / 6 / 15
Chromium	blob	8,538	58 / 48 / 41	1.4 / 2.6 / 1.4	5 / 7 / 6	14 / 11 / 9
Firefox	inline	194,369	63 / 57 / 39	18 / 16 / 10	20 / 18 / 9	6 / 14 / 3
Firefox	blob	8,538	37 / 34 / 30	7 / 5 / 3	8 / 6 / 7	5 / 3 / 2

• Wasm compile is not the cost (1–3 ms Chromium, 3–18 ms Firefox for a 114 KB component). polyengine's linking dominates in-frame, and the whole mount is 30–95 ms wall.
• blob mode: 23× smaller srcdoc, 10–25 ms faster, but requires script-src blob: in the visor's own header — a widening of the trusted realm's policy (any visor-realm code may then run blob scripts). inline mode: hash-only policies, at the price of a ~190 KB srcdoc string re-parsed per mount. Either is workable; the choice is policy hygiene vs ~20 ms, and should be re-measured with the real frame runtime size.
• Inline mode needs <script type="module">: deno bundle emits one import.meta.url even without top-level imports/exports. Inline module scripts are hash-addressable in both engines, so this costs nothing in policy.

Findings with design reach

1. The frame does not need JSPI for this world. Playwright's Firefox 144 has WebAssembly.Suspending === undefined and WebAssembly.promising === undefined (measured), and the app still boots, suspends across the port for add/items, and re-renders. Reason: every import that crosses a realm is a WIT async func (component-model async ABI, no stack switching), and the sync imports (dom) are bound directly and never suspend. Consequence for B: JSPI is required in the frame only if a sync-declared import must go over a port — the runtime SharedWorker's requirement (NOTES "Browser floor") is untouched, but the frame's floor is lower than the runtime's. Under B, keep cross-realm imports async-declared and the frame runs on engines without JSPI.
2. The srcdoc must be a build-time constant. Its inline script's hash is carried in the visor's header policy, which cannot know a runtime-assembled string. Everything variable goes through postMessage. This is also what makes it pinned-by-value under Release integrity: content-addressed assets, the tiny mutable bootstrap, signed manifests, third-party monitoring #3.
3. img-src data: is a real requirement, not default-src 'none' purism: TodoMVC's CSS glyphs are data-URL SVGs and were blocked (4 violations/mount) until added. Any surface CSS with data-URL images needs it; data: is not a network scheme, so the exfil claim is unaffected.
4. The frame must relay its own CSP violations — they fire on the frame's document, invisible to the embedder. The loader should post them out; the visor treats a frame violation as a kill signal alongside its own frame-src events.
5. Loader hardening for production (not in the spike): accept the mount message only when e.source === window.parent and only once; sibling app frames can reach each other's WindowProxy via parent.frames[i] and call postMessage. The transferred port is the authenticator; the source check just closes the pre-mount window.
6. height reported 0 once (posted before layout): production should use a ResizeObserver, not a one-shot read.

Repo papercut

just app in demo/ fails on a fresh checkout: wasm-tools component new … -o build/app.component.wasm → No such file or directory — the app recipe does not mkdir -p build (the translate recipe does, so site happens to work). One-line fix.

Where this leaves B

Both spikes' open items are closed except the ones that are design work rather than validation: the WebIDL-projection scope for the dom surface (which vocabulary the direct binding exposes beyond today's 14 tags — a denylist over a generated projection, per the brainstorm) and the #16 checkpoints (walking-skeleton app, a11y review, porting spike), which now run against a real DOM. Nothing measured contradicts B; the only engine-dependent degradation remains the Firefox process split (spike 1), accepted for v1.

[lannbot]

Correction to "the srcdoc must be a build-time constant" (2026-09-05, measured with hdr.ts in the spike dir). The precise claim: the visor's header script-src must allow the srcdoc's inline script; a runtime-computed hash in the srcdoc's own <meta> does not suffice. With the hash removed from the header only (?nohdrhash=1), the frame fails to mount in Chromium 143 and Firefox 144, both delivery modes — "Executing inline script violates … script-src" / "blocked an inline script (script-src-elem)". With the hash present, 4/4 mount.

Consequences, restated:

• The script text must be known to whoever emits the visor's response header — build-time config on a static host, or serve-time from release content when the Release integrity: content-addressed assets, the tiny mutable bootstrap, signed manifests, third-party monitoring #3 bootstrap SW synthesizes the response. Not "the srcdoc": markup, styles and data attributes are unconstrained and may be assembled at runtime.
• A runtime-arbitrary loader script is possible via a per-response nonce (readable by the page through script.nonce, applied to the srcdoc <script nonce>): SW-synthesized responses only — a fixed nonce on a static host is 'unsafe-inline' with a password — and it forfeits the hash pin that ties the loader to release content. B has no need for it: app code is wasm bytes over postMessage; the loader never varies.

[lannbot]

Spikes 3 and 4 (2026-09-05): the dioxus dialect in-frame, and four platform probes

Code: /tmp/opencode/dioxus-frame-spike/ and /tmp/opencode/platform-probes/ (tempdirs, RESULTS.md in each). Coder subagents against written dispatches; results re-checked by me. Chromium 143.0.7499.4 (full build), Firefox 144.0.2, Playwright 1.57. The frame change itself is #146.

Spike 3 — polymorph:dioxus guest (wasm32-wasip2) instantiated in the srcdoc + <meta> frame, applier same-realm

The spikes/todomvc/guest-dioxus component mounted with polyengine-dioxus's own unmodified same-realm mountApp inside the frame (sandbox="allow-scripts", meta default-src 'none'; script-src 'sha256-…' 'wasm-unsafe-eval'; style-src 'unsafe-inline'; img-src data:; header carries the same hash; no 'unsafe-inline'/'unsafe-eval'). 9/10 assertions pass in both engines; zero CSP violations; zero unexpected requests.

Imports: 5 polymorph:dioxus/* (dom, events, head, history, mutations; no eval) + 16 wasi:*, all satisfied by @polyengine/wasi's wasi() — no filesystem stub needed, the guest imports none.

The four degradations spikes/todomvc/README.md records for the two-hop transport, re-examined one-hop:

#	two-hop status	one-hop result
1	prevent-default/stop-propagation are no-ops	closed. Both reachable sites exercised: <label for> click no longer toggles the checkbox; the #/active filter anchor no longer navigates (about:srcdoc unchanged, no load) while the filter still applies. DomEvent calls through to the live native event (host.ts:474-480). The frame-side anchor mitigation is no longer needed.
2	sync dom queries can't cross; auto-focus broken	plumbing closed, symptom remains — different cause. createDomImports now serves the real table; programmatic el.focus() (what set-focus does, host.ts:355) works in both engines. But TodoMVC's edit field uses the declarative autofocus attribute, and every engine refuses declarative autofocus in a cross-origin subframe (Chromium: "Blocked autofocusing on a element in a cross-origin subframe."; Firefox silently). Categorical for any opaque-origin frame. Actionable fix is in polyengine-dioxus's DomApplier: follow a truthy autofocus (BOOL_ATTRS, applier.ts:89) with a real focus() call.
3	eval not granted	unchanged — a rule. Not imported, not supplied.
4	resource payloads (files, transfer) can't survive structuredClone	closed by reading. No clone in the same-realm path: serializePayload → handleEvent directly (host.ts:477-479) with live HostFile/HostDataTransfer (events.ts:541, 466). Not fabricated a test.

Numbers: frame runtime 220,332 B raw / 67,495 gz (vs 186/56 KB for the polyvisor:surface runtime — the dioxus host adds ~11 KB gz); component 659,926 / 227,614; srcdoc 228,259 B (inline mode). Mount wall: Chromium 116/49/53 ms, Firefox 57/48/48 ms; compile 5 ms / 15–19 ms — still not the cost.

Firefox + JSPI, a hard finding. Default prefs: no JSPI (WebAssembly.Suspending undefined) and the spike passes — same as spike 2. With javascript.options.wasm_js_promise_integration: true: Suspending/promising appear and the content process crashes on mount, deterministically (jspi-probe.ts reproduces both configs in one process). The pref rescues nothing; any future "enable JSPI in Firefox" plan runs this reproducer first.

Two things the one-hop placement leaves genuinely open (interpretation calls, not measurements): where a framed app's route lives — the frame's URL is about:srcdoc and nothing reads it; the spike used history: "memory"; the visor-owned route/on-route seam is the candidate — and head imports now land in the frame's own <head>, which is the app's; nothing to protect.

Spike 4 — four platform probes

P1 — inert on the <iframe> as the suspension primitive: not sufficient alone.

	Chromium	Firefox
pointer clicks into the frame	blocked	blocked
programmatic focus() from inside the frame	not blocked	not blocked
keystrokes to an input focused before inert was set	still delivered	dropped

Recovers fully on removal in both. So inert handles pointer input uniformly and nothing else uniformly. Suspension needs inert plus the loader-side gate (the existing runner pause semantics — stop dispatching events into the guest), and the visor should move focus out of the frame when suspending. Not a platform primitive we can lean on alone.

P2 — remove-while-spinning (4 s busy-loop, remove() at 500 ms): Chromium full build — remove() 0.4 ms, embedder timer gap 28 ms, CDP iframe target gone within 1 s, the frame's end-of-spin message never arrives (it died mid-loop). Firefox — remove() returns in 1 ms but the embedder stalls the full 4000 ms and the frame's end-of-spin message does arrive: removal can't preempt a loop already running on the shared thread. Matches spike 1; the v1 Firefox posture stands.

P3 — blob: assets in the opaque frame: PNG via URL.createObjectURL → <img> loads (naturalWidth correct); FontFace(blobUrl).load() → "loaded"; @font-face { src: url(blob:…) } + document.fonts.check → true. Both engines, zero violations, zero frame-originated requests. The asset-handle story (bytes in over postMessage, blob: URLs minted in-frame) works as designed.

P4 — forms. Without allow-forms, the submit event never fires in either engine — not "fires then navigation blocked" — so <form onsubmit> is dead, including requestSubmit(). Chromium logs "Blocked form submission … 'allow-forms' permission is not set"; Firefox logs nothing Playwright can see. Follow-up variant (mine): sandbox="allow-scripts allow-forms" + meta form-action 'none':

	Chromium	Firefox
submit fires, preventDefault() honoured	yes	yes
un-prevented submission	blocked by CSP form-action (violation event, console error)	same
server saw /probe-submit-*	never	never
iframe load / navigation	none	none

Ruling for #5: allow-forms on, form-action 'none' in the meta. Consequence: a form-action violation is an app that forgot preventDefault, not an attack — log it, don't kill on it. (Kill-on-violation stays for frame-src and anything under default-src.)

Updated frame policy

sandbox="allow-scripts allow-forms"
<meta http-equiv="Content-Security-Policy" content="default-src 'none'; script-src 'sha256-<loader>' 'wasm-unsafe-eval'; style-src 'unsafe-inline'; img-src blob: data:; font-src blob:; media-src blob:; form-action 'none'">

(#146 ships the first half of this — default-src 'none', hash, style-src, img-src data: — for the current two-hop frame; the rest arrives with the in-frame instance.)

Repo papercuts found along the way

• just app in demo/ fails on a fresh checkout: no mkdir -p build in the app recipe.
• spikes/todomvc just build fails on a fresh checkout: guest-preact needs npm install first (Could not resolve "preact").
• engine's MinIO fetch is linux-amd64 only, so the demo e2e lane can't run on arm64 hosts.