Google has released an experimental set of development tools called Native Client, or NaCl, for running x86 native code in browser-based applications. The open source research project represents the beginnings of a sandbox for plug-in code that takes full advantage of local computational power, like Microsoft's ActiveX but with stronger security.

NaCl attempts to contain untrusted x86 code using an inner-sandbox that limits the interaction between a native code module and the host system. It uses static analysis to detect security problems, augmented by structural rules aimed at ensuring that code can be reliably disassembled so unsafe elements can be identified.

NaCl, the chemical formula for sodium chloride, can be seen as salt in Microsoft's wounds. If Google's Native Client becomes a robust system, the performance gap between desktop and Web applications could all but vanish.

For companies that continue to rely on revenue from desktop software, such as Microsoft and Adobe, that would further undermine the value proposition of their costly software products. That possibility has long been foreseen, however, and both Adobe and Microsoft are moving their applications online in ways that make the browser less relevant.

NaCl includes a runtime, a browser plug-in, and a set of compilation tools based on the GNU Compiler Collection. It's available for Mac OS X, Linux, and Windows.

Google engineer Brad Chen illustrates how the Native Client could be used to make a browser-based version of an image-editing program like Photoshop more feasible than it is presently.

"Today, you could provide this feature using a combination of JavaScript and server side processing," he explains in a blog post. "This approach, however, would cause huge amounts of image data to be transferred between browser and the server, leading to an experience that would probably be painfully slow for users who just want to make a few simple changes. With the ability to seamlessly run native code on the user's machine, you could instead perform the actual image processing on the desktop CPU, resulting in a much more responsive application by minimizing data transfer and latency."

Java applets arguably could be used for this purpose, but they take time to download and activate. For Google, which considers every millisecond of delay a blow to the user experience, this isn't an option.

In a post on Google Groups, Chen elaborates on why Google is looking beyond Java and other virtual machines. "I think these are great, and that the people who like them should use them and help make them successful," he said. "At the same time, a part of the motivation for Native Client is to give people more choices. Native Client was created in part for people who want to use other programming languages, and not be locked into a single language or programming environment just because that's all they get from a particular [virtual machine]."

But before Google Native Client can fulfill that promise, it has a long way to go. In typical Google fashion, the research project has been released in its early stages. Given the slow adoption curve of related Google efforts to make the browser more competitive with the desktop like Google Gears, it could be years before NaCl represents a viable alternative to vaguely comparable technologies like Adobe AIR or Microsoft Silverlight.