5 ms·

Java is no longer a valid deployment platform for dynamically executing untrusted code. https://www.java.com/en/download/faq/chrome.xml https://www.java.com/en

by chubot 8y ago

Java is no longer a valid deployment platform for dynamically executing untrusted code. https://www.java.com/en/download/faq/chrome.xml https://www.java.com/en/download/faq/chrome.xml The Java Plugin for web browsers relies on the cross-platform plugin architecture NPAPI, which had been supported by all major web browsers for over a decade. Google's Chrome version 45 and above have dropped support for NPAPI, and therefore Java Plugin do not work on these browsers anymore. All the other browsers killed it as well. There's probably some way you can do it outside the browser, but I've never seen it used. Was it called Java WebStart or something? I think it's because the sandbox had too many holes, and it was large and clunky. It didn't integrate well with the browser. Java is obviously still extremely popular, but it's used in trusted contexts, like on the server, or "semi-trusted" contexts, like the Android app store. Although that is a different JVM which is probably easier to secure. And in that case there has to be a manual review process before allowing arbitrary code to execute (which is imperfect, but better than nothing.)

AnIdiotOnTheNet 8y ago
It remains to be seen if WASI will actually have fewer holes in its sandbox. Fundamentally it is not different.
- chubot 8y ago
  I think an important difference is that in the new architecture, there's a separation between WASM and WASI. That is, computation and I/O are treated separately. It's more like capability-based security. WASM modules have no capabilities except the ones explicitly injected when you instantiate it. As far as I understand, the JVM wasn't as rigorous about this, although to be fair I don't know all the details. So WASI could still have a lot of holes, but WASM would survive and be useful. And then maybe someone else could come around and do it in a different, better way. That hasn't happened with Java.
naikrovek 8y ago
Java inside the browser doesn't exist. That's fine. That's not what I'm talking about or making comparisons to. Java runs just fine outside of the browser. You don't even need a browser installed to run Java applications. Javascript and WASM run fine inside the browser, and that's not what I'm talking about or making comparisons to. I'm talking about running WASM binaries outside of the browser. Similar to how Java runs outside of the browser. Very similar, actually. Java needs a runtime to be installed or available, so will WASI. Java is a write-once-run-anywhere type of platform, so is WASI. Why does WASI need to exist if Java already exists for the intended uses?
- Rusky 8y ago
  The JVM doesn't run languages that weren't designed for it, like C or C++ or Rust. WebAssembly does. This is important for a lot of reasons- huge amounts of existing code you can now use without JNI or whatever, a higher ceiling for optimization, more freedom to implement new kinds of languages. The core WebAssembly standard is also much smaller than Java, as a consequence of this design. This makes it easier and/or more feasible to deploy in more scenarios, even without subsetting things the way mobile/embedded Java does.
  - anoncake 8y ago
    Python, Ruby and Common Lisp were designed for the JVM?
    - Rusky 8y ago
      To the extent that their object and memory models match the JVM's, you might say they were. To the extent that they don't, their JVM implementations wind up with warts and inconsistencies. (But this is pedantry, you clearly know what I meant.)
      - anoncake 8y ago
        No, I did not know what you meant. There is a difference between guessing and knowing.
  - chrisseaton 8y ago
    > The JVM doesn't run languages that weren't designed for it, like C or C++ or Rust. You can run all those languages on top of the JVM! The JVM also runs many other languages which weren't designed for it, like Ruby and Python.
    - yellowapple 8y ago
      > You can run all those languages on top of the JVM! Do you have a source for this? I'm sure it's theoretically possible in a Turing-completeness sense, but considering Java lacks any concept whatsoever of a pointer, and considering that most (if not effectively all) C code uses pointers pretty extensively, I find it unlikely that this statement is meaningfully true without some severe efficiency penalties.

by chubot 8y ago

AnIdiotOnTheNet 8y ago

It remains to be seen if WASI will actually have fewer holes in its sandbox. Fundamentally it is not different.

chubot 8y ago
I think an important difference is that in the new architecture, there's a separation between WASM and WASI. That is, computation and I/O are treated separately. It's more like capability-based security. WASM modules have no capabilities except the ones explicitly injected when you instantiate it. As far as I understand, the JVM wasn't as rigorous about this, although to be fair I don't know all the details. So WASI could still have a lot of holes, but WASM would survive and be useful. And then maybe someone else could come around and do it in a different, better way. That hasn't happened with Java.

naikrovek 8y ago

Java inside the browser doesn't exist. That's fine. That's not what I'm talking about or making comparisons to. Java runs just fine outside of the browser. You don't even need a browser installed to run Java applications. Javascript and WASM run fine inside the browser, and that's not what I'm talking about or making comparisons to. I'm talking about running WASM binaries outside of the browser. Similar to how Java runs outside of the browser. Very similar, actually. Java needs a runtime to be installed or available, so will WASI. Java is a write-once-run-anywhere type of platform, so is WASI. Why does WASI need to exist if Java already exists for the intended uses?

Rusky 8y ago
The JVM doesn't run languages that weren't designed for it, like C or C++ or Rust. WebAssembly does. This is important for a lot of reasons- huge amounts of existing code you can now use without JNI or whatever, a higher ceiling for optimization, more freedom to implement new kinds of languages. The core WebAssembly standard is also much smaller than Java, as a consequence of this design. This makes it easier and/or more feasible to deploy in more scenarios, even without subsetting things the way mobile/embedded Java does.
- anoncake 8y ago
  Python, Ruby and Common Lisp were designed for the JVM?
  - Rusky 8y ago
    To the extent that their object and memory models match the JVM's, you might say they were. To the extent that they don't, their JVM implementations wind up with warts and inconsistencies. (But this is pedantry, you clearly know what I meant.)
    - anoncake 8y ago
      No, I did not know what you meant. There is a difference between guessing and knowing.
- chrisseaton 8y ago
  > The JVM doesn't run languages that weren't designed for it, like C or C++ or Rust. You can run all those languages on top of the JVM! The JVM also runs many other languages which weren't designed for it, like Ruby and Python.
  - yellowapple 8y ago
    > You can run all those languages on top of the JVM! Do you have a source for this? I'm sure it's theoretically possible in a Turing-completeness sense, but considering Java lacks any concept whatsoever of a pointer, and considering that most (if not effectively all) C code uses pointers pretty extensively, I find it unlikely that this statement is meaningfully true without some severe efficiency penalties.