4 ms·

As did Java ... EDIT "does" - and of course it's flawed but the "story" is pretty great :-D

by rusk 8y ago

colanderman 8y ago
And JavaScript.
- rusk 8y ago
  Is Javascript the same though? I've seen numerous stories where security vulnerabilities have been introduced by way of third-party hosted libraries. Java has had signed classloading since the 90s.
  - colanderman 8y ago
    The same as WASM? Yes. Java? No, for the reasons you state.
    - rusk 8y ago
      No, you misunderstand me. Java has a very strong sandboxing and verification "story". Javascript does not - not even close. Author is saying that WASM does.
      - kodablah 8y ago
        > Java has a very strong sandboxing and verification "story" I disagree that it is very strong (I see java.security.Permission littered everywhere in the stdlib) and it definitely wasn't strong in the days of applets. Maybe in theory, but in practice access to such a large stdlib because it was desktop tech shoehorned onto the browser caused a great many issues.
        rusk 8y ago
        "story"
TorKlingberg 8y ago
Indeed. But, making a secure sandbox is the easy part. The hard part is poking holes all over the sandbox so the code can interact with the outside world without compromising security. JavaScript and browsers have spent decades figuring out that balance and working out all the detailed tradeoffs like same-origin policy, cookie rules, etc.
willvarfar 8y ago
the Java and Flash approach was software-implemented security contexts and managers, running the VM in the same process as the browser. People used to say that you couldn't do strong process isolation because it would be unworkably slow. And then Google Chrome demonstrated that was a falacy. People actually flocked to chrome because it was faster, despite it using multiple processes and isolating plugins. NaCL built on that - it's security model was strong process isolation and verification that the code run in that isolated process couldn't 'escape'. Mozilla is still kinda in denial re process isolation.
- Sean1708 8y ago
  > Mozilla is still kinda in denial re process isolation. Isn't that exactly what Electrolysis[0] was for? [0]: https://wiki.mozilla.org/Electrolysis https://wiki.mozilla.org/Electrolysis
hsivonen 8y ago
As I understand it, Java has features that make the time complexity (in the O(n^2) sense) and the general implementation complexity (in the probablity of bugs sense) of the Java byte code verifier worse than WebAssembly validation.

As did Java ... EDIT "does" - and of course it's flawed but the "story" is pretty great :-D

by rusk 8y ago

As did Java ... EDIT "does" - and of course it's flawed but the "story" is pretty great :-D

colanderman 8y ago

And JavaScript.

rusk 8y ago
Is Javascript the same though? I've seen numerous stories where security vulnerabilities have been introduced by way of third-party hosted libraries. Java has had signed classloading since the 90s.
- colanderman 8y ago
  The same as WASM? Yes. Java? No, for the reasons you state.
  - rusk 8y ago
    No, you misunderstand me. Java has a very strong sandboxing and verification "story". Javascript does not - not even close. Author is saying that WASM does.
    - kodablah 8y ago
      > Java has a very strong sandboxing and verification "story" I disagree that it is very strong (I see java.security.Permission littered everywhere in the stdlib) and it definitely wasn't strong in the days of applets. Maybe in theory, but in practice access to such a large stdlib because it was desktop tech shoehorned onto the browser caused a great many issues.
      - rusk 8y ago
        "story"

TorKlingberg 8y ago

Indeed. But, making a secure sandbox is the easy part. The hard part is poking holes all over the sandbox so the code can interact with the outside world without compromising security. JavaScript and browsers have spent decades figuring out that balance and working out all the detailed tradeoffs like same-origin policy, cookie rules, etc.

willvarfar 8y ago

the Java and Flash approach was software-implemented security contexts and managers, running the VM in the same process as the browser. People used to say that you couldn't do strong process isolation because it would be unworkably slow. And then Google Chrome demonstrated that was a falacy. People actually flocked to chrome because it was faster, despite it using multiple processes and isolating plugins. NaCL built on that - it's security model was strong process isolation and verification that the code run in that isolated process couldn't 'escape'. Mozilla is still kinda in denial re process isolation.

Sean1708 8y ago
> Mozilla is still kinda in denial re process isolation. Isn't that exactly what Electrolysis[0] was for? [0]: https://wiki.mozilla.org/Electrolysis https://wiki.mozilla.org/Electrolysis

hsivonen 8y ago

As I understand it, Java has features that make the time complexity (in the O(n^2) sense) and the general implementation complexity (in the probablity of bugs sense) of the Java byte code verifier worse than WebAssembly validation.