Connection Allowlist and Context Menu Commands

[xiaochen-z]

Context menu commands—such as "Open Link in New Tab"—are a common way for users to initiate network requests (including navigation and downloads) using the URL of a selected HTML element.

For a document with a connection allowlist enforced, should this enforcement apply to network requests initiated via context menu commands?

Consider a page containing an LLM-generated anchor element:

• The URL of the anchor element's href attribute can be arbitrary, presenting a data exfiltration risk.
• An event listener like oncontextmenu can alter the href URL the moment the user opens the context menu.

Two options:

1. Enforce the allowlist for network requests initiated via context menu commands:
   • Mitigates exfiltration risks described above.
   • Requires more complex implementation.
   • May disrupt user expectations or perceived functionality.
2. Treat these network requests as browser-initiated (out of scope for the connection allowlist):
   • In Chromium, a navigation request triggered by "Open Link in New Tab" sets initiator_frame to null and browser_initiated to true. This indicates the navigation is treated similarly to a user typing a URL into the Omnibox and pressing Enter, which is out of the scope of the connection allowlist.
   • Leaves exfiltration risk unaddressed.

[mikewest]

As we've discussed elsewhere, I think it's pretty reasonable for the web-facing definition of Connection Allowlist to match other primitives we've introduced in this vein. Like CSP, I see these policies as governing the things that a page is allowed to do. I don't see it as immediately reasonable for them to limit users as well, and I'd initially err on the side of allowing requests via context menus in the same way that we'd allow users to copy the link and paste it into the omnibox (or, for that matter, to use one of the "Search this tab with Google Lens" or "Ask Copilot" or etc. options even though those are clearly exfiltration vectors in some strict sense). I'd prefer for the threat model we're working with to remain clearly focused on network connections the page creates.

That said, I think there's room for discussion about how sites might wish to limit the navigational opportunities they offer to users. I could imagine some mechanism by which we'd simply treat an <a href> attribute as invalid if it didn't match some asserted list of potential navigational targets. But I initially suggest that such a policy would simply be a different thing, targeting a different kind of threat. 🤷

[kbabbitt]

Thanks @mikewest. To clarify, since the README states that navigation is considered in scope: Would a simple link click be included? Or is that section of the README referring strictly to things like "script assigns to window.location"?

[mikewest]

Would a simple link click be included?

Hrm.

I think the answer should be yes (and they are enforced upon in Chromium's implementation). Users clicking a link seems like something that's directly under the page's control, and that kind of simple navigation feels different in kind to me than the other navigational options the user agent might offer when users dig in a bit. My intuition is that enforcing upon simple clicks is easily justified, and enforcing on context menu interactions isn't.

That said, I'm not sure I have a philosophically pure way to justify that answer given what I wrote above. :) I can certainly be convinced that they're actually only different in degree, and that we could find some reasonable principle that enforced upon "open in a new tab", while pushing things like "Ask Copilot" to the side.

WDYT?

[shivanigithub]

Would a simple link click be included?

Hrm.

I think the answer should be yes (and they are enforced upon in Chromium's implementation).

Confirming that simple link click is included in Chromium's implementation, test added in this CL