4 ms·

Java only had one closed source implementation and had many security issues during its life. It wasn't designed for proper sandboxing and for having multiple im

by DiThi 9y ago

Java only had one closed source implementation and had many security issues during its life. It wasn't designed for proper sandboxing and for having multiple implementations in the first place. And its communication with the rest of the browser was done through a slow and ugly channel (IIRC everything had to be sent around as strings).

AnIdiotOnTheNet 9y ago
And how much of that is true today?
- DiThi 9y ago
  All of it except the closed source part. The design decisions are still there, the attack surface is still pretty big (although with much more testing and fuzzing done to date), and there's still only one implementation that can run any applet out there (not counting MS java which was abandoned when XP was released).
- primeblue 9y ago
  It's still ugly
weinzierl 9y ago
> Java only had one closed source implementation... This is not true. There were alternative implementations from very early on, most notably the Microsoft one. > ...and had many security issues during its life. True, but WASM hadn't had much of a life so far, so we will see. > And its communication with the rest of the browser was done through a slow and ugly channel (IIRC everything had to be sent around as strings). From what I understand, so far, every communication between the browser and WASM has to go through JavaScript and from what I see I think it's ugly as well[1]. Don't get me wrong, I'm not at all against WASM, but I see the very same arguments for and against WASM I remember from the 90s about Java. This is especially true when it comes to security. Java was designed with a sandbox and a bytecode verifier from very early on. [1] https://kripken.github.io/emscripten-site/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.html https://kripken.github.io/emscripten-site/docs/porting/conne...
- DiThi 9y ago
  > most notably the Microsoft one. My bad. However it was closed source too, and abandoned rather quickly. > True but WASM hadn't had much of a life so far, so we will see. It uses the same security model as JS, which is much more mature than VMs not designed for so much exposure to random third party code. > from what I see I think it's ugly as well Ugly but not slow. WASM memory can be read and written directly from/to a typed array, instead of converting strings. Since it's fast enough, one can make less ugly APIs wrapping that behaviour. > Java was designed with a sandbox and a bytecode verifier from very early on. They probably protected the code itself from escaping the sandbox, but not the environment (all the API in its complex glory). WASM on the other side is exclusively allowed to talk with JS (for now, at least), therefore the only API level bugs are in JS, not in WASM.
  - weinzierl 9y ago
    > The goal for WASM is to enable browsers to run untrusted code in a trusted environment. Our approach is to be conservative at first, and to add functionality when it can be added securely. The intent is to prevent code from inspecting or changing files on the client file system. Also, the intent is to prevent code from using network connections to circumvent file protections or people's expectations of privacy. > WASM provides the basic technology for loading and authenticating signed code. This enables browsers to run trusted code in a trusted environment. Sounds familiar? This is straight from 1998 [1](ha!) with JDK replaced by WASM and applet/classes by code;-) I hear you and I hope this is enough for WASM to succeed. Still I don't see the killer argument why I should believe it will. [1] https://web.archive.org/web/19980214233937/http://java.sun.com:80/sfaq/index.html#otherBytes https://web.archive.org/web/19980214233937/http://java.sun.c...
    - DiThi 9y ago
      "functionality" in this case means APIs. WASM won't have any APIs that JS doesn't already have. So "conservative" means "just a few APIs", not "just communication with code in an already battle-proven VM". And AFAIK there are no plans for "loading and authenticating signed code" in WASM. It's always untrusted unless you run it with a runtime that provides the privileged APIs (such as node.js). Java always had both unprivileged and privileged APIs in the same place.

by DiThi 9y ago

AnIdiotOnTheNet 9y ago

And how much of that is true today?

DiThi 9y ago
All of it except the closed source part. The design decisions are still there, the attack surface is still pretty big (although with much more testing and fuzzing done to date), and there's still only one implementation that can run any applet out there (not counting MS java which was abandoned when XP was released).
primeblue 9y ago
It's still ugly

weinzierl 9y ago

> Java only had one closed source implementation... This is not true. There were alternative implementations from very early on, most notably the Microsoft one. > ...and had many security issues during its life. True, but WASM hadn't had much of a life so far, so we will see. > And its communication with the rest of the browser was done through a slow and ugly channel (IIRC everything had to be sent around as strings). From what I understand, so far, every communication between the browser and WASM has to go through JavaScript and from what I see I think it's ugly as well[1]. Don't get me wrong, I'm not at all against WASM, but I see the very same arguments for and against WASM I remember from the 90s about Java. This is especially true when it comes to security. Java was designed with a sandbox and a bytecode verifier from very early on. [1] https://kripken.github.io/emscripten-site/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.html https://kripken.github.io/emscripten-site/docs/porting/conne...

DiThi 9y ago
> most notably the Microsoft one. My bad. However it was closed source too, and abandoned rather quickly. > True but WASM hadn't had much of a life so far, so we will see. It uses the same security model as JS, which is much more mature than VMs not designed for so much exposure to random third party code. > from what I see I think it's ugly as well Ugly but not slow. WASM memory can be read and written directly from/to a typed array, instead of converting strings. Since it's fast enough, one can make less ugly APIs wrapping that behaviour. > Java was designed with a sandbox and a bytecode verifier from very early on. They probably protected the code itself from escaping the sandbox, but not the environment (all the API in its complex glory). WASM on the other side is exclusively allowed to talk with JS (for now, at least), therefore the only API level bugs are in JS, not in WASM.
- weinzierl 9y ago
  > The goal for WASM is to enable browsers to run untrusted code in a trusted environment. Our approach is to be conservative at first, and to add functionality when it can be added securely. The intent is to prevent code from inspecting or changing files on the client file system. Also, the intent is to prevent code from using network connections to circumvent file protections or people's expectations of privacy. > WASM provides the basic technology for loading and authenticating signed code. This enables browsers to run trusted code in a trusted environment. Sounds familiar? This is straight from 1998 [1](ha!) with JDK replaced by WASM and applet/classes by code;-) I hear you and I hope this is enough for WASM to succeed. Still I don't see the killer argument why I should believe it will. [1] https://web.archive.org/web/19980214233937/http://java.sun.com:80/sfaq/index.html#otherBytes https://web.archive.org/web/19980214233937/http://java.sun.c...
  - DiThi 9y ago
    "functionality" in this case means APIs. WASM won't have any APIs that JS doesn't already have. So "conservative" means "just a few APIs", not "just communication with code in an already battle-proven VM". And AFAIK there are no plans for "loading and authenticating signed code" in WASM. It's always untrusted unless you run it with a runtime that provides the privileged APIs (such as node.js). Java always had both unprivileged and privileged APIs in the same place.