[Product Gap] Ship a signed cross-platform Chromium distribution and update lifecycle

[seonghobae]

Buyer-visible gap

OriginWeave intentionally keeps Chromium as the web-compatibility kernel and places the governed Agent control plane in Rust. Protected main and active pull requests can test pinned Chrome/Chromium behavior, but a buyer still cannot install, update, roll back, verify, or operate a supported OriginWeave browser distribution.

A source repository plus a Chrome-for-Testing fixture is not a commercial browser product. Completion requires an exact release artifact and security-patch lifecycle that binds:

OriginWeave build
+ Chromium revision
+ protocol adapters
+ extension compatibility claim
+ native host policy
+ platform sandbox/profile behavior
+ signed updater metadata
+ SBOM/provenance

This issue owns that distribution and lifecycle. It does not authorize a Blink/V8 rewrite or a large Chromium fork before the first stock-Chromium vertical slice in #28 proves product value.

Product strategy

Use a staged architecture:

1. Reference runtime — pinned stock Chromium/Chrome-for-Testing plus separately signed OriginWeave Rust services and managed launch policy.
2. Minimal OriginWeave distribution — only the integration hooks needed for Agent side panel, isolated profiles, semantic observation, secret fill, policy, and evidence.
3. Supported release channels — signed stable, beta, and development artifacts with tested update/rollback.

Chromium changes must remain narrow, documented, and upstream-trackable. Product logic belongs in independent Rust services/crates wherever possible.

Supported platform contract

Define an explicit matrix for:

• Windows x86-64;
• macOS Apple Silicon and supported Intel transition policy;
• Linux x86-64 reference distributions/container profile;
• headless/server Agent Task runtime; and
• desktop Human/Assist/Agent Task modes where supported.

Each matrix entry must state:

• operating-system versions;
• architecture;
• Chromium revision;
• sandbox/site-isolation status;
• updater/installer support;
• native-messaging registration path;
• managed-extension policy support;
• codecs/DRM/Google-service availability or non-goals;
• accessibility/assistive-technology evidence;
• known limitations; and
• support sunset date.

Do not claim Chrome-compatible or universal extension compatibility. Publish exact capabilities proven by issue #27 and the release fixture suite.

Build and release artifacts

Every release must produce, where applicable:

• signed Windows installer/package;
• signed and notarized macOS package;
• signed Linux packages and/or OCI reference image;
• standalone headless runtime artifact;
• exact Chromium and protocol revision manifest;
• extension compatibility manifest;
• native host manifest/registration package;
• SPDX SBOM;
• SLSA provenance/attestation;
• license and third-party notice bundle;
• update metadata;
• rollback metadata;
• reproducibility manifest; and
• credential-free release verification report.

The release manifest must bind every artifact digest, source commit, toolchain, Chromium revision, adapter version, build environment, dependency lock, signing identity, timestamp, and channel.

Update architecture

Use Chromium Updater/Omaha/CUP-compatible behavior or a separately reviewed equivalent. Protect metadata and target artifacts through a TUF-style role and threshold model where practical.

Required properties:

• signed update metadata and artifact digests;
• channel separation;
• rollback/freeze/mix-and-match protection;
• staged rollout and pause;
• retry with bounded backoff;
• atomic install/switch;
• health validation before promotion;
• automatic rollback after failed health checks;
• offline enterprise update bundles;
• air-gapped verification workflow;
• proxy and enterprise network support without ambient authority bypass;
• update audit trail;
• signing-key rotation and compromise response;
• emergency revocation; and
• no downgrade below the security floor without an explicit signed emergency policy.

Already-created external transaction/update objects remain provider/channel sticky. A failed update must not cause the runtime to fetch an unsigned alternate artifact.

Security patch lifecycle

Define and test a published security response policy. Initial engineering acceptance targets are:

• actively exploited or otherwise critical Chromium/security fixes: supported release candidate within 72 hours of verified upstream availability;
• high-severity fixes affecting the supported boundary: within 7 calendar days;
• emergency kill switch or feature disablement when a safe build cannot be produced immediately;
• documented unsupported/end-of-life policy; and
• customer-visible security bulletin, affected-version range, mitigation, update, and rollback evidence.

These are release targets, not claims that the current pre-alpha repository meets them.

A scheduled job must monitor pinned Chromium, Rust, TLS/WebPKI, protocol, extension, updater, and packaging dependencies. It may create evidence/issues but must not bypass review, signing, or release authority.

Extension and native-host lifecycle

Compose issue #27 rather than duplicating Chromium extension implementation.

• Human Mode may use the user's compatible managed extension set.
• Agent Task Mode defaults to no extensions or an authenticated managed allow-list.
• Browser extension permission remains separate from OriginWeave Agent capability.
• Native messaging hosts require signed/managed registration, exact extension allow-list, process identity, bounded framing, and no ambient secret access.
• Extension/native-host update provenance must be recorded and tested independently from Chromium binary updates.
• Attached-tab mode must be visibly reduced-assurance when existing extensions can influence page state.

Process and profile isolation

Release acceptance must prove:

• ephemeral Agent Task profiles do not inherit cookies, local storage, extension state, history, caches, saved credentials, or policy from an unrestricted human profile;
• browser, renderer, GPU, utility, native-host, and Rust service processes are attributable to the exact task/distribution version under a reviewed platform model;
• teardown removes task-local profiles and terminates the owned process set under bounded deadlines;
• crash recovery and update transitions do not reopen stale browser/session/node authority;
• sandbox and site isolation remain enabled unless an explicitly documented platform exception is approved; and
• support bundles, crash reports, update logs, and installer logs contain no protected values or credentials.

Supply-chain security

• Pin GitHub Actions and build dependencies by immutable identity.
• Use hermetic or otherwise reproducible build inputs and preserve dependency lockfiles.
• Generate signed SLSA provenance and SPDX SBOMs for every release.
• Verify installer/updater/build identities through independent release gates.
• Test compromised metadata, stale metadata, key rotation, threshold signature loss, mirror compromise, artifact substitution, rollback, and partial-download recovery.
• Keep signing keys outside general CI credentials and require maker-checker release approval.
• Do not use release/signing credentials in product-development or review agents.

Realistic acceptance tests

1. Clean install on every supported platform/profile.
2. Upgrade stable N to N+1 while preserving only policy-authorized state.
3. Roll back automatically after a failed health check without accepting an older security floor.
4. Offline and air-gapped install/update verification.
5. Interrupted download, truncated artifact, wrong digest, wrong signature, expired metadata, rollback attack, mix-and-match metadata, mirror failure, and signing-key rotation.
6. Pinned Chromium/BiDi/CDP/MV3 compatibility suite bound to the exact release artifact, not a different CI browser.
7. Isolated Agent Task execution, browser crash, process cleanup, profile cleanup, stale-handle rejection, and recovery on each supported platform.
8. Native host registration/update/removal and exact managed-extension policy behavior.
9. SBOM/provenance/license bundle completeness and artifact reproducibility verification.
10. Update telemetry and support-bundle scanners find no secrets or protected values.
11. OriginWeave-owned production function, line, region, and branch coverage remain exactly 100%; public Rust APIs have complete rustdoc; packaging/update code has equivalent executable branch/edge coverage.
12. No skipped required platform lane is represented as a supported platform.

Documentation and ADR

• Add an ADR for stock Chromium versus minimal distribution, patch budget, supported platforms, updater trust, signing, rollback, emergency response, extension/native-host lifecycle, and reversal.
• Add a release BOM and Chromium patch inventory.
• Add platform installation, enterprise deployment, update, rollback, disaster recovery, signing-key compromise, and security bulletin runbooks.
• Update PRD, TRD, ARCHITECTURE, THREAT_MODEL, TEST_STRATEGY, OPERABILITY, RELEASE_AND_ROLLBACK, doctoring, UML/ERD/traceability, roadmap, README, AGENTS.md, CLAUDE.md, SECURITY.md, and CHANGELOG only as implementation becomes protected-main truth.

Dependencies and non-goals

Dependencies:

• [Product Gap] Complete the first real Chromium agent vertical slice #28 proves the real Chromium Agent Task runtime;
• [Product Gap] Prove Manifest V3 extension compatibility and isolate extension authority #27 proves the exact Manifest V3 compatibility and extension-authority matrix;
• [Product Gap] Publish a stable BAP/MCP runtime API with resumable task lifecycle #200 supplies the stable external runtime/API lifecycle;
• [Product Gap] Deliver schema-bound extraction with durable WARC/PROV replay #199 supplies durable release-task evidence where appropriate.

Non-goals:

• rewriting Blink, V8, Skia, or the Chromium extension system in Rust;
• promising Google account sync, Widevine/DRM, proprietary codecs, Chrome Web Store distribution, or other licensed Google services without separate legal/technical evidence;
• supporting every historical OS or CPU architecture;
• unsigned self-modifying binaries;
• allowing a product-development agent to sign, publish, or promote releases.

Commercial proof

A buyer can install an exact signed OriginWeave release on a declared supported platform, verify its Chromium/OriginWeave provenance and SBOM, execute a governed browser task, receive a security update through a tamper-resistant channel, and recover or roll back without losing policy, audit, or authority boundaries.

Standards and authoritative references — APA 7th

The Update Framework. (2026). The Update Framework specification, version 1.0.33. https://theupdateframework.github.io/specification/latest/

Open Source Security Foundation. (2026). Supply-chain Levels for Software Artifacts (SLSA) specification, version 1.2. https://slsa.dev/spec/v1.2/

SPDX Workgroup. (2024). SPDX specification, version 3.0.1. Linux Foundation. https://spdx.github.io/spdx-spec/v3.0.1/

Chromium Project. (n.d.). Chromium Updater design and protocol documentation. https://chromium.googlesource.com/chromium/src/+/main/chrome/updater/

Google Chrome Developers. (n.d.). Manifest Version. https://developer.chrome.com/docs/extensions/reference/manifest/manifest-version

Google Chrome Enterprise. (n.d.). ExtensionSettings policy. https://chromeenterprise.google/policies/#ExtensionSettings