Ah, alright. Too bad, actually; I was hoping there was a silver lining.
Well, maybe—did the API previously give extensions the ability to rewrite the request in-flight? Such as e.g. to rewrite Amazon requests to embed the extension-author’s Amazon affiliate ID? I know extensions can do that, but I’m not sure how they accomplish it; it’d be nice if that could be quashed.
But really, you shouldn’t be equivocating the particular capabilities this API provides with the ability to block ads altogether. There are many ways to implement ad blocking, and not all of them require the capability to have your extension active “on the wire”, intercepting network traffic and doing arbitrary Turing-complete things in response with full extension-level capabilities.
Personally, from my perspective (and Google might share this perspective), this API was never “the ad-blocking API.” A true “ad-blocking API”—a single-purpose one that can’t be used for any other malicious purpose—is the thing Safari has, where your extension can feed a block list into the browser, and the browser will prevent network requests matching the block list itself, without ever informing your extension that it has done so.
Of course, Google would never implement that API in Chrome. And that’s the real problem.
I don’t blame Google for limiting some other API that isn’t really “about” ad-blocking, but which can be used to block ads as a side-effect; just like I don’t blame Intel for making their processors slower in response to Spectre/Meltdown. Sometimes security for users trumps useful features or performance.
But I certainly do blame Google for not implementing an API that has absolutely no security impact—is perfectly safe, perfectly performant—and blocks ads.
If anything has ever been decreed on-high from Alphabet to the Chrome team, it’s likely “don’t implement the Safari content-blocking API, or any standard based on it.” Not anything to do with this API. This API is just problematic, and the Chrome team themselves want its capabilities out of the hands of extension authors.
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.
Well, maybe—did the API previously give extensions the ability to rewrite the request in-flight? Such as e.g. to rewrite Amazon requests to embed the extension-author’s Amazon affiliate ID? I know extensions can do that, but I’m not sure how they accomplish it; it’d be nice if that could be quashed.
But really, you shouldn’t be equivocating the particular capabilities this API provides with the ability to block ads altogether. There are many ways to implement ad blocking, and not all of them require the capability to have your extension active “on the wire”, intercepting network traffic and doing arbitrary Turing-complete things in response with full extension-level capabilities.
Personally, from my perspective (and Google might share this perspective), this API was never “the ad-blocking API.” A true “ad-blocking API”—a single-purpose one that can’t be used for any other malicious purpose—is the thing Safari has, where your extension can feed a block list into the browser, and the browser will prevent network requests matching the block list itself, without ever informing your extension that it has done so.
Of course, Google would never implement that API in Chrome. And that’s the real problem.
I don’t blame Google for limiting some other API that isn’t really “about” ad-blocking, but which can be used to block ads as a side-effect; just like I don’t blame Intel for making their processors slower in response to Spectre/Meltdown. Sometimes security for users trumps useful features or performance.
But I certainly do blame Google for not implementing an API that has absolutely no security impact—is perfectly safe, perfectly performant—and blocks ads.
If anything has ever been decreed on-high from Alphabet to the Chrome team, it’s likely “don’t implement the Safari content-blocking API, or any standard based on it.” Not anything to do with this API. This API is just problematic, and the Chrome team themselves want its capabilities out of the hands of extension authors.