Hacker News new | ask | show | jobs
by 43920 2702 days ago
There's a couple of different issues with the proposed API:

* There's a limit of 30k blocked rules, which isn't enough to fully block every ad (for example, EasyList alone is 87k filters right now).

* The declarativeNetRequest API only supports a limited set of filter options. Currently, uBlock supports a bunch of additional options that give you more fine-grained control over what is blocked [0]; most of that wouldn't be possible in the new API.

* AFAICT, the ruleset can't be updated dynamically, which would prevent uBlock's dynamic filtering [1] mode from working.

Google's argument is that doing this improves performance (because it doesn't require communicating with the extension), and that it improves privacy. The privacy issue does have some merit - uBlock's author seems to be trustworthy, but other extensions might not be - but the performance argument in particular seems really shaky. uBlock's benchmarks [2] show that it takes around 0.1ms to decide whether to allow a network request. The only way it could noticeably impact performance is if the overhead of communicating with the extension process is really high, and that sounds like something Google should fix rather than eliminating it.

[0] https://github.com/gorhill/uBlock/wiki/Static-filter-syntax [1] https://github.com/gorhill/uBlock/wiki/Dynamic-filtering [2] https://github.com/gorhill/uBlock/wiki/uBlock-vs.-ABP:-effic...