Update on Google Native Client - now built into Chrome

http://groups.google.com/group/native-client-announce/browse_thread/thread/e69fe64e8decbe16

by ropiku • 17 years ago

28 20 17 years ago

groups.google.com

enomar• 17 years ago

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.

skorgu2• 17 years ago

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?

[1] http://www.matasano.com/log/1674/the-security-implications-o...

oconnor0• 17 years ago

"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.

skorgu2• 17 years ago

How did I miss that?

Even granting the benefit of the doubt that they have solved the issues raised this still seems like putting the cart before the horse to me.

mishmash• 17 years ago

What are the chances of this being adopted anywhere else (leaving IE out, of course)?

patcito• 17 years ago

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).

pilif• 17 years ago

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.

wvenable3• 17 years ago

> 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?

wmf3• 17 years ago

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.

wmf3• 17 years ago

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.

tptacek2• 17 years ago

All sandboxes are not created equal.

gojomo• 17 years ago

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.

jsz0• 17 years ago

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.

sketerpot• 17 years ago

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.

samlittlewood• 17 years ago

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.

Update on Google Native Client - now built into Chrome

Related Stories