Native Client Update - June 2009

[Brad Chen]

This seems like an appropriate time to share some perspective and some plans on the Native Client project. We've made a lot of progress since our open source release in December, and as we firm up plans for the next year or so we want to share some of our thinking with you.

To date, Native Client has been presented primarily as a research project. We recognized the underlying technology to be ambitious and risky, and felt strongly than a generous measure of public scrutiny was appropriate before we committed to any definite plans. In addition to multiple internal security and design reviews, we did a number of things to expose our work outside Google and encourage community scrutiny:

• We released the project open source in December 2008
  
• We held a security contest 
• We submitted a detailed technical paper to a peer-reviewed conference; it appeared in the IEEE 2009 Symposium on Security and Privacy in May

Based on our experience to date, we believe that the basic architecture of our system is sound and the implementation is supportable. So now we are undertaking a number of tasks to transition Native Client from a research technology to a development platform. Here's some of what you should expect:

• Moving Google's efforts from our internal research repository to a public SVN repository
• Reorganizing the source code
  
• Creating a collection of SDK-style examples of Native Client applications
• Proposing adaptation of the Web Workers interface to support native workers
  
• Developing revisions to NPAPI to improve portability and performance of plugins hosted in Native Client
  
• Dropping some temporary safety features as we replace them with other permanent safety features
• Exploring integration with Google's O3D

Details

Some of you have already noticed that our public SVN repository has changed from a simple reflection of the latest tarball to an active development repository. We are using the native-client-reviews discussion group for our code reviews; take a look if you want all the gritty details. You should also notice that we've undertaken a major source code reorganization as a part of this transition. We think the new tree is simpler, better reflects the distinction between trusted and untrusted code, and will also help us support multiple instruction set architectures.

With these changes, it will be harder for us to guarantee the stability of the SVN head-of-tree; people who don't want to track the bleeding edge should use a tarball release. In the coming weeks we plan to introduce a label for the 'last stable' build and also evolve our tarball release into more of an SDK-like package, omitting most source except what's needed to build sample programs.

The current release includes a number of temporary safety features that we are looking forward to removing. These include an expiration date on the plug-in, and a whitelist that prevents using Native Client modules from the open Internet. These features were added to protect developers during the research phase of the project. They aren't appropriate for end-users, so we will be dropping them as we enable other, friendlier safety features:

• The outer sandbox
• A platform qualification test (see native_client/src/trusted/platform_qualify)
• A CPU blacklist
• A module blacklist
• A robust installer with auto-update support

Most of these are already represented someplace in the source tree. Google's Omaha project is representative of the kind of auto-update support we think is appropriate for robust desktop infrastructure.

We also recognize the importance of OpenGL and hardware-accelerated graphics to our community. We were very pleased to see the announcement of O3D, and are working with the O3D team to study how we can leverage their system to deliver hardware-accelerated graphics to native code. This is a complicated effort, so unfortunately we can't say much about what and where, but we're happy to be able to share our intentions, and welcome additional feedback from the community on how you would like to see this work proceed.

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

Some details from this note were also mentioned at Google IO. Video and slides are now available online.

On behalf of the entire Native Client team, thank you for your interest in this project.

Brad Chen
Engineering Manager
Google Native Client

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.