There are already ways to limit access to the webRequest API using host permissions, for which the user gives explicit consent.
Once the host can be accessed the webRequest API isn't even needed to rewrite requests and read or modify page content, all of it can be acomplished using content scripts.
There are really no meaningful security or privacy benefits in limiting the webRequest API in ways that are being proposed by the Chrome team.
Host permissions are required to access the requests through the webRequest API. Once you have set the host permission, you can redirect requests using a content script, without needing to touch the webRequest API.
The performance impact is negligible in sensibly implemented extensions, and there are several other ways to make the webRequest API more performant if that's really a valid reason for the change, some of which are already implemented in Firefox.
I don't believe most honest software engineers would rip out a core functionality of the browser that so many people depend on, just to gain a couple of microseconds, at least not before trying other optimization techniques.
> Once you have set the host permission, you can redirect requests using a content script, without needing to touch the webRequest API.
Then I'm a bit confused, why does this change cause a problem for ad-blockers? Can't they block and redirect requests via a content script after these changes?
No, you can't block requests from a content script as you would with the webRequest API. You can however redirect the page from a content script, read and replace page content, and steal passwords.
The webRequest API gives you fine control over all requests on the page in a performant way. A content script based ad blocker would be able to block ads to some degree by removing the DOM elements that initiate the request, though it would be limited, prone to breaking, and not performant.
Ah. I'm caught up now. That jives with my understanding.
(this was meant as an edit to the prior comment, if it seems out of place):
Looking into this more, I think what you're saying is that you can request both a content script and a host permission for the webrequest, and the user will approve both at the same time. But you have to specify them differently in the manifest, ie. it looks like
permissions: [
"declarativeNetRequest",
"<all sites>", // old way
],
host_permissions: [ // new way
"<all sites>"
],
"content_scripts": [
{
"matches": ["<all sites>"],
"js": ["contentScript.js"]
}
],
My (limited) understanding is one of the points of the new manifest is to make things more declarative so that they can be statically analyzed. So that, for example, host_permissions "<all sites>" might be allowed, but would require manual review, and content_scripts: ["<all sites>"] could be flagged even more strongly, etc.
If you don't specify the content_scripts portion of your manifest, you don't have the ability to write content scripts, so there isn't a security concern, you're limited by the declarativeNetRequest sandbox, and can't do the snooping.
For reference, uBlock, which I use, requests a ton in the manifest[0], and there are valid reasons for that (the userscript is, iiuc, for using the content picker). But a minimal ad-blocker could declarativeNetRequest, host:<all sites>, and nothing else, if I'm reading correctly. And that limited footprint can be statically validated. You know that extension can do nothing but modify requests, the way the requests are modified is statically verifiable. That sure sounds more secure to me.
Declaring content scripts in the manifest helps with performance and perhaps static checks, but it's not required to run code in pages, only the host permission has to be declared in the manifest, and you can just inject the code when the page loads: https://developer.chrome.com/extensions/tabs#method-executeS...
Malware would prefer executeScript to avoid scrutiny, and also wouldn't care about performance.
The declarativeNetRequest API is actually a welcome addition, but it's not a valid reason to deprecate parts of the webRequest API. We should be able to modify request headers for various use cases, some of which can't be forseen, because that's just how innovation works. This is why neutering that API is considered so harmful by pretty much everyone outside of Google.
If security and performance are an issue, webRequest API features can be decoupled into granular APIs, optimized, and accessed with granular permissions. The new proposed APIs do not even come close to the feature set of the webRequest API.
When feature parity is achieved through new APIs, deprecating the webRequest API makes perfect sense.
FWIW, it looks like changes to lock down tabs.executeScript and content scripts were originally considered[0], but I agree that tabs.executeScript not requiring a declared permission is a giant issue.
Thanks for this discussion btw, you introduced me to a bunch of quirks in the chrome apis I wasn't aware of.
I'm happy to chat, and I hope the discussed concerns about deprecating the webRequest API will motivate you to bring up the topic internally at Google.
Once the host can be accessed the webRequest API isn't even needed to rewrite requests and read or modify page content, all of it can be acomplished using content scripts.
There are really no meaningful security or privacy benefits in limiting the webRequest API in ways that are being proposed by the Chrome team.