5 ms·

> Wasm has a really strong sandboxing and verification story that others simply did not. Eh, (P)NaCL had a very strong sandboxing and verification story. Wasm

> Wasm has a really strong sandboxing and verification story that others simply did not. Eh, (P)NaCL had a very strong sandboxing and verification story. Wasm is, basically, NaCL in a form that Mozilla and the non-googles etc could accept. There are small implementation differences but the details are all non-important. It was all political. If they had accepted NaCL we'd have had what we have with wasm only we'd have had it years ago.

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.
wffurr 8y ago
At this point, Chrome is just as happy to get rid of NaCl. It's one of the last things to still use the crufty old PPAPI interface. Mozilla dropped the predecessor, NPAPI, years ago.
- willvarfar 8y ago
  This may be true re chrome wanting to move on, but it seems a bit unfair to liken ppapi to npapi in reply to a discussion on security! Npapi was in-process, which was the whole security problem. Ppapi was built around strong process isolation.
floatboth 8y ago
> small implementation differences Naaah it really doesn't seem small. Details are important. NaCl comes from the plugin world (NPAPI → PPAPI), while wasm comes from the JS world ("removing the JS from asm.js"), and most existing JS engines have been able to just reuse their codegen/backend parts. PNaCl was based on a bad idea: "let's make a stable subset of LLVM IR". LLVM moves quickly, if you have a stable subset you'll eventually have to translate it to actual updated LLVM IR anyway. And good luck to anyone who wants to implement a simple small interpreter for that! wasm is really simple — just a close-to-metal abstract machine. No included libc, no bindings to any particular platform (there might be DOM/etc. bindings in the future, but on top of wasm, not right in the core spec).
bzbarsky 8y ago
Unlike NaCl, Wasm doesn't require building an entire separate (undocumented and unspecified) API to make it work. Accepting NaCl without accepting PPAPI would not have been very useful. Accepting PPAPI was a non-starter without a lot more work than Google was willing to put into it.
hinkley 8y ago
We are standing in a Google hole and you’re complaining about how we would be getting somewhere faster if someone hadn’t put down their shovel. It’s only a “political thing” if you don’t think that autonomy gives us diversity, or that diversity gives us more unique ideas to consider. If we went with NaCL then everyone but the dominant player would be playing catch-up forever, worse than they already will be.
swiley 8y ago
NaCL had to be largely rewritten for each no platform just to get the applications to run. WASM doesn't need that.

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.

wffurr 8y ago

At this point, Chrome is just as happy to get rid of NaCl. It's one of the last things to still use the crufty old PPAPI interface. Mozilla dropped the predecessor, NPAPI, years ago.

willvarfar 8y ago
This may be true re chrome wanting to move on, but it seems a bit unfair to liken ppapi to npapi in reply to a discussion on security! Npapi was in-process, which was the whole security problem. Ppapi was built around strong process isolation.

floatboth 8y ago

> small implementation differences Naaah it really doesn't seem small. Details are important. NaCl comes from the plugin world (NPAPI → PPAPI), while wasm comes from the JS world ("removing the JS from asm.js"), and most existing JS engines have been able to just reuse their codegen/backend parts. PNaCl was based on a bad idea: "let's make a stable subset of LLVM IR". LLVM moves quickly, if you have a stable subset you'll eventually have to translate it to actual updated LLVM IR anyway. And good luck to anyone who wants to implement a simple small interpreter for that! wasm is really simple — just a close-to-metal abstract machine. No included libc, no bindings to any particular platform (there might be DOM/etc. bindings in the future, but on top of wasm, not right in the core spec).

bzbarsky 8y ago

Unlike NaCl, Wasm doesn't require building an entire separate (undocumented and unspecified) API to make it work. Accepting NaCl without accepting PPAPI would not have been very useful. Accepting PPAPI was a non-starter without a lot more work than Google was willing to put into it.

hinkley 8y ago

We are standing in a Google hole and you’re complaining about how we would be getting somewhere faster if someone hadn’t put down their shovel. It’s only a “political thing” if you don’t think that autonomy gives us diversity, or that diversity gives us more unique ideas to consider. If we went with NaCL then everyone but the dominant player would be playing catch-up forever, worse than they already will be.

swiley 8y ago

NaCL had to be largely rewritten for each no platform just to get the applications to run. WASM doesn't need that.