Skip to content

[Product Gap] Prove Manifest V3 extension compatibility and isolate extension authority #27

Description

@seonghobae

Buyer-visible gap

OriginWeave is intentionally Chromium-compatible rather than a new browser engine, but the current Rust safety/network foundations do not yet prove that real Manifest V3 extensions continue to work or that extension authority stays isolated from Agent Task authority.

A buyer evaluating OriginWeave as a browser cannot accept Chromium-compatible as an architectural intention alone. The product needs an executable compatibility and security contract for the extension surface.

Product contract

Preserve Chromium's native extension implementation as the compatibility plane. Do not create a second Rust plugin ecosystem that requires reimplementing Chrome APIs.

The first supported compatibility matrix should cover, where available in the selected Chromium baseline:

  • extension install, disable/enable, update and browser restart;
  • extension service-worker start, suspend/restart and event delivery;
  • content-script injection and isolated-world behavior;
  • tabs, windows, storage, scripting, downloads, bookmarks, history, commands, sidePanel, declarativeNetRequest, and managed enterprise extension policy;
  • native messaging only behind an explicit host-managed allow-list and process boundary;
  • state restoration after browser restart;
  • extension update/version migration behavior;
  • compatibility evidence separated from Chrome-only Google service, codec, DRM, Web Store distribution, or licensing claims.

Authority boundary

Human browsing and delegated agents must not share ambient extension authority.

  • Human Mode may use the person's normal compatible extension set.
  • Agent Task Mode defaults to no extensions or a managed explicit allow-list.
  • An extension's Chrome permissions do not automatically become OriginWeave Agent capabilities.
  • Agent observation/action APIs are exposed to an extension only through an explicit OriginWeave extension_grant/policy decision.
  • Extension content, messages and tool output are untrusted observations, not trusted instructions.
  • A compromised or malicious extension must not obtain raw secret values from the secret broker or silently widen task origin/capability grants.
  • Attached human-tab sessions must be identified as reduced-assurance when existing extensions can influence page state.

TDD / compatibility evidence

Implement the smallest executable Chromium integration necessary to run a pinned compatibility fixture suite. Tests must include:

  1. a benign MV3 extension covering service worker + content script + storage + DNR;
  2. restart/update persistence;
  3. Agent Task isolation when an extension is not granted;
  4. explicit managed extension grant success;
  5. denial of extension attempts to widen agent origin/action authority;
  6. prompt-injection/untrusted-message treatment for extension-produced content;
  7. secret-broker non-disclosure;
  8. compatibility results bound to exact Chromium revision and OriginWeave build;
  9. repeated-run pass rate rather than one-off success;
  10. regression evidence for every extension API OriginWeave publicly claims to support.

Do not claim 100% Chrome extension compatibility. Publish an exact supported-capability matrix and known gaps.

Documentation / ADR

The canonical product documentation should include a dedicated extension-authority ADR covering:

  • Chromium //extensions retained vs Rust plugin rewrite;
  • Human/Agent Task profile separation;
  • extension permission vs Agent capability separation;
  • managed allow-list and signed/host policy;
  • update/supply-chain behavior;
  • native messaging boundary;
  • Chrome-only service/licensing non-goals;
  • compatibility test farm and release gate;
  • rollback/supersession conditions.

Update PRD/TRD/Architecture/UML/ERD/traceability only where the executable contract changes. Keep planned behavior labeled Planned/Proposed until protected-main integration exists.

Standards / primary evidence

Use current Chromium and Chrome Extensions primary documentation for the exact selected revision; record relevant sources in APA 7th style in doctoring/ADR. Do not treat experimental browser APIs as final standards.

Acceptance

Close only when an exact Chromium-backed fixture suite runs in CI/release acceptance, Agent Task extension isolation is enforced by production code, the supported MV3 capability matrix is published, the dedicated ADR is accepted, and the release gate fails when a declared compatibility capability regresses.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions