feat(core): refuse Chrome downloads as Agent download - #175
Conversation
A Chrome downloads permission is compatibility evidence only. Adapters must fail closed before treating it as Capability::Download. Co-authored-by: Seongho Bae <[email protected]>
There was a problem hiding this comment.
Stale comment
Review — exact head
f6c089b8faae015c5b8845296af7cdc3ddcd0c65
chrome_permission_authorizes_agent_actionis fail-closed: a Chromedownloadstoken, and every other reviewed compatibility permission, cannot authorize AgentDownloador any otherActionKind. Case, empty, and control-bearing tokens stayUnrecognizedPermission. That is the correct adapter check for ADR 0013 rule 4.Next action: keep this primitive independent of MV3 runner PRs #43/#176. Do not treat a passing Chrome fixture as Agent filesystem authority. Wire adapters to call this boundary before policy, and add
commandsandwindowsto the reviewed-token list when those protected-main surfaces should be classified asCompatibilitySurfaceOnlyinstead ofUnrecognizedPermission. Both paths already refuse the action.Rust contracts, production coverage, and the pinned Chrome MV3 fixture succeeded on this head at review time. Remaining SAST/security/Strix/review workflows were still queued and are not promoted. This review is not an approval.
Sent by Cursor Automation: Fix Issues
There was a problem hiding this comment.
Review — exact head f6c089b8faae015c5b8845296af7cdc3ddcd0c65
The isolation primitive is sound and independent of the #43/#176 downloads runner. chrome_permission_authorizes_agent_action never returns Ok. Reviewed Chrome tokens including downloads become CompatibilitySurfaceOnly. Empty, case-shifted, newline-injected, and unrecognized tokens become UnrecognizedPermission. The ActionKind argument is intentionally unused so a Chrome permission cannot mint Download or any other Agent action.
is_exact_chrome_permission_token correctly admits mixed-case Chrome names such as sidePanel and declarativeNetRequest while rejecting DOWNLOADS and host-permission punctuation.
Residual, non-blocking
Protected-main MV3 evidence also exercises windows and commands. Those names are not in REVIEWED_CHROME_COMPATIBILITY_PERMISSIONS, so they currently classify as UnrecognizedPermission rather than CompatibilitySurfaceOnly. Both arms still refuse Agent authority. Add them only if an adapter needs the clearer diagnostic; do not treat the omission as a capability leak.
Stay draft until exact-head required checks are green. Do not fold this into the downloads runner, HTTP #37, or reserved MV3 drafts #49/#56/#59/#60/#61.
Sent by Cursor Automation: Fix Issues
|
Bugbot is not enabled for your account, so this pull request was not reviewed. Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs. |
seonghobae
left a comment
There was a problem hiding this comment.
Exact-head review found one current documentation-truth defect that must be fixed before approval. docs/traceability/extension-authority-security.md adds chrome_permission_authorizes_agent_action under the heading “Protected main already provides:”, but protected main is still 0c376acf059be9ddddddfbde1d0189e4f39ef014 and does not contain this PR-only function. That promotes active-PR behavior to shipped truth and violates the repository’s protected-main-vs-active-PR documentation contract. Keep the existing protected-main bullets unchanged and move/label this function as active/non-shipped PR #175 evidence (and make the docs/traceability/README.md wording equally explicit if needed). The Rust fail-closed implementation itself looks coherent on this head; exact-head CI, MV3, SAST, and Security are green. Please repair the truth-status wording without widening scope, then re-run exact-head evidence.


Buyer-visible gap
Partial implementation of #27. Active PR #43 can prove that pinned Chromium exercises
chrome.downloads. That compatibility proof must not become OriginWeave AgentCapability::Downloador filesystem authority. Protected main already evaluates explicit extension-to-Agent grants, but adapters had no reusable function that refuses a Chrome permission string as Agent action authority.Current exact implemented boundary
Protected main is exact
0c376acf059be9ddddddfbde1d0189e4f39ef014; current exact contributor head is52e42370ce49ad6142fb19eb0211f43716f19803.This active PR adds
chrome_permission_authorizes_agent_actioninoriginweave-core:downloads,bookmarks,history,storage,tabs,scripting,sidePanel,declarativeNetRequest,declarativeNetRequestWithHostAccess) returnCompatibilitySurfaceOnly;UnrecognizedPermission;Ok, so a Chrome permission cannot mint any Agent action includingDownload.This is IMPLEMENTED_ON_ACTIVE_PR, not protected-main shipped truth. This PR does not implement HTTP/1.1 (#37), revocation freshness (#48), MV3 downloads (#43), or a Chromium adapter.
TDD and documentation-truth repair
The first test-only compile failed because
ChromePermissionAuthorityErrorandchrome_permission_authorizes_agent_actiondid not exist. The production function was added after that RED.A later exact-head review found that
docs/traceability/extension-authority-security.mdhad incorrectly placed this PR-only function under “Protected main already provides”. Current head52e42370ce49ad6142fb19eb0211f43716f19803repairs the documentation truth boundary: protected-main capabilities remain listed separately and PR #175 is explicitlyIMPLEMENTED_ON_ACTIVE_PR. The same dossier also refreshes the exact active evidence for PRs #62/#63 without claiming those branches as shipped. No production behavior or gate was weakened.Exact-current gate state
On unchanged exact head
52e42370ce49ad6142fb19eb0211f43716f19803:31969518244: success;31969518201: success;31969518285: currently queued, not passing evidence;31969518231: currently queued, not passing evidence;CHANGES_REQUESTEDreview was submitted against predecessor headf6c089b8faae015c5b8845296af7cdc3ddcd0c65; it is historical evidence after the repairing push and is not converted into approval.The repeated unassigned-runner queue class is already routed to the organization control-plane incident
ContextualWisdomLab/.github#712; this clean head is not mutated merely to retrigger scanners.Integration gate
The active organization ruleset requires one qualifying approving review, dismisses stale reviews on push, requires latest-push approval, and requires review-thread resolution. Because this scheduled actor made the latest repairing push, it cannot supply the qualifying independent/latest-push approval. Required central workflows remain enforced independently from review state.
Keep this PR Ready until every applicable exact-head required workflow and a legitimate independent/latest-push approval are satisfied. Do not fold this into the downloads runner, #37, or reserved MV3 descendant lanes.
Standards
Chrome for Developers. (n.d.). chrome.downloads. Google. Retrieved August 16, 2026, from https://developer.chrome.com/docs/extensions/reference/api/downloads
Scope boundary
This fail-closed primitive separates Chrome compatibility permission from OriginWeave Agent action authority. It does not itself install an extension, parse Chrome messages, launch Chromium, grant filesystem authority, or prove the full #27 runtime boundary.
This scheduled actor does not merge, self-approve, tag, publish, alter workflows, add secrets, or weaken checks.
Partial implementation of #27.