3 ms·

The discussed API changes do not limit malware to snoop on browser traffic, requests can still be observed, and scraping is also not affected. Ad blocking is a

The discussed API changes do not limit malware to snoop on browser traffic, requests can still be observed, and scraping is also not affected. Ad blocking is arguably one of the best ways to protect yourself from malware, and that is the capability Google attempts to limit.

derefr 7y ago
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.
- dessant 7y ago
  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.
  - joshuamorton 7y ago
    I don't think the host permissions do what you think they do. 1. They don't address the performance issue. 2. They still allow redirection of requests, which is a bigger security issue. V3 fixes 2, which is a security issue, and a unique one if your threat model is a malicious extension.
    - dessant 7y ago
      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.
      - joshuamorton 7y ago
        > 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?
danShumway 7y ago
This also isn't even a first step where eventually privacy restrictions around observation will be added later. From the discussion thread[0]: > Chrome is deprecating the blocking capabilities of the webRequest API in Manifest V3, not the entire webRequest API (though blocking will still be available to enterprise deployments). Extensions with appropriate permissions can still observe network requests using the webRequest API. The webRequest API's ability to observe requests is foundational for extensions that modify their behavior based on the patterns they observe at runtime. It's not just that the people claiming that this will improve privacy are wrong about this specific change. Google's stance is that blocking request observation is fundamentally not acceptable, specifically because it would stop extensions from tracking and responding to user behavior. To all the people saying, "well, it's about time extensions got locked down" -- Google is not your friend and they don't want the same things as you. [0]: https://groups.google.com/a/chromium.org/forum/#!topic/chromium-extensions/veJy9uAwS00%5B101-125%5D https://groups.google.com/a/chromium.org/forum/#!topic/chrom...
- yellowapple 7y ago
  > though blocking will still be available to enterprise deployments So I guess the answer is to be an "enterprise", then.
  - danShumway 7y ago
    Not necessarily, since having the API available for you personally is only one part of the problem. The other question to ask is, will you even have an ad blocker to install, given that Gorhill has hinted these changes might mean abandoning Chrome as a target platform?[0] If enough ordinary people move to enterprise, Google will eventually restrict that as well. If not enough people move to enterprise, extension authors won't support Chrome and you'll be stuck writing or forking your own ad blocker. So you're gambling on being able to walk very thin line alongside a company that's already shown you that it is actively hostile to your interests. The more permanent answer is to just switch to Firefox and stop playing their game. Switching to enterprise will probably at best buy you some time before you're forced to make that decision. [0] https://github.com/uBlockOrigin/uBlock-issues/issues/338#issuecomment-456179825 https://github.com/uBlockOrigin/uBlock-issues/issues/338#iss...

derefr 7y ago

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.

dessant 7y ago
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.
- joshuamorton 7y ago
  I don't think the host permissions do what you think they do. 1. They don't address the performance issue. 2. They still allow redirection of requests, which is a bigger security issue. V3 fixes 2, which is a security issue, and a unique one if your threat model is a malicious extension.
  - dessant 7y ago
    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.
    - joshuamorton 7y ago
      > 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?

danShumway 7y ago

This also isn't even a first step where eventually privacy restrictions around observation will be added later. From the discussion thread[0]: > Chrome is deprecating the blocking capabilities of the webRequest API in Manifest V3, not the entire webRequest API (though blocking will still be available to enterprise deployments). Extensions with appropriate permissions can still observe network requests using the webRequest API. The webRequest API's ability to observe requests is foundational for extensions that modify their behavior based on the patterns they observe at runtime. It's not just that the people claiming that this will improve privacy are wrong about this specific change. Google's stance is that blocking request observation is fundamentally not acceptable, specifically because it would stop extensions from tracking and responding to user behavior. To all the people saying, "well, it's about time extensions got locked down" -- Google is not your friend and they don't want the same things as you. [0]: https://groups.google.com/a/chromium.org/forum/#!topic/chromium-extensions/veJy9uAwS00%5B101-125%5D https://groups.google.com/a/chromium.org/forum/#!topic/chrom...

yellowapple 7y ago
> though blocking will still be available to enterprise deployments So I guess the answer is to be an "enterprise", then.
- danShumway 7y ago
  Not necessarily, since having the API available for you personally is only one part of the problem. The other question to ask is, will you even have an ad blocker to install, given that Gorhill has hinted these changes might mean abandoning Chrome as a target platform?[0] If enough ordinary people move to enterprise, Google will eventually restrict that as well. If not enough people move to enterprise, extension authors won't support Chrome and you'll be stuck writing or forking your own ad blocker. So you're gambling on being able to walk very thin line alongside a company that's already shown you that it is actively hostile to your interests. The more permanent answer is to just switch to Firefox and stop playing their game. Switching to enterprise will probably at best buy you some time before you're forced to make that decision. [0] https://github.com/uBlockOrigin/uBlock-issues/issues/338#issuecomment-456179825 https://github.com/uBlockOrigin/uBlock-issues/issues/338#iss...