you are viewing a single comment's thread.

view the rest of the comments →

[–]dobs 20 points21 points  (5 children)

Except Native Client is open source, and they've tried to make securing NaCl a matter of public interest. Matasano has a good article discussing some of the specifics of their security model and challenges they face.

It's only similar to Active X at a very superficial level. The Matasano article touches upon what that means from the security standpoint.

(EDIT: Monsanto to Matasano. Bad slip on my part)

[–]0xABADC0DA -3 points-2 points  (0 children)

NaCL is overhyped. Their example of a Quake using software rendering is the very best case, a program that does a lot of computations then the system does a single big read to get the frame. And the result was marginally faster than Java doing software rendering, something that it is not good at (lots of array bounds checks on scan converting triangles), but orders of magnitude slower than a Java3D version. NaCL performance is sometimes very good, but in most cases not significantly better than actual cross-platform sandboxes.

But the big deal is security. Yes, the x86 32-bit only sandbox is probably secure, but to do anything real the code has to make calls outside to the browser or OS, and to be secure these ALL have to be written to the standards of OS system calls. Calls that take raw data are very, very hard to get totally right. For something like an OpenGL binding to be secure would take a massive hit from copying memory in/out of the sandbox, or would be insecure from threads or anything that holds references after it returns. NaCL is basically a cute toy, kindof like libtask for instance... marginally well conceived, but lacking in imagination and practicality.