Well, I'm Back: Blink, PNaCl, And Standards

When the Blink fork was announced, it came with an admirable commitment to good citizenship when adding new Web-exposed features. Unfortunately, Google has recently announced that they will expose Portable Native Client (PNaCl) --- and by extension, the Pepper APIs --- to all Web pages, a move which clearly runs counter to Blink's commitments.

PNaCl is an execution framework that lets Web developers compile code in various languages using LLVM-based compilers to LLVM "bitcode", which is then served to clients (i.e. Chrome) which compile it down into native code. To be useful, code needs APIs to interact with the outside world (e.g. graphics APIs), so Google created the "Pepper" APIs for NaCl/PNaCl applications to use. Let's see how PNaCl and Pepper stack up against the Blink principles:

• In practice, we strive to ensure that the features we ship by default have open standards. PNaCl and Pepper are not open standards, and there are not even any proposals on the table to standardize them in any forum. They have documentation, but for the details one must defer to the large bundle of Chrome code that implements them. Other vendors wishing to support PNaCl or Pepper would have to adopt or reverse-engineer this code.
• Factors that decrease compatibility risk (in rough order of importance): Other vendors shipping compatible implementations A mature specification in the relevant standards body Positive signals from other browser vendors A small API footprint PNaCl and Pepper satisfy none of these. In particular, there are no positive signals from other browser vendors; in fact all the signals I've detected have been hostile.
• The following tiers are good rules of thumb to know that the feature is on the right track (ordered by increasing risk to compatibility and therefore decreasing order of desirability): Two other browser engines already ship roughly interoperable implementations in stable or experimental channels. In this situation, the feature is already a de facto standard. If a de jure standard does not yet exist, we should help create one. One other browser engine ships a roughly interoperable implementation in a stable or experimental channel, we believe the feature to be stable, and we’ve consulted with the appropriate standards body. The appropriate standards body considers the feature ready for implementation. For example, the W3C issuing a Call for Implementations or publishing a Candidate Recommendation of the feature would meet this guideline. The specification for the feature has been accepted by the appropriate standards working group (e.g., a First Public Working Draft in the W3C) and we’ve received positive feedback from other browser engines about the feature’s feasibility and value.