Conversation

That's not what's happening. The programmatic webRequest API is being partially phased out in favor of a of declarativeNetRequest. developer.chrome.com/extensions/dec It's not true that they're disabling ad-blockers. In fact, they added a built-in ad-blocking engine for extensions to use.

1

1

4

Replying to

and

I don't think it's helpful to spread misinformation about it. The main issue with the proposed draft of the declarative API is the limit of 30000 static rules which is still provisional and they should be pressured to raise it before it ships. It's also genuinely a good approach.

1

1

Replying to

and

It's very similar to Safari content blockers. A declarative API is more efficient and enables extensions to offer content filtering without needing to see the content of the requests / responses. There are still more complex valid uses for programmatic webRequest blocking though.

1

1

Replying to

and

such as JS blocking, which I refuse to browse the web without (e.g. NoScript on Firefox)

1

1

Replying to

and

No, that's still possible with the new API, especially with the added support for dynamic rules. I recommend reading over the API documentation at developer.chrome.com/extensions/dec. Just keep in mind the current limits are placeholders and they haven't decided on the real initial values.

1

1

Replying to

and

The placeholder values (30000 static rules, etc.) were set as a lower bound to avoid a situation like setting it to 3000000 and then needing to lower it to 500000 at a later point. It has been officially stated a bunch of times that the shipped values are going to end up higher.

1

Replying to

and

NoScript allows you to block all JS by default (the most secure way to browse the web). This doesn't allow for that AFAIK. NoScript also has other security features like XSS detection which needs to be able to read requests.

2

1

Replying to

and

if they care about the performance overhead they should work on that. if they're worried about abuse they should work on that. breaking web standards is lazy and monopolistic

1

2

Replying to

and

The performance and reliability issues with webRequest are tied to it fundamentally working based on intercepting, reading and modifying each request. That inherently involves communication between the browser core and sandboxed extension process running the JavaScript extension.

2

Replying to

and

I understand that. if they care, they can make that clear to end users. that way users can blame the extension for being slow instead of Chrome.

1

1

Replying to

and

What they should do is providing a capable enough declarative API to cover what users want, which means raising the rule limit at least 10x and providing stronger filtering functionality. They implemented an engine able to handle EasyList-style rules, which is the actual issue.

12:23 AM · May 31, 2019Twitter Web Client

Replying to

and

uBlock Origin goes beyond the standard EasyList / Adblock Plus filtering, but they used Adblock Plus as the benchmark. webRequest is fundamentally not a good approach. You may have noticed that if a filtering extension crashes or lags, filtering doesn't happen. It's not robust.