Conversation

This Tweet was deleted by the Tweet author. Learn more

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

There's no web standard involved in this. It's the Chromium extension API, not a web standard. They're moving to the superior declarative approach used by Safari. I recommend reading developer.chrome.com/extensions/dec and developer.apple.com/documentation/ rather than spreading misinformation.

9:37 PM · May 30, 2019Twitter Web Client

Replying to

and

how about you actually explain it instead of insulting people

1

Replying to

and

I haven't insulted anyone here. Can you please be specific about what you're claiming is an insult? I've looked through my tweets to confirm and I don't see anything that could be reasonably interpreted as an insult or personal attack. What exactly are you talking about?

1

Show replies