Conversation

Uhg. This is catastrophically broken if true - that would mean you can cram malware into a user's browser just by loading down the cpu so UBO is slow.

Quote Tweet

Daniel Micay

@DanielMicay

May 30, 2019

Replying to @DanielMicay and @RichFelker

In my opinion, a built-in content blocking engine with a declarative API is the right approach, rather than having asynchronous fallible IPC calls to an extension. For the current API, if the extension fails to respond in time, the content passes through without filtering.

Replying to

It happens in practice on my desktop Linux installation. If I'm doing a bunch of builds without bothering to set idle priority or even a low priority it can get bogged down enough that there's massive lag and filtering extensions start failing. OOM killer also likes killing them.

Replying to

and

If it crashes or gets killed for any reason, it stops working and the failure mode is that the requests pass through. I think this applies to all the browsers implementing the web extensions APIs. The webRequest API involves IPC calls to the extension and they're async/fallible.

Replying to

Failure mode should be everything inaccessible.

Replying to

That's not how webRequest was designed though. It was never intended to be used for filtering based on privacy / security reasons. It's designed to make asynchronous requests where the response from extensions is treated as optional for the browser to continue onwards.

Replying to

and

For declarativeNetRequest, there is no failure case like that, and it at least covers the EasyList / Adblock Plus style blocking right now. uBlock Origin has a more advanced approach, but unfortunately they targeted EasyList as the benchmark for content filtering functionality.

Replying to

and

This applies to more than content filtering extensions. It applies to things like HTTPS Everywhere. The way they're implemented right now is not robust. As long as they increased the static rules to a large enough value, HTTPS Everywhere could also be implemented via the new API.

Replying to

and

I've been frustrated about the lack of a robust way to do these things for years, and I see the current inadequate declarative API as some solid progress. I think the focus should be on pressuring them to make it good instead of all this fuss distracting from the real issues.

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

Replying to

and

It is definitely not good enough yet. Needs 10x more rules and they should be trying to get parity with uBlock Origin instead of EasyList / Adblock Plus which is what they did. Removing webRequest at the end of this year would be premature but I do think it needs a replacement.