Hacker News Reader

Comment by bassdropvroom | Hacker News Reader

> The Firefox version of uBO makes use of WebAssembly code for core filtering code paths. This is not the case with Chromium-based browsers because this would require an extra permission in the extension manifest which could cause friction when publishing the extension in the Chrome Web Store.

Anyone know what this extra permission is and why requesting this extra permission would cause friction?

View on HN

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.

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

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.

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?

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

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

> 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.

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?

> 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.

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/

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

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

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.

Presumably one that allows the extension to run Wasm code

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.

Reply on news.ycombinator.com