Skip to content

Store policy: define the isolated execution contract for model-authored and network-derived code #333

Description

@NotASithLord

Problem

Disabling first-class HTTP(S) module imports does not prove that the store
package executes only code bundled in the extension.

  • Script, Notebook, and App code can be supplied by the selected model.
  • Notebook and persistent Script workspaces can fetch source, save it locally,
    and import that file on a later run.
  • WebVM workloads can download and execute software inside the VM.

These contexts are isolated from direct extension APIs, but they have explicit
host bridges and different capability sets. The store policy position for that
architecture is not documented or cleared.

Why this matters

The dashboard remote-code answer must describe the whole uploaded artifact, not
only the module resolver's direct URL path. A narrow gate can reduce the surface
without supporting a blanket claim that every executable byte is packaged.

Acceptance

  • Inventory every context that executes user-authored, model-authored, or
    network-derived code in each store artifact.
  • For each context, document origin, CSP, extension API reach, host bridges,
    storage, network, and delegated capabilities.
  • Obtain a clear Chrome Web Store and AMO policy position for the isolated
    execution design, or remove the disallowed capability from the store channel.
  • Add artifact-level tests for the accepted boundary.
  • Make dashboard declarations, reviewer notes, privacy text, and security docs
    match the uploaded package without blanket claims.
  • Keep preview behavior separate from the store decision.

Related

Metadata

Metadata

Assignees

No one assigned

    Labels

    documentationImprovements or additions to documentation

    Projects

    Status
    Backlog

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions