Gregory's ServerI must admit I don't quite understand what WASM sandbox does right but JVM did not. It wasn't JUST the Java API was too insanely large, but there were plenty of JVM exploits as well. Is there a guide someplace why WASM hasn't repeated the fate of the JVM?
|
9 comments
I think that may be it. The JavaScript JITs are insane, and that they aren't subject to more OMG breakages, and the browsers these days split the rendering engine per origin into a separate process (with all the process isolation on top), the browser folks have a lot of experience. Also, I think WASM started much smaller, and the only outside world is through the JavaScript framework rather than direct probably helps too.    One weakness in Java was JNI because at some point you have to get data in/out of real devices. If my webcam is some janky Costco $6 special, with a buggy, vulnerable terrible driver, does WASM protect me from malicious web pages that want to tickle my vulnerable webcam driver? Or is it just orthogonal? I.e. not WASM’s circus, so not WASM’s monkeys? I think they handle that by basically EVERY bit of I/O has to go through the JavaScript, so it isn't adding to that problem space.  I've been playing with safe WASM plugins for resource edition in @capyloon and one super-power is that the "host" code can check which functions are imported by plugins. That makes it possible to enforce eg. privacy policies or permission models. |
@ncweaver @anildash I don't have a great solid answer for that, but the impression I've got is that WASM was helped by twenty years of lessons from the JVM and from browser development in general
Browser developers are really, really good at understanding the challenges involved in executing code from untrusted sources!