51–60 of 111 posts
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, cros…
Why not just run a vm?
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”
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.
Earlier quoted context omitted.
> 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.
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…
Earlier quoted context omitted.
We had that in the 90's with Java. Why would this approach succeed today?
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.
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.
Earlier quoted context omitted.
I'm curious if people have a good story for why WASI will succeed where Java failed
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.
Earlier quoted context omitted.
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…
Those are not flaws in WASM itself, but in different WASM runtimes.
> 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 wi…
Otherwise in a couple of years no one would care Component Model ever existed.
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 recen…
According to https://chromestatus.com/metrics/feature/timeline/popularity... WebAssembly runs on about 6.11% of Chrome page loads, up from 3.37% in January 2024.
Earlier quoted context omitted.
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.
The article cites the research that JS wrapping of DOM calls slows things down by 50%.
Earlier quoted context omitted.
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.
Check out https://extism.org , it is built for those kinds of use cases. However I think WASI and components could enhance it.
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.