Conversation

An accurate/informative thread about the proposed changes in Chrome by the uBlock Origin developer, summarized in this conclusion: twitter.com/gorhill/status I recommend reading that thread and skipping all the fake news falsely claiming Chrome is removing support for ad-blocking.

Quote Tweet

R. Hill

@gorhill

May 30, 2019

I am not against the declarativeNetRequest API, and I am not arguing against the stated advantages -- they are legitimate. I am against the conversion of the webRequest API into a passive one and other changes crippling uBO's ability to seamlessly function as it does now.

Show this thread

This Tweet was deleted by the Tweet author. Learn more

Replying to

I don't quite know what you mean. Filter lists is how existing extensions work, and they implemented an equivalent to the EasyList / Adblock Plus style filters. uBlock Origin offers more power than that, but there's no reason it couldn't be how the built-in blocking engine works.

Replying to

and

These kinds of blacklists inherently don't work against an adversary putting any effort into bypassing the blacklists or detecting blocking and responding to it. It would need to keep being updated, and they can respond to each update. How could it be any different?

Replying to

and

Declarative filters are perfectly capable of supporting other things like a difference between first and third parties, etc. That's not a rigorous distinction since the first party server can be used to serve third party content to bypass that too. It can and does act as a proxy.

Replying to

and

There is no rigorous / fundamental way of blocking the ads or tracking going on in any of this. It's an opportunistic way of doing it and depends on there not being active work to bypass. Most of the stories / tweets that I've seen about this have definitely been misinformation.

2:31 AM · May 31, 2019Twitter Web Client

Replying to

and

webRequest doesn't even work properly for implementing a privacy or security feature. It's not a reliable API and is fallible. The failure mode is not blocking the request. It wasn't designed for the kind of privacy and security related features that it's being used to implement.

Replying to

and

An extension like HTTPS Everywhere is far better off with a reliable declarative list than intercepting requests / responses and making changes in a way that's treated by the browser as optional, and fails open when something goes wrong like the extension crashing or timing out.

Show replies