Chrome Dev Hits Version 7; Native Client Part of Release

Security has been a focus of NaCl from the outset. It uses a sandbox security model built around a restricted set of "native code". The aim was to make NaCl apps verifiable from a security stand point.

Chris Rohlf from Matasano did a great blog post, The Security Implications Of Google Native Client, that compares the NaCl approach to ActiveX and Java -- and included beautiful diagrams to boot! Unfortunately the images appear to be broken on the Matasano blog [1] but I've found a PDF'd version [2] that contains them in all their glory.

The post came out of the Matasano team's entry in the Native Client Security Contest [3] that Google held early last year. The Matasano team ended up taking second place behind Mark Dowd / Ben Hawkes [4]. All those guys are 'rockstars' in the security industry.

So, Google has thought deeply and tried hard when designing NaCl's security. They a care enough and are switched on enough to run a security contest that was well received by the industry (rare). A number of mega-brains-on-sticks found issues back in May '09 -- hopefully they have all been addressed.

It looks to me that Google has done a good job at learning from past mistakes when implementing NaCl and it should be different. No doubt there will be further security issues found but then again, name a framework that is free from flaws?

[1] http://chargen.matasano.com/chargen/2009/8/27/the-security-i...

[2] http://beefchunk.com/documentation/security/the_security_imp...

[3] http://code.google.com/contests/nativeclient-security/index-...

[4] http://code.google.com/contests/nativeclient-security/index....

They are certainly trying to make it as secure as possible. It is open source, they've held at least one contest to try to break the security of it (http://code.google.com/contests/nativeclient-security/faq.ht...), it is running inside a sandbox with limited permissions, etc.

While it is always risky to introduce anything new, that is a price we pay for progress. And that is true for anything - at this point, I don't think using it would be too much more risky than using a new javascript engine, for example. Aside from never trying anything new, what else can we hope for?

Also, I will point out that even in the dev channel it is still disabled by default. So there is some time yet for the security to be evaluated, to see if there are any endemic problems.

This was my first concern followed by, "wait, Chrome silently auto-updates..."

As far as I know it silently auto-updates across major versions as well as minor. The automatic updating of Flash 10.x that got linked on HN a little while ago is a great example of how this is good. A widely publicized hole in Native Client could turn it on its head quickly. It's a gut reaction on my part, but distributing Native Client to Chrome's user-base feels premature. It's only been an acknowledged project at Google for what, less than two years? I recall hearing about it at I/O 2009, and I'd wish they'd let it bake a while longer.

I've never been aware of NaCl, but when I just read what it was, I was filled with the exact same sentiment.

Isn't this what ActiveX was all about? We all know what happened in that instance.

Can you point to a similar thing? I personally haven't seen it: binary proving of a limited subset of the x86 instruction set.

> _People have talked about how webapps are going to kill traditional software for the next decade. If the relevant browsers implemented this, could it finally actually happen?_

I would say that the difference between webapps and desktop apps will disappear.

In fact, Native Client started as a browser plugin for Firefox, so portions of it certainly could be integrated into other browsers. However, the developers have moved from the plugin to direct browser integration to overcome limitations in the plugin API. Presumably similar integration would be necessary in other browsers to achieve the same level of functionality.

http://groups.google.com/group/native-client-announce/browse...

Here's the source code; I'm sure other browsers are welcome to use it. http://code.google.com/p/nativeclient/wiki/Source

Not yet, but they're working on a solution using the LLVM bitcode format:

http://nativeclient.googlecode.com/svn/data/site/pnacl.pdf http://www.chromium.org/nativeclient/native-client-documenta...

Not truly machine-independent. How can you run x86 code on an ARM architecture, and vice-versa? Although if they do have this feature in Chromium it could make a huge difference in performance of web apps.

This is just how Chromium does versioning.

Chromium version #'s are four parts: major.minor.build.patch. Of these four parts, major.minor are "marketing" controlled. The other two parts, build.patch are engineering controlled and related to the Chromium branching strategy.

Chromium develops everything on trunk. Typically, once a day, they increment the build #. The build #'s are part of their branching process. Once a branch is cut, its build # is fixed. Instead, only the patch # is incremented on that branch, again about once a day.

So for example, the current stable release is milestone 5. This was built from the 375 branch. So the full version # is 5.0.375.127, which indicates that about 127 days have passed since the 375 branch was cut as you can see here:

http://src.chromium.org/viewvc/chrome?view=rev&revision=...

Chromium hasn't made much use of the minor part of the version #, the notable exception being 4.1.

Also, historically, Chromium has aimed to release a new major version every 6 months. But they announced recently that they plan to move to an even shorter release schedule:

http://blog.chromium.org/2010/07/release-early-release-often...

So if you think it's got high versions now, just wait. I notice that even though milestone 6 is only in the beta channel, the dev channel already has milestone 7 loaded in it:

http://omahaproxy.appspot.com/

tl;dr: Chrome versions move fast because they have a major milestone release every 6 months and soon the versions will move even faster.

This isn't unheard of - emacs is at version 22, but it is really only because they grew tired of adding 1. in front.

Software versioning never made much sense in the first place.

Smart marketing, it's perceived stability.

"Oh, you're running Firefox''3.5''? my Chrome is on version 7"*

(*note, I have overheard pretty much this exact conversation)

Why do you imagine that versioning should be used for anything other than milestones the development team believe are important enough to warrant bumping the major version number?

Also, do you imagine that Chrome 7 is not as advanced and has not seen as much improvement as IE 7? If you look at the advancements made with each Chrome revision, they are as significant as, if not sometimes more than, the differences between major versions of Firefox or IE.

Doesn't really matter. The version numbers are for internal use and for tech blogs, the consumer is never exposed to it because of the auto update.

Chrome also uses the pepper plugin API.