Hubbry Logo
Google Native ClientGoogle Native ClientMain
Open search
Google Native Client
Community hub
Google Native Client
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Google Native Client
Google Native Client
Google Native Client
View on Wikipedia
from Wikipedia
"Google NaCl" redirects here. For Networking and Cryptography library, see NaCl (software).

Google Native Client
DevelopersGoogle, others
Initial release16 September 2011; 14 years ago (2011-09-16)[1]
Stable release
SDK: Pepper 45 / 10 July 2015; 10 years ago (2015-07-10)

Clients: Same as Google Chrome

Repository
Written inC, C++
Operating systemWindows, Linux, macOS, ChromeOS
Platformx86, ARM, MIPS
SuccessorWebAssembly
TypeSandbox in web browsers for native code
LicenseNew BSD
Websitedeveloper.chrome.com/docs/native-client/ Edit this at Wikidata

Google Native Client (NaCl) is a discontinued sandboxing technology for running either a subset of Intel x86, ARM, or MIPS native code, or a portable executable, in a sandbox. It allows safely running native code from a Chromium-based web browser, independent of the user operating system, allowing web apps to run at near-native speeds, which aligns with Google's plans for ChromeOS. It may also be used for securing browser plugins, and parts of other applications or full applications[2] such as ZeroVM.[3]

Google first demonstrated the technology on 9 December 2011 by releasing several new Chrome-only versions of games known for their rich and processor-intensive graphics, including Bastion (no longer supported on the Chrome Web Store). Later Google released Portable Native Client (PNaCl), an architecture-independent compiled ahead-of-time version of NaCl. The general concept of NaCl (running native code in web browser) has been implemented before in ActiveX, but NaCl runs content in a sandbox while ActiveX application has full access to the system (disk, memory, user-interface, registry, etc.).

Mozilla proposed asm.js as an alternative to both ActiveX and NaCl. asm.js also allows applications written in C or C++ 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.[4] On 30 May 2017, Google announced deprecation of PNaCl in favor of WebAssembly.[5] Although initially Google planned to remove PNaCl in first quarter of 2018,[5] developers postponed the date multiple times until June 2022.[6][7]

Overview

[edit]

Native Client was an open-source project developed by Google.[8] Games such as Quake,[9] XaoS, Battle for Wesnoth,[10] Doom,[11] Lara Croft and the Guardian of Light,[12] From Dust,[13] and MAME, as well as the sound processing system Csound, have been ported to Native Client. Native Client has been available in the Google 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.[14][15][16] Native Client has also been used to safely run downloaded code in software other than web browsers, like in the Dæmon game engine.[17]

An ARM implementation was released in March 2010.[18] x86-64, IA-32, and MIPS were also supported.

To run an application portably under PNaCl, it must be compiled to an architecture-agnostic and stable subset of the LLVM intermediate representation bytecode.[19] The executables are called PNaCl executables (pexes). The PNaCl Toolchain makes .pexe files; NaCl Toolchain .nexe files. The magic number of .nexe files is 0x7F 'E' 'L' 'F', which is ELF. In Chrome, they are translated to architecture-specific executables so that they can be run.

NaCl uses software fault detection and isolation for sandboxing on x86-64 and ARM.[20] The x86-32 implementation of Native Client is notable for its novel sandboxing method, which makes use of the x86 architecture's rarely used segmentation facility.[21] 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.[21] Because of these constraints, C and C++ code must be recompiled to run under Native Client, which provides customized versions of the GNU toolchain, specifically GNU Compiler Collection (GCC), GNU Binutils, and LLVM.

Native Client is licensed under a BSD-style license.

Native Client uses Newlib as its C library, but a port of GNU C Library (GNU libc) is also available.[22]

History

[edit]

On 9 December 2011, Google demonstrated the readiness of the technology by announcing availability of several new Chrome-only versions of games known for their rich and processor-intensive graphics, including Bastion (no longer supported on the Chrome Web Store). NaCl runs hardware-accelerated 3D graphics (via OpenGL ES 2.0), sandboxed local file storage, dynamic loading, full screen mode, and mouse capture. There were also plans to make NaCl available on handheld devices.[23][24]

Portable Native Client (PNaCl) is an architecture-independent version. PNaCl apps are compiled ahead-of-time. PNaCl is recommended over NaCl for most use cases.[25] The general concept of NaCl (running native code in web browser) has been implemented before in ActiveX, 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 was asm.js, which also allows applications written in C or C++ 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.[4] On 30 May 2017, Google announced deprecation of PNaCl in favor of WebAssembly.[5] Although initially Google planned to remove PNaCl in first quarter of 2018,[5] and later in the second quarter of 2019,[26] it has been removed in June 2022 (together with Chrome Apps).[6][7]

Pepper

[edit]
See also: NPAPI § PPAPI

NaCl denotes sodium chloride, common table salt; as a pun, the name of pepper was also used. Pepper API is a cross-platform, open-source API for creating Native Client modules.[27] Pepper Plugin API, or PPAPI[28][29] is a cross-platform API for Native Client-secured web browser plugins, first based on Netscape's NPAPI, then rewritten from scratch. It was used in Chromium and Google Chrome to enable the PPAPI version of Adobe Flash[30] and the built-in PDF viewer.[31]

PPAPI

[edit]

On 12 August 2009, a page on Google Code introduced a new project, Pepper, and the associated Pepper Plugin API (PPAPI),[32] "a set of modifications to NPAPI to make plugins more portable and more secure".[33] 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:

  • Uniform semantics for NPAPI across browsers.
  • Execution in a separate process from the renderer-browser.
  • Standardize rendering using the browser's compositing process.
  • Defining standardized events, and 2D rasterizing functions.
  • Initial attempt to provide 3D graphics access.
  • Plugin registry.

The Pepper API also supports Gamepads (version 19) and WebSockets (version 18).[34]

As of 13 May 2010, Google's open source browser, Chromium, was the only web browser to use the new browser plug-in model.[35] 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.[36]

PPAPI in Firefox

[edit]

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 with Blink layout engine only, and had private APIs specific to the Flash Player plugin which were not documented.[37] 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,[38] however no such steps were taken. In July 2017, Adobe deprecated Flash and announced its end-of-life in the end of 2020.[39] By January 2021, Adobe Flash Player, Google Chrome, Firefox, Safari, and Windows[40] received updates disabling or entirely removing Flash.

Applications

[edit]

One website[41] used NaCL on the server to let users experiment with the Go programming language from their browsers.[42]

Usage outside of web browsers

[edit]

The open-source Unvanquished game makes use of Native Client in the Dæmon game engine[43] in replacement of the Q3VM (Quake III virtual machine).[44][45] 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 for gameplay 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.[17]

Reception

[edit]

Some groups of browser developers supported the Native Client technology while others did not.

Supporters

[edit]

Chad Austin (of IMVU) 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 (besides JavaScript).[46]

Id Software's John D. Carmack praised Native Client at QuakeCon 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."[47]

Detractors

[edit]

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."[48]

Mozilla's Christopher 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's ActiveX technology, plagued with DLL 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]

Second generation

[edit]

The second generation of sandboxing developed in Google is gVisor.[49][50] It is intended to replace NaCl in Google Cloud, to be more exact in Google App Engine. Google has also been promoting WebAssembly.[51]

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Google Native Client

View on Grokipedia
from Grokipedia
Google Native Client (NaCl) was a sandboxing developed by that enabled the secure execution of compiled and C++ code directly within web browsers, allowing high-performance applications to run at near-native speeds while remaining isolated from the host operating system. Introduced as an open-source project on December 8, 2008, NaCl consisted of a runtime environment, a browser plugin, and GCC-based compilation tools, initially supporting x86 processors across multiple browsers including Chrome, , , and on Windows, Mac, and . Its primary goals were to harness the full power of the CPU for web applications, ensure browser neutrality and OS portability, and maintain through software fault isolation, which enforced strict validation of modules to prevent malicious . In 2013, extended NaCl with Portable Native Client (PNaCl), which compiled to LLVM-style for architecture-independent distribution (supporting x86, , and MIPS), with the browser translating it to native at runtime for enhanced portability without recompilation. NaCl integrated with the Pepper API to provide access to web features like graphics and input, facilitating applications such as games (e.g., Quake and Doom ports) and complex tools, while its sandbox restricted access to system resources to mitigate risks associated with native code execution. Security was a core focus, with modules required to adhere to structural constraints and avoid unsafe instructions, verified both statically and dynamically to isolate faults without relying on OS-specific protections. However, as web technologies evolved, began deprecating NaCl components starting in 2017, with PNaCl support removed in Q4 2019 except for Chrome Apps and extensions, citing low usage and the superiority of for cross-browser, high-performance native code execution. Chrome Apps were deprecated outside in Q1 2018, and Native Client support for extensions on non- platforms ended with Chrome M117 in September 2023, while full end-of-life on occurred with version 138. By 2022, had phased out official support, recommending migration to via tools like , which offers broader compatibility and a more active ecosystem. As of 2025, remaining compiler support in was also eliminated, marking the complete obsolescence of NaCl in modern .

Overview and Fundamentals

Definition and Purpose

Google Native Client (NaCl) was a sandboxing developed by that enabled the execution of subsets of native code for x86, , or MIPS architectures directly within web browsers. It allowed developers to run compiled and C++ code in a secure, isolated environment, independent of the underlying operating system, thereby bridging the gap between web applications and traditional native software performance. The primary purpose of NaCl was to facilitate high-performance web applications, such as , tools, and computational tasks like image processing, without requiring third-party plugins, while preserving the browser's model through strict isolation. By executing native code at near-full CPU speed, NaCl aimed to enhance web interactivity and responsiveness, enabling richer experiences that were previously limited by interpreted languages like . At a high level, NaCl worked by compiling C/C++ source code using a modified GNU toolchain into a verifiable binary format, which a browser validator then checked for safety before execution in the sandbox. This process ensured that code adhered to predefined constraints, preventing unauthorized access to system resources. NaCl modules interacted with web pages via the Pepper Plugin API (PPAPI), providing a standardized interface for integration. Google initially announced Native Client on December 8, 2008, as an open-source project to advance secure native code execution on the web.

Core Architecture

Native Client (NaCl) employs a modular architecture designed to execute untrusted native code within a environment. At its core, the system comprises several key components that facilitate the loading, verification, and execution of compiled modules. The primary artifact is the Native Client Module, typically delivered as a Native Manifest File (NMF) with a .nmf extension, which is a JSON-formatted document specifying the locations and configurations of architecture-specific executable files. These executables, known as Native Executables (NEXEs) and denoted by .nexe files, contain the compiled native code in (Executable and Linkable Format) for the target platform. Complementing these are the validator and the runtime service: the validator performs static analysis on the NEXE to ensure compliance with NaCl's structural constraints, while the runtime service manages the loading and execution of the validated module within the browser's process model. The architecture follows a two-tier structure to isolate and manage untrusted code execution. In this setup, the untrusted native code from the NEXE runs within a dedicated sandboxed process, separate from the browser's main renderer. A browser-hosted verifier, integrated into the plugin or extension framework, preprocesses the module before execution, enforcing format and behavioral rules to maintain isolation. This division allows the runtime service—often referred to as the service loader (sel_ldr)—to host the code in a controlled environment, handling resource allocation and interfacing with browser APIs without direct access to resources. The operational process begins with compilation using a modified , such as GCC for standard NaCl or for portable variants, producing either architecture-specific NEXEs or intermediate bitcode. The NMF is then embedded in the via an tag, prompting the browser to download and parse it to select the appropriate NEXE based on the client architecture. The validator examines the NEXE's ELF headers, program segments, and instruction stream for adherence to NaCl conventions, such as 32-byte alignment. Upon successful validation, the runtime service loads the module and, for portable bitcode formats, performs just-in-time (JIT) or ahead-of-time (AOT) translation to native before initiating execution. NaCl supports multiple architectures to ensure broad compatibility, including x86-32, , and for direct NEXE deployment. Additionally, the portable bitcode format enables cross-platform distribution by compiling to an that the runtime translates on-the-fly, mitigating the need for multiple pre-built binaries.

Historical Development

Origins and Early Releases

Google Native Client (NaCl) originated as a research project within to enable web applications to leverage the full computational power of native code while preserving and portability. Development was led by engineers including Matt Papakipos, focusing on sandboxing techniques for untrusted x86 code to overcome JavaScript's performance constraints in handling intensive tasks like graphics rendering or simulations. The project received its first public announcement on December 8, 2008, via an official blog post introducing NaCl as an open-source technology for running native compiled code directly in the browser. This announcement highlighted the goal of creating richer web experiences without relying on server-side or less secure plugins. Alongside the announcement, released an early open-source snapshot of NaCl, including experimental tools for compilation and runtime execution on platforms like Windows, , and Mac OS X. This initial version aimed to solicit community feedback and to refine the sandboxing model. Early motivations for NaCl were rooted in the need for secure, high-performance web computing amid growing concerns over vulnerabilities in browser plugins such as , which had exposed users to exploits due to insufficient isolation from the host system. By June 2009, had advanced the project sufficiently to host a , confirming the robustness of its architecture before broader integration efforts. In October 2009, NaCl was integrated as a built-in feature into the Developer Channel (version 4.0.220.1), providing the first browser-native support without requiring a separate plugin and setting the stage for developer experimentation. A formal alpha release followed in May 2010 with the Native Client SDK developer preview, which offered streamlined C/C++ development tools and APIs for building portable web applications.

Key Milestones and Evolutions

In August 2011, Native Client was enabled by default in the Chrome 14 beta channel, with stable integration in September 2011, allowing developers to deploy native code execution for production use without requiring user flags. Later that year, in December 2011, support for 3D graphics via 2.0 was added through Pepper interfaces, allowing for processor-intensive demos such as the port of and other games that showcased NaCl's potential for real-time rendering. The following year, 2012, saw further enhancements with the maturation of the Pepper Plugin API (PPAPI), including initial stable versions that expanded NaCl's plugin ecosystem for audio, 2D graphics, and compute tasks. Threading support was also introduced via PPAPI extensions, permitting multithreaded native code execution within the sandbox to handle more complex workloads efficiently. By mid-2012, these updates had solidified NaCl as a viable platform for developers seeking near-native performance in web environments. A pivotal evolution occurred in November 2013 with the launch of Portable Native Client (PNaCl), the second-generation architecture that addressed architecture-specific limitations by compiling code to portable bitcode, enabling seamless deployment across x86 and platforms without recompilation. Concurrently, debugging tools were enhanced in the NaCl SDK, including improved symbol loading and remote capabilities that facilitated easier development and . PNaCl became enabled by default in Chrome 31, broadening for web applications. From 2014 to 2016, NaCl entered its peak adoption phase within Chrome, powering a range of high-profile web applications that demanded intensive computation and graphics, such as interactive simulations and geospatial tools. Deprecation signals emerged in 2017 as Google prioritized WebAssembly for future native code efforts.

Technical Components

Sandboxing and Security Model

Google Native Client (NaCl) implements a multi-layered sandboxing strategy to isolate untrusted native code from the host operating system and other processes. The inner sandbox employs software fault isolation (SFI) within the service runtime, using x86 segment registers like %ds and %cs for memory isolation, with the first 64KB of the address space reserved for initialization and trampolines, while enforcing strict 32-byte instruction alignment to prevent code misalignment exploits. This SFI mechanism bans hazardous instructions, such as system calls (e.g., syscall, int), string operations, and control transfers that could enable unauthorized memory access. Complementing this, the outer sandbox leverages OS-level process isolation, confining the entire renderer process—including the service runtime—within the browser's security boundaries to limit resource access and contain potential privilege escalations. A critical component of NaCl's security is its static validation process, performed by a lightweight verifier implemented in under 600 lines of C code. Before execution, the verifier disassembles the NEXE binary and checks every instruction against a predefined set of safe operations, ensuring compliance with SFI constraints like aligned loads/stores and the absence of or indirect branches that could lead to buffer overflows or invalid memory accesses. This deterministic validation is designed to be fast and reliable, rejecting non-compliant modules outright without executing them, thereby blocking common exploit vectors at load time. NaCl's security model guarantees that untrusted has no direct access to the operating , with all input/output operations routed through mediated browser APIs, such as the Pepper Plugin API (PPAPI), for controlled interactions with and resources. calls are restricted to a minimal set of NaCl-specific syscalls handled by the service runtime, using trampolines for safe transitions between trusted and untrusted segments, which prevents exploits from escalating privileges beyond the sandbox. Despite these protections, NaCl's model has inherent limitations, as it depends on compiler-generated binaries adhering to the restricted instruction set; hand-written assembly or non-compliant toolchains could introduce unverifiable code. Additionally, while effective against direct memory corruption, the sandbox remains susceptible to side-channel attacks, such as timing-based information leaks, if the host environment or browser configuration does not mitigate them adequately.

Pepper Plugin API (PPAPI)

The Pepper Plugin API (PPAPI) serves as the primary interface for Native Client (NaCl) modules to communicate with the host browser, enabling access to web platform features while adhering to sandbox constraints. Developed by , PPAPI provides a C and C++ that allows developers to implement plugins capable of interacting with browser resources such as the (DOM), graphics contexts, audio systems, and input devices. This abstracts low-level browser functionalities into structured, asynchronous calls, ensuring that NaCl code remains isolated and secure without direct system access. By design, PPAPI facilitates high-performance native code execution in web applications, supporting tasks like rendering complex visuals or processing real-time inputs without compromising browser stability. PPAPI's evolution began in 2009 as an experimental extension to the Plugin API (), aimed at modernizing plugin development for Chromium-based browsers. The initial stable integration with NaCl occurred in 2011, providing foundational support for basic operations, 2D , and compute tasks through a core set of interfaces. Subsequent updates in 2013 expanded these capabilities, incorporating 3D graphics acceleration via bindings and audio handling, which broadened PPAPI's applicability to multimedia and interactive applications. These enhancements were delivered through iterative releases, such as Pepper_31 in 2014, aligning with NaCl's growing while maintaining for existing modules. Central to PPAPI are its key interfaces, which handle essential interactions between the NaCl module and the browser. The Graphics2D interface (PP_Graphics2D) enables 2D rendering by providing a device context for drawing operations like painting pixels, paths, and text directly onto a browser-provided buffer, supporting formats such as RGBA. For advanced visuals, the Graphics3D interface (PP_Graphics3D) offers access to 3D acceleration, allowing creation of contexts for shader-based rendering and texture management within the sandbox. User interactions are managed via the InputEvent interface (PP_InputEvent), which delivers events for keyboard, , and actions as structured objects, enabling plugins to query event details like coordinates and modifiers without polling. is facilitated by the generic PP_Resource interface, which serves as a handle for all plugin objects and supports , , and asynchronous messaging to the browser proxy for operations like requests or file I/O. These interfaces collectively ensure efficient, secure data flow, with all communications proxied through the browser to prevent unauthorized access. In contrast to , PPAPI is specifically optimized for NaCl's model, emphasizing sandboxed, cross-platform operation without the vulnerabilities inherent in NPAPI's architecture. While NPAPI allowed plugins to run in-process with the renderer, exposing browsers to crashes and exploits, PPAPI enforces out-of-process execution via a dedicated plugin , enhancing isolation and fault tolerance. Communication with is restricted to asynchronous PostMessage mechanisms rather than direct scriptable objects, mitigating risks from untrusted . This NaCl-centric design avoids NPAPI's platform-specific quirks and legacy dependencies, promoting consistent behavior across supported browsers and eliminating issues like asynchronous initialization problems common in older plugins.

Implementations and Extensions

Browser Integrations

Google Native Client (NaCl) was primarily integrated into , receiving native support starting with version 14 in September 2011, which allowed developers to upload and run NaCl applications via the . This integration relied on the Pepper Plugin API (PPAPI) as the underlying layer for embedding NaCl modules within web pages. By 2013, NaCl achieved greater stability in Chrome, with enhancements to its sandboxing and broader availability beyond initial restrictions. Support in other browsers was limited and experimental. did not provide official support for NaCl or PPAPI, with only experimental plugin compatibility available early on; Pepper Flash support ended in 2015 via an NPAPI adapter, but this did not enable NaCl functionality. , as a Chromium-based browser, offered partial NaCl support via PPAPI during this period, though it remained secondary to Chrome's implementation. NaCl faced significant compatibility challenges across browsers. Apple and provided no official support for NaCl or PPAPI, limiting its reach to Chromium-derived environments. Development and testing required Chrome-specific tools, such as the Native Client SDK, which were not portable to other platforms. Chrome began phasing out NaCl support in 2019, aligning with the rise of as a successor technology, with general announced in 2017. Support ended on non- platforms by September 2023 in Chrome version 117, while extended legacy compatibility until version 138 in October 2025. As of November 2025, all NaCl support, including on , has been fully discontinued.

Portable Native Client (PNaCl)

Portable Native Client (PNaCl) was launched in 2013 as the second-generation iteration of Google Native Client, designed to enable architecture-agnostic execution of native code in web browsers through an LLVM-based portable bitcode format known as .pexe files. This approach allowed developers to compile C and C++ code once into a platform-independent intermediate representation, which could then be distributed and run across diverse hardware without requiring separate binaries for each architecture, such as x86 or ARM. Unlike the original Native Client, which relied on ahead-of-time compilation to architecture-specific binaries, PNaCl compiles source code to a validated LLVM bitcode intermediate representation that undergoes static verification at installation time to ensure safety and compliance with constraints like a 32-bit address space and ILP32 data model. This bitcode is then just-in-time (JIT) compiled on the target device within the NaCl sandbox, leveraging the browser's hardware for optimized code generation while maintaining security through software fault isolation. The validation process minimizes the trusted computing base by confirming the bitcode's invariants before execution, enabling seamless adaptation to new instruction set architectures without developer intervention. PNaCl significantly reduced the developer burden for multi-platform support by eliminating the need for maintaining multiple compiled binaries, streamlining testing and deployment for web applications requiring high performance, such as physics simulations or interpreters. By 2014, it had been fully integrated into Chrome's Native Client (SDK) as the recommended for creating portable modules, supporting features like APIs, threading, and SIMD instructions. This integration facilitated broader adoption for web-based native code, providing near-native speed while preserving the sandboxed security model of the original NaCl architecture. PNaCl was supported in Chrome until its deprecation announced in 2017, with removal phased out starting in Q1 2018 for general use (except Chrome Apps and extensions), and Q2 2019 for web content, after which Google recommended migration to as the emerging standard for portable, high-performance web code. The deprecation announcement highlighted 's growing maturity and cross-browser compatibility, with PNaCl support phased out in early 2018 for general use, though extended for Chrome Apps and Extensions until later in 2019.

Applications and Deployments

Web-Based Use Cases

Google Native Client (NaCl) facilitated high-performance applications in web environments by allowing compiled C and C++ code to execute at near-native speeds within the browser sandbox, targeting scenarios where JavaScript's interpreted nature proved insufficient for intensive computations. Primary use cases included high-performance web games, 3D simulations, and video editors that demanded low-latency processing for real-time rendering and manipulation. For instance, NaCl enabled ports of complex titles like the award-winning game Bastion from , which ran directly in Chrome without plugins, leveraging native code for enhanced graphics and gameplay fluidity. In 3D simulations, NaCl powered demonstrations of advanced physics engines, such as the Bullet Physics SDK port, which achieved full-speed real-time simulations in the browser using for rendering complex interactions like collisions and dynamics. This capability extended to geospatial applications, exemplified by the 2017 web version of , where NaCl compiled C++ code to deliver high-fidelity 3D globe rendering with native threading for smooth navigation and data processing exclusively in Chrome. Video editors and similar tools benefited from NaCl's architecture for tasks like frame-by-frame processing and effects application, outperforming JavaScript-based alternatives in computational efficiency. A key advantage of NaCl in web contexts was its superior performance over for CPU-intensive operations, such as physics simulations in games or rendering pipelines in 3D environments, often achieving speeds comparable to desktop applications while maintaining . Developers integrated NaCl modules using the Pepper Plugin API (PPAPI) for and input handling. The NaCl SDK provided essential tools for compiling into portable modules (.nexe or .pexe files), which were then embedded in HTML5 pages via <embed> tags, allowing seamless invocation from for hybrid web-native experiences.

Non-Browser Applications

Google Native Client (NaCl) supported non-browser execution through its SDK, which included the sel_ldr tool for running NaCl modules as standalone executables on desktop systems. Introduced around 2011 as part of the SDK's standalone build, sel_ldr provided a to load and execute sandboxed native code outside a , primarily for development, testing, and purposes. This allowed developers to validate C and C++ modules, such as those from the GCC test suite, in an isolated environment mimicking the browser's security model without relying on Chrome or other browsers. In Chrome OS, NaCl was embedded in certain applications and extensions to deliver native performance for compute-intensive tasks, extending beyond pure web contexts within the operating system. Support for NaCl in Chrome OS persisted longer than on other platforms, with official deprecation limited to non-Chrome OS environments starting in Chrome M117 ( 2023), reflecting its utility in OS-specific deployments like packaged apps. Experimental integrations on Android occurred via Chrome, enabling NaCl modules in mobile contexts, though these remained tied to browser execution and were not widely adopted for standalone mobile apps. Server-side applications of NaCl, such as secure computations in backend environments, were conceptually possible but rarely implemented due to the technology's browser-centric design. Non-browser uses of NaCl required developers to manually configure custom sandboxes using tools like sel_ldr, increasing complexity compared to browser-integrated deployments. This overhead, combined with limited support outside the Pepper interface, made standalone and embedded applications less common than web-based ones, confining NaCl's non-browser impact to niche development and OS-specific scenarios.

Reception and Legacy

Adoption and Supporters

Google Native Client (NaCl) saw significant adoption among game developers seeking to deliver high-performance experiences directly in web browsers without plugins. Unity Technologies integrated NaCl support into Unity 3.5 in 2012, enabling developers to compile and deploy C++-based games for Chrome with near-native speeds while maintaining cross-platform compatibility. Other prominent adopters included Square Enix, Bungie, Supergiant Games—which ported its title Bastion to NaCl for seamless distribution across desktop operating systems—and Spacetime Studios, which adapted its massively multiplayer online game Star Legends using a codebase exceeding 500,000 lines in under two weeks. These efforts highlighted NaCl's appeal for bridging the gap between native applications and web delivery, allowing reuse of existing C and C++ libraries for graphics, audio, and physics. The Chrome team strongly endorsed NaCl as a means to advance and security, integrating it into Chrome starting with version 14 in and enabling it by default in version 31 with Portable Native Client (PNaCl). Developers praised the technology for its sandboxed execution model, which permitted compute-intensive tasks like and multithreading in the browser without compromising user safety. Community contributions further bolstered support, with ports of middleware such as , Mono, , , Wwise, and the Bullet physics engine facilitating broader adoption. By late 2011, NaCl applications were distributed through the , providing access to over 200 million active users and fostering an ecosystem of public apps focused on gaming and interactive content. engineers emphasized its innovative potential, noting that NaCl empowered developers to create dynamic, OS-agnostic applications that enhanced the web's capabilities. As Christian Stefansen, NaCl Product Manager, stated, "The gives developers a simple, effective strategy to reach over 200 million active users of ." This reception influenced broader discussions on secure native code execution in browsers, paving the way for subsequent web technologies. NaCl's concepts of sandboxed, portable native code execution significantly influenced the development of WebAssembly, a standardized binary instruction format announced in 2015 that achieved similar goals of high-performance, secure code in web browsers across multiple vendors.

Criticisms and Challenges

One major criticism of Google Native Client (NaCl) centered on the complexity of its development toolchain, which required developers to use a customized version of the GNU Compiler Collection (GCC) and related tools to generate sandbox-safe binaries, diverging significantly from standard C/C++ workflows. This modification process, including adjustments for NaCl's restricted instruction set and alignment requirements, increased code size by up to 57.5% in benchmarks and demanded familiarity with proprietary validation steps, making it challenging for developers accustomed to conventional native compilation. Additionally, NaCl's support was limited primarily to Google Chrome and other Chromium-based browsers, excluding major competitors like Firefox and Internet Explorer, which restricted its viability for cross-browser web applications. Mozilla, in particular, expressed strong reluctance toward adopting NaCl, citing heightened security risks from running native code in the browser and a strategic preference for optimizing instead. , Mozilla's CTO and 's creator, dismissed NaCl as unnecessary, arguing that already provided sufficient performance and safety features through ongoing enhancements like ECMAScript 6, while NaCl's architecture risked sandbox escapes similar to historical vulnerabilities in plugins like . He further highlighted concerns over potential browser fragmentation, positioning NaCl as a Google-specific technology that could undermine the open web's evolution. Challenges also arose from perceived vendor lock-in to the Google ecosystem, as NaCl's initial x86-only focus tied applications to Intel architectures prevalent in Chrome OS devices, limiting portability to ARM-based systems common in mobile browsing. This dependency exacerbated worries about ecosystem control, with critics like Eich equating it to proprietary extensions that favored one vendor over interoperable standards. Furthermore, NaCl incurred performance overhead from its validation and sandboxing mechanisms; the static code validator processed modules at approximately 30 MB/second, while runtime sandboxing added an average 5% slowdown in SPEC2000 benchmarks due to instruction alignment and cache effects, with peaks up to 12% in certain workloads. A notable event underscoring these security concerns was a 2011 audit by Matasano Security, which uncovered 10 previously unknown vulnerabilities in NaCl's Pepper Plugin API (PPAPI) interfaces, including integer overflows, use-after-free errors, and heap overflows that could potentially enable sandbox escapes. was notified and issued patches prior to the findings' public disclosure at Black Hat USA 2012, prompting enhancements to the PPAPI but highlighting ongoing risks in validating untrusted native code.

Discontinuation and Successors

Deprecation Timeline

Google announced the deprecation of Native Client (NaCl), including its Portable Native Client (PNaCl) variant, in May 2017, positioning as the primary successor for running native code in the browser. This initial signal included plans to remove PNaCl support in the first quarter of 2018 outside of Chrome Apps and extensions, with developers encouraged to migrate existing applications. The announcement emphasized that no new features would be added to NaCl moving forward, focusing engineering resources on instead. The deprecation process unfolded in phases, with multiple postponements to accommodate legacy users. Support for NaCl, PNaCl, and related Pepper APIs (PPAPI) ended in June 2021 for non-Chrome OS platforms (Windows, Mac, and ), while Chrome OS support was initially extended to June 2022. In October 2021, Chrome Apps support on Chrome OS was further extended to at least January 2025 for enterprise and users to facilitate migration. Developers received warnings starting from the 2017 announcement, with intensified notifications in 2019 as the Q4 removal target approached, urging migration to for continued compatibility. By 2020, NaCl was formally deprecated across Chrome, requiring new applications to adopt alternatives, though existing Chrome Apps received extended support until mid-2022 on Chrome OS. Key milestones in the rollout included the removal of NaCl support for extensions on non-Chrome OS platforms in Chrome Milestone 117, stable in September 2023. On Chrome OS, NaCl remained available longer for enterprise and users; it was disabled by default on managed devices starting with Chrome OS 132 in January 2025, marking the last version with support for unmanaged and consumer users. Chrome OS 138, released in July 2025, served as the final version with any NaCl support, after which legacy functionality was phased out entirely. Post-deprecation, NaCl received no further updates or patches beyond basic for supported versions. For Chrome Enterprise and Education customers, legacy NaCl support in (LTS) channels extended until the LTS last refresh in April 2026, with no exceptions granted and mandatory migration to recommended. By November 2025, NaCl was fully discontinued in stable Chrome releases, completing the transition away from the technology.

Transition to Alternatives

As Google phased out Native Client (NaCl), (Wasm) emerged as its primary successor, achieving widespread adoption in 2017 across major browsers including Chrome, , Edge, and , delivering comparable near-native performance while benefiting from broader cross-platform compatibility and a streamlined development based on bitcode. To facilitate the shift, explicitly recommended migrating existing NaCl and Portable Native Client (PNaCl) applications to using , a that translates C and C++ code into Wasm modules, enabling developers to reuse much of their codebase with minimal modifications for most use cases. Furthermore, PNaCl's reliance on a stable subset of bitcode as an interchange format directly shaped WebAssembly's architecture, providing a foundation for portable, architecture-agnostic binaries that addressed NaCl's platform-specific limitations. In the interim period leading to full deployment, served as a practical bridge technology, allowing high-performance code subsets to run efficiently within standard engines as a stopgap measure while the Wasm standard was finalized through collaboration between browser vendors. Meanwhile, the Pepper Plugin API (PPAPI), integral to NaCl's integration with Chrome, continued to support legacy extensions until its discontinuation in June 2021 for non-Chrome OS platforms and June 2022 for Chrome OS. NaCl's enduring legacy lies in its pioneering of sandboxed native code execution on the web, employing software fault isolation (SFI) to enforce and prevent unauthorized access, concepts that profoundly informed WebAssembly's model by ensuring untrusted modules operate in isolated environments without compromising host system integrity.

References

  1. https://developer.chrome.com/docs/native-client
  2. http://googlecode.blogspot.com/2008/12/native-client-technology-for-running.html
  3. https://blog.chromium.org/2013/11/portable-native-client-pinnacle-of.html
  4. https://developer.chrome.com/docs/native-client/migration
  5. https://groups.google.com/a/chromium.org/g/chromium-extensions/c/v8H1UHnPotY
  6. https://www.phoronix.com/news/LLVM-22-Removes-Native-Client
  7. https://research.google.com/pubs/archive/34913.pdf
  8. https://media.blackhat.com/bh-us-12/Briefings/Rohlf/BH_US_12_Rohlf_Google_Native_Client_WP.pdf
  9. https://www.cnet.com/tech/services-and-software/google-native-client-grows-out-of-research-phase/
  10. https://cacm.acm.org/research/technical-perspective-native-client-a-clever-alternative/
  11. https://chromereleases.googleblog.com/2009/10/dev-channel-updated-with-fixes.html
  12. https://blog.chromium.org/2010/05/sneak-peek-at-native-client-sdk.html
  13. https://arstechnica.com/information-technology/2011/08/native-client-enabled-in/
  14. https://www.theregister.com/2011/09/16/native_client_debuts_in_chrome/
  15. https://developers.googleblog.com/en/games-apps-and-runtimes-come-to-native-client/
  16. https://news.softpedia.com/news/Google-Chrome-to-Get-Full-Pepper-Plugin-API-Support-Soon-254658.shtml
  17. https://thenextweb.com/news/google-launches-portable-native-client-lets-developers-compile-code-run-hardware-site
  18. https://blog.chromium.org/2017/05/goodbye-pnacl-hello-webassembly.html
  19. https://code.google.com/archive/p/ppapi/
  20. https://blog.chromium.org/2011/02/native-client-getting-ready-for-takeoff.html
  21. https://developer.samsung.com/smarttv/develop/api-references/pepper-api-references/overview.html
  22. https://chromium.googlesource.com/native_client/src/native_client/+/refs/heads/master/docs/pepper.md
  23. https://blog.chromium.org/2011/08/native-client-brings-sandboxed-native.html
  24. https://blog.chromium.org/2013/01/
  25. https://www.ghacks.net/2015/10/08/mozilla-announces-the-end-of-npapi-plugins-in-firefox/
  26. https://www.theregister.com/2013/01/23/google_native_client_for_arm/
  27. https://learn.microsoft.com/en-us/microsoft-edge/web-platform/site-impacting-changes
  28. https://support.google.com/chrome/a/answer/10314655
  29. https://www.infoq.com/news/2013/05/pnacl-google-chrome-llvm/
  30. https://llvm.org/devmtg/2014-04/PDFs/Talks/PortableNativeClient.pdf
  31. https://css.csail.mit.edu/6.566/2015/readings/pnacl.pdf
  32. https://www.phoronix.com/news/MTQyNTE
  33. https://pybullet.org/wordpress/index.php/2011/10/27/bullet-supports-native-client-runs-full-speed-in-chrome-15/
  34. https://medium.com/google-earth/earth-on-web-the-road-to-cross-browser-7338e0f46278
  35. https://www.cnet.com/culture/google-well-prove-native-clients-worth-on-the-web/
  36. https://blog.mayflower.de/4560-Salt-and-Pepper-e28094-Running-native-code-within-the-browser-with-Google-Native-Client.html
  37. https://stackoverflow.com/questions/4690526/can-i-run-googles-native-client-outside-of-the-browser
  38. https://www.cnet.com/culture/unity-game-engine-embraces-googles-native-client/
  39. https://uk.pcmag.com/news/114987/google-game-developers-show-off-native-client-games-in-chrome
  40. https://redmonk.com/kholterhoff/2025/10/17/wasms-identity-crisis/
  41. https://www.infoworld.com/article/2286704/javascript-founder-dismisses-google-native-client-2.html
  42. https://arstechnica.com/information-technology/2011/09/critics-call-foul-as-google-takes-aim-at-javascript-with-dart/
  43. https://lwn.net/Articles/335974/
  44. https://support.google.com/chrome/a/answer/10314655?hl=en
  45. https://blog.chromium.org/2020/08/changes-to-chrome-app-support-timeline.html
  46. https://blog.chromium.org/2021/10/extending-chrome-app-support-on-chrome.html
  47. https://storage.googleapis.com/support-kms-prod/oFjzQoiAKzWY3b0IEITxklGUAbX4YZJ5kR6U
  48. https://groups.google.com/g/xtralogicrdpclientsupport/c/zDzRv7IplNk
  49. https://brendaneich.com/2015/06/from-asm-js-to-webassembly/
  50. https://cacm.acm.org/research/bringing-the-web-up-to-speed-with-webassembly/
  51. https://blog.chromium.org/2020/01/moving-forward-from-chrome-apps.html
  52. https://people.mpi-sws.org/~rossberg/papers/Haas%2C%2520Rossberg%2C%2520Schuff%2C%2520Titzer%2C%2520Gohman%2C%2520Wagner%2C%2520Zakai%2C%2520Bastien%2C%2520Holman%2520-%2520Bringing%2520the%2520Web%2520up%2520to%2520Speed%2520with%2520WebAssembly.pdf
Add your contribution
Related Hubs
User Avatar
No comments yet.