Shipping declarativeNetRequest doesn't imply deprecating blocking via webRequest though. It also appears that it's going to ship long before that happens. A better approach would have been implementing declarativeNetRequest and iterating on it before announcing any deprecation.
Conversation
I think they should cancel the current webRequest blocking deprecation and rethink it. They also need to be clued into the fact that the benchmark to match for content filtering is not EasyList / Adblock Plus anymore. They succeeded at doing that, but people want uBlock Origin.
1
2
10
uBlock origin funnily does not block everything either and does not allow all workflows, especially for false positives
1
Sure, all I'm saying is that they chose the wrong benchmark to use for matching the status quo. A blacklist-based approach is fundamentally not going to block all tracking / advertising and doesn't provide fundamental improvements to privacy and security. It's opportunistic.
1
It provides privacy and security improvements in practice, by opportunistically blocking a lot of stuff, but it's not a workable approach to fundamentally improving that in the browser. It can be bypassed by heavily tying it into actual 1st party content or just lots of changes.
1
The webRequest API itself was not designed for privacy / security improvements and has the failure mode of allowing requests. If the filtering extension crashes, times out or fails in some other way, the requests go through unfiltered. Making a robust replacement is important.
1
Lots of people are also harmed by malicious extensions. If you host a site with Content-Security-Policy and report-uri you end up with a huge number of policy violation reports for all kinds of naive and often malicious extensions injecting tracking and advertisements into pages.
1
The clever ones know how to remove the headers and meta tags for Content-Security-Policy, but many of them don't do that, since decent strict CSP policies are not common. It's a nice view into the world of what browsing is like for regular people. It's a very real issue.
1
The declarative API doesn't give extensions that power, so that's another advantage. It could still make sense to have a programmatic API for more complex use cases, but it shouldn't be normalized with such widespread use. They probably shouldn't distribute those without review.
1
i agree that ABP is a bad benchmark but so is uBO. lots of sites detect it, and that sucks.
1
They're detecting filtering in general, not uBlock Origin specifically. It's something that they're inherently able to do. It can be countered by a filter, which they can counter by changing their detection. They could also just keep changing how the ads are integrated, etc.
It's the reality of filtering with blacklists, especially when the content being filtered has arbitrary code execution with the virtual machine. Blacklists won't block all advertisements or tracking and they can't provide fundamental browser privacy/security improvements.
1
Show replies