There are different kinds of safety, though. There's sandboxing, which means that applications running in WebAssembly should not have access to resources they are not privileged to access. And there's memory safety, which means the WebAssembly application itself shouldn't try to break guarantees about memory. These are two separate things, and only the first can do things outside of breaking the website you're on.

WebAssembly protects you from untrusted code getting out of its sandbox and accessing data outside its own context, and that's the whole point.

But it will not (and hasn't been designed to) magically remove crashing bugs from your code, just as (e.g.) Javascript doesn't protect you from calling an undefined function.

But those bugs can't do any harm to your machine except crashing the WebAssembly application itself.

*this doesn't mean the sandbox itself doesn't contain bugs of course, but it's the job of the sandbox to prevent stuff running inside it from accessing stuff outside

Your system is safe from the arbitrary code. The article points out that WASM makes it really hard to catch memory bugs inside the app itself even though these bugs can't escape the sandbox.

> it has zero business being used to run arbitrary code that's automatically downloaded from the Internet

That has always been the very nature of the web.

Web Assembly, like other web applications, will be executed in a sandbox separate from other things. Isolation alone does not make it safe, but it does prevent corruption of other things.

This is why many websites execute advertisements in an iframe, because the code that comes across is not trusted and often not safe. The unsafe code will still attempt to stalk and/or attack the end user, but the iframe prevents that malicious code from corrupting the serving page. There is no reason expect anything different from WASM.