Permissions and trust #9

Status reconciliation, 2026-10-02

Trust has two concrete unresolved items. Packaged extension caller checks, stale-document rejection, native backend auth and the Firefox optional-host refusal/grant/removal/regrant sequence are implemented and verified. The Chrome native permission sequence has not completed: its first interactive attempt granted access during the refusal step, so no passing manual receipt exists. The authority review confirms that background-owned content execution can proceed through native browser APIs without a new SDK trust policy. Page-originated privileged RPC remains unimplemented; a specific host must decide its exposed operations if that relay is introduced. Current rejection tests do not grant relay authority. Native document/frame denial and lifecycle acceptance remain required.

Current full CI passed at 52bc770bde38ecb2042aa4713a32a1c87abc4c56 for all maintained scenarios; it does not certify the unimplemented or untested cases above. Earlier dated checkpoints record their historical state.

Reconciled status, 2026-10-01

c84fcf1 adds native optional-host permission controls and maintained Chromium/Firefox trust suites. The actor/operation table, diagram, commands and receipts record the implemented boundary without changing SDK contracts, native auth or Port admission.

• Both browsers reject actual content-script Ports with forged packaged-sender message fields, as well as wrong-channel packaged callers. Actual Devframe action/state-read frames receive no replies; the attempted service-disable action has no effect and the admitted panel still works.
• Native document IDs reject a replaced top-level document; explicit current-document selection succeeds. MAIN code has no extension runtime.connect in the fixture.
• Firefox's real optional-host prompt refusal/grant, removal/regrant and permission events reaching another panel pass. Each fresh native injection checks current access. This does not promise rollback or termination of already-running work.
• Chromium proves ungranted optional-host rejection. Its extension prompt grant/refusal and post-grant removal still need a manual receipt; website permission overrides are not equivalent. The README gives the exact manual sequence.

The first full CI run caught a regression in these new controls: Firefox omits chrome.permissions in DevTools documents. ab39e95 detects the missing API, disables the controls with an options-page direction, and keeps the panel connected. The focused Firefox test now opens the real DevTools panel and asserts that unsupported case. No background permission broker or replacement API was introduced.

Local evidence: Chromium 153.0.8010.12 and focused Firefox 157.0. Type checks, strict Oxlint, Oxfmt, production builds and all 3 extension bundle tests pass. CI runs both new commands; the full Firefox suite remains pinned to 156.0.1 while its separate 157 sidebar selector is tracked under #16.

Full CI is green on ab39e95: repository builds/types/strict lint/format/unit tests; Chromium and Firefox extension suites; both new trust commands; native renderer/Vite/debugger integrations; and concurrent Chromium/Firefox development reloads. CI verifies the Firefox prompt and DevTools availability checks on its pinned 156.0.1, alongside the local focused 157.0 receipt.

Existing Port framing/codec/close, rich values, unsupported functions, disconnect, failed mounts and native server auth/origin rejection remain covered. A privileged page relay, child-frame/resource policies, private-state isolation and untrusted-recipient error disclosure remain open. CDB-specific approvals remain optional capability behavior, not a second mandatory authorization layer. Earlier checkpoint comments are historical evidence, not reopened decisions.

Accepted two-layer selection amendment, 2026-09-27

The owner chose typed command/results with native state observation, and implementation-owned applicability. Contract migration and authenticated native proof are on main. The architecture diagram and API examples supersede the earlier universal target contract and A1/A2/B mapping questions.

Client selectors choose realm/provider recipients. Selected action/service implementations inspect schema-defined domain/resource input and return their own declared result, such as applied or not-applicable. There is no SDK target envelope, target resolver, accepts hook or new topic/event bus. A not-applicable result is fulfilled; it neither makes the provider unavailable nor triggers fallback/replay. If multiple selected implementations match, all may act.

Provider incarnation, contribution activation generation, exact versions, native authorization/serialization and dispatch ownership remain unchanged. Browser/debugger capabilities still validate actual resources and permissions.

Part of Design a portable contribution SDK and WebExtension runtime.

Remote adapter prerequisite review, 2026-09-27

Updated in 4852525. The affected server package passes strict Oxlint, TypeScript and all 22 tests, including two native serialization compatibility tests.

The local router is implemented. The earlier Q4/Q5 recommendations in ffcc8f1 are superseded by the owner's upstream-first direction: ordinary native connections retain native authorization and serialization. A second mandatory SDK policy or JSON-only business payload restriction is not an implementation prerequisite.

The updated remote boundary record records native auth/session behavior, meaningful method-level authorization, the public records serializer, and the remaining cleanup/extension bridge gaps. The installed public codec preserves structured values through a JSON envelope; structuredCloneSerialize rejects a function where structuredCloneStringify can silently drop an object property. These entry points are not interchangeable for strict rejection. Real extension transport proof remains outstanding.

That dated investigation is now resolved for target-free native calls in 0c170ec: finite host/client definitions, removable adapter listeners, an authorized catalog query and payload-free invalidations. The owner accepts local cancellation without backend unary cancellation. 48 server tests include authenticated delivery, denied access, metadata guards and cleanup. The browser example runs on both hosts. Full repository CI passed at dfef733: builds, types, strict lint, formatting, packed-consumer checks and tests.

The target authority investigation separates authenticated RPC caller identity from exact-document authority. The owner removed the universal target contract. Capability implementations own resource selection, applicability and freshness; there is no generic mapping question left. Complete actors/permissions, real extension sender checks, target freshness, error disclosure and state privacy remain open. This is not the complete permission matrix.

Upstream integration boundary, 2026-09-27

Inherit native authentication and authorization for ordinary Devframe calls. Preserve authorize(methodName, session) and actual getCurrentRpcSession() ownership; custom native authorize overrides replace rather than automatically compose the default gate. Reuse devframe/utils/structured-clone for explicit bridge encoding. Page-to-extension and target authority still require checks at the boundary that gains privilege. No mandatory second SDK policy callback, JSON-only business-value restriction or new codec is introduced.

See the implementation and map review. This narrows implementation mechanisms without dropping the accepted feature or real-host coverage requirements.

Question

Which actors may invoke contribution actions, read or change shared state, inject code, transform traffic, and control debugger targets? Decide how permissions, trusted extension contexts, and authenticated server peers combine without treating page messages or rendered JSON as authority.

Context and current behavior

The SDK will compose executable contributions at build time and present shared interfaces through a JSON renderer. Those choices do not make every caller trusted. The inspected page, content script, extension background, popup, options page, DevTools page, renderer, and server peer have different privileges and lifetimes.

Chrome content scripts normally run in an isolated world, while main-world code shares the page's environment. A page can observe or interfere with main-world logic. A message relayed through a content script does not become a user decision. Chrome also provides optional permissions and temporary activeTab access, which have different lifetimes.

CDB already separates presentation intents from trusted approval, then binds authority to principals and target generations. Its architecture is useful input when the optional adapter is composed. The generic SDK must preserve that boundary without imposing an agent-grant workflow on every ordinary local contribution.

Packaged executable modules and remote JSON data also need a clear boundary. Chrome's MV3 policy permits data and configuration but restricts remote executable logic, including complex command interpreters disguised as data. Firefox requires self-contained executable code.

Requirements and scope

• Define actors, trusted entry points, target identity, permission ownership, and the actions each actor can request. Cover both extension and server adapters.
• Keep contribution composition at build time. Decide whether compiled-in modules are mutually trusted; do not imply a sandbox between modules sharing the same extension process.
• Expose native realm context only to local code in that context. Define the serializable action, state, error, and capability descriptions that may cross RPC.
• Scope operations to the correct tab, frame, document, origin, and connection where those identities matter. A stale popup or reconnecting page must not redirect an old action onto a new target.
• Define required versus optional permissions, user activation requirements, denial, revocation, and availability changes. Avoid silently requesting broader authority to satisfy an unavailable capability.
• Keep transport authentication and final action authorization separate. Renderer visibility, a disabled button, and a known action name do not authorize execution.
• Specify storage boundaries for public state and private credentials. Examples use synthetic data and must not expose credentials through shared state, logs, or error payloads.

Options and recommendation

Granting the entire extension every permission simplifies implementation but hides which module needs authority. Asking for approval on every action makes routine use cumbersome and duplicates browser or host policy. Treating all page-origin requests as trusted would cross the wrong boundary.

Preserve native host policy, explicit contribution capability declarations and browser permission requirements. Ordinary native calls inherit existing authority; introduce additional checks only for a concrete exposure or privilege transition. A trusted local operation may proceed under existing authority; a sensitive request crossing from a page or remote principal must pass the relevant authorization boundary. Prefer the existing native hooks, and preserve optional integrations’ existing grant model rather than adding a universal one.

Proposed API or experiment

Boundary pseudocode, not new SDK API declarations: native RPC supplies the trusted session and codec; a bridge validates any less-trusted source before forwarding:

ordinary native call:
  native method/session authorization
  -> adapter resolves registered contract and validates input
   -> capability checks its domain/resource applicability and permissions
  -> owned contribution validates input and executes

page request relayed through extension:
  actual browser sender + document/target authority check
  -> extension's existing authenticated connection
  -> ordinary native call path

The host derives caller authority from its authenticated connection or actual browser sender. Resource references supplied in operation input are requests, never proof of permission; the capability checks them against native resource authority. Produce sequence diagrams for a popup action, a page-origin request, a JSON renderer action, and a server-peer action. For each, identify validation, authorization, execution, result filtering, and cancellation ownership.

Scenarios and acceptance criteria

• A forged page message naming a privileged action fails before execution, even when its JSON matches the public schema.
• An authorized popup operation succeeds; denied permission leaves the capability unavailable with a stable reason and a usable UI.
• Revocation or navigation between validation and dispatch prevents stale work where possible and documents uncertain outcomes after dispatch. Mutations are not blindly replayed.
• Main-world events cannot fabricate CDB approval. Optional CDB integration preserves its principal, generation, and final-approval rules.
• Reload, reconnect, worker shutdown, and disposal release listeners and pending requests without leaking private state into another connection.
• Every public authorization and permission API, hook, and lifecycle event has a runnable example and automatic tests on all supported hosts. The overall suite includes contributions, renderers, Devframe, DevTools, Chromium, and Firefox; unsupported and denied cases are explicit assertions.

Use real browser permissions and real adapter connections for acceptance. Mocks may supplement adversarial cases, but stubbed authorization or compile-only examples cannot satisfy the contract.

Dependencies

Depends on Contribution and realm contract to establish local context, RPC boundaries, and module lifecycle, and Browser capability audit to establish available permission mechanisms and browser limitations. Security policy must attach to actual actors and capabilities.

Definition of Ready

• Identify each real authority transition and map SDK operations to meaningful native RPC authorization; prove the chosen public codec and registration cleanup.

• Dependency resolutions identify supported hosts, execution contexts, and serializable contracts.

• Every privileged capability has a proposed caller and target scope.

• Firefox fixtures exercise real native prompt refusal/grant, removal/regrant and navigation in a disposable profile without production credentials.

• Chromium native prompt grant/refusal and post-grant removal have a manual receipt; automated missing-grant rejection is already covered.

• The optional CDB approval and authority boundaries are available for comparison.

Definition of Done

• Authenticated native fixtures prove allow/deny; real extension fixtures prove packaged-page sender checks, wire values and disconnect cleanup.

• Both browsers reject forged content callers before native RPC execution or state disclosure and reject replaced document IDs.

• Firefox proves native optional-host refusal/grant/removal/regrant and cross-panel permission events.

• Privileged page relays, remaining target/child-frame authority and Chrome prompt acceptance have real-host evidence.

• An actor/operation matrix, trust-boundary diagrams, permission policy, and revocation semantics are accepted.

• Public authorization hooks, error outcomes, and local native-context rules are specified with concrete examples.

• Shared-state and credential storage responsibilities are assigned without coupling generic code to a downstream application.

• Every public API and hook maps to runnable examples and automated success, denial, unsupported, spoofing, and lifecycle cases on every supported host.

• Remaining security decisions and real-host gaps are recorded explicitly; implemented slices remain separate from acceptance of the full contract.

• The human has confirmed the resolution through discussion; the agent has not supplied the human side of the decision.

Resolution record

Post the accepted trust model, permission matrix, interface sketches, adversarial scenarios, and rejected alternatives in the resolution comment. Link it by this issue's title from the parent map.