w3c / webextensions

Charter and administrivia for the WebExtensions Community Group (WECG)
Other
576 stars 50 forks source link

[DNR] extensionPath should not require exposing the target in web_accessible_resources #604

Closed tophf closed 1 month ago

tophf commented 1 month ago

declarativeNetRequest's extensionPath should not require exposing the target in web_accessible_resources, because it's problematic:

Rob--W commented 1 month ago

By design, web_accessible_resources blocks access from content unless explicitly allowed. When an extension redirects to an extension resource, the web page will try to fetch it. It is not possible to create an exception for redirects, because ultimately a direct fetch from web pages is indistinguishable from a redirect at the policy enforcement level.

If there is broader interest, I am willing to become supportive of a mechanism for extensions to declare web_accessible_resources as only exposed in response to a specific DNR request.

Ultimately, I think that the better approach to this problem is to not weaken the policies around network requests, but to introduce a dedicated way to synthetize a response body (and headers?) for a given request. On the Firefox side I filed a request for this feature at https://bugzilla.mozilla.org/show_bug.cgi?id=1712096.

tophf commented 1 month ago

The use case I had in mind was only about main_frame navigation (also sub_frame), sorry for not clarifying, it just slipped my mind. In this case navigation isn't performed by the page, but by the browser. I guess I should make another issue?

Extensions like Tapermonkey/Violentmonkey/Stylus and others want to redirect specific URLs to their own built-in UI page without exposing it to the web. URLs ending on .user.js or .user.css and such, so this is not solved by custom protocol handlers.

tophf commented 1 month ago

Superseded by #610.