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

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

1

1

8

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.

1

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?

1

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.

1

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.

1

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.

1

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.

1

Replying to

and

I'd personally rather have a declarative API that actually works properly, rather than a programmatic API which fails open and enables malicious extensions. I'm tired of ads and tracking injected into my web sites by extensions. They don't account for CSP and break the sites.

1

1

Replying to

and

Shipping the declarative API is not going to disable / deprecate webRequest anyway. They aren't disabling webRequest blocking when that ships. They proposed disabling it in the Manifest V3 draft. Remains to be seen what happens down the road. It's not in the immediate future.

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