|
|
|
|
|
|
by gingerbread-man
2700 days ago
|
|
|
Could someone please help explain the technical details of this? From what I can gather from the chrome.webRequest and chrome.declarativeNetRequest documentation, it looks like this change would make it difficult to have long lists of blocked hosts, or perhaps to update such lists automatically. Obviously there is a conflict of interest here for Google, but it looks like there are at least a few non-bogus justifications for the proposed change. See also (especially the section "Comparison with the webRequest API): https://developers.chrome.com/extensions/declarativeNetReque... |
|
|
* 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...