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.
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.
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.
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.
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.
> 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.
EDIT "does" - and of course it's flawed but the "story" is pretty great :-D