Update on Google Native Client - now built into Chrome(groups.google.com)
groups.google.com
Update on Google Native Client - now built into Chrome
http://groups.google.com/group/native-client-announce/browse_thread/thread/e69fe64e8decbe16
7 comments
"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.
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.
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.
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.
Let me play devil's advocate here:
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.
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.
> 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?
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?
Google could have built a C-compatible VM machine language that would be easier to validate
A JIT is significantly more code than the NaCl verifier, and generally JITs don't handle SIMD well.
A JIT is significantly more code than the NaCl verifier, and generally JITs don't handle SIMD well.
A JIT could handle SIMD if those instructions are included in the VM. I'm not thinking about a high-level VM like Java but something considerably more low-level. A machine language with the most important features of any modern CPU but without the ambiguities and trappings of any particular architecture. In NaCl, they're already restricting the code to a subset of x86 instructions, so it's not far off.
And it doesn't even have to be JIT -- it could just be a compiler that translates from the verifiable VM code directly into x86 before anything is run.
And it doesn't even have to be JIT -- it could just be a compiler that translates from the verifiable VM code directly into x86 before anything is run.
> A machine language with the most important features of any modern CPU but without the ambiguities and trappings of any particular architecture.
Could you elaborate? I'm not convinced that x86 looks like other architectures.
Could you elaborate? I'm not convinced that x86 looks like other architectures.
All architectures have opcodes for moving data, addition, multiplication, bit shifting, etc. They also all have a stack and registers. While the details are different (number of registers, for example), in general they all work the same.
I agree with you, and I've never heard an argument that decisively positioned native code past the bounds of what's likely to be achieved with JITs. Native also seems like a bad bet on the future of computation.
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.
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.
[1] http://www.matasano.com/log/1674/the-security-implications-o...