I think they're trying to say that an out of bounds memory access within the emulated WebAssembly machine can be caught by the WebAssembly runtime. (I don't know whether this is true; I hardly know anything about WebAssembly.)

The way they said it, though, makes it sound like WebAssembly is implemented with full process sandboxing or something, which is patently false. It works that way in neither Chrome nor Firefox, and there are no other browsers right now.

WebAssembly follows the unfortunate C paradigm that no checks are done at runtime, only these that programmer requests explicitly (and only if no undefined behavior is involved), to improve speed.

The WASM sandbox can call only set of specified host functions, but I expect so much functionality snowballing inside sandboxes that we'll have to allow everything including unsafe ones, anyway.

WebAssembly uses 32 bit indexes to access memory. The default way of implementing memory safety for it is to put a few gigabytes of dead address space before and after the memory a WASM program uses. This makes it impossible for the memory access instructions to escape, despite having no runtime checks.

So it can segfault all the way up to the machine level. But more importantly, it's safe for it to 'segfault' out of its allocated memory, because it can't reach any other memory with 32 bit numbers.

This is nothing new, memory space of a process in all modern OSes is protected so that segfaults are safe too. Combined with original UNIX idea of small tools that communicate by pipes it was fine.

But now the processes are behemoths with gigabytes of dynamically linked libraries that are too hard to secure and to restrict system access, we just enable everything. This will happen to wasm. I'm sure there are WASM blobs configured with unfettered access to DOM in the wild already.

> This is nothing new, memory space of a process in all modern OSes is protected so that segfaults are safe too.

Right, but look at what I'm replying to.

"The way they said it, though, makes it sound like WebAssembly is implemented with full process sandboxing or something, which is patently false."

Unlike with Javascript, the program hosting a WASM script is immune to corrupt pointers inside the script. That's equivalent to OS-level isolation, which is pretty good!

> But now the processes are behemoths with gigabytes of dynamically linked libraries that are too hard to secure and to restrict system access, we just enable everything. This will happen to wasm. I'm sure there are WASM blobs configured with unfettered access to DOM in the wild already.

There will inevitably be bugs in the code handling the html/css/dom/rendering. But WASM greatly reduces the attack surface of the scripting VM.

The types of bugs most likely to still exist with WASM are the types where isolating it in a separate process that communicates by pipes wouldn't help.