Thursday, August 18, 2011

Native Client brings sandboxed native code to Chrome Web Store apps

By Christian Stefansen, Native Client Team

Wouldn’t it be great if you could create web apps using your existing C and C++ code? Native Client lets you do just that, and it is now enabled for Chrome Web Store apps in Google Chrome’s beta channel.

Native Client apps live on the web platform, so you don’t need to create separate versions of your app for each operating system. Rather than relying on OS-specific APIs, Native Client apps use Pepper, a set of interfaces that provide C and C++ bindings to the capabilities of HTML5. This means that once you’ve ported your code to Native Client, it will work across different operating systems, and you only need to maintain one code base.

Today Native Client supports the Pepper APIs for 2D graphics, stereo audio, URL fetching, sandboxed local file access (File API), and asynchronous message passing to and from JavaScript. In future releases we will be adding support for hardware accelerated 3D graphics (OpenGL ES 2.0), fullscreen mode, networking (WebSockets and peer-to-peer connections), and much more. As new capabilities are added to HTML5 and Pepper, they will become available to Native Client.

This functionality does not come at the expense of security. To ensure that Native Client is as safe as JavaScript, Native Client code is isolated from the operating system by two nested security sandboxes: the Native Client sandbox and the Chrome sandbox. And unlike NPAPI plugins or ActiveX controls, Native Client apps do not have access to the underlying OS APIs.

We encourage you to start developing apps with Native Client. You can download the SDK and find tutorials, examples, API documentation, and our FAQ on the Native Client site. Once version 14 of Chrome hits stable channel, you’ll be able to upload your Native Client apps to the Chrome Web Store, where you can reach Chrome’s 160 million users.

The next milestone for Native Client is architecture independence: Portable Native Client (PNaCl) will achieve this by using LLVM bitcode as the basis for the distribution format for Native Client content, translating it to the actual target instruction set before running. Until then the Chrome Web Store will be the only distribution channel for Native Client apps. This will help us ensure that all Native Client apps are updated to PNaCl when it’s ready – and in the meantime avoid the spread of instruction set architecture dependent apps on the web. We’ll be providing updates on the progress of PNaCl on this blog.

Christian Stefansen is the Product Manager for Native Client. In his spare time, when he is not writing Native Client apps for fun, he likes playing tennis, playing the piano, and living as a travel writer in India for a couple of weeks at a time

Posted by Scott Knaster, Editor


  1. are there any apps in web store which use NaCl?

  2. How is access to platform API's blocked?

  3. This is great news! I can't wait to see some apps that leverage NaCl.

    Congrats Google, this is a monumental achievement.

  4. Will UDP connections ever be supported? TCP is kind of a pain for real time games. Also, can you give a very rough estimate of when opengl might be available? 1 month? 6 months? A year?


  5. I wonder if native client works with qt.

  6. @Tim: You are unlikely to ever see raw UDP due to well known security issues. We agree that more networking support would be very useful and have a number of enhancements in progress. See for example and

  7. @jongary: This question is central to the entire project. Native Client uses an OS-independent sandbox, based on machine code analysis, to prevent direct access to the native OS by the NaCl module. We've published several research papers on this subject; Please see for all the details.

  8. Kinda sad not to see openGL in the initial push...

    I also thought the whole point of installing web apps was that users could opt into security risks like UDP.

    I know its hard to accept but sometimes you must embrace "bad security".

    At the moment flash has a hideous strangle hold on peer to peer UDP traffic in the browser. Please don't let flash continue to effortlessly win the internets.

  9. I seriously doubt that UDP traffic alone is enough to have flash maintain its lead. NaCl brings the advantage of supporting legacy C[++] libs which is a far larger advantage.

    On another note, I'm looking forward to seeing OpenGL in the near future as well. Nexuiz would be a great demo, and hopefully we see a Unity3D NaCl client, or at least some games. For the time being, we have Quake:

    We also have DOSBox, er, NaClBox:

  10. Google finally delivered on the original Netscape goal of abstracting the Operating System from the web application.
    Will this change the world?