| Google Native Client | |
|---|---|
| Developers | Google, others |
| Initial release | 16 September 2011; 14 years ago (2011-09-16)[1] |
| Stable release | |
| Written in | C,C++ |
| Operating system | Windows,Linux,macOS,ChromeOS |
| Platform | x86,ARM,MIPS |
| Successor | WebAssembly |
| Type | Sandbox in web browsers for native code |
| License | New BSD |
| Website | developer |
| Repository | |
Google Native Client (NaCl) is a discontinuedsandboxing technology for running either a subset of Intelx86,ARM, orMIPS native code, or a portable executable, in a sandbox. It allows safely runningnative code from aChromium-basedweb browser, independent of the useroperating system, allowingweb apps to run at near-native speeds, which aligns with Google's plans forChromeOS. It may also be used for securing browserplugins, and parts of other applications or full applications[2] such asZeroVM.[3]
Google introduced Native Client to the public on 8 December 2008 shortly after the September introduction of Google Chrome.[4] NaCl became generally available to the web when it was released in a stable Chrome version in September 2011.[1] In 2013 Google introduced the Portable Native Client (PNaCl), an architecture-independentcompiled ahead-of-time version of NaCl.[5] The general concept of NaCl (running native code in the web browser) has been implemented before inActiveX, but NaCl runs content in a sandbox while ActiveX application has full access to the system (disk, memory, user-interface, registry, etc.). Mozilla proposedasm.js as an alternative to both ActiveX and NaCl. asm.js also allows applications written inC orC++ to be compiled to run in the browser and also supports ahead-of-time compilation, but is a subset of JavaScript and hence backwards-compatible with browsers that do not support it directly.
In 2016, Google de-prioritized feature development for Pepper and Native Client. On 30 May 2017, Google announced deprecation of PNaCl in favor ofWebAssembly.[6] Over the following years, Google Chrome slowly deprecated and removed NaCl on different platforms. ChromeOS version 137 released in 2025 became the last platform and version to support Native Client.
Native Client was anopen-source project developed byGoogle.[7] Games such asQuake,[8]XaoS,Battle for Wesnoth,[9]Doom,[10]Lara Croft and the Guardian of Light,[11]From Dust,[12] andMAME, as well as the sound processing systemCsound, have been ported to Native Client. Native Client has been available in theGoogle Chrome web browser since version 14, and has been enabled by default since version 31, when the Portable Native Client (PNaCl, pronounced: pinnacle) was released.[13][14][15] Native Client has also been used to safely run downloaded code in software other than web browsers, like in the Dæmon game engine.[16]
AnARM implementation was released in March 2010.[17]x86-64,IA-32, andMIPS were also supported.
To run an application portably under PNaCl, it must be compiled to an architecture-agnostic and stable subset of theLLVMintermediate representationbytecode.[18] The executables are called PNaCl executables (pexes). The PNaCl Toolchain makes .pexe files; NaCl Toolchain .nexe files. Themagic number of .nexe files is 0x7F 'E' 'L' 'F', which isELF. In Chrome, they are translated to architecture-specific executables so that they can be run.
NaCl uses softwarefault detection and isolation for sandboxing on x86-64 and ARM.[19] The x86-32 implementation of Native Client is notable for its novel sandboxing method, which makes use of the x86 architecture's rarely usedsegmentation facility.[20] Native Client sets up x86 segments to restrict the memory range that the sandboxed code can access. It uses a code verifier to prevent use of unsafe instructions such as those that perform system calls. To prevent the code from jumping to an unsafe instruction hidden in the middle of a safe instruction, Native Client requires that all indirect jumps be jumps to the start of 32-byte-aligned blocks, and instructions are not allowed to straddle these blocks.[20] Because of these constraints, C and C++ code must be recompiled to run under Native Client, which provides customized versions of theGNU toolchain, specificallyGNU Compiler Collection (GCC),GNU Binutils, andLLVM.
Native Client is licensed under aBSD-style license.
Native Client usesNewlib as itsC library, but a port ofGNU C Library (GNU libc) is also available.[21]
On 9 December 2011, Google demonstrated the readiness of the technology by announcing availability of several new Chrome-only versions ofgames known for their rich andprocessor-intensivegraphics, includingBastion (no longer supported on theChrome Web Store). NaCl runshardware-accelerated 3D graphics (viaOpenGL ES 2.0), sandboxed local file storage,dynamic loading, full screen mode, andmouse capture. There were also plans to make NaCl available on handheld devices.[22][23]
Portable Native Client (PNaCl) is an architecture-independent version. PNaCl apps arecompiled ahead-of-time. PNaCl is recommended over NaCl for most use cases.[24] The general concept of NaCl (running native code in web browser) has been implemented before inActiveX, which, while still in use, has full access to the system (disk, memory, user-interface, registry, etc.). Native Client avoids this issue by using sandboxing.
An alternative by Mozilla wasasm.js, which also allows applications written inC orC++ to be compiled to run in the browser and also supports ahead-of-time compilation, but is a subset of JavaScript and hence backwards-compatible with browsers that do not support it directly.
On 12 October 2016, a comment on the Chromium issue tracker indicated that Google's Pepper and Native Client teams had been destaffed.[25] On 30 May 2017, Google announced deprecation of PNaCl in favor ofWebAssembly.[6] Although initially Google planned to remove PNaCl in first quarter of 2018,[6] and later in the second quarter of 2019,[26] it has been removed in June 2022 (together withChrome Apps).[27][28]
NaCl denotessodium chloride, common tablesalt; as apun, the name ofpepper was also used. Pepper API is a cross-platform, open-source API for creating Native Client modules.[29] Pepper Plugin API, or PPAPI[30][31] is a cross-platform API for Native Client-secured web browser plugins, first based on Netscape'sNPAPI, then rewritten from scratch. It was used in Chromium andGoogle Chrome to enable the PPAPI version ofAdobe Flash[32] and the built-inPDF viewer.[33]
On 12 August 2009, a page on Google Code introduced a new project, Pepper, and the associated Pepper Plugin API (PPAPI),[34] "a set of modifications to NPAPI to make plugins more portable and more secure".[35] This extension is designed specifically to ease implementing out-of-process plugin execution. Further, the goals of the project are to provide a framework for making plugins fully cross-platform. Topics considered include:
The Pepper API also supportsGamepads (version 19) andWebSockets (version 18).[36]
As of 13 May 2010[update], Google's open source browser,Chromium, was the only web browser to use the new browser plug-in model.[37] As of 2020, Pepper is supported by Chrome, Chromium and Blink layout engine-based browsers such as Opera and Microsoft Edge.
In August 2020, Google announced that support for PPAPI would be removed from Google Chrome and Chromium in June 2022.[38]
Firefox developers stated in 2014 that they would not support Pepper, as there were no full specification of the API beyond its implementation in Chrome, which itself was designed for use withBlink layout engine only, and had private APIs specific to the Flash Player plugin which were not documented.[39] In October 2016, Mozilla announced that it had re-considered and was exploring whether to incorporate the Pepper API and PDFium in future releases of Firefox,[40] however no such steps were taken. In July 2017, Adobe deprecated Flash and announced itsend-of-life in the end of 2020.[41] By January 2021, Adobe Flash Player, Google Chrome, Firefox, Safari, and Windows[42] received updates disabling or entirely removing Flash.
One website[43] used NaCl on the server to let users experiment with theGo programming language from their browsers.[44]
Theopen-sourceUnvanquished game makes use of Native Client in the Dæmon game engine[45] in replacement of the Q3VM (Quake IIIvirtual machine).[46][47] In such game engine, the Native Client sandbox is used to safely run arbitrary game code (mods) downloaded from game servers. Using the Native Client technology makes possible forgameplay developers to use the C++ language for games running in the virtual machine, to use C++ libraries, to share code between the game and the engine and to get better performance than with the Q3VM.[16]
Some groups of browser developers supported the Native Client technology while others did not.
Chad Austin (ofIMVU) praised the way Native Client can bring high-performance applications to the web (with about 5% penalty compared to native code) in a secure way, while also accelerating the evolution of client-side applications by giving a choice of the programming language used (besidesJavaScript).[48]
Id Software'sJohn D. Carmack praised Native Client atQuakeCon 2012, saying: "if you have to do something inside a browser, Native Client is much more interesting as something that started out as a really pretty darn clever x86 hack in the way that they could sandbox all of this in user mode interestingly. It's now dynamic recompilation, but something that you program in C or C++ and it compiles down to something that's going to be not your -O4 optimization level for completely native code but pretty damn close to native code. You could do all of your evil pointer chasings, and whatever you want to do as a to-the-metal game developer."[49]
Other IT professionals were more critical of this sandboxing technology as it had substantial or substantive interoperability issues.
Mozilla's vice president of products,Jay Sullivan, said that Mozilla has no plans to run native code inside the browser, as "These native apps are just little black boxes in a webpage. [...] We really believe in HTML, and this is where we want to focus."[50]
Mozilla'sChristopher Blizzard criticized NaCl, claiming that native code cannot evolve in the same way that the source code-driven web can. He also compared NaCl to Microsoft'sActiveX technology, plagued withDLL Hell.[2]
Håkon Wium Lie, Opera's CTO, believed that "NaCl seems to be 'yearning for the bad old days, before the web'", and that "Native Client is about building a new platform – or porting an old platform into the web [...] it will bring in complexity and security issues, and it will take away focus from the web platform."[2]
The second generation ofsandboxing developed in Google isgVisor.[51][52] It is intended to replace NaCl inGoogle Cloud, to be more exact inGoogle App Engine. Google has also been promotingWebAssembly.[53]
PNaCl sandboxes allow game-play developers to use modern C++ and C/C++ libraries directly within their virtual machines and will allow for better code sharing between the engine code and game logic. PNaCl is also reported to offer better performance than the original Quake III virtual machines.
They've continued moving along with their open-source game and Daemon engine. […] their libRocket implementation has moved into the NaCl VM.
Open-source Unvanquished developers continue working on support for using Google's Portable Native Client (PNaCl) to replace Quake III QVMs.
Under the hood, they remain hard at work on porting the game logic from QVMs to Portable Native Client (PNaCl).
As a replacement, Google is now pushing WebAssembly.
