
Update on Google Native Client - now built into Chrome - ropiku
http://groups.google.com/group/native-client-announce/browse_thread/thread/e69fe64e8decbe16
======
skorgu
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...](http://www.matasano.com/log/1674/the-security-implications-
of-google-native-client/)

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

~~~
skorgu
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.

~~~
wmf
I think the headline is a bit optimistic. NaCl _will_ be built into Chrome
_after_ they fix all the security holes.

------
enomar
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>](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
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>](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
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.

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

~~~
wmf
_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.

~~~
wvenable
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.

~~~
swolchok
> 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.

~~~
wvenable
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.

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

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

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

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

