The current reference (only?) implementation of jpeg-xl is a c++ library, which I do not entirely trust to run in process in my go web server, and yet I would like to process images. Conveniently, the build system for jpeg-xl seems to support building to wasm, so if I can jam that into my process, I'd be a lot happier.
Ah, now THAT's an interesting aspect I wish someone would have brought up over the years I've seen WASM.
I guess WASM as a target and embeddable VM really helps with security in those cases. Couldn't we also do the same though with any number of arch/vm pairings?
I guess what WASM brings to the table is a compile target friendly enough for things like C and C++, i.e. low level code, and a reasonable VM implementation. It just has to be accepted by everything (both as an output format, and virtual machine impl in the language choice) to work, I think...
I don't know the current state, but the JVM had historically quite bad isolation. Javascript's isolation in browsers is actually pretty good. It's possible that the existing non-browser WASI implementations are terrible at isolation; since they exist specifically to allow access system resources they might be bad at denying access to system resources...
The JVM’s security in the Applet days were bad due to actually being capable at many functionality — it is trivial to properly sandbox something that has zero capabilities.
There is nothing inherent in the JVM that would make it less secure, we just realized in the meanwhile that blacklisting is not the way ahead, but whitelisting is.
Library sandboxing is a well known application of WASM. Search for the WebAssembly Component Model. There's also a way to use WASM to sandbox a C library - search for RLBox.
