WASM is great, but I think it's a wrong approach for sandboxing problem. It's technically possible to sandbox native applications (compiled into target machine code) using OS-builtin mechanisms, but it's not done for compatibility reasons, because this is the way things were done last 50 years or so.

1) Replace webhooks in web apps with wasm binaries provided by the customer, but that run in the web app servers.

2) Safer plugin system for professional software (plugins for photoshop, plugins for IDEs, etc)

3) Safer mod system for games and server-side mods that run on the game-maker server.

Point being you wouldn't run untrusted code in the first place and for "trusted code" you end up accepting it's access requirements anyway.

So logically I'd think that the malware would just get piggy bagged into actual non-obvious utility apps and nothing is gained.

Second problem is that the security model hoops make for terrible APIs and user experiences. Just look at the current filesystem browser APIs. It must be mentally challenging to design APIs to Be usable and the nerf them for security purposes to make them "not too usable".

Finally one must note that at least right now the webasm ecosystem is rather immature and the de-facto only tool (emscripten) is an amateur hour hobby project. So it's going to take some decades still before the tooling is really getting there.

As soon as you compile to WASM you no longer have the C FFI and the ability to call the OS systems interfaces for files, network and others.

It is extra work to move something to WASM vs just compiling it and running it in a sandbox.

I was mostly looking at it for its state as being a cross-platform supported output platform of bytecode that's fairly well sandboxed. That makes it an excellent target for things like running untrusted plugins in an application in a performant manner.