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.

11:56 PM · May 30, 2019Twitter Web Client

Replying to

and

I think the solution is building an equivalent to the uBlock Origin engine into the browser. From my perspective, the main technical issue aside from obviously needing to increase the allowed rules is building an equivalent to the less capable EasyList / Adblock Plus engine.

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.

Show replies