PNaCl is no more a Google-proprietary feature than XMLHttpRequest is a Microsoft-proprietary feature. Anyone else is free to implement it, and then Google would have no more control over the "spec" of PNaCl than Microsoft has control over the evolution of AJAX.

Last I looked into this, the (P)NaCl codebase was heavily enmeshed with Chromium. Documentation on how any of it fit together was spread out across a multitude of wiki sites and mailing list archives, with conflicting descriptions of the exposed interfaces in varying states of obsolescence. The "spec" was, effectively, this big tangled ball of code in the Chromium tree.

The one method of running NaCl programs on their own relied on thousands of lines of Python code spread across a nested hierarchy of frameworks just to generate command line arguments to pass to the main runner binary -- and this used completely different interfaces into NaCl from Chromium's implementation. And all of this, being tightly integrated into the Chromium codebase, was subject to change at any point with no guarantee of API stability.

Maybe things have changed since then, but at the point when (P)NaCl was receiving the most attention I found it entirely impenetrable. Though the code may have been open source, the knowledge needed to integrate it with a new system was entirely proprietary. And anyone doing so would have ended up with an implementation bound to the evolution of the Chromium internals.

Note that I'm not talking about integrating "Google's PNaCl" into another browser (that code is Google-proprietary, for your listed too-much-of-a-mess reasons if nothing else.) Mozilla et al wouldn't use Google's NaCl engine in Firefox any more than they would use Google's Javascript engine, or any more than they would have integrated ActiveX into Firefox just to call XMLHttpRequest.

I'm instead talking about implementing one's own LLVM-bitcode-compiling zero-install plugin architecture with safety guarantees derived from static analysis (i.e. what you get by implementing the whitepaper[1]), providing a similar API to plugins to NaCl's PPAPI.

The result would just be an ecosystem of "Native-binary Sandbox engines" and an API working group that is to {portable LLVM IR ISA, PPAPI} as the ECMA is to {Javascript, the browser DOM}.

[1] http://static.googleusercontent.com/media/research.google.co...

For a feature to not be proprietary in the modern browser landscape, it has to have multiple parties able to participate in the design. Including the core design decisions of "should we use JS as a basis" (the consensus solution) vs. "should we use LLVM as a basis" (the PNaCl solution).

PNaCl allows me to run vim and python natively in my browser.

Thanks.

(Shout out to my boys, Sam Clegg, Brad Nelson and company!)

Finally catching up to Firefox 1.5, eh? :) https://brendaneich.com/2005/09/python-for-xul-scripting/