> The Firefox version of uBO makes use of WebAssembly code for core filtering co...

the_duke · on April 9, 2021

UBlock already had a new version rejected a while ago. Big HN thread at the time.

Presumably they are just really careful to avoid giving Google any excuses.

10000truths · on April 9, 2021

My guess is that it’s much harder to review WASM bytecode to make sure it doesn’t do anything sketchy.

starwatch · on April 10, 2021

The approval process differs for extensions published to the Firefox and Chrome stores.

When submitting to the Firefox store you need to send them your un-minified, un-obfuscated source, along with step by step instructions on how to build. If you get big enough they do review the code in surprising depth. The hash of the compressed file pushed for release, also needs to match that of the compressed file the reviewer can build.

When submitting to the Chrome store this is not the case. You can push up minified, obfuscated code and that's what the reviewers have to work with.

I'm not familiar with why WASM needs extra permissions for Chrome extensions. It might be that the increased complexity of reviewing bytecode does indeed introduce more risk for the user. The permission request might just be the Chrome store pushing acceptance of that risk to the user?

ehsankia · on April 10, 2021

> You can push up minified, obfuscated code and that's what the reviewers have to work with.

Minified maybe, but obfuscated is against the rules, for over 2 years now: https://www.zdnet.com/article/google-to-no-longer-allow-chro...

Chrome also does check the code manually, not sure if it's on the same level as Firefox though.

starwatch · on April 10, 2021

yup, you're absolutely right [1]

  Code Readability Requirements:

  Developers must not obfuscate code or conceal functionality of their extension. This also applies to any external code or resource fetched by the extension package. Minification is allowed, including the following forms:

  - Removal of whitespace, newlines, code comments, and block delimiters
  - Shortening of variable and function names
  - Collapsing files together

[1]:https://developer.chrome.com/docs/webstore/program_policies/

antpls · on April 10, 2021

The whole point of WASM bytecode is that it doesn't need to be reviewed. The worse it can do is "stealing" your CPU time, but WASM was specifically designed to safely run third-party programs in the browser

dahfizz · on April 10, 2021

Surely the ublock devs are not writing WASM directly? It would be possible to have the source code available for audit with some way of proving it generates the assembly that is being shipped.

tmp538394722 · on April 10, 2021

Sorry anything is possible, but your comment is a bit hand wavy.

Reproducible builds are non trivial.

And then what - the reviewer is now supposed to build your software and verify some Hash?

Or were you thinking something else?

seba_dos1 · on April 10, 2021

> Reproducible builds are non trivial.

That's true, but they aren't rocket science either. It's perfectly reasonable to require them for browser extensions.

wnevets · on April 10, 2021

>And then what - the reviewer is now supposed to build your software

I believe that is standard operating procedure for the chrome store.

RamRodification · on April 9, 2021

Yeah that one sounds like a negative being described as a positive.

bassdropvroom · on April 9, 2021

I wouldn't say that. Using WASM is legitimate and will certainly give a performance boost at the very least. I'm just curious about the nuances of having it included in Chrome.

entropicdrifter · on April 9, 2021

Presumably one that allows the extension to run Wasm code

geku3 · on April 10, 2021

If extension requires new permission it wouldn't automatically update anymore until you allow it. It's enough friction for such an extension I guess, personally installed it for countless of people and most of them would just ignore updating it.