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 :-(.

35 comments:

  1. Worth pointing our that the idea of LLVM IR as a platform's IR has been discouraged by a LLVM developer: http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/043719.html

    ReplyDelete
  2. A serious question, which I have never seen answered: other browser developers are outright hostile to PNaCl, which doesn't bode well for adoption, but *why*?

    ReplyDelete
    Replies
    1. I think this has been answered several times on various mailing lists, but here is my personal take on things:

      1. NaCl is CPU-specific. That's not suitable for the web.
      2. PNaCl is in theory portable, so it is potentially worth considering.
      3. However there is no spec for PNaCl, and standardizing it would take an extreme amount of effort: It means standardizing a subset of LLVM IR, which is quite rich and complex, as well as the Pepper plugin API. This is an enormous amount of work that has not even been begun by Google AFAIK.
      4. A specific issue is that there are worries about the Pepper API duplicating things that are already done by standardized web APIs. That makes it hard to reach consensus on standardization.
      5. There has been no public indication of interest whatsoever from Apple or Microsoft, without which this can't go forward.
      6. A large new technology like PNaCl (which requires LLVM) has a large surface area, and ensuring it is secure is challenging.
      7. Finally, if PNaCl-like performance can be achieved by other means, then all the effort and risk is even more worrying (while that is not yet clear either way, there are positive indications that it might).

      Delete
    2. A small correction on 6: PNaCl has no more security surface area than NaCl has. The LLVM translator itself is SFI-sandboxed, and the executables it produces are SFI-sandboxed. All of these are validated (small verifiable validator, see the NaCl paper), and then executed within another sandbox.

      Furthermore, there are quite compelling security features that PNaCl offers on top of what NaCl has.

      I'd make the argument that PNaCl is more appealing from a security point of view than compile-once-run-everywhere (e.g. NaCl) as well as traditional language VMs.

      Delete
    3. Your last two paragraphs smell of arrogance. If you are going to defend something, don't say “I could argue” and proceed to give naked advocacy without bothering to give your arguments.

      Delete
    4. > A small correction on 6: PNaCl has no more security surface area than NaCl has.

      Yes, sorry for my mistake, what I wanted to say was that adding either NaCl or PNaCl to a browser will increase the surface area, compared to not having them at all and just running apps in JS. I forgot that you use the same sandbox for LLVM, so NaCl and PNaCl are basically equivalent.

      Delete
    5. Enu, I purposefully didn't pursue that argument because it wasn't my point. I wanted to correct one of Alon's points, not argue over it.

      Discussing the security of traditional VMs versus SFI VMs is a pretty lengthy subject that would require its own writeup, not a comment on an unrelated blog post. At that point you'd probably also want to go into implementation details of NaCl's runtime versus SpiderMonkey as well as each of their browser's sandboxing and other mitigations.

      I hope you'll reconsider what I wrote as a concise, to the point, reply instead of arrogance.

      Delete
    6. In addition to what Alon said, the Pepper APIs are also a significant increase in surface area. One of the successful p0wnium attacks used (in part) a vulnerability in Pepper.

      Delete
    7. Any browser that supports NPAPI but not PPAPI has no real basis for claiming that PPAPI is worse off. The whole design of NPAPI is fundamentally flawed from a security perspective and is the entire reason why PPAPI was created in the first place.

      Delete
    8. Your reasoning is incorrect. The choice is not "NPAPI vs PPAPI", the choice is "NPAPI vs "NPAPI + PPAPI", and the latter can (and is) certainly an increase in surface area.

      Delete
  3. roc, I think your concerns are legitimate, but somewhat premature. (Disclaimer: While I am a Chromium developer, I have no connection to the PNaCl or Pepper teams.)

    PNaCl and Pepper are, by virtue of what they're trying to do, large. It seems reasonable for other vendors to remain on the sidelines while market testing demonstrates whether their benefits are worth the effort of cross-browser implementation and standardization, but it also seems reasonable for Google to pursue getting these technologies to the public so that that testing can happen.

    It's not as if there is no interest in feedback. PNaCl is a direct response to the (legitimate) complaints that NaCl baked in the x86 architecture in a way incompatible with the cross-platform nature of the web.

    Furthermore, Pepper is hardly just a layer for [P]NaCl executables to touch the web. Its proper name, PPAPI, makes it clear that it is a next-generation replacement for NPAPI, which is both necessary and desirable for a multi-process browser that wants to implement plugins in a sandboxable and performant fashion. The fact that other vendors have not taken PPAPI (or begun working on similar efforts, or given feedback about what they want to see change) is, to me, more an indication that Chrome is the only browser which has to this date implemented sandboxing for e.g. Flash.

    To me, the PNaCl folks have reason to believe that there are compelling wins if they can ship their product, and reason to believe that if they can demonstrate those compelling wins, other vendors may reconsider. At that point I cannot imagine Google not going to the trouble of proper standardization along with assistance to other vendors who wish to implement these technologies. For now, as those vendors reasonably sit on the sidelines, such activities should not be a priority.

    ReplyDelete
    Replies
    1. You ignore the point of my post, which is that Blink lays out best practices for the implementation/standardization dance, and PNaCl/Pepper completely violates them. Those Blink principles aren't arbitrary, they've been learned from bitter experience. We know full well that once you expose PNaCl/Pepper to the public Web, if there's uptake the features will quickly become immutable for compatibility reasons and the standardization process will amount to documenting every quirk in the Chrome implementation. This is more true the more complex the feature, so Blink's principles are *more* important for complex features, not less (as the Blink page makes clear).

      Regarding feedback, years ago I had a telecon with Google people where I explained that Pepper duplicates standard Web APIs and NaCl should instead reuse the standard APIs in some way, and this would be a blocker for us. I was of course ignored.

      Mozilla has no interest in a "next generation replacement for NPAPI". Flash is dying quickly. To support legacy Flash content we are investing in Shumway. Other plugins are used much less and that usage is also declining. We don't expect or want new plugins to become important. None of this should be news to Google at large.

      I'm sure every Google team working on a Web-facing feature believes "there are compelling wins if they can ship their product". If that's a free pass to bypass Blink's principles, they have no value.

      Delete
    2. Flash is dying? YOU are killing it.

      And your product Shumway is useless other than simple bunners (10 times slower than the native Flash Player) so it can't exterminate Flash. Probably Shumway (and pdf.js) will be needed to recreate from scratch using asm.js by serious performance issues.

      I feel Mozilla people never admit their mistakes. You were saying JavaScript should be enough for all tasks just half a year ago, Of course it was WRONG because you are now pushing asm.js like crazy. If asm.js is not welcomed as you thought, I think it might be by the faithless of Mozilla guys. Think that you might be making another mistake by asm.js.

      From my perspective Google and Mozilla are not different much. All browser vendors suck. Google loves their PNaCl/Dart and Mozilla loves their asm.js/JavaScript. That's all. Hence I dislike the unproductive web platform and love native development.

      Delete
    3. I'd like to take credit for killing Flash, but it wasn't me (or us).

      asm.js is JS. That's the point.

      Delete
  4. Isn't your argument for standardization circular? NaCl did a good-faith effort at supporting Firefox (before Pepper) through a plugin and it was summarily executed by Mozilla. Mozilla then continually bashes NaCl and PNaCl, is there a point in standardization before demonstrating worth?

    Once they do demonstrate worthiness I assume Mozilla will back it up. Didn't the same thing occur with SPDY and VP8? Both of these are going for standardization, and Mozilla is now changing its position because technical merit was shown.

    ReplyDelete
    Replies
    1. I don't think Mozilla has ever been hostile to SPDY or VP8. In fact, they were counting on Google to support them (on Google sites) in order to give them some worth. A better example might be WebP, which has grown to support enough features that it may be useful now, but wasn't in its original form.

      I also don't think Mozilla had anything to do with the death of the NaCl plugin that I know of (you're free to write any plugin you want with NPAPI, and I'm not sure what Google writing it has to do with supporting open standards). Google ported it to Pepper and let the plugin die.

      My take on these tech's has usually been that they're too large and complex. They're not well engineered, and Google's shown no real interest in getting outside input to change or fix that. There's plenty of people trying new things on the web all the time. The bad ones should be thrown away or fixed, and if you're not willing to take outside help to do that, you shouldn't be pushing them onto the web.

      Delete
  5. Google's trying new things—this is how progress is made. As a consumer and developer I'm glad they're trying things such as this, same thing with SPDY, Chrome and Blink, etc.

    ReplyDelete
    Replies
    1. Chrome itself didn't/doesn't cause Web compatibility or standards problems. The whole point of standards is that someone can release a new browser and Web developers and other browser vendors don't have to change anything. Ditto for Blink.

      SPDY is rather different to NaCl/Pepper. Mozilla and Opera expressed support for the SPDY work early on, implemented it themselves, and provided a lot of feedback. SPDY is also just better than NaCl/Pepper, e.g. it doesn't duplicate existing Web standards (one reason we supported it).

      "Trying new things" is good, but there are good and bad ways to do it, and some of the bad ways are very bad for the Web.

      Delete
  6. It saddens me that, after all this time and after all the battles that have been fought --- against tag soups in the 90s, against "HTML is just a document format" and "roll your own anti-social language" (XML/RDF and XUL, XAML, etc.) in the 00s, against magical binary blobs (ActiveX, Java, Flash, Silverlight), against proprietary lock-in in the mid 90s (Netscape), early 00s (Windows/IE), late 00s (iOS), early 10s (Android/WebKit), against any proposal that allows dime-a-dozen creators hide and protect their techniques, tricks and secret ingredients (DRM, etc.) --- after all this, we still have to fight the same garbage in a gleaming new packaging (PNaCl and even asm.js) and the same tired arguments put up as defence (all in the name of innovation).

    More importantly, we *still* haven't come to understand the essence of The Internet. The internet is an extraordinary human achievement, not because it allows people to communicate across the globe (a cheap trick already achieved by many other mediums). No, the reason the internet is an extraordinary human achievement is because almost every scrap of knowledge is associated with a unique name (URL/URI) that can potentially be accessed by anyone and that there is a *universal* and *universally* *understood* vocabulary (HTML/CSS and, as a clear text polyfiller, Javascript), understood by humans and machines, that expresses this knowledge. Or to put it slightly more pithily: Everything its Name and Every Thing Explained.

    PNaCl and asm.js threaten to fill the web with black boxes. I imagine they will fail for all the same reasons that everything of their ilk has failed before them.

    But let's not play with fire.

    ReplyDelete
    Replies
    1. asm.js is no more a black box than minified js that is very common on the web. It is still familiar js syntax, and all communication with the browser APIs is still through the exact same human-readable APIs as normal JavaScript.

      Delete
    2. And where did I say minified js was unproblematic?

      asm.js is an order of magnitude better than PNaCl, precisely because it makes use of human-readable Javascript APIs. I think we agree on that. But the excitement surrounding asm.js is about being able to port native apps into the browser, which typically creates code like this:

      function Vb(d) {
      d = d | 0;
      var e = 0, f = 0, h = 0, j = 0, k = 0, l = 0, m = 0, n = 0,
      o = 0, p = 0, q = 0, r = 0, s = 0;
      e = i;
      i = i + 12 | 0;
      f = e | 0;
      h = d + 12 | 0;
      j = c[h >> 2] | 0;
      if ((j | 0) > 0) {
      c[h >> 2] = 0;
      k = 0
      } else {
      k = j
      }
      j = d + 24 | 0;
      if ((c[j >> 2] | 0) > 0) {
      c[j >> 2] = 0
      }
      ...


      Can I read this? Technically, yes. I can read assembler code too. But how well can I understand it? Would I be able to copy and modify it in an intelligent way? Probably not.

      Is this kind of code likely to become common? I would expect and hope not. It might be just a stop-gap for the next 5-10 years, until JS/DOM engines can stand on their own in terms of performance. But things might take an unexpected turn. Somebody (I'd imagine Adobe would be keen) might create a toolchain that makes it easy (if you have the money and the toolchain mindset) to create apps for this target. And then what? Black boxes that penetrate the web to an even greater extent than Flash managed, I'd imagine.

      Delete
  7. This seems awfully hypocritical.

    Sure Blink should live up to their standards they've declared but what about Mozilla? What standards body was asm.js proposed at so other browser vendors could have input into the primitives before mozilla shipped it? Was the Audio Data API any different? My recollection is you just shipped it with no input from anyone. Parallel js? How about the myriad of moz only APIs documented on mdn?

    One of Mozilla's principles is: Transparent community-based processes promote participation, accountability, and trust.

    Yet as far as I can see none of the above features were done transparently.

    Should Mozilla operate on a different set of rules?

    ReplyDelete
    Replies
    1. > What standards body was asm.js proposed at so other browser
      > vendors could have input into the primitives before mozilla
      > shipped it?

      It was discussed at TC39 and there was informal support. asm.js is designed to work in all browsers even if they don't add explicit support, so having a spec for it is not so important. Having said that, unlike Pepper/PNaCl, asm.js does have a spec.

      > Was the Audio Data API any different?

      We discussed the design and implementation of the Audio Data API in public and solicited feedback. Google's (belated) response was to reveal Web Audio, which they'd been developing in secret. For various reasons (some good, some bad) Web Audio won out so we deprecated Audio Data without ever making it into a formal spec. It was always prefixed, which used to be best practices for experimental stuff. If we were doing it again we'd make it behind a pref, disabled by default.

      Comparing Audio Data to PNaCl/Pepper is a bit ridiculous though. Audio Data is trivial to implement, PNaCl/Pepper not at all.

      Parallel JS was originally proposed by Intel (Rivertrail), not Mozilla. It's experimental and we definitely will not enable it by default without a standardization story.

      > Should Mozilla operate on a different set of rules?

      Definitely not. We try to do the right thing, but we don't always get it right, so your attention is appreciated.

      Delete
    2. This comment has been removed by the author.

      Delete
  8. What kind if support was at TC39? Are there notes to see? I only see Mozilla names on the spec. What input did other browser vendors have? Did thay have input into the primitives supported? Did they have input into the method of implementation? Did they have input into how asm.js code is identified? Did they have input into how to transfer data to/from JavaScript and asm.js?

    To be honest I think asm.js is a neat idea and I'm glad Mozilla implemented it to show its potential. Rather than see Blink or Mozilla hobbled by design by committee I think they should both continue what they've BOTH been doing. Shipping new features and proposing them as possible new standards. I believe that leads to moving the web forward faster than waiting for standards committees to hammer out agreements.

    ReplyDelete
    Replies
    1. I don't know the details of what happened at TC39, and I'm not in a position to know all the feedback we've received. But Google has at least provided indirect feedback --- they praised asm.js at Google I/O, and indicated they'll optimize V8 for it but without using a specialized front-end triggered by the "use asm" directive, like we do. So most of those issues you raise are not relevant to them.

      Unfortunately Apple and Microsoft people are choosy about what they provide feedback on. They often implement specs without ever having provided any feedback.

      We do avoid being hobbled by committees by implementing and shipping experimental features. That's fine, but there has to be a bright line between experimental features which are not standardized and should not be used by production sites, and the actual Web platform. Current Gecko and Blink policy is to enforce that line by disabling-by-default experimental features in release builds. That is the line PNaCl/Pepper is going to cross, hence this blog post.

      Implementing a feature, shipping it enabled in releases, encouraging sites to depend on it, and THEN thinking about standardizing it is a recipe for disaster. Web Audio is going through this right now.

      Delete
    2. Google giving feedback AFTER you shipped is not an example of the "best behavior" you're seeking from blink unless I'm mis-understanding.

      I see your point about PPAPI/PNaCl. I think the difference of view point there is that PPAPI is a plugin API and PNaCL is a PPAPI plugin and plugins, to some people, don't seem to fall under the same umbrella of standards.

      Companies can ship any plugins they want (Flash, Unity3D, ...). NPAPI is arguably insecure and the largest single hole for exploits. PPAPI is an attempt to make it possible to fix that hole while recognizing that plugins, while usage might be going down, still have many years of life left in them.

      Telling Blink they can't ship a more secure plugin API to protect their users seems out of line. Telling someone they can't ship a plugin (which anyone can do) also seems like telling someone they can't write JavaScript. I'm not saying your point is invalid. Only pointing out there's another way of looking at it.

      Delete
    3. asm.js has not shipped yet. It's currently in our beta branch.

      If the goal for PNaCl/PPAPI was only to replace existing usage of NPAPI with a more secure alternative, I'd be more sympathetic --- but still concerned, since we have a spec (of sorts) for NPAPI, and a public multi-vendor process for updating it, and replacing it with something lacking those virtues is a step backwards in some dimensions. But in any case, PNaCl/PPAPI's goals are clearly much broader than that, otherwise Google would be limiting the attack surface by whitelisting specific plugins that matter and not encouraging people to build new ones.

      Delete
    4. pkasting points out on chromium-dev that NPAPI plugins have always had a reasonably high installation barrier (or else were specifically bundled with the browser or other non-Web products). As I understand it, the plan for PNaCl/Pepper is to eliminate that barrier as it's no longer a security requirement --- making it a much broader platform than NPAPI.

      Delete
    5. Like I said I think there are different points of view. PPAPI and PNaCl are two separate features. Just like NPAPI and Flash are two separate features.

      PPAPI is a plugin system. It is better than NPAPI in at least 3 ways:

      1) It is designed to run plugins out of process only
      2) It provides cross platform OS level features
      3) It's design to be more secure than NPAPI

      All of those are valid enough reasons to ship PPAPI regardless of what other browser vendors do (in my personal opinion). Protecting users from the #1 area of exploit (NPAPI) is important. Giving them a better experience by requiring out-of-process plugins is also important. Providing a cross platform API surface is arguably also important is it let's the browser give a uniform API for plugins (devs don't have to learn N OSes) and it let's the browser limit what a plugin can call and how it can call it.

      Separately someone (Google) has written a plugin called PNaCl. It runs native code securely. It's similar to Flash (which runs ActionScript) or Silverlight (which runs .NET languages) or Unity3D (which runs .NET languages through Mono integration).

      Just like the Flash plugin downloads .swf and executes them, the Unity3D plugin downloads .unity3D files and executes them, Silverlight downloads ?? files and executes them, the PNaCl plugin downloads .pexe files and executes them.

      So, from a certain POV, the basic complaint then is that Google is bundling a plugin. If Google announced tomorrow they were bundling the Unity3D plugin would that be just as upsetting would people be happy that Unity3D was able to negotiate bundling? Google is already bundling the Flash plugin and Unity's growth is huge. I'm not suggesting Google will ever do that. Only point out how that hypothetical situation is analogous to the PNaCL situation.

      I understand there's another POV which says "because it's Google and because it's Chrome which has a large market share that it's not cool to bundle yet another plugin because suddenly XX% of the net will have access to some new feature and possibly become dependent on it.

      I'm not saying that pov is invalid, only that the other POV that it's just a plugin is also valid.

      In any case, please consider not conflating PPAPI and PNaCl. They are 2 completely separate techs. There are already 2 other PPAPI plugins. There's the PPAPI Flash which is far more secure than NPAPI flash and has been known not to be vulnerable to some of the exploits of NPAPI flash. There's also Chrome's PPAPI PDF viewer.

      So, PPAPI is not going away. Chrome requires it at this point to secure Flash and provide PDF support.

      Separately, there's a new plugin, PNaCl.

      Delete
    6. I don't think you can cleanly separate (P)NaCl and PPAPI that way. The security features of PPAPI depend on (P)NaCl.

      Yes, bundling a plugin --- any plugin --- that exposes non-standard platform API to Web pages is a problem, just as exposing non-standard APIs in other ways is a problem. It doesn't matter whether we call the implementation a "plugin" or not; the effect is the same.

      You're going to ask: "Chrome already bundles Flash so what's new?" Flash is a problem and if we made Flash usage disappear from the Web tonight I think browser vendors would all cheer. Flash bundling can only be justified because Flash is already ubiquitous on desktops and widely used on sites, so bundling causes minimal additional harm.

      Delete
  9. It's sad to see that Mozilla has become a company that has no grand vision for the web. This is clearly demonstrated by something like asm.js which is a really cheap attempt at fixing a fundamental problem with the web platform, that being how to make web apps faster and more scalable. If developers have to choose between dart+simd vs asm.js for games I have no doubt they will opt for something like dart, and it won't be because google is forcing it on them either, instead it will be because dart provides a structured workflow and great tools. All google is doing with dart is hedging their bets on the web platform. For years people at mozilla have said that javascript can be evolved into something that isn't a total mess, and yet nobody at mozilla has provided a shred of evidence that these kinds of statements are true, and they sure as hell can't provide a time frame for when that will happen. When it come to the question of whether javascript can be fixed the burden of proof lies entirely on mozilla. Google has emphasised they will continue to help improve javascript however given how much they have invested into the web platform I believe they have earned the right to hedge their bets, it would be silly not to.

    ReplyDelete
    Replies
    1. ActiveX, vbscript... Yay!!

      Delete
  10. ActiveG, GBScript... Yay!?

    Apparently.

    See also http://blog.tojicode.com/2013/06/a-tale-of-two-web-technologies.html.

    /be

    ReplyDelete
  11. Mozilla is a company that likes to complain based on standards rather than work to improve things. This is the second post I read from Mozilla complaining someone doesn't follow the standards therefore they are "wrong". I will expecting a concrete reason to switch back to their browser.

    ReplyDelete