I don't ever want to run untrusted code from the internet outside of a sandbox ever again. If WASI lives up to its full potential I won't have to - we'll have a robust, cross-platform sandboxing solution for running real applications.
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.
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.
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...
------
[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...
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.
Kind of strange that such experience still allows for WASM to be the target of C and C++ compilers, and there is no bounds checking support inside linear memory regions.
For example a SaaS services that accepts WASM plugins could provide a WASI that lets the plugin write to a object-store filesystem (like AWS S3) provided by the SaaS owner.
For example here is Gzip in WASM: https://github.com/ColinTimBarndt/wasm-gzip
You will of course need to include a lot of support code to provide the relevant syscalls and otherwise emulate the environment that the code expects. But there are plenty of examples of that at this point.
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.
But it doesn't need network access to be useful, so it doesn't have that permission and can't exfiltrate your data?
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.
Also security, Java has reflection so you cannot reliably sandbox java libraries
With WASM it may be the same, unless al major OS vendors integrate a WASM runtime so that it doesn't need to be installed separately.
It doesn't have to, the program can bundle its own jre as its often the case, and then you also don't have to worry about jre compatibility. Downside is then you have many jres installed and of course you can't trust their sandboxing.
The really big issue in this case is network effect, which is why I hope something can come out from the momentum building behind WASM.
I am currently developing a WASI runtime for exaequOS and Woua programming language that will target WASI and will have access to DOM through a virtual/dev/dom driver.
wex —dir /dev /usr/tests/woua/dom_demo.wasm
Really leave WASM on the browser.
I had a spec file sitting around for an OS project idea I had, where the kernel would just be the WASM compiler + a few small shim drivers, and everything else (including e.g. PCIe device drivers) would be WASM modules with WIT interface specs. I handed the spec off to Fable and it seems to have made a working proof-of-concept. Has a maximally-WASM OS running on browser/QEMU/Orange Pi. https://eo9.org
I don't quite understand why the Component Model is now suddenly a browser thing, and on top something that needs to be implemented natively in browsers instead of a convention between different compiler toolchains.
Keep that boondoggle in WASI and the Bytecode Alliance. WASM in the browser works just fine without the added runtime complexity.
Otherwise in a couple of years no one would care Component Model ever existed.
I confess I was quite frustrated at first when browsers all said no to wasi / wasm components. But honestly, it was the right call. It's taken so long to make wasm components happen, to get them far enough along to start really consider implementing. I can accept that as just the reality of what it takes for a small team to do such amazing work. I am so thankful for the folks who have kept this going, kept advancing.
But it's time now. 0.3 delivers an incredibly comprehensive & gorgeous suite of capabilities that offer a winning combination of characteristics (fast, lightweight, sandboxable, runtime composeable components) that is ideal for the web. I hope browsers can help get us set up for 1.0, help steer us forwards towards that spec, and I hope they're moving quickly towards being ready to implement!
> It works in the browser already, by bundling another browser runtime engine into wasm.
Note that that's not how JCO works: JCO unbundles a Component, emitting core wasm modules plus JS glue code. JCO also is a toolchain that can orchestrate turning JS into a Component, and that does bundle a JS runtime (StarlingMonkey), but that's not for running Components in JS/browsers, but for running JS in Component runtimes, such as Wasmtime.
It still hasn't really reached a breakthrough.
Billions use HTML+CSS+JavaScript. Who really uses WASM? There are of course users, but very, very few in absolute numbers. Many projects are not web-based really. For Autodesk Fusion, as one example for many, I have some mega-slow application that takes forever to work with in some cases on my laptop (it is not the fastest laptop, but I recently tested this on a faster desktop computer with 32GB RAM and it is still slow to no ends; using it all WASM based would be even slower I bet. That's not winning anyone over ...).
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.