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
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.
1
2
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.
1
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.
2
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.
1
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.
1
Show replies