Eyes Above The Waves

Friday 31 May 2013

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.

  Again, PNaCl and Pepper satisfy none of these.

• In extremely rare cases, we may enable a feature by default before the feature's compatibility risk is as low as we'd like. In such cases, we will meet the following requirements:

  • We will propose an editor’s draft (or equivalent) to the relevant standards group.
  • We will discuss the feature publicly with implementers of other browser engines.

  Further, we will take on an active commitment to shepherd the feature through the standards process, accepting the burden of possible API changes.

  Again, none of this is happening for PNaCl and Pepper.

• [Regarding the Blink "Feature Dashboard"] We associate each value with a shade of red or green, corresponding to how the value reflects our web citizenship. For example, “opposition from another browser vendor” is red and “a similar implementation in another browser” is green. Viewed in aggregate, these colors provide a quick snapshot of the project’s overall web citizenship.

  PNaCl and Pepper aren't on that dashboard, but if they were, they'd be a very, very bright shade of red.

The disconnect is alarming. Unfortunately it appears Blink's principles only apply to Blink, not Chrome as a whole. I'm sad, because this seriously undermines the value of the Blink team's good intentions; a Google team that doesn't want to be a good Web citizen can probably find a way to be "not Blink" and run roughshod over the Blink team's good work :-(.