I'm unreasonably excited about WASI. WASI is the thing which takes WebAssembly from a tool for running stuff in a browser to a tool that can run entire portable sandboxed applications on a computer - with controlled filesystem and network access.
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.
Panzerschrek 15 hours ago [-]
> 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 14 hours ago [-]
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 14 hours ago [-]
> 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 13 hours ago [-]
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 11 hours ago [-]
That's what WASI is for
pjmlp 9 hours ago [-]
And like CORBA, or POSIX, the portability does not work 100% as being sold.
rvz 14 hours ago [-]
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.
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.
> 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.
Those are not flaws in WASM itself, but in different WASM runtimes.
GoblinSlayer 12 hours ago [-]
Might as well run java or flash.
DonHopkins 11 hours ago [-]
But WASM is "lawnmower not included"!
12 hours ago [-]
DanielHB 14 hours ago [-]
Use cases I am more excited about:
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.
bzzzt 13 hours ago [-]
We had that in the 90's with Java. Why would this approach succeed today?
DanielHB 5 hours ago [-]
WASM sandbox is miles better than the JVM
WASI is a standard on where to poke holes on the sandbox for your specific use-case
WASM+WASI as a compilation target allows any program written for modern operating systems to work on any WASM runtime
simonw 12 hours ago [-]
Why wouldn't it? It's a different technology stack, developed with the benefit of decades of additional experience running hostile code on the web.
pjmlp 12 hours ago [-]
You mean like the CLR?
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.
dtj1123 9 hours ago [-]
Because Java is a language, not a compilation target?
ptx 7 hours ago [-]
From the introduction section of the Java specification [1]:
"The Java Virtual Machine is the cornerstone of the Java platform. It is the component of the technology responsible for its hardware- and operating system-independence, the small size of its compiled code, and its ability to protect users from malicious programs."
"The Java® programming language is a general-purpose, concurrent, object-oriented language."
Edit:
Having thought a little, I appreciate that it's possible to compile for the JVM from source code which is not Java, which makes the JVM a compilation target. As far as I'm aware the JVM doesn't have first class support for this though, It's been tacked on as an afterthought. Compiling C to JVM bytecode for example doesn't appear to be an enjoyable process. WASM on the other hand was designed explicity to function as a compilation target for arbitrary languages.
Maybe I'm missing something, happy to be proven wrong.
ptx 4 hours ago [-]
There are (or have been) lots of languages using the JVM as a compilation target, whether it is well-suited for this or not. Wikipedia has a partial list: https://en.wikipedia.org/wiki/List_of_JVM_languages
dtj1123 2 hours ago [-]
My point is that it isn't well suited for it. Hence WASM.
crabmusket 13 hours ago [-]
Check out https://extism.org, it is built for those kinds of use cases. However I think WASI and components could enhance it.
DanielHB 11 hours ago [-]
sorry I meant "most excited about", WASI and components should be useful for the usecases I mentioned too.
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.
tuananh 13 hours ago [-]
i had this same vision when i created hyper-mcp with modular plugin system via WASM plugins. Too bad, the community moves on from MCP to CLI with coding agent
Hey, this is also my interest. I was just looking into whether it was possible to e.g. build an archive extractor that runs like a normal program but does the actual extraction completely in wasm. Unfortunately, AFAICT it's possible but requires custom code; you can't (yet, I hope) just compile unzip/libarchive/whatever with CC=wasicompiler and get a sandboxed binary. But we're getting close.
nl 13 hours ago [-]
What do you mean? You absolutely can run compression in WASM.
You should be able to do exactly that though? Why do you think you can't?
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.
grayrest 13 hours ago [-]
The thing that interests me the most is that execution is deterministic. If the inputs to a WASM module are logged you get durable execution and rr style reverse debugging as part of the package.
samiv 13 hours ago [-]
Sorry but how exactly does the sandboxing help? You download and run an app that you expect to be useful and that you need. The app needs permission to access your data. If you want to use the application what choice do you have except to grant it access?
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.
eviks 11 hours ago [-]
> The app needs permission to access your data. If you want to use the application what choice do you have except to grant it access?
But it doesn't need network access to be useful, so it doesn't have that permission and can't exfiltrate your data?
In general, what's three point of a link to a sandbox in a conversation about the benefits of sanboxingm
But specifically, this sandbox also kills all interop with your system, other apps/utilities, so way too disruptive for the purpose of isolating just from the network.
pjmlp 5 hours ago [-]
Just like any WebAssembly runtime, without imports of external functions, the code can only warm CPUs.
eviks 5 hours ago [-]
So? Will they not have imports of external functions?
pjmlp 5 hours ago [-]
The point being that WASM doesn't improve anything over sandoxing native applications, on the OSes that actually are serious about it.
It should confine itself as the evolution from browser plugins.
eviks 4 hours ago [-]
So it does improve since the OSes are not actually serious about it otherwise they would've fixed these basic usability concerns years ago.
pjmlp 2 hours ago [-]
I haven't said such thing.
wyager 15 hours ago [-]
I'm curious if people have a good story for why WASI will succeed where Java failed
simonw 14 hours ago [-]
My main one is that WASI has benefitted from an additional 31 years of accumulated industry-wide experience compared to when Java was first released.
pjmlp 12 hours ago [-]
So where has the experience gone in the support of C and C++ for WASM?
DonHopkins 11 hours ago [-]
Plus, Larry Ellison doesn't own WASM: "Lawnmower Not Included"!
Panzerschrek 14 hours ago [-]
Programs written in Java require installation of a middleware called Java runtime. It adds extra friction for end-users. And even if one has Java runtime installed, a newer version may be necessary for a recently-published application.
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.
GoblinSlayer 50 minutes ago [-]
>And even if one has Java runtime installed, a newer version may be necessary for a recently-published application.
WASM doesn't remove version churn, the linked article literally discusses a newer version. Oh and the wonderful web compat story.
pjmlp 13 hours ago [-]
It is exactly the same for WASM outside of the browser, and Java has Android as counter part to built in runtime.
afiori 11 hours ago [-]
Java's vm does not start in milliseconds nor has dozen independent implementations in every ecosystem
pjmlp 9 hours ago [-]
Folks tend to think only Oracle does Java, and the only place to get it is from https://www.java.com.
And some like PTC or microEJ are missing from the list.
auggierose 13 hours ago [-]
Yes, but inside the browser is a freaking big use case.
pjmlp 13 hours ago [-]
Not really, I don't need COM / CORBA on the browser.
bzzzt 13 hours ago [-]
> Programs written in Java require installation of a middleware called Java runtime.
It's possible to link or embed a Java runtime in an existing application.
tpm 11 hours ago [-]
> It adds extra friction for end-users
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.
afiori 11 hours ago [-]
Because Java was doing nothing similar, a better comparison would be .NET CLR that actually tried to be a decent compilation target.
Also security, Java has reflection so you cannot reliably sandbox java libraries
fla 14 hours ago [-]
My main one is: distribution & access. If major browsers implement the WASI runtime then using and distributing a WASI app will be way simpler than the Java equivalent ever was.
emadda 13 hours ago [-]
I like the technical design of WASM, but I feel that better OS sandboxes for regular native code will be the common approach to running untrusted code.
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.
pistoriusp 12 hours ago [-]
Why not just run a vm?
AndrewDucker 12 hours ago [-]
Far more overhead.
ptx 7 hours ago [-]
In particular (as I just learned when looking it up), WASM can dynamically allocate host memory with the memory.grow instruction, so you don't have to waste a huge chunk of statically allocated memory per VM:
https://developer.mozilla.org/en-US/docs/WebAssembly/Referen...
Although... it doesn't say anything about releasing memory back to the host (I don't see a memory.shrink instruction) so maybe it's not all that helpful? Will WASM applications continue hogging the maximum amount of memory they've ever used until they're restarted?
A VM could release memory back to the host using memory ballooning, but this has to be managed manually somehow, at least with QEMU.
thefounder 16 hours ago [-]
It’s great we are past the “wasm is not replacing JavaScript” phase. Or “you don’t need DOM for wasm . That’s what JavaScript is for”
DarkNova6 12 hours ago [-]
I don't get it why you need direct DOM access. Just wrap it in JS calls.
It's not like current websites are super fast and creating a wrapper will slow it down unnecessarily.
AndrewDucker 12 hours ago [-]
The article cites the research that JS wrapping of DOM calls slows things down by 50%.
discreteevent 11 hours ago [-]
Just to be clear: It slows down the overhead of a function call by 50%. It doesn't slow down the function implementation which takes a very large percentage of the time.
thefounder 8 hours ago [-]
Can I just say fuck JavaScript so we can stop mentioning this time and time again ?
flohofwoe 14 hours ago [-]
I'm pretty sure you'll will still need a JS shim to talk to most web APIs. For instance the Mozilla DOM experiments seems to use a special JS variant with a 'use component' header (similar to the old 'use asm' for asm.js) as shim, but the JS shim is still there. The component model can marshal 'record types' between different WASM modules, but AFAIK not between a WASM module and a web API.
tpm 11 hours ago [-]
we still need js shim for dom access :(
afiori 11 hours ago [-]
Asking for 0% js 100% wasm website is like wanting a C-free linux distro
tpm 10 hours ago [-]
One could write a js-less DOM impl I think.. neither Chrome nor Firefox itself is written in js unlike big parts of Linux that are indeed written in C. Explorer shipped with vbscript as a language that can manipulate the DOM.
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.
dfabulich 6 hours ago [-]
One couldn't, because you'd need to standardize a JS-less DOM, which requires one to persuade Apple, Google, Microsoft, and Mozilla to agree on a new standard for a JS-less DOM API.
The DOM API is currently defined as a JS API, including JS strings, JS objects + properties, JS Exceptions, JS Promises, JS garbage collection, and on and on and on.
The effort to get all the browsers to agree to standardize a new JS-less DOM API would take years; none of the browser vendors even want to begin that conversation today.
rohitsriram 14 hours ago [-]
The microkernel analogy for the Component Model vs WASI is actually a really useful mental model that I hadn't seen framed that way before. Component Model as the always-present kernel, WASI as optional OS services on top. That framing makes it obvious why browser implementation of the Component Model is tractable even though browsers have strong opinions about I/O, and why 1.0 for the Component Model and WASI are separate milestones. The lazy ABI change is also underrated, zero-copy forwarding between calls is going to matter a lot for the use cases where WASM actually competes with native.
baudaux 13 hours ago [-]
I will be interested in getting details about the experiments of Ryan Hunt about DOM performances.
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
catlifeonmars 13 hours ago [-]
I’m curious if this helps make WASM a potential alternative to eBPF for userspace kernel extensions.
fyrn_ 16 hours ago [-]
Please please please bring it to the browser. I'm so done with the terrible ergonomics of everything at the was bounary having to pretend it's JavaScript
flohofwoe 13 hours ago [-]
Pretty sure the JS shim is still needed to talk to web apis, even if it might look slightly different (there is a 'use component' now in the JS shim in Mozilla's experiment similar to the old 'use asm' for asm.js - at least that's what the post says).
It works in the browser already, by bundling another browser runtime engine into wasm. You need a whole fork of Mozilla's SpiderMonkey engine, compiled to wasm, running in whatever browser you have, to run wasm components today.
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!
tschneidereit 10 hours ago [-]
[Creator of the StarlingMonkey JS runtime here]
> 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.
jauntywundrkind 3 hours ago [-]
Apologies for consuming your time unnecsesarily & for misinformation! Mea culpa! Sorry again, & thank you so much for writing in! Oh my gosh. I don't have a good excuse, don't know how I mis-recalled so badly; it has been a year since I looked. My interest has usually been in getting component runtimes going, less so in downcompiling components into a single blob to run (perhaps on the web), but that is still a grevious mis-statement I made, and I thank you again for showing up. Yikes. My very bad. :(
enos_feedler 13 hours ago [-]
I agree with you, but sadly without killer use cases in the browser this still ends up being quite political to adopt. I feel good about the approach being taken. The browser vendors have analytics on the usage of JCO and so despite it not being "ideal", it works. We need to make stuff using JCO and make those things popular. It's not on the browser vendors to build native component model yet. At some point I suspect it will be though.
pjmlp 13 hours ago [-]
So, Jini with RMI, CORBA, DCOM, and gRPC, hello again.
Really leave WASM on the browser.
wyager 14 hours ago [-]
Very exited about WASM/WCM as a portable format for capability-secure applications.
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
DanielHB 11 hours ago [-]
The ABI stuff is huge, we might be heading (at least in the WASM world) to a place where non-C libraries are not locked to certain dev ecosystems. On top of not having to deal with C linking madness.
mastermage 14 hours ago [-]
Oh yes give me the component model lets go.
flohofwoe 14 hours ago [-]
> The Component Model can’t formally reach 1.0 without native implementation in at least two browser engines.
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.
pjmlp 11 hours ago [-]
Because no one cares about yet another CORBA, gRPC is good enough, and going forward stuff like MCP and A2A are way more relevant even, so they need the browser for having any use case at all that people would actually care about.
Otherwise in a couple of years no one would care Component Model ever existed.
shevy-java 16 hours ago [-]
WASM first appeared in 2017.
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 ...).
Suno also runs on WASM. Pretty good showcases, both, imho.
afiori 11 hours ago [-]
Sure, figma is 6% of the internet
pjmlp 9 hours ago [-]
There are many designers out there.
Deukhoofd 14 hours ago [-]
When I last played with it checking out its capabilities, I found the thing I was mostly missing to really make use of it was the thing referenced in this article, the Component Model. Without a type model and binary specifications, interop was made a lot harder than it'd have been otherwise. Now that that's in, it becomes a lot more useful.
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.
esafak 16 hours ago [-]
WASM made Figma.
afiori 11 hours ago [-]
oh no, a new edge case tech has not replace the most popular tech stack ever, yet another failure after webGL
h4ch1 15 hours ago [-]
I wrote an Unreal file parser in C# and use it in our in-house web based DAM. It was much more ergonomic and performant than writing it in Javascript.
aatd86 15 hours ago [-]
WASM is super useful for FFI in some env
Rendered at 20:16:49 GMT+0000 (UTC) with Wasmer Edge.
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.
WASI is a standard on where to poke holes on the sandbox for your specific use-case
WASM+WASI as a compilation target allows any program written for modern operating systems to work on any WASM runtime
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.
"The Java Virtual Machine is the cornerstone of the Java platform. It is the component of the technology responsible for its hardware- and operating system-independence, the small size of its compiled code, and its ability to protect users from malicious programs."
[1] https://docs.oracle.com/javase/specs/jvms/se26/html/jvms-1.h...
"The Java® programming language is a general-purpose, concurrent, object-oriented language."
Edit: Having thought a little, I appreciate that it's possible to compile for the JVM from source code which is not Java, which makes the JVM a compilation target. As far as I'm aware the JVM doesn't have first class support for this though, It's been tacked on as an afterthought. Compiling C to JVM bytecode for example doesn't appear to be an enjoyable process. WASM on the other hand was designed explicity to function as a compilation target for arbitrary languages.
Maybe I'm missing something, happy to be proven wrong.
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.
https://github.com/hyper-mcp-rs/hyper-mcp
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?
But specifically, this sandbox also kills all interop with your system, other apps/utilities, so way too disruptive for the purpose of isolating just from the network.
It should confine itself as the evolution from browser plugins.
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.
WASM doesn't remove version churn, the linked article literally discusses a newer version. Oh and the wonderful web compat story.
Maybe they should broaden their horizons.
https://en.wikipedia.org/wiki/List_of_Java_virtual_machines
And some like PTC or microEJ are missing from the list.
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.
Also security, Java has reflection so you cannot reliably sandbox java libraries
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.
Although... it doesn't say anything about releasing memory back to the host (I don't see a memory.shrink instruction) so maybe it's not all that helpful? Will WASM applications continue hogging the maximum amount of memory they've ever used until they're restarted?
A VM could release memory back to the host using memory ballooning, but this has to be managed manually somehow, at least with QEMU.
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.
The DOM API is currently defined as a JS API, including JS strings, JS objects + properties, JS Exceptions, JS Promises, JS garbage collection, and on and on and on.
The effort to get all the browsers to agree to standardize a new JS-less DOM API would take years; none of the browser vendors even want to begin that conversation today.
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
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.
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.
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.