Ehm, I'm by no means a security expert but Matasano's overview [1] of the security model seemed to throw some sizable monkey wrenches into the works. Has Google addressed those criticisms?
"P.S. No, we haven't forgotten about the security contest, but we really
don't like to rush the jury. Please watch for a related announcement in the
coming weeks."
I would assume the security issues will be mentioned or addressed in their upcoming announcement.
The pertinent part is at the bottom of the post...
Finally, some of you have asked when Native Client will be ready for end-users. In this context, we recognize that there is well-justified resistance to installing browser plug-ins. For this reason we have a strong preference for delivering Native Client pre-installed or built into the browser, and we'll be focusing on that as our main strategy for delivering Native Client to users. Careful readers may have already noticed evidence of integration into Chromium <http://dev.chromium.org>; in the Native Client source. Recognizing the many technical and non-technical challenges to browser integration, we will continue to support our NPAPI plug-in until we can deliver the system via a better alternative.
The headline is a controversy-stirring deception: the word "Chrome" does not appear in the linked email.
What it does say: "Careful readers may have already noticed evidence of integration into Chromium <http://dev.chromium.org>; in the Native Client source."
Chromium, not Chrome. "[E]vidence of integration", not completion. "[I]n the Native Client source", not the Chromium/Chrome source.
So now chrome contains means to call native code. Isn't that what we initially used as a reason to move away from IE which also allowed to do that via ActiveX?
So if IE allows native code to run, then it's bad.
But if Chrome does it, it's cool.
Just because one is sandboxed and the other is not, does not mean that it's inherently more secure. Sandboxes can be broken out of.
> Just because one is sandboxed and the other is not, does not mean that it's inherently more secure.
Actually, that is actually what it means. Security is the reason for the sandbox and is an essential property of the native client. Sure, bugs could exist that defeat the protections but that can just as easily be said for any code.
ActiveX is very different -- by design, there are no protections.
However, I'm not sure I understand why the code has to be native -- A think Google could have built a C-compatible VM machine language that would be easier to validate and then just JIT that in the browser. They already need a patched GCC to compile the native code for the client. And a VM JIT could be ported to other platforms besides x86. Why does it have to be native?
Hypothetical arguments can go any way you choose. If sandboxes can be broken out of then all browsers are equal and you better disable JavaScript, Java, and Flash.
They say they are trying to respect the NPAPI spec, so it should work with any browser that works with NPAPI that is to say firefox, webkit, opera etc except IE I guess (not sure).
Will the bulk of the browser wind up inside the NaCl sandbox? A supervisor runs a bunch of sandboxes - one for each tab - each having the minimum necessary hooks for communications, storage & interface.
I know Google is a big company but it really seems like they're going off in a thousand different directions these days. Might not be a bad idea for them to focus a bit more.
Most of Google's weird stuff makes sense in the long term. Google is big on making web apps, for example, so they have a serious interest in making web apps less painful. To that end:
1. They design a browser to make web apps more reliable and secure. One process per tab, plus fine-grained OS-level security.
2. In that browser, they introduce a JavaScript engine meant to make execution of JS a lot faster.
3. They continue to fund Mozilla, which is working on some of the same things, and may have a better approach to the JavaScript performance issue with TraceMonkey.
4. And now the Native Client. Theoretically its speed may even be surpassed by sufficiently good JITting of JavaScript (or whatever), but practically it will probably be pretty handy for some applications. It's nice to be able to get native speed now instead of waiting for a better JIT to be developed and deployed.
About the only thing Google's spending serious money on that doesn't improve the environment for their money-making products is the Google Lunar X-Prize. And that can be justified by the sheer coolness of sending probes to the moon.
[+] [-] skorgu|17 years ago|reply
[1] http://www.matasano.com/log/1674/the-security-implications-o...
[+] [-] oconnor0|17 years ago|reply
I would assume the security issues will be mentioned or addressed in their upcoming announcement.
[+] [-] enomar|17 years ago|reply
Finally, some of you have asked when Native Client will be ready for end-users. In this context, we recognize that there is well-justified resistance to installing browser plug-ins. For this reason we have a strong preference for delivering Native Client pre-installed or built into the browser, and we'll be focusing on that as our main strategy for delivering Native Client to users. Careful readers may have already noticed evidence of integration into Chromium <http://dev.chromium.org>; in the Native Client source. Recognizing the many technical and non-technical challenges to browser integration, we will continue to support our NPAPI plug-in until we can deliver the system via a better alternative.
[+] [-] gojomo|17 years ago|reply
What it does say: "Careful readers may have already noticed evidence of integration into Chromium <http://dev.chromium.org>; in the Native Client source."
Chromium, not Chrome. "[E]vidence of integration", not completion. "[I]n the Native Client source", not the Chromium/Chrome source.
[+] [-] pilif|17 years ago|reply
So now chrome contains means to call native code. Isn't that what we initially used as a reason to move away from IE which also allowed to do that via ActiveX?
So if IE allows native code to run, then it's bad.
But if Chrome does it, it's cool.
Just because one is sandboxed and the other is not, does not mean that it's inherently more secure. Sandboxes can be broken out of.
In IE, I can at least turn this crap off.
[+] [-] wvenable|17 years ago|reply
Actually, that is actually what it means. Security is the reason for the sandbox and is an essential property of the native client. Sure, bugs could exist that defeat the protections but that can just as easily be said for any code.
ActiveX is very different -- by design, there are no protections.
However, I'm not sure I understand why the code has to be native -- A think Google could have built a C-compatible VM machine language that would be easier to validate and then just JIT that in the browser. They already need a patched GCC to compile the native code for the client. And a VM JIT could be ported to other platforms besides x86. Why does it have to be native?
[+] [-] wmf|17 years ago|reply
[+] [-] mishmash|17 years ago|reply
[+] [-] patcito|17 years ago|reply
[+] [-] samlittlewood|17 years ago|reply
[+] [-] jsz0|17 years ago|reply
[+] [-] sketerpot|17 years ago|reply
1. They design a browser to make web apps more reliable and secure. One process per tab, plus fine-grained OS-level security.
2. In that browser, they introduce a JavaScript engine meant to make execution of JS a lot faster.
3. They continue to fund Mozilla, which is working on some of the same things, and may have a better approach to the JavaScript performance issue with TraceMonkey.
4. And now the Native Client. Theoretically its speed may even be surpassed by sufficiently good JITting of JavaScript (or whatever), but practically it will probably be pretty handy for some applications. It's nice to be able to get native speed now instead of waiting for a better JIT to be developed and deployed.
About the only thing Google's spending serious money on that doesn't improve the environment for their money-making products is the Google Lunar X-Prize. And that can be justified by the sheer coolness of sending probes to the moon.