P0 T3 runtime spike: CEF Chrome Runtime vs Electron vs Full Chromium

[marcohost33-maker]

Purpose

Execute ADR-006 for Marco's decided G1=T3 target: a browser-grade native runtime for arbitrary foreign web content/apps. This issue must produce process-isolation, sandbox, compatibility and security-patch evidence. It is not a framework preference vote.

Depends on #30 for the exact offline acquisition/execution modes. Advances #21.

Candidates

1. CEF Chrome Runtime / Chrome Bootstrap — primary embedding candidate.
2. Electron / bundled Chromium — rapid-development and operational baseline.
3. Full Chromium downstream/control build — highest-parity, highest-maintenance control and migration path.
4. Tauri/WRY/system WebView — T1/APP-02 and negative/control baseline only; not presumed capable of T3 browser isolation.

Do not treat "CEF" as one uniform security profile. Record the exact CEF/Chromium version, runtime style/bootstrap, feature flags, sandbox configuration and rendering mode. Older Alloy behavior and Chrome Runtime/Bootstrap may differ materially.

Common adversarial fixture

The same fixture and assertions must exercise:

• HTML/CSS/ES modules, Wasm, workers, shared workers and service workers;
• IndexedDB, CacheStorage, cookies, local/session storage and permission state;
• same-site and cross-site iframes, nested OOPIFs and redirects;
• window.open, popup/opener relationships and cross-origin navigation;
• downloads, drag/drop, clipboard and external-protocol attempts;
• network redirects, DNS rebinding/private-address attempts and mixed content;
• zero-grant native IPC, malformed arguments, confused-deputy and wrong-sender cases;
• renderer, GPU, utility and browser-process crash/hang scenarios;
• oversized resources, decompression pressure and recovery;
• deletion/recreation of app-local state;
• all acquisition modes selected in P0 architecture: define offline acquisition modes for foreign webapps #30.

Site-Isolation evidence

Framework documentation is insufficient. For every supported candidate/platform:

• enable and pin the intended Site Isolation policy, including --site-per-process or the equivalent product configuration;
• prove that cross-site iframes use separate renderer processes;
• capture a machine-readable mapping of app/site, frame tree, SiteInstance and OS process ID;
• inspect chrome://process-internals or equivalent instrumentation where available;
• verify popup/opener, worker and service-worker process behavior;
• repeat in windowed mode and off-screen rendering if OSR is considered;
• retain failures involving OOPIF input, rendering, IPC or crash containment;
• prove that release builds cannot silently launch with isolation or sandbox disabled.

CEF's general multi-process model and a renderer per unique origin do not by themselves prove full Chrome Site Isolation parity.

Sandbox and broker evidence

• no --no-sandbox, single-process or equivalent production escape;
• enumerate sandbox status for renderer/GPU/utility/helper processes;
• no Node/Electron or generic native APIs in untrusted content contexts;
• every native broker request binds app ID, origin/site, frame/SiteInstance, renderer process, capability, validated arguments and user action;
• reject stale, replayed, cross-app, cross-frame and process-reuse sender identities;
• default-deny filesystem, shell, process, devices, clipboard, downloads and external protocols.

Patch-path drill

A candidate is not acceptable merely because it bundles Chromium. Perform a real or simulated upstream security-update drill:

1. detect a new upstream Chromium/CEF/Electron security release;
2. identify applicable CVEs and dependency delta;
3. build all supported platforms;
4. run the full isolation/security/regression corpus;
5. generate SBOM, provenance and signed artifacts;
6. stage rollout;
7. perform rollback and interrupted-update recovery;
8. record elapsed time and manual effort by phase.

Metrics:

• upstream-release-to-candidate latency;
• candidate-to-staged and staged-to-general latency;
• build success rate by platform;
• regression/failure count;
• rollback and recovery success;
• supported-field versions still vulnerable after the target SLA.

Performance and compatibility measurements

Record raw samples, environment and distributions rather than one synthetic score:

• at least 30 stabilized cold launches per OS/runtime;
• cold/warm median, p95, MAD and bootstrap 95% CI;
• idle RSS and RSS for 1, 5 and 10 isolated apps/sites;
• memory slope beta_RSS = Cov(n, RSS_n) / Var(n);
• idle/active CPU and GPU-process behavior;
• runtime/package/build-cache sizes;
• Web API, Wasm, accessibility, keyboard and IME compatibility;
• crash containment and recovery rate;
• cross-app/cross-site storage leakage attempts;
• sandbox and Site-Isolation coverage;
• reproducible-build/SBOM/provenance coverage.

Hard vetoes

A candidate fails the T3 gate if any supported platform shows:

• cross-site iframe not isolated into the required renderer process;
• successful cross-app or cross-site data access contrary to policy;
• native capability access with zero grant or wrong sender;
• unapproved navigation, popup, download or external protocol;
• production dependence on --no-sandbox, single-process or disabled Site Isolation;
• unrecoverable host corruption after renderer/GPU/utility crash;
• shared app/profile identity contrary to the selected mode;
• unknown, externally uncontrollable or SLA-incompatible engine-update responsibility;
• non-atomic or unauthenticated runtime update/rollback;
• inability to reproduce the process/isolation evidence on the exact release build.

No memory, launch-time or bundle-size advantage may override a hard veto.

Decision rule

• Prefer CEF Chrome Runtime/Bootstrap only if it meets all hard gates without a fragile long-lived fork.
• Escalate to Full Chromium downstream if CEF cannot expose or preserve required Site Isolation, IWA/package integration or security-update hooks.
• Use Electron only if the enlarged Electron/Node trust surface is demonstrably constrained and its release cadence meets the patch SLA; official Electron guidance that it is not a browser and should not load arbitrary untrusted content is a material negative prior, not an automatic rejection.
• Tauri/system-WebView remains outside the APP-01 T3 final set unless new evidence overturns the patch-control and isolation gaps.

Acceptance

• P0 architecture: define offline acquisition modes for foreign webapps #30 mode requirements incorporated;
• exact runtime/bootstrap/version/flags pinned;
• common fixture and assertions independently reviewed;
• SiteInstance/frame/process evidence committed;
• sandbox/broker evidence complete;
• Windows measurements complete;
• macOS/Linux complete or scope explicitly reduced;
• real patch and rollback drill complete;
• security veto table complete;
• raw results and analysis reproducible;
• owner decision records trade-offs and rejected alternatives;
• independent final-head security review.

Primary references

• Chromium Site Isolation: https://www.chromium.org/Home/chromium-security/site-isolation/
• Chromium sandbox: https://chromium.googlesource.com/chromium/src/+/HEAD/docs/design/sandbox.md
• CEF general usage: https://chromiumembedded.github.io/cef/general_usage.html
• CEF Chrome Runtime/Bootstrap context: alloy: Include built-in Chrome isolated origins chromiumembedded/cef#3672
• Electron security: https://www.electronjs.org/docs/latest/tutorial/security
• Electron release timelines: https://www.electronjs.org/docs/latest/tutorial/electron-timelines

No runtime is selected and no hostile-content safety claim is made until the acceptance evidence exists.

[marcohost33-maker]

Reframe-Update (Marco G1 = T3, 2026-07-14): Unter dem T3-Ziel (arbiträre fremde Apps) ist Electron/CEF (gebündeltes Chromium) der Haupt-Runtime-Kandidat für APP-01 — Tauri/System-Webview reicht für Fremd-App-Site-Isolation + kontrollierbaren Engine-Patch-Pfad nicht (Tauri bleibt für die eigene KI-Shell APP-02, dort bereits gemergt). Spike-Fixture daher gegen Electron/CEF priorisieren; hartes Cut-Kriterium ergänzen: von uns auslieferbarer Engine-Security-Patch-Pfad (gebündeltes Chromium selbst patchen vs. OS-System-Webview).

[marcohost33-maker]

Cross-family review (007acc 2026-07-16) → runtime hard-gates (ChatGPT)

ChatGPT hardened the decision rule; key corrections (some already applied in 265bf62):

• No candidate is pre-selected. "Electron = fastest prototype" is a hypothesis, not evidence.
  Electron, Tauri/WRY, WebView2-direct and CEF are all measurement candidates decided by the
  same corpus + neutral hard gates. CEF must be measured as a real control or dropped from conclusions.
• Site isolation ≠ origin isolation (Chromium default = site = scheme+eTLD+1; check same-site-cross-origin).
• Patchability is end-to-end: measure upstream-fix → installed-user-version latency, plus min-version,
  emergency-block, rollback, vendor-support — a bundled Chromium is not automatically faster.
• T1 runtime need not be the T3 runtime. An explicit split architecture beats weakening a hard gate.
• Shared gates: identical signed fixture + versioned adversarial corpus; ≥30 cold-starts/OS; 1/5/10 isolated
  profiles (cookies, permissions, cache, IDB, SW, downloads separated); negative navigation/popup/download/
  protocol/cert/permission/IPC tests; crash/hang/memory-pressure recovery; measured patch latency; no
  aggregate score compensates a failed hard gate.
• Per-candidate gates (Electron fuses/sandbox/session-partition; Tauri capabilities = bridge-containment only;
  WebView2 env/UDF per app; CEF sandbox on, no generic JS bridge) — see ADR-006.

Source: ChatGPT 007acc v2_HARDENED, primary sources (Chromium Site Isolation, Electron security/sandbox/
fuses/timelines, Tauri capabilities, WebView2 process model, WICG IWA, TUF).