Re: I will not use this
No worse than anything else.
Seriously, the problem is not what technology you choose, but how stupid your browser manufacturer's are.
P.S. You've had a webassembly-enabled browser for several years now, I guarantee it.
Go play with Emscripten, which has been compiling to Webassembly for a long time already. It's basically bound by the browser DOM security model. If that was broke, it really doesn't matter *what* language you've been using.
But you'll notice that you can't access local files, you have to run code from remote websites (so you can't just be pointed at something compromised on a local network machine), that permissions to audio, video capture and everything else are: the same damn permissions you've got available to every website and are denying/allowing already. It doesn't allow arbitrary file, memory or resource access. Hell, you have to jump through hoops just to preload files from a website and access them in a virtualised storage in order to do anything on them, and the performance hit is enormous because of the way it's done (but still more than viable for 99% of things you want to do in a browser because, hey, it's a browser).
The only interesting thing is WebSockets, but that's no different to the myriad of websites that talk back in the same way over HTTPS already.
Honestly, if your browser is dumb, it doesn't matter what language it's dumb in.
And, no, if you compile a memory-unsafe language (say, C99) to WebAssembly, all that happens is that your code falls over inside the WebAssembly virtual machine. Arbitrary memory pointer access is actually faked by allocation of a giant array, for instance. There are some things you just can't do because the browser DOM and the inherent absence of a capability in WebAssembly stops you.