5 ms·
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 compil
by nequo 2y ago
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.
- NomDePlum 2y agoDid Java applets arguably not do this 20+ years ago?
- jimbob45 2y agoI thought those were interpreted by the JVM, which was subject to security issues. WASM faces no such security issues, no?
- 3np 2y agoOh, sweet summer child
- lmz 2y agoThe JVM implemented properly should not have security issues. The class library however... (i.e. it's a lot easier to sandbox things if you start without any classes that interact outside the sandbox).
- Earw0rm 2y agoAt least in so far as the higher level (DOM, browser runtime) and lower level (memory access, to the extent that it's mediated by the WASM VM) have no security issues... The VM itself is pretty tight, but abstractions have a nasty habit of being leaky.
- pjmlp 2y agoWASM also has potentials for security exploits, but those selling it are quite silent on those. Everything Old is New Again: Binary Security of WebAssembly https://www.usenix.org/conference/usenixsecurity20/presentation/lehmann 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.
- swiftcoder 2y agoThe JVM is fairly good at sandboxing, as these things go. Turns out sandboxing arbitrary software is an extremely hard problem (as the WASM folks are starting to encounter in the wild)
- nequo 2y agoMaybe you know this better than me. Were non-JVM native languages available 20 years ago for Java applets? 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?
- nine_k 2y agoYes, you could write applets in other languages. The choice was rather narrow, but you could use [Python], [Scala], or [JRuby]. [Python]: https://www.jython.org/jython-old-sites/archive/21/applets/index.html https://www.jython.org/jython-old-sites/archive/21/applets/i... [Scala]: https://cs.trinity.edu/~mlewis/ScalaApplet/scalaWebApplet/WebAppletsInScala/WebAppletsInScala.html https://cs.trinity.edu/~mlewis/ScalaApplet/scalaWebApplet/We... [JRuby]: https://www.jruby.org/getting-started https://www.jruby.org/getting-started — offers to run as an applet in the first few lines.
- eecc 2y agoalso JavaScript. See https://en.wikipedia.org/wiki/Nashorn_(JavaScript_engine) https://en.wikipedia.org/wiki/Nashorn_(JavaScript_engine)
- fulafel 2y agoSome other >20 year old JVM languages not yet mentioned in sibling commins: Kawa (a Scheme) and Groovy (a JVM native dynamic language)
- deleted 2y ago[deleted]
- antupis 2y agoWell yeah but the problem was that you still needed that runtime, WASM should solve this.
- Cthulhu_ 2y agoJava, Flash, Silverlight, ActiveX? There were loads of technologies to run different languages in a browser, but they were all proprietary to a point; none of them were a web standard, they all needed separate installation or a specific browser, and they were all basically black boxes in the browser. Whereas (from what I understand) wasm is a built-in browser standard. 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.