About a year after it’s original announcement, Google released a new version of the Native Client (NaCl) SDK, which allows the safe execution of native code from a web browser. It is unclear though, if this ambitious project will be making it to production, or have the fate of other projects like Wave or Gears.
The new SDK features support for Chrome’s new plugin interface (Pepper), better security and other improvements:
The SDK now includes support for a comprehensive set of Pepper interfaces for compute, audio, and 2D Native Client modules. These interfaces are close to being stable, with some important exceptions that are listed in the release notes.
In addition, we’ve focused on improving security. We have enabled auto-update and an outer sandbox. This allowed us to remove the expiration date and localhost security restrictions we had adopted in previous research-focused releases. Beyond security, we’ve also improved the mechanism for fetching Native Client modules based on the instruction set architecture of the target machine, so developers don’t need to worry about this any more.
Native Client origins can be traced to Robert Wahbe et al. “Efficient software-based fault isolation”:
One way to provide fault isolation among cooperating software modules is to place each in its own address space. However, for tightly-coupled modules, this solution incurs prohibitive context switch overhead. In this paper, we present a software approach to implementing fault isolation within a single address space. Our approach has two parts. First, we load the code and data for a distrusted module into its own fault do main, a logically separate portion of the application's address space. Second, we modify the object code of a distrusted module to prevent it from writing or jumping to an address outside its fault domain. Both these software operations are portable and programming language independent. Our approach poses a tradeoff relative to hardware fault isolation: substantially faster communication between fault domains, at a cost of slightly increased execution time for distrusted modules. We demonstrate that for frequently communicating modules, implementing fault isolation in software rather than hardware can substantially improve end-to-end application performance.
In this release NaCl has several limitation like:
- On Mac requires Snow Leopard,
- Won’t work on Windows XP 64-bit systems,
- Is not available on all Linux distributions,
- All available Pepper functions must be invoked from the main Pepper/JavaScript thread of execution. Although traditional plugins in Chrome run only out of process, Pepper plugins only run in process and in the future the will be supported only within NaCl.
- No support for 3D graphics, file I/O, or peer-to-peer networking,
- No support for devices such as cameras and microphones.
If you what to give NaCl a try you must first enable it on Chrome v10, at the about:flags configuration page, and use the built-in Python HTTP server.
Mono developers can also directly target the Native Client:
The support for Native Client allows Mono's virtual machine, garbage collector and Just-in-Time compiler to be used inside a Native Client sandbox.
Google added JIT support to their Native Client engine to give users greater flexibility while using Native Client. In the past, Native Client was limited to running statically compiled code (Mono on AOT mode), but this would prevent interesting scenarios, prevent System.Reflection.Emit, scripting languages and other dynamic cases from working. We are incredibly excited about Google's work and Elijah's contributions on this area.
Similarly Qt developers might be interested in looking into how they can use NaCl for deploying Qt-based UIs.
The Native Client mission to bring sandboxed Intel x86 native code to the browser is a very ambitious one, so it is only fair for the community to wonder if Google can actually pull it off:
Can you guarantee that this is here for keeps and won't have its plug pulled like Wave?
Besides the cancellation of Wave, one can recall the highly acclaimed Gears project, which Google cancelled, although there were several hight profile deployments both from Google and 3rd-party. Especially one part of Gears, which aimed at relational browser storage, was even recently dropped by the W3C as an HTML5 spec all together.
With this track record, do you think that Google will be taking the Native Client all the way?