Monday, September 23, 2013

The great "I told you so" on plugins

*ahem* I told you so.

Google is not banning every plugin -- Flash still operates in Chrome -- but it is banning the NPAPI plugin family to which nearly every extant plugin belongs and entirely switching to its Pepper plugin API protocol, Chrome's closed source private implementation of Flash, the Chrome PDF viewer, and Google Native Client being the only known PPAPI plugins. There have never been PPAPI plugins for PowerPC OS X, and no Power Mac browser has ever supported the protocol.

A little history is in order. NPAPI stands for the Netscape Plugin Application Programming Interface, and dates all the way back to Netscape Navigator 2.0 when Adobe reverse-engineered Netscape Navigator to allow PDFs to display natively in the browser. This was "Allan's Hack," named after Adobe developer Allan Padgett, who convinced Netscape CEO Jim Clark to put resources into an API to generalize the process. It was gradually expanded in scope with the modern interface descending from NPRuntime circa 2004. Virtually every browser plugin in existence today is based on the NPAPI spec.

Like our plugins page says, plugins bring lots of concerns with them owing to NPAPI's permissive design: they can destabilize the browser, spy on it, or do anything that any other application can with the credentials of the browser user. Plus, being blobs of proprietary code we don't control, we can't update them or easily patch them. Now that Mozilla has removed the QuickDraw and Carbon code on which every Power Mac-compatible NPAPI plugin depends, we don't support them at all, and after the release of 17.0.10 ends support for TenFourFox 17, no supported release of TenFourFox will have any plugin support in any fashion.

Google, because Google wants to redefine the web and eat it, tried to issue a competing "standard" in 2009 called the Pepper Plugin API (PPAPI). PPAPI has some advantages such as proper sandboxing and arguable performance improvements, but calling it a standard or even just a specification is somewhat disingenuous of Google because PPAPI isn't really a true spec like NPAPI was; it's mostly exposed hooks in Chromium that a plugin library can link against, which is why Mozilla refused to support it in Firefox: it would either require importing large portions of WebKit Blink and/or Chromium (Google even uses Chrome and Pepper synonymously), or putting lots of hours into creating an API that looks just like it, and then dealing with the moving target of additional functionality being rapidly added to the core using a description that was obsolete the day it was published. Google engineers have even admitted off-the-record that the Flash Pepper plugin in Chrome depends on APIs that aren't even documented.

Either way, plugins as we know them are on their way out. Mozilla doesn't like them because of their security issues and their provenance as opaque and possibly untrustworthy binary blobs, and Google doesn't like them because they're not under Google's thumb. In this circumstance, think of TenFourFox as merely being ahead of the curve.

4 comments:

  1. This is very bad news for developers community. We are moving to the web and apps fully controlled by a large corporations.

    ReplyDelete
  2. This comment has been removed by a blog administrator.

    ReplyDelete
    Replies
    1. This bug also says a lot. https://bugzilla.mozilla.org/show_bug.cgi?id=899080
      [edit: typo]

      Delete
    2. That was planned for awhile, though notice Flash gets a free pass, of course. -_-

      Delete

Due to an increased frequency of spam, comments are now subject to moderation.