Google Native Client

~ the last words ~

The pitch fit in one sentence. Take the C++ you already have, compile it, and run it in a browser tab at close to the speed it runs on the desktop, inside a sandbox that will not let it touch the machine. Google announced it on 8 December 2008 as an open source research project, and the reason it got attention is that the sentence turned out to be true.

The hard part was the sandbox. Native Client did not interpret anything. It took real machine code and ran it, after a validator inspected the binary ahead of time and refused anything it could not prove was safe, with the operating system's own isolation underneath as a second wall. Academic security people took it seriously, which is not the usual reception for a browser feature. It went into stable Chrome on 16 September 2011, and by 9 December that year Google was showing what it could carry: Supergiant's Bastion, a full commercial game, sold in the Chrome Web Store and running in a tab.

The first version had an awkward property. Because it shipped actual machine code, a developer had to build a separate binary for each processor family and the page had to pick the right one. Portable Native Client arrived in 2013 to fix that, shipping LLVM bitcode instead and compiling it on the user's machine at load time. It solved the architecture problem completely and did nothing about the other one.

I am an engineer and this is the kind of thing I read about carefully and then decline to build on. The arithmetic was never difficult. Firefox was not going to implement it, Safari was not going to implement it, and a technology that runs in one browser is a technology whose users you have to recruit before you can serve them. Everyone outside Google ran the same numbers and reached the same place, which is why the most interesting browser runtime of that decade has almost nothing to show for itself.

~ the record ~

~ the sandbox ~

What made Native Client different from the plugin era is that it did not ask for trust. ActiveX ran native code by asking the user to approve a certificate, and Java applets ran inside a virtual machine with a security model that spent fifteen years leaking. Native Client checked the code itself. The validator walked the binary before execution and rejected instructions that could escape the region it was confined to, so safety came from a property of the file rather than a promise about its author.

That design bought it real respect, and it also made the thing enormous. The runtime and its validator were one body of work. The Pepper API that gave sandboxed code access to graphics and sound was another, and together they came to more surface area than any other vendor was going to reimplement from scratch. Google was asking its competitors to adopt a system whose specification was, in practice, whatever Chrome did.

~ why one browser was not enough ~

Mozilla said no early and said it in public, arguing that shipping architecture-specific binaries to the web was a step backward and that the web platform should not be defined by one company's implementation. Their counter-proposal was asm.js in 2013, an ordinary subset of JavaScript that engines could recognize and optimize aggressively, which was slower than Native Client and had the one advantage that mattered. It already ran everywhere.

Google kept building. Native Client stayed locked to Chrome apps for its first years and only escaped to the open web with the portable version, by which point the argument had moved. In October 2016 the Pepper and Native Client teams were destaffed inside Google, seven months before anything was announced publicly, which is the point where the decision had already been made and nobody outside had been told yet.

~ what webassembly did differently ~

WebAssembly was announced in June 2015 by all four browser vendors at once, which is the entire difference between the two projects. It took the lesson of asm.js and the lesson of Native Client and dropped what made each of them unshippable, arriving as a compact bytecode with a proper standards process behind it. Browsers shipped the first version in 2017. Google announced the deprecation of Portable Native Client on 30 May 2017 and pointed developers at Emscripten.

The removal took another five years because things with users always do. In June 2022 the Chrome Web Store stopped supporting Chrome Apps and Native Client together on every platform. ChromeOS held on for enterprise and education customers until version 139 dropped it in July 2025, and the last trace went in February 2026 when LLVM 22 removed the ability to build a Native Client binary at all. What Native Client wanted is now ordinary. Compiled code runs in every browser on the web, on a standard nobody owns, and none of it is Google's.

@}-->--

              )
             (_)
            .-'-.
            |   |
            |   |
            |   |
            |   |
          __|   |__   .-.
       .-'  |   |  `-:   :
      :     `---'     :-'
       `-._       _.-'
           '""""""

« previous  ·  random  ·  next »