While replacing JavaScript might not be a design goal, the experience on Android and iOS shows what happens when there is a native layer for other eco-systems to plug into the platform.
For me, WebAssembly will be the revenge of browser plugins.
We already have Flash, Java applets and Silverlight being made available on WebAssembly, even if not at same feature level as their former selfs.
I’m well aware of hardware support for enforcing memory safety, but that’s not quite what I’m talking about here: browser plugins have historically been poorly sandboxed, while WebAssembly should be an improvement in this area.
Which I doubt, given that it depends on what is being compiled into WebAssembly anyway.
It is really nothing new here, just the politics to have a bytecode execution platform that everyone agrees on.
For example, if I can replicate a Flash security flaw with CheerpX, should I blame Flash, CheerpX for being a good implementation, or WebAssembly for allowing Leaning Technologies to faithfully re-implement Flash?
Memory tagging or inner bound checks have no effect on sandboxing. The wasm guarantee is that a module cannot escape it's sandbox, not that it is logically correct.
the security model of the web site based on executing arbitrary code, so you would need to assume that the wasm you receive tagged it's memory in the most malicious way possible anyway.
the way I see it real hardware needs this kind of checks more because they have worse sandboxing
Also, Flash vulnerabilities were about escaping the execution sandbox of the web, so you should blame bad the implementation/specification of wasm in your case.
AFAIK WebAssembly can't do more harm than JS since it lives in the same sandbox, so that's not a concern? You're basically running Flash in a small VM.
For me, WebAssembly will be the revenge of browser plugins.
We already have Flash, Java applets and Silverlight being made available on WebAssembly, even if not at same feature level as their former selfs.