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