Generally agreed.
About WASM, it is not the first sandboxed bytecode interpreter but the first that runs in a browser and that has usable toolchains to compile not “browsers first” languages into it. I’d argue that that’s where the novelty is.
About WASM, it is not the first sandboxed bytecode interpreter but the first that runs in a browser and that has usable toolchains to compile not “browsers first” languages into it. I’d argue that that’s where the novelty is.
My conception of it is that they were pretty much Java only (with Clojure and Scala also available in the later years before they got deprecated?). Is this conception wrong?
[Python]: https://www.jython.org/jython-old-sites/archive/21/applets/i...
[Scala]: https://cs.trinity.edu/~mlewis/ScalaApplet/scalaWebApplet/We...
[JRuby]: https://www.jruby.org/getting-started — offers to run as an applet in the first few lines.
There was (is?) also asm.js, which IIRC was a subset of JS that removed any dynamicness so it would be a lot faster than vanilla JS. But again, no broadly carried / w3c standard.
Everything Old is New Again: Binary Security of WebAssembly
https://www.usenix.org/conference/usenixsecurity20/presentat...
Just one of the many articles that are slowly surfacing, now that WebAssembly is interesting enough as possible attack vector.
While there is a sandbox, you can attack WASM modules the same way as a traditional process via OS IPC, by misusing the public API in a way that corrupts internal memory state (linear memory accesses aren't bound checked), thus fooling future calls to follow execution paths that they shouldn't. With enough luck, one gets an execution path that e.g. validates an invalid credential as good.
The VM itself is pretty tight, but abstractions have a nasty habit of being leaky.