Https-everywhere: Rewrite key portions of the code in WASM to get better performance

[Giltyhub]

Type: feature request

From the uBlock Origin release notes 1.17.4:

I will keep bringing in WebAssembly ("wasm") versions of key portions of code where it is found to be beneficial. In this release, a wasm version of the algorithm used to lookup a hostname from a set of hostnames has been created (related benchmark page).

However, only the Firefox version of uBO benefits from this at this point, as it's is not possible to use wasm in the Chromium version without adding 'unsafe-eval' to the extension's own Content Security Policy in its manifest -- which is not something I am willing to do (my view is that any extension using 'unsafe-eval' should be assumed malicious by default). It works in Firefox because the wasm module is loaded using a same-origin fetch, meaning the module can only be loaded from uBO's own package, which is probably what Chromium ought to implement.

Also, on Firefox/Linux, the WebAssembly module may fail to load due to a missing MIME type entry in the OS, see https://bugzilla.mozilla.org/show_bug.cgi?id=1500710 (solution is in comment 11).

It seems like a good idea if this can be investigated for HTTPS Everywhere as well.

[Hainish]

One of the considerations here is that WASM was disabled in Tor Browser: https://trac.torproject.org/projects/tor/ticket/21549

I'm unsure when this will be re-enabled, but until then we can't include it in Tor Browser builds of HTTPS Everywhere. We may be able to have divergent compilations and just enable code paths dependent on what browser we're building for, though. But this will introduce an increased maintenance overhead.

[Hainish]

This may be relevant to @gorhill as well, in case he knows of anyone using uBlock Origin within Tor Browser. This is probably uncommon but not unheard of.

[gorhill]

Latest uBO works with Tor browser. In uBO there is always a JS implementation available should the WASM version fail to load for whatever reason -- this way I don't need two versions of the extension. The WASM version of key portion of code is nice to have but does not make the JS implementation obsolete performance-wise. See https://github.com/ghacksuserjs/ghacks-user.js/issues/599#issuecomment-447640287.

[Hainish]

Thanks @gorhill, that's helpful. This seems a likely path forward for us as well, using a JS implementation as a backup. Still an increased maintenance overhead, but at least not divergent code generated based on build.

[Hainish]

Update: https://github.com/EFForg/https-everywhere/pull/18093 includes a submodule https-everywhere-lib which replaces much of the rules.js logic with WASM.