[Firefox] Evaluate using the new webRequest API to filter a response body on the fly

[gorhill]

As mentioned here: https://blog.mozilla.org/addons/2017/09/28/webextensions-in-firefox-57/.

This is a big deal for a blocker such as uBO.

One immediate use I want to evaluate is to be able to inject a site's scriptlets -- if any -- before any other inline script tags on the page. If uBO injects its scriptlets before all existing inline script tags in a document, this guarantees that the scriptlets win over these inline script tags.

For instance, if Chromium had this API, there would be no need for a separate extension to foil Instart Logic and other such nuisances.

[jspenguin2017]

Firefox extension API is getting better (although their timeline is absolutely ridiculous), being able to alter response body can be pretty useful, is there an open issue in Chromium issues tracker about it?

[gorhill]

There is also this new API to consider: contentScripts.register.

[jspenguin2017]

I obviously have not tried it nor have I read the whole thread, but my instinct tells me the API is intended for toggling features, like 3 or 4 files, maybe a bit more for Userscript host, probably won't work well for hundreds if not thousands of scriptlet filters that uBO has.
Related in Chromium issue tracker: https://bugs.chromium.org/p/chromium/issues/detail?id=471801

I think browser.webRequest.filterResponseData is the right tool to inject scriptlets "synchronously", you can disconnect the filter right away after the first bit of data.

[sebast889]

Just heads up contentScripts.register API has landed in Firefox 59 (edit: now realized it was implemented months ago but only just announced so you probably already know this).

[uBlock-user]

@gorhill I came across chrome.declarativeWebRequest API. Is this the chrome's version of FF's response body API ?

[jspenguin2017]

It's not. Either way, declaring 70000 rules will likely to dump performance down the drain.

[Hrxn]

This is similar to what is already in Safari, but as far as I know, it's not really used there..

It is significantly faster than the chrome.webRequest API because you can register rules that are evaluated in the browser rather than the JavaScript engine with reduces roundtrip latencies and allows higher efficiency.

True, it might degrade performance if all rules are used here, but I think it would be beneficial to use for the most common stuff etc.
At least in theory..

[jspenguin2017]

If you register the equivalent rule to raw webRequest filter, performance will go missing as well. So in that case, declarativeWebRequest is way faster.

But uBO will register one event handler for all URLs, and use custom algorithms to apply filters. That shouldn't be slower than declarativeWebRequest with proper tokenization and hashing. Also you can't use declarativeWebRequest to handle RegExp filters. Although the performance is still smoked by Brave with its ad-block written in C++.

After some research, I think that WebAssembly could speed up filters parsing, but using it for applying filters will likely to not work. Because you need to go from native code to JS to native code again, then back to JS and then back to native code again.

You can't really register part of the rules to declarativeWebRequest and use JS to handle the rest, because there isn't a way to exclude URLs from the normal webRequest, so you'll have to handle it in JS either way.