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<http://code.google.com/contests/nativeclient-security/>

   - We submitted a detailed technical
paper<http://nativeclient.googlecode.com/svn/data/docs_tarball/nacl/googlec...>to
a peer-reviewed conference; it appeared in the IEEE
   2009 Symposium on Security and
Privacy<http://oakland09.cs.virginia.edu/>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
<http://whatwg.org/ww>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<http://code.google.com/apis/o3d/>

*Details*

Some of you have already noticed that our public SVN
repository<http://code.google.com/p/nativeclient/source/checkout>has
changed from a simple reflection of the latest tarball to an active
development repository. We are using the
native-client-reviews<http://groups.google.com/group/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 <http://code.google.com/p/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<http://google-code-updates.blogspot.com/2009/04/toward-open-web-stand...>,
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 <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.

Some details from this note were also mentioned at Google IO.
Video<http://code.google.com/events/io/sessions/NativeClientUsingNativeCode...>and
slides<http://dl.google.com/io/2009/pres/Th_1200_NativeClientUsingNativeCode...>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.