What Chrome 45 dropping NPAPI Plug-in support means

With the recent news that Google has now killed off NPAPI plugins in Chrome 45, it has left many wondering exactly what NPAPI plugins are, and what impact this news will have, if any. Here is a brief history of plugins in web browsers, along with an explanation of what the implications are of Google killing off NPAPI in Chrome.

What is NPAPI?

NPAPI (Netscape Plugin Application Programming Interface) was created all the way back in 1995 by John Warnock and Allan Padgett at Adobe, who wanted to display PDF files from within the web browser (Netscape Navigator 2.0, at the time). As the web expanded and other web browsers were born, they also adopted NPAPI. Mozilla Firefox, Internet Explorer, Safari, Opera, Google Chrome, and others have all supported NPAPI either in the past or to this day.

The simplest way to describe NPAPI is that it’s a thin layer between the web browser and the operating system that allows the web browser to defer to applications installed on the local file system in order to display content that the web browser itself can not handle. The huge problem however is that it means that if that an application has a security vulnerability it can allow the attacker access to the host computer, which has potentially very dangerous consequences.

It’s no surprise then, that web browser makers have been on a bit of a crusade in recent years to eliminate this attack vector. What has been getting in their way is that there were and are some extremely popular uses of NPAPI, such as Adobe Reader, Flash, and Silverlight. The growth of HTML5 has helped to reduce web browser dependence on plugins (and to increase the performance of web browsers), but it has only got us part of the way there. Chrome’s solution for dropping NPAPI is a new API called PPAPI (Pepper Plugin Application Programming Interface) where plugins run inside a sandbox, limiting the amount of damage that a vulnerable plugin can do.

What have web browsers done about NPAPI?

All the way back in 2010, Google announced their built in PDF reader (which uses PPAPI), which they boasted about using a sandbox, helping to protect from malware and security attacks targeted at PDF files. In late 2012, Google announced that they were working on porting Flash from NPAPI to PPAPI across platforms, which has taken some time for them to complete. What Chrome users may have noticed in the past is that there have actually been 2 Flash plugins installed in the Chrome web browser; one which used NPAPI, and another which used PPAPI, with the NPAPI plugin used for web pages that used flash features that the PPAPI plugin did not support.

With PDF reading and Flash out of the way, Google announced in late 2013 their desire to remove NPAPI support entirely. They stated that based on anonymous usage data, only 6 NPAPI plugins were actually used by more than 5% of users, which were Silverlight (15%), Unity (9.1%), Google Earth (9.1%), Java (8.9%), Google Talk (8.7%), and Facebook Video (6.0%).

Microsoft migrated away from NPAPI very early, with versions 5.5 SP2 to 11 all using Microsoft’s proprietary ActiveX framework instead. Their most recent browser, Microsoft Edge, has Adobe Flash built into the browser (not as a plugin), as well as their own PDF reader built in too. Support for Silverlight has also been dropped in Edge, so you can assume that they won’t be too upset about Chrome dropping support for it either.

Mozilla Firefox has been working on moving away from NPAPI, too. Mozilla do not have any interest in supporting PPAPI, and instead prefer to push open web standards. In mid 2014, they forced the default PDF reader to be PDF.js, which renders PDF files using pure HTML(5) and JavaScript. Like Chrome, they have also been active in making sure that plugins are disabled by default and forcing users to explicitly accept security prompts. Their solution for Flash is a (Mozilla supported, but community driven) project called Shumway, which aims to parse and render SWF (Flash) as HTML5. Progress is steady, but quite slow. Based on the roadmap, there is a long way to go before it can fully replace the Flash plugin.

Where are we now?

So where does that leave us now? If you are a Google Chrome user, the chances are that you wont notice anything different about Chrome now that it has dropped support for NPAPI. We have come to accept that some plugin replacements have not been quite as good as the technology they are replacing, for example I’m not sure that anyone can honestly say that the Edge, Firefox or Chrome PDF readers are better than the Adobe Reader. HTML5 video had an unsettled start and has got better (but still does not have the performance of Flash).

Where these changes really have an effect are in enterprise and legacy use, in particular for the enterprise and government organisations that have standardised on PDF Forms and have now lost the ability to use those forms in Google Chrome. Of course, the solution is to move on and to adopt new technologies in the most efficient way possible. We have seen a surge of enquiries recently in the PDF Forms (AcroForms and XFA) to HTML5 conversion functionality in BuildVu, the PDF to HTML5 converter we develop. For them, not only does this provide an easy way to leverage their existing technologies, but it also has the added bonus that it allows them to offer a consistency across desktop and mobile platforms, which is something you can not have when relying on browser plugins.

FormVu allows you to