They're changing how extensions can access web requests, in order to increase user privacy and prevent phishing. This requires all extension devs to change how they handle web requests. ublock is making a stink about how it's "targeting them", despite it being a change that all devs have to make, and you can still block ads with the new version. Adblock plus works fine with the new changes, for example.
No it isn’t. Your take is absolutely inconsistent with the on the ground impact of the specific technical changes in Manifest v3.
> and you can still block ads with the new version.
Based on a static, fixed limit of URLs. That cannot be updated without resubmitting the extension to Google for reapproval. Which match using a fixed, dumb matching algorithm that Google alone controls (negating a number of the more sophisticated pattern-matching based rules UBlock Origin relies upon).
> Adblock plus works fine with the new changes, for example.
That the crappy adblocker that has largely sold out to advertisers is unaffected by this change is hardly a ringing endorsement. Ublock Origin’s dev is complaining about this new API precisely because it cripples the much more sophisticated ad blocking rules that are Ublock Origin’s entire advantage over less sophisticated, less performant, less effective ad blockers like Adblock plus.
It's really not. The new mechanism for blocking ads is extremely limiting - not unlike what Safari provides. While Google's stated intention is to protect user's privacy it just so happens to cripple extensions that pose the greatest threat to Google's business. If Google wasn't one of the world's largest ad companies, perhaps their statements could be taken at face value. But perhaps in that case they would have taken the time to come up with an API that could achieve the goals of both Google and uBlock Origin.
Edit:
> Adblock plus works fine with the new changes, for example.
Adblock plus is an "ad blocker" who's main concern is protecting the interests of "good" advertisers, not those of its users.
42% of chrome extensions have abused the web requests API in it's current format, and Google has long since said they're going to change how it works to protect users' privacy.
uBlock Origin can change how they block ads for the new more secure manifest, just like AdBlock plus does. Even if you don't like ABP as a company it is an example of how it is still possible to block ads on the new more secure Chrome manifest, making it sensationalism to claim otherwise.
> 42% of chrome extensions have abused the web requests API
No. The accurate quote is (my emphasis) "According to Google, 42% of MALICIOUS extensions have used the Web Request API since January 2018".[1]
Note that the source for this quote is Google itself, so they picked this one statistic for publication. We do not know what else they found which is not published, i.e. it's potentially conveniently self-serving toward their manifest v3 narrative.
I reiterate: deprecating the blocking ability of the webRequest API will break key parts of uBlock Origin ("uBO"), and will break uMatrix completely, because of the hard-coded matching algorithm of declarativeNetRequest (there are other issues) which is merely an implementation to enforce EasyList-like rules.
I know how uBO/uMatrix extensions work, I wrote them from scratch. If you want to argue why they will work fine, you will have to do better they merely repeating Google's narrative regarding changes in manifest v3.
ABP will be fine because the primary purpose of ABP is to serve as a revenue source for Eyeo GmbH through its "Acceptable Ads" product (of which Google is a partner), which can still function just fine with the declarativeNetRequest API -- as shown by it's Safari iOS version.
Chrome Web Store allows extensions with remote code execution capability[2], this is the foremost issue and it's the one they could have fixed a long time ago with no API changes. That it has not been fixed is what you should be questioning.
There is no privacy benefit to v3, since it still allows dynamic notification of requests made by the page, it only removes the ability for addons to inject their own responses.
It's almost like someone sat down and asked "How can we get rid of ad blockers, without impacting spyware?".
> 42% of chrome extensions have abused the web requests API in it's current format, and Google has long since said they're going to change how it works to protect users' privacy.
So we're throwing the baby out with the bathwater because Google's extension approval process is so dismal it allows through a large minority of abusive extensions, and this is supposed to make us feel better about a change in the API that gives this dismal and apparently near-useless approval process more control over the contents and behaviour of ad blockers?
> uBlock Origin can change how they block ads for the new more secure manifest, just like AdBlock plus does
Which, again, entails UBlock Origin moving from a frequently updated list of blocking rules relying on sophisticated wildcard matching functionality to a hard-coded, fixed-size static list of blocked URLs that are not allowed to contain any wildcards for redirecting to more secure or private versions of content, and which cannot use any other kind of more complex ad-blocking logic. A hard-coded list of dumb blocked domains that is infrequently updated only with Google's approval (via the same dismal process that allowed through 42% of abusive extensions above...) of a complete re-submission of the blocking extension, approved or rejected at their whim and leisure, because live updating rulesets will also be banned "for security".
"UBlock Origin will be able to work every bit as poorly, and be every bit as easily defeated as Ad-Block Plus' unsophisticated, frequently useless filters are, plus its rules will get updated far less often" is, again, not in any way the good thing you seem to be pretending it is.
Just some highlights about this "great" change that you're signing the praises of, discoverable from the very link you posted:
> uBlock Origin heavily relies on pattern matching, and the extension developer stated that it is not possible to retrofit his extension’s matching algorithm to meet the APIs requirement. The API would also require a complete extension update to simply update the filter list, which would be a far too frequent activity considering the frequency with which these filter lists are updated. Of course, these updates would also hinge on Google’s extension review criteria and processes.
Hmmm.
> The blocking list must be present in the extension at install time and can’t be updated without updating the entire extension. This is subject to Google’s extension review criteria and processes. This means you won’t be able to opt-out of something like AdBlock Plus’ Acceptable Ads program, as the proposed new API doesn’t allow for rulesets to be turned on or off in the same extension.
Hmmm.
> declarativeNetRequest’s redirect action can only redirect to a static URL; meaning that you cannot redirect using the new API from a pattern like “://www.youtube.com/embed/” to “https://www.youtube-nocookie.com/embed/%2”. This is pretty much all my Privacy Enhanced Mode for Embedded YouTube Videos extension does, by the by.
Hmmm.
> Some extensions, like the EFF’s Privacy Badger that compiles lists of and blocks web beacons and trackers based on browsing activity (a method that breaks a fair number of websites), wouldn’t survive the transition.
Hmmm.
This API redesign "for security" just so happens to expertly fuck over the most powerful privacy and ad-blocking extensions, while leaving neutered crap like Adblock Plus With Mandatory "Acceptable" Ads working.
None of this is an accident. With Ublock Origin neutered out of usefulness, driving users back to Adblock Plus with mandatory acceptable ads that just so happen to whitelist Google will, of course, be a big win for Google's ad revenue.
