Conversation

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

> NoScript allows you to block all JS by default I'm well aware of what NoScript does along with extensions with similar features like uMatrix. > This doesn't allow for that AFAIK. I linked to the API documentation above which clearly shows that what you're saying isn't true.

2

Replying to

and

........ it requires that rules be registered before a page is loaded. therefore JS can't be blocked on the first page load.

1

Replying to

and

What you're saying simply isn't true, and is clearly incorrect based on the documentation. It's certainly possible to block JavaScript with a static rule based on type, along with including exceptions. If you look at the documentation, you'll see it supports dynamic rules too.

1

Replying to

and

again, the rules must exist before the requests happen in order to block them. NoScript-style blocking of all JS by default isn't possible with dynamic rules.

1

Replying to

and

As I said, it's certainly possible to block JavaScript as a whole based on type and to make exceptions. It's possible to make a NoScript-style extension with the new API. I don't understand why you don't think it's possible to do that. Do you see you can block JS based on type?

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

Replying to

and

It's definitely possible to have a global rule blocking JavaScript and make exceptions to the rule. There's nothing preventing that from being set up before pages are loaded. I don't understand what you see as a blocker to using it for that. It's not an example of what I meant.

1

Replying to

and

When I said "There are still more complex valid uses for programmatic webRequest blocking though", I didn't mean something like this which is covered by the new declarative API. By programmatic blocking, I mean changing the approach based on the content of requests/responses.

2

Show replies