3 ms·

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 i

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.

lima 6y ago
> - 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 https://twitter.com/justinschuh/status/1138889508512866304
- fouric 6y ago
  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.
- twhb 6y ago
  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.
- gorhill 6y ago
  > 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-performance-report#performance-impact-of-ad-blockers https://www.debugbear.com/blog/2020-chrome-extension-perform... [2] https://www.eff.org/de/deeplinks/2019/07/googles-plans-chrome-extensions-wont-really-help-security https://www.eff.org/de/deeplinks/2019/07/googles-plans-chrom...
throwaway189262 6y ago
> 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.

lima 6y ago

> - 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 https://twitter.com/justinschuh/status/1138889508512866304

fouric 6y ago
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.
twhb 6y ago
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.
gorhill 6y ago
> 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-performance-report#performance-impact-of-ad-blockers https://www.debugbear.com/blog/2020-chrome-extension-perform... [2] https://www.eff.org/de/deeplinks/2019/07/googles-plans-chrome-extensions-wont-really-help-security https://www.eff.org/de/deeplinks/2019/07/googles-plans-chrom...

throwaway189262 6y ago

> 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.