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".

> 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.

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.

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.

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.

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.

I'm curious if people have a good story for why WASI will succeed where Java failed

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.

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.

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.

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.

WASM made Figma.

WASM is super useful for FFI in some env

Pretty sure the JS shim is still needed to talk to web apis, even if it might look slightly different (the 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: https://github.com/bytecodealliance/jco