4 ms·

The JVM requires a huge standard library, is tightly tied to implementation details of the host, is not easily compiled to by any language with stack types and

The JVM requires a huge standard library, is tightly tied to implementation details of the host, is not easily compiled to by any language with stack types and pointers, embeds a number of historical mistakes, makes sandboxing basically impossible, and must be very carefully written if performance approaching native is required.

kaba0 3y ago
> is tightly tied to implementation details of the host Heh? > embeds a number of historical mistakes Well, you need history for that first. Wasm won’t be any different. > makes sandboxing basically impossible Why would it? It just turned out that whitelisting should be the default approach to security over blacklisting. There is nothing inherent in the JVM that would preclude one from doing that.
- josephg 3y ago
  Safely sandboxing java is difficult because a lot of the standard library is written in native code with full filesystem access. And java code can dynamically load other java code. So its much easier for a security vulnerability in the standard library or runtime can quickly escalate into a RCE vulnerability. Java applets being secure largely depends on the entire JVM + JRE being secure. Given how massive that is, there have (of course) been many sandbox escapes over the years. Oracle's security vulnerabilities database[1] lists 730 CVEs in the java runtime environment. (They aren't all sandbox escapes but wow thats a lot!) WASM is far, far easier to reason about from a security perspective because its orders of magnitude simpler. There is no standard library. All wasm code (including any library code you compile in to your software) runs in an entirely encapsulated virtual machine with no ability to interact with anything outside of its little bubble. (Except for any functions the application explicitly passes in to the wasm module.) The wasm module boundary is fixed and simple, and as a result its much easier to secure. I'm sure someone will eventually find a sandbox escape for wasm code somehow. But I bet there'll be at least an order of magnitude fewer sandbox escapes in wasm than we've had with java because of the differences in the security model. [1] https://www.cvedetails.com/vulnerability-list/vendor_id-93/product_id-19117/Oracle-JRE.html https://www.cvedetails.com/vulnerability-list/vendor_id-93/p...
  - kaba0 3y ago
    We are not talking about Applets, those came from a time when the rest of the web technologies were way behind, and the best we could do is to put up a canvas to render into. Also, why would we expose the full filesystem api to a theoretical JVM for the Web? The core of the JVM is a simple stack-machine and a GC, there is nothing demanding all these additional hooks to useful, but potentially unsafe APIs. Of course WASM is safe without any outside functionality, so is brainfuck in and of itself.
    - josephg 3y ago
      > The core of the JVM is a simple stack-machine and a GC, there is nothing demanding all these additional hooks to useful, but potentially unsafe APIs. So you're suggesting we put a subset of the JVM in the browser, with no access to the java standard library? Why? You couldn't run any existing java code or any code in other languages without a compiler. It would just be a weird sub-language that nobody really wants to use, with no existing code or libraries. The pressure would be on to add all the crap from the JRE - putting a tension between security (who knows how secure any of that code is) and usability (who wants a language with no standard library?). This has all played out before and java ended up giving up and deprecating SecurityManager. Even if you succeed, to what end? So we can run java in the browser? So we have 2 average languages instead of 1? Should we add a C# subset next? The beauty of wasm is that any language can target it. Or would we compile our C, Go, C# and Rust to this new java subset? But that wouldn't work well - java is missing many features which would be needed to run C code properly. You could make it work using some horrible hacks on top of ByteBuffers, but then it'd run much slower than native code. Much slower than wasm runs today. Whats the point when we could just do the same thing on top of javascript? (And we did - it was called asmjs).
      - kaba0 3y ago
        I have replied to many of these points in another thread where we talk, so I won't repeat those. I suggest putting a subset of the JVM that has access to many parts of the standard library, but certain APIs would need proper browser permissions, the same way it works with JS today. It could run the vast majority of the very high quality of Java ecosystem, and every JVM guest language code out of the box. It is also not a bad compile target -- I would argue that most mainstream languages would actually prefer a managed runtime, and C/C++/Rust are the niche. Aren't there orders of magnitude Java+Python+C#+Haskell+... devs that would prefer to write in their language over JS? Sure, you might say that the reason for WASM's existence is mostly the performance gains for small algorithms, and there certainly is a new niche made available thanks to it, but one way or another people will use it simply due to preferring their stack to JS. The performance aspect is also improved to the JS-only world by possibly allowing proper shared-memory multithreading. > java is missing many features which would be needed to run C code properly Why would ByteBuffers be a horrible hack? Is it worse of a hack then what C compilers have to do when targeting WASM, like only having structured control flow? It's just an array read mapped to a single instruction, but in context can also be optimized efficiently (e.g. autovectorizing them when they occur in a loop). GraalVM actually has support for any LLVM language (though their way of interpretation is different enough from the standard JVM bytecode mode that I only mention it as an interesting data point) with quite great performance, certainly comparable to WASM. Nonetheless, please don't take my possibly argumentative tone as a negative, I enjoy this discussion and you make great points. I also don't dislike WASM, it is imo a net positive thing. I just believe that a JVM-fueled web failed mostly due to politics, not something inherently technical.

kaba0 3y ago

> is tightly tied to implementation details of the host Heh? > embeds a number of historical mistakes Well, you need history for that first. Wasm won’t be any different. > makes sandboxing basically impossible Why would it? It just turned out that whitelisting should be the default approach to security over blacklisting. There is nothing inherent in the JVM that would preclude one from doing that.

josephg 3y ago
Safely sandboxing java is difficult because a lot of the standard library is written in native code with full filesystem access. And java code can dynamically load other java code. So its much easier for a security vulnerability in the standard library or runtime can quickly escalate into a RCE vulnerability. Java applets being secure largely depends on the entire JVM + JRE being secure. Given how massive that is, there have (of course) been many sandbox escapes over the years. Oracle's security vulnerabilities database[1] lists 730 CVEs in the java runtime environment. (They aren't all sandbox escapes but wow thats a lot!) WASM is far, far easier to reason about from a security perspective because its orders of magnitude simpler. There is no standard library. All wasm code (including any library code you compile in to your software) runs in an entirely encapsulated virtual machine with no ability to interact with anything outside of its little bubble. (Except for any functions the application explicitly passes in to the wasm module.) The wasm module boundary is fixed and simple, and as a result its much easier to secure. I'm sure someone will eventually find a sandbox escape for wasm code somehow. But I bet there'll be at least an order of magnitude fewer sandbox escapes in wasm than we've had with java because of the differences in the security model. [1] https://www.cvedetails.com/vulnerability-list/vendor_id-93/product_id-19117/Oracle-JRE.html https://www.cvedetails.com/vulnerability-list/vendor_id-93/p...
- kaba0 3y ago
  We are not talking about Applets, those came from a time when the rest of the web technologies were way behind, and the best we could do is to put up a canvas to render into. Also, why would we expose the full filesystem api to a theoretical JVM for the Web? The core of the JVM is a simple stack-machine and a GC, there is nothing demanding all these additional hooks to useful, but potentially unsafe APIs. Of course WASM is safe without any outside functionality, so is brainfuck in and of itself.
  - josephg 3y ago
    > The core of the JVM is a simple stack-machine and a GC, there is nothing demanding all these additional hooks to useful, but potentially unsafe APIs. So you're suggesting we put a subset of the JVM in the browser, with no access to the java standard library? Why? You couldn't run any existing java code or any code in other languages without a compiler. It would just be a weird sub-language that nobody really wants to use, with no existing code or libraries. The pressure would be on to add all the crap from the JRE - putting a tension between security (who knows how secure any of that code is) and usability (who wants a language with no standard library?). This has all played out before and java ended up giving up and deprecating SecurityManager. Even if you succeed, to what end? So we can run java in the browser? So we have 2 average languages instead of 1? Should we add a C# subset next? The beauty of wasm is that any language can target it. Or would we compile our C, Go, C# and Rust to this new java subset? But that wouldn't work well - java is missing many features which would be needed to run C code properly. You could make it work using some horrible hacks on top of ByteBuffers, but then it'd run much slower than native code. Much slower than wasm runs today. Whats the point when we could just do the same thing on top of javascript? (And we did - it was called asmjs).
    - kaba0 3y ago
      I have replied to many of these points in another thread where we talk, so I won't repeat those. I suggest putting a subset of the JVM that has access to many parts of the standard library, but certain APIs would need proper browser permissions, the same way it works with JS today. It could run the vast majority of the very high quality of Java ecosystem, and every JVM guest language code out of the box. It is also not a bad compile target -- I would argue that most mainstream languages would actually prefer a managed runtime, and C/C++/Rust are the niche. Aren't there orders of magnitude Java+Python+C#+Haskell+... devs that would prefer to write in their language over JS? Sure, you might say that the reason for WASM's existence is mostly the performance gains for small algorithms, and there certainly is a new niche made available thanks to it, but one way or another people will use it simply due to preferring their stack to JS. The performance aspect is also improved to the JS-only world by possibly allowing proper shared-memory multithreading. > java is missing many features which would be needed to run C code properly Why would ByteBuffers be a horrible hack? Is it worse of a hack then what C compilers have to do when targeting WASM, like only having structured control flow? It's just an array read mapped to a single instruction, but in context can also be optimized efficiently (e.g. autovectorizing them when they occur in a loop). GraalVM actually has support for any LLVM language (though their way of interpretation is different enough from the standard JVM bytecode mode that I only mention it as an interesting data point) with quite great performance, certainly comparable to WASM. Nonetheless, please don't take my possibly argumentative tone as a negative, I enjoy this discussion and you make great points. I also don't dislike WASM, it is imo a net positive thing. I just believe that a JVM-fueled web failed mostly due to politics, not something inherently technical.