There are fact several layers of sandboxing, which dramatically limit both the ability to create exploits, and the damage that a successful exploit can cause.
To be clear: I work for Mozilla, and I think Asm.js is a great project with a lot of potential for developers and the web; however, Google did a lot of innovative work to have a great security foundation for NaCL, which was not a real goal for NaCL AIUI.
> a "beta product" shows that it's not 100% safe
There is no correlation here.
> in the context of an interpreted, thoroughly tested JS engine, which is very much more secure.
> but since JS engines are heavily optimized, it makes the security problem disappear completely because JS is an old language, so all security problems are already known.
The continuing drive for JS performance has lead to new avenues for serious exploits, some of which are poorly understand are only have been partially mitigated by widely used engines. For just one example, see http://www.matasano.com/research/Attacking_Clientside_JIT_Co...
> The fact android uses java for its app is another demonstration of the easiest path to security.
Then I don't understand their choice. I know there are many java devs, but I think delivering an API through java shields from many attack vectors.
I know java has its vulnerabilities, but it's easier to cover those than to design an OS which is secure from a C/C++ point of view.
Using old techs that are being used by many devs has many advantages, one is that security problems won't be new.
And to be clear: I hate java.
> There is no correlation here.
I was just saying it's better to march into known territory which are existing techs, than to create new techs in which you don't know who will find an exploit first: the white hat or the black hat. Existing techs are like old guys you can trust because they've been here for a long time. I guess the sandboxing is very nicely done, but a tech is not mature until it's not a very little bit used in a mainstream fashion, so that security people can look its parts more closely.
I'm not a security expert anyways, I'd love to watch NaCL be used more, but computer security will always make things suck one way or another.
It is actually quite different, read: http://static.googleusercontent.com/media/research.google.co...
There are fact several layers of sandboxing, which dramatically limit both the ability to create exploits, and the damage that a successful exploit can cause.
To be clear: I work for Mozilla, and I think Asm.js is a great project with a lot of potential for developers and the web; however, Google did a lot of innovative work to have a great security foundation for NaCL, which was not a real goal for NaCL AIUI.
> a "beta product" shows that it's not 100% safe
There is no correlation here.
> in the context of an interpreted, thoroughly tested JS engine, which is very much more secure.
> but since JS engines are heavily optimized, it makes the security problem disappear completely because JS is an old language, so all security problems are already known.
The continuing drive for JS performance has lead to new avenues for serious exploits, some of which are poorly understand are only have been partially mitigated by widely used engines. For just one example, see http://www.matasano.com/research/Attacking_Clientside_JIT_Co...
> The fact android uses java for its app is another demonstration of the easiest path to security.
I lol'ed.