For a language whose compiler already outputs safe binaries, this step would be redundant.
It's not that easy to write a safe compiler though. Would a compile toolchain that uses WebAssembly for all compilation be useful?
For a language whose compiler already outputs safe binaries, this step would be redundant.
It's not that easy to write a safe compiler though. Would a compile toolchain that uses WebAssembly for all compilation be useful?
The big difference is that the WASM sandbox significantly reduces the surface area of what bad stuff can be done.
Today, a compromise in the browser means the attacker can do whatever the browser can do (which is usually a LOT). With the sandbox, a compromise can only really affect what the sandbox has available to it. That means, if your sandbox only exposes a single method which takes in a string and returns a string, the worst thing an attacker can do is return a malformed string.
Of course, if you mishandle that returned string then bad stuff will happen but it's a far cry from the input string being able to potentially cause arbitrary code execution which installs a virus on your machine.
To really do something evil you have to not only compromise the code running in WASM, you have to find a way to break out of WASM. That's a lot harder to do.
Alternatively WASM could eventually support memory tagging like SPARC and ARMv8.
For example, a WASM based security module can just start logging-in everyone as admin, because the user metadata got corrupted.
Nobody is surprised that an exploit in the authentication module can be used to log in as admin. It is different if an exploit in the font rendering module lets you log in as admin.
They are just two (equally important but) orthogonal facets of security
It seems like there is some kind of cross-module memory protection? Maybe Erlang would be an interesting comparison?