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.
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...
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.
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.
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.
Also security, Java has reflection so you cannot reliably sandbox java libraries
Golem is a durable workflow platform and can run any wasm.
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.
https://hacks.mozilla.org/wp-content/uploads/2026/02/Screens...
As per the article, that's temporary until Component Model 1.0 is implemented natively in the browser. In the meantime, jco can be used:
> The groundwork for browser implementations is being laid today: jco’s transpile command already converts any component into equivalent core Wasm and JavaScript glue, making components runnable in any browser without native support.
That's no longer needed once native support is there.
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.
Everyone who uses Amazon Prime Video: https://www.amazon.science/blog/how-prime-video-updates-its-...
Everyone who uses Google Sheets: https://web.dev/case-studies/google-sheets-wasmgc
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!
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.
Perhaps some people are happy to keep the status quo where each call between Wasm and the browser needs to roundtrip through a JS glue layer. But personally I'm excited about a future where that is no longer needed.
The only advantage you'll get is slightly faster string marshalling, which admittedly is important for DOM access, since the DOM is an extremely string heavy API.
Eliminating the glue layer completely would only be possible if the browser offers a separate 'WASM API' for each web API, but this is very unlikely to happen.
Otherwise in a couple of years no one would care Component Model ever existed.
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 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.
