In a real sense, WASM isn't a new VM. It's an evolution of Javascript, via asm.js, so it builds on the sandboxing that browsers need for JS. As part of that,

In a real sense, WASM isn't a new VM. It's an evolution of Javascript, via asm.js, so it builds on the sandboxing that browsers need for JS. As part of that, it really doesn't do very much. Other more general purpose VMs first let you do things. This has implications for running untrusted code: the JVM has never _quite_ managed to lock things down, and has a model where we restrict code that would otherwise have access (via reflection) to a lot of things we don't want it to have access to. WASM starts with a bounded set of "RAM" and the ability to define code that runs on a "CPU". There's no mechanism for the CPU to access anything outside of the data it's been explicitly allocated. That makes it more difficult to actually do anything, but also more difficult for malicious code to do anything it shouldn't. With much stricter invariants comes the ability to statically validate the invariants, too. Which is where projects like Mozilla's use of WASM as an intermediate format that's then converted to C are really interesting: correctly written C will maintain these invariants too, but we can't validate them directly. We can validate the invariants in WASM then maintain them by construction as we convert to C and onwards to native code.