3 ms·

"The real advantages of ASM.js is security" - isn't NaCl sand-boxed?

jokoon 13y ago
I'm not sure but I think it's not a real sandbox, the code is still executed like any native code, the code is just thoroughly checked for instructions that would try to access things that are not supposed to be accessed. It's just some kind of compiling that does very strict security checks, and maybe recheck the executable file hash to match. NaCL is at true native speed, but the fact that it's still a "beta product" shows that it's not 100% safe. Well anything really is 100% safe, but if NaCL isn't entirely safe, a NaCL vulnerability could be quite disastrous. That's where the google beta culture lag behind. Security is still the most important features of any massively distributed product. If ASM.js manages to reach a mere 2x slowdown, it's great because it does in the context of an interpreted, thoroughly tested JS engine, which is very much more secure. NaCL introduces new standards and compiling methods, which would require a lot of testing and reviewing before being really deemed secure. There are a balance of pro and cons, but in the grand battle of big innovations, keeping things secure is a hard problem, because you can't always introduce new things without creating new risks. asm.js relies heavily on the fact that it uses an old, crap language, 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. It's a problem about how developers practice their job, what they use, how it is deployed and ran by users. Innovation on a massive scale and security never mix well. Also, execution speed and security don't mix very well. The fact android uses java for its app is another demonstration of the easiest path to security.
- deleted 13y ago
  [deleted]
- handsomeransoms 13y ago
  > I'm not sure but I think it's not a real sandbox, the code is still executed like any native code It is actually quite different, read: http://static.googleusercontent.com/media/research.google.com/en/us/pubs/archive/34913.pdf 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_Compilers_Paper.pdf 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.
  - jokoon 13y ago
    Thanks for the clarification. > I lol'ed. 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.
    - CmonDev 13y ago
      "And to be clear: I hate java." Most people probably like JVM rather than Java.
      - stcredzero 13y ago
        The JVM contains decades worth of knowledge, some of which was developed for languages like Self.
    - lucian1900 13y ago
      The sole reason for basing Android on Java was its popularity, which grant it good tools and familiarity. The creators said as much several times.

I'm not sure but I think it's not a real sandbox, the code is still executed like any native code, the code is just thoroughly checked for instructions that would try to access things that are not supposed to be accessed. It's just some kind of compiling that does very strict security checks, and maybe recheck the executable file hash to match. NaCL is at true native speed, but the fact that it's still a "beta product" shows that it's not 100% safe. Well anything really is 100% safe, but if NaCL isn't entirely safe, a NaCL vulnerability could be quite disastrous. That's where the google beta culture lag behind. Security is still the most important features of any massively distributed product. If ASM.js manages to reach a mere 2x slowdown, it's great because it does in the context of an interpreted, thoroughly tested JS engine, which is very much more secure. NaCL introduces new standards and compiling methods, which would require a lot of testing and reviewing before being really deemed secure. There are a balance of pro and cons, but in the grand battle of big innovations, keeping things secure is a hard problem, because you can't always introduce new things without creating new risks. asm.js relies heavily on the fact that it uses an old, crap language, 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. It's a problem about how developers practice their job, what they use, how it is deployed and ran by users. Innovation on a massive scale and security never mix well. Also, execution speed and security don't mix very well. The fact android uses java for its app is another demonstration of the easiest path to security.

deleted 13y ago
[deleted]
handsomeransoms 13y ago
> I'm not sure but I think it's not a real sandbox, the code is still executed like any native code It is actually quite different, read: http://static.googleusercontent.com/media/research.google.com/en/us/pubs/archive/34913.pdf 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_Compilers_Paper.pdf 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.
- jokoon 13y ago
  Thanks for the clarification. > I lol'ed. 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.
  - CmonDev 13y ago
    "And to be clear: I hate java." Most people probably like JVM rather than Java.
    - stcredzero 13y ago
      The JVM contains decades worth of knowledge, some of which was developed for languages like Self.
  - lucian1900 13y ago
    The sole reason for basing Android on Java was its popularity, which grant it good tools and familiarity. The creators said as much several times.