3 ms·
> - 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 dyna
by 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 agoThere'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 agoOne 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...