My apologies on the failure to communicate. I will step aside and let this article “Standardizing WASI: A system interface to run WebAssembly outside the web” hopfully make it clearer.
WebAssembly’s way of doing security is different. WebAssembly is sandboxed.
This means that code can’t talk directly to the OS. But then how does it do anything with system resources? The host (which might be a browser, or might be a wasm runtime) puts functions in the sandbox that the code can use.
This means that the host can limit what a program can do on a program-by-program basis. It doesn’t just let the program act on behalf of the user, calling any system call with the user’s full permissions.
Just having a mechanism for sandboxing doesn’t make a system secure in and of itself — the host can still put all of the capabilities into the sandbox, in which case we’re no better off — but it at least gives hosts the option of creating a more secure system.
On the plus side there are a lot of resources being poured into this problem via the WebAssmbly community and the Safe Browser is in a great position to leverage it. Sure an open source condition is not an absolute requirment, but there is a lot more automated checking you can do when say the Safe Browser verifies the WASM binaries itself once on first use. Combined with Safe Network’s immutable storage of code->WASM binary versioning it could provide quite robust basic security level.