Most native applications can access everything on your computer – including your files. This access means that you have to make decisions about which apps you trust enough to install, because a malicious or buggy application might harm your machine. Here at Google we believe you shouldn't have to choose between powerful applications and security. That's why we're working on Native Client, a technology that seeks to give Web developers the opportunity to make safer and more dynamic applications that can run on any OS and any browser. Today, we're sharing our technology with the research and security communities for their feedback to help make this technology more useful and more secure.

Our approach is built around a software containment system called the inner-sandbox that is designed to prevent unintended interactions between a native code module and the host system. The inner-sandbox uses static analysis to detect security defects in untrusted x86 code. Previously, such analysis has been challenging due to such practices as self-modifying code and overlapping instructions. In our work, we disallow such practices through a set of alignment and structural rules that, when observed, enable the native code module to be disassembled reliably and all reachable instructions to be identified during disassembly. With reliable disassembly as a tool, it's then feasible for the validator to determine whether the executable includes unsafe x86 instructions. For example, the validator can determine whether the executable includes instructions that directly invoke the operating system that could read or write files or subvert the containment system itself.

To learn more and help test Native Client, check out our post on the Google Code blog as well as our developer site. Our developer site includes our research paper and of course the source for the project under the BSD license.

Ian, i don't think that an emulator running in a VM (Even with JIT support) could come close to native execution (With the few alignment and instructions limits here) for any processor intensive application.

James, I assume you didn't read the paper. If you had, you would know they use a totally different security model, and don't assume NaCl authors are trustworthy (there isn't even a digital signature to fake).