-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[DNR] extensionPath should not require exposing the target in web_accessible_resources #604
Comments
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. |
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. |
Superseded by #610. |
declarativeNetRequest's
extensionPath
should not require exposing the target in web_accessible_resources, because it's problematic:{cancel:true}
or{redirectUrl: 'javascript:0'}
and then redirect the tab viachrome.tabs.update(tabId, {url: 'own.html'})
- in Chrome's ManifestV3 implementation normal extensions can't use webRequestBlocking anymore;The text was updated successfully, but these errors were encountered: