There's a lot of hyperbole and exaggeration thrown around the subject of manifest v3 and declarativeNetRequest, but everything we've seen so far suggests that it really is an attempt to restrict ad blockers to a level Google is comfortable with (the level of Google's existing partner, AdBlockPlus).

Some relevant points:

- Google still hasn't raised the rules count like it announced last year in the blog post you linked. The current API is still limited to 30k rules. (the dynamic rule count is ridiculously low too)

- Even if the rule count were unlimited, having a static list of rules handicaps more complex algorithms like those used in uBlock Origin, that aren't limited to "if URL in URL_LIST then block". For instance, a Levenshtein-distance-based algorithm can't be implemented with declarativeNetRequest.

- Manifest v3 doesn't seem to prevent extensions from examining traffic, just blocking it. So Google's stance that its API is against data mining, not ad blockers in particular seems hypocritical.

- Similarly, its stance that the proposed API is more efficient is extremely dubious. Modern WebAssembly has close-to-C++ performance, meanwhile ads and analytics are one of the biggest source of slowdowns of the modern net. The idea that restricting adblockers would improve performance in the general case is absurd.

Overall I have the same view of adblockers as I have of pirate sites: they're very convenient for me and I like to have them, but I don't begrudge corporations for doing everything they can to get rid of them. In a world where most of the internet is funded by ads, I understand why Google would want to find ways to make adblockers just a little less powerful.

But Google's insistence that it isn't doing exactly that, and that its API is technically motivated, reads as corporate nonsense. They haven't responded at all how I'd expect them to if the whole controversy was just a misunderstanding.

> Even if the rule count were unlimited, having a static list of rules handicaps more complex algorithms like those used in uBlock Origin, that aren't limited to "if URL in URL_LIST then block".

Google is deeply afraid of machine learning based ad blocking. You can only camouflage ads so much before they don't serve their purpose. Forcing ad blockers to use a primitive blocking method prevents smarter ad blockers from being built.

> - Google still hasn't raised the rules count like it announced last year in the blog post you linked. The current API is still limited to 30k rules. (the dynamic rule count is ridiculously low too)

Manifest v3 is still in development, so I'm assuming that this simply hasn't happened yet. It definitely needs to fit uBlock Origin's default rule set and I don't see them backtracking on the 150k announcement.

> - Even if the rule count were unlimited, having a static list of rules handicaps more complex algorithms like those used in uBlock Origin, that aren't limited to "if URL in URL_LIST then block". For instance, a Levenshtein-distance-based algorithm can't be implemented with declarativeNetRequest.

This is the explicit trade-off that is being made. I'll gladly accept this limitation in exchange for not having to trust the ad blocker extension.

> - Similarly, its stance that the proposed API is more efficient is extremely dubious. Modern WebAssembly has close-to-C++ performance, meanwhile ads and analytics are one of the biggest source of slowdowns of the modern net. The idea that restricting adblockers would improve performance in the general case is absurd.

The blog post explains this - the issue isn't the (in the case of uBlock, carefully written and very fast) extension code, but the IPC overhead in routing all requests through the extension. The Chromium teams loves metrics and they wouldn't make this claim without having substantial data to back it up - it's not a matter of opinion, but objectively quantifiable.

> - Manifest v3 doesn't seem to prevent extensions from examining traffic, just blocking it. So Google's stance that its API is against data mining, not ad blockers in particular seems hypocritical.

The blocking version sits in the critical path, the non-blocking one can be called asynchronously. This is consistent with their reasoning.

With Manifest v3, blanket host permissions are going away, which addresses data mining extensions and would make the existing blocking webRequest API impractical: https://twitter.com/justinschuh/status/1138889508512866304

One point, Google regularly makes false announcements about unpopular changes. When they changed search results to better hide which ones are ads they announced they’d backtrack on it, then didn’t. When they started hiding parts of the URL they backtracked on it, waited a few months, then re-implemented it. When they decided “don’t be evil” isn’t really appropriate for them any more they said it’d only apply to Alphabet not Google, then waited a few months, then applied it to Google.

> the IPC overhead in routing all requests through the extension

The case has never been made that this is the issue of why wesites take long to load nowadays, and rather the finding is that content blockers help significantly page load speed.[1]

You seem eager to uncritically accept Google claims while leaving out the views of the critics.[2]

* * *

[1] https://www.debugbear.com/blog/2020-chrome-extension-perform...

[2] https://www.eff.org/de/deeplinks/2019/07/googles-plans-chrom...

There's no good reason for us to not be able to have 150k (or unlimited) rules now. The fact that we have this completely arbitrary and far too low restriction clearly shows that Google is not making even a passing attempt to enable adblockers to do their job.

> Ad blocker extensions are a major security risk

This is only true in the sense that an all-purpose browser is "a major security risk". That is to say, it's not true in any coherent sense.

Yes, the ad blocker needs to be trustworthy, and there are a variety of approaches for furthering that goal.

> Adblocker extensions need full access to all network traffic and all it takes is a single person's account or machine to be compromised to get access to millions of browsers.

Again, you could say the same about the browser itself. Even if it were infeasible for extension developers to implement more security safeguards, that would be a flaw in the Chrome Web Store, not in the concept of web extensions.

A trivial "backspace to go back" extension needs access to all sites. Fraudsters buy semi-popular extensions and load them up with tracking and link rewriting malware, unhindered by Google.

Their continued "refinement" of the core ad blocker APIs while all these abuses and deficiencies go unaddressed is extremely suspicious.

> A trivial "backspace to go back" extension needs access to all sites.

Yes, this is bad and a big security risk. I don't use any extensions that request this permission. My company even pushes a Chrome policy that outright blocks them.

Manifest v3 fixes this by taking away blanket <all_urls> permissions. This would break ad blockers, so they add declarativeWebRequest and remove the blocking webRequest API that would be useless anyway.

Chrome is a security risk. Blocking extensions because "security" is just taking away control from the user. Why should Google be the arbiter of whether something I install is secure or not?

Almost any browser extension is a security risk, because it can inject JS code into web pages.

If the tradeoffs were reasonable, ad blocker developers would voluntarily use the new API without Google forcing them.

the other way to keep extensions away is to use chrome's profile feature

I have one for banking, for example, with zero extensions