[Panzerschrek]

> I don't ever want to run untrusted code from the internet outside of a sandbox ever again

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.

[tancop]

sandboxing native apps just gives you security. with wasm you also get a single portable binary that can run on x86 windows, arm64 linux and in your browser with zero modification. you dont need to write platform specific code or use third party frameworks.

[Panzerschrek]

> you dont need to write platform specific code

You don't need to write platform-specific code if you use some cross-platform framework. For simple programs it may be enough to use only the standard library of your language of choice.

> single portable binary that can run on x86 windows, arm64 linux and in your browser with zero modification

It has little value. Compiling a separate binary for each OS isn't that hard, since only a handful of architectures and operating systems are actually in use. Using an abstract cross-platform binary (like WASM) in the other hand adds extra performance costs and other user-side overhead, which isn't strictly necessary.

[pjmlp]

No you don't, because WASM is only compute, and you need exactly runtime specific code and third party frameworks for everything else as imported functions.

[hmry]

That's what WASI is for

[pjmlp]

And like CORBA, or POSIX, the portability does not work 100% as being sold.

[rvz]

Exactly. It is entirely a misconception to believe that WASM is this silver bullet on sandboxing and it is not that great security-wise I’m afraid.

It is only now being inspected by researchers and attackers who have found sandbox escapes [0] (chrome 0day), out-of-bounds [1] / use-after-free [2] and many other [3] flaws [4] in WebAssembly which I also agree that it is not enough for sandboxing at all.

[0] https://nvd.nist.gov/vuln/detail/CVE-2026-11645

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=2009901

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=2013741

[3] https://www.miggo.io/vulnerability-database/cve/CVE-2026-269...

[4] https://github.com/bytecodealliance/wasm-micro-runtime/secur...

[dns_snek]

There's no reason to believe that [0] has anything to do with WASM, [1] and [2] are runtime implementation bugs, [3] is a vulnerability in a "weak" sandboxing library VM2 - it has nothing to do with WASM as such, and [4] is another implementation bug in an experimental WASI feature of that specific runtime which is gated behind a build flag.

------

[Re: 3] https://github.com/patriksimek/vm2

> vm2 attempts to sandbox untrusted JavaScript code within the same Node.js process as your application. It does this through a complex network of Proxies that intercept and mediate every interaction between the sandbox and the host environment.

> JavaScript is an extraordinarily dynamic language. Objects can be accessed through prototype chains, constructors can be reached via error objects, symbols provide protocol hooks, and async execution creates timing windows. The sheer number of ways to traverse from one object to another in JavaScript makes building an airtight in-process sandbox extremely difficult.

[Re: 4] https://github.com/search?q=repo%3Abytecodealliance%2Fwasm-m...

[hobofan]

Those are not flaws in WASM itself, but in different WASM runtimes.

[GoblinSlayer]

Might as well run java or flash.

[DonHopkins]

But WASM is "lawnmower not included"!