Settings for users to manage which websites/domains can use WebAssembly

[moonstein]

WebAssembly has undeniably expanded the horizons of web development and user experience. However, the potential for misuse and the rising concern surrounding malicious parties exploiting WebAssembly requires the implementation of some kind of permissions management. This would allow users to explicitly give permissions (more control) and promote more transparency.

According the article WebAssembly Is Abused by eCriminals to Hide Malware the "CrowdStrike researchers analyzed 12,291 unique WebAssembly (Wasm) samples from May 2018 to June 2021 and found that 75% of Wasm modules are malicious". They discovered that "cryptocurrency miners boost efficiency by abusing WebAssembly to achieve near-native execution performance" and they also "turn to WebAssembly to hide web-based malware".

Without a proper permissions management system in place, malicious code could use WebAssembly to harness the power of users devices to perform actions without their consent. A permissions framework would act as a crucial layer of defense, ensuring that only trusted sites can use WebAssembly. Apart from that, many users would like to have more control about which websites uses WebAssembly, given them the power to decide what a website can or cannot do with their processing power.

[Jon]

Thanks for submitting an idea to the Mozilla Connect community! Your idea is now open to votes (aka kudos) and comments.

[luis123456789]

Allowing for a per-domain / per-site permission (or, would I even suggest, per-container permission similar to proxy support) would improve not only privacy and security, but also privacy and security conscious *usage patterns* (aka: "light patterns", in contrast to "dark patterns"). Since ATM it would be normal for secure usage to have WASM disabled in user.js, but then when a site malfunctions due to lack of WASM:

1. it is first needed to diagnose that lack of WASM is the cause. Tutanota for example offers no diagnostic (merely a generic "browser unsupported" message, and not even console errors)

2. then the user needs to reenable WASM in about:config.

3. then after usage, the user needs to remember to redisable WASM in about:config. Or wait until browser is restarted.

A permission would also helpfully come with added control features, such as a toggle or command to manually delete all WASM-related caches.