Nacl-web-plug-in
One significant limitation of the original NaCl was architecture dependence. A NaCl module compiled for an x86 processor would not run on an ARM device (like a smartphone).
To solve this, Google introduced PNaCl (Portable Native Client). PNaCl used an intermediate bytecode format called pexe. When the user loaded the page, the browser would translate this portable bytecode into the specific machine code required by the user's device, regardless of whether they were on a desktop or a mobile phone.
| Feature | NaCl Plug-in | WebAssembly (Wasm) | |---------|--------------|---------------------| | Standardization | Google-proprietary | W3C standard | | Browser support | Chrome only | Chrome, Firefox, Safari, Edge | | Security model | Validator + sandbox | Memory-safe, sandboxed by design | | Tooling | Specialized SDK | LLVM-based, supports many languages | | Integration | Plug-in required | Native engine in all browsers |
WebAssembly achieved NaCl’s performance goal without the security and portability overhead. nacl-web-plug-in
To address architecture-specific binaries, Google introduced PNaCl (Portable Native Client), which used LLVM bitcode. The browser compiled the bitcode to the host architecture at runtime, making distribution easier.
Despite its power, NaCl faced major issues:
| Issue | Description | |-------|-------------| | Browser lock-in | Only fully supported in Chrome. Other browsers required plug-in installation. | | Security surface | The validator and PPAPI were complex, leading to potential exploits. | | Developer complexity | Required separate build toolchains and knowledge of native memory management. | | Mobile incompatibility | Never worked on iOS (due to App Store restrictions) or Android (partially). | | Maintenance burden | Google had to maintain architecture-specific validators (x86, ARM, etc.). | One significant limitation of the original NaCl was
Deprecation timeline:
Unlike JavaScript, which is interpreted or Just-In-Time (JIT) compiled by the browser, NaCl allowed developers to compile their C/C++ code directly into a native binary format (an .nexe file).
When a user visited a webpage containing a NaCl application, the browser would download the .nexe file and execute it directly on the CPU. To prevent security risks (such as malware taking over the user's computer), NaCl used a rigorous Sandbox. This sandbox isolated the plugin from the rest of the operating system, restricting its access to system resources and preventing it from making unsafe system calls. The manifest ( my_module
A typical HTML snippet that triggered the plugin looked like this:
<!DOCTYPE html>
<html>
<head>
<title>NaCl Demo</title>
</head>
<body>
<!-- The nacl-web-plug-in automatically handles this embed -->
<embed type="application/x-nacl"
src="my_module.nmf"
width="800"
height="600"
id="nacl_plugin" />
<script>
const plugin = document.getElementById('nacl_plugin');
// Once loaded, call exported functions
plugin.postMessage('start_computation');
</script>
</body>
</html>
The manifest (my_module.nmf) looked like:
"program":
"x86-64": "url": "my_module_x86_64.nexe",
"portable": "url": "my_module.pexe"
The NaCl plug-in functioned as an integral part of Chrome (and briefly other browsers via an extension). Key technical aspects include: