WASM being used to exploit your PC isn't much of a risk, because it has a really robust security model. It's been used in exploit chains before but my understan

WASM being used to exploit your PC isn't much of a risk, because it has a really robust security model. It's been used in exploit chains before but my understanding is that the number of times people have found holes in WASM sandboxes is much smaller than the number of times people have found holes in JS runtimes. So it's pretty fit for purpose there. Unfortunately, the design of WASM and common compilers targeting it means that your security is at risk as a user, even though your PC is safe. Applications compiled to WASM have a wide variety of fun security vulnerabilities that have been gone on native targets for decades, which means that if (for example) Gmail moved to WASM, it would now be possible for malicious parties to attack your Gmail tab even though they can't attack your PC. Some examples: * Address space layout randomization is gone - if an attacker gets a write-anwyhere primitive, it will work 100% of the time * Function pointers are densely packed - any possible value within the correct range (0 - function count) is a valid function pointer, as long as the signature matches. Even worse than not having ASLR. * Page protections are gone - all data is mutable, even things that shouldn't be like string constants compiled into the binary * Zero page accesses don't trap - while compilers go out of their way to try and make reading/writing from null pointers fail in WASM, the actual runtime happily allows you to do it. This makes attacks easier to execute because while stray nulls would kill a native application on dereference, in WASM they will just yield a 0 and execution will often continue. * Most stuff is static linked - for native applications, it is common (albeit less common now in our modern era of Electron Hell) to pull in services from the OS and its packages, whether it's zlib or https or whatnot. The WASM runtime model generally offers a very limited set of capabilities in comparison, and there's no equivalent way to dynamically link against vendored packages that get security updates automatically. So every application ships its own ICU (for time zone and localization data), ships its own zlib (for compression/decompression), ships its own crypto (because the browser crypto APIs are extremely limited and async-only), etc... Ultimately WebAssembly runtimes are very secure, but you have to protect everything else from the code you're running, because the code itself can easily be attacked by uncontrolled input.