What Chrome 45 dropping NPAPI Plug-in support means

Chrome & NPAPI

What does it mean for you?

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 (FDF & XFA) to HTML5 conversion functionality in JPDF2HTML5, 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.

If you’re a first-time reader, or simply want to be notified when we post new articles and updates, you can keep up to date by social media (TwitterFacebook and Google+) or the  Blog RSS.

Related Posts:

The following two tabs change content below.
Leon is a developer at IDRsolutions and product manager for JPDF2HTML5. He is responsible for managing the JPDF2HTML5 product strategy and roadmap, and also spends a lot of his time writing code to build new features, improve functionality, fix bugs, and improve the testing for JPDF2HTML5.
Leon Atherton

About Leon Atherton

Leon is a developer at IDRsolutions and product manager for JPDF2HTML5. He is responsible for managing the JPDF2HTML5 product strategy and roadmap, and also spends a lot of his time writing code to build new features, improve functionality, fix bugs, and improve the testing for JPDF2HTML5.

One thought on “What Chrome 45 dropping NPAPI Plug-in support means

  1. Siavas Firoozbakht

    Everything understood!
    I remember some time ago when I went to chrome:plugins to disable one of these versions of Flash, but I’m not sure which one I did disable actually. But yes, there were two. NPAPI and PPAPI, as I recall now, back then not having a clue about them. Now I do – thanks to you.
    I understand Google’s concern about the “old” NPAPI and their solution to this, but as you may also say, it’s not fitting perfectly. I use Chrome because… it’s the best browser – I think I don’t need to explain this. But as for now, when I design a Unity game and I need to go to test it online (or even sending link to other Chrome users), Unity is not working anymore, so another browser is needed – Microsoft Edge… well… Internet Explorer 12, let’s say. The name was quite old-style, so it’s better now.

    I would like to quote this part from you:
    “HTML5 video had an unsettled start and has got better (but still does not have the performance of Flash).”

    In this case, I don’t really agree, as I tested it myself on YouTube both with an i5 and C2D, where the results in framerate and memory consumption were quite identical (only that as Flash is not used, the memory consumption will be shown as a Chrome process, instead of the former Flash Player). I think the overall experience is not dropped when switching to HTML5.

    Anyway, I really liked your article and you gave me some useful information herein! Thank you for that, Leon!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>