We recently announced that Chrome will be phasing out support for NPAPI in 2014. This guide provides more details about what to expect and alternatives to NPAPI.
Starting in Chrome 32—expected to reach the Stable channel in mid-January 2014—when a user visits a page with a non-whitelisted NPAPI plug-in, they will see:
Note that users who have already installed the plug-in in previous versions of Chrome will still need to go through this "click-to-accept" experience. You can test the behavior on this site.
In mid-2014, the blocking UI will become more difficult to navigate, as a means of discouraging NPAPI use by developers. With the harder-to-bypass blocking UI, users will see a puzzle piece in place of the plug-in and a "Blocked plug-in" page action icon in the Omnibox:
Note that there will not be a yellow info bar (i.e. "drape") at the top of the page. Also, the page action icon will appear even if the plug-in itself is invisible. Visit this site in Canary to see the new UI in action: http://www.medicalrounds.com/quicktimecheck/troubleshooting.html
This behavior is similar to existing behavior when all plug-ins are blocked by default (“Settings” => “Advanced Settings” => “Privacy - Content Settings” => “Plug-ins,” select “Block all,” and then load, for example, http://techcrunch.com).
End of 2014
Even though users will be able to let NPAPI plug-ins run by default in January, we encourage developers to migrate of off NPAPI as soon as possible. Support for NPAPI will be completely removed from Chrome in a future release, probably by the end of 2014.
The only whitelisted plug-ins are the ones mentioned in the blog post. That list is based entirely on usage. There is no "process" for other plug-ins to be universally whitelisted.
Apps and Extensions
Apps and Extensions that use NPAPI plug-ins will not be affected by the initial January 2014 block. They have their own phase-out schedule, defined in the penultimate paragraph of the blog post. If your NPAPI plug-in is installed by a wrapper extension and then used by pages on the open web, it will not be affected by the initial January 2014 block. It will follow the Apps/Extension deprecation path instead. Note the update at the bottom of the post: as of April 2014, developers will be able to update Apps and Extensions that use NPAPI until their listings are unpublished in September. This deviation from the original schedule is to allow for security updates.
Enterprise administrators will be able to whitelist specific NPAPI plug-ins by adding them to the EnabledPlugins policy list, to avoid their users seeing the UI mentioned above. This, however, will not be relevant once support for NPAPI is completely removed from Chrome. Hence we recommend enterprises and enterprise app developers as well to move entirely off NPAPI by Q2 2015.
On Mac, version 39 onward, Chrome will be 64 bit only and this will imply 32 bit NPAPI plugins will stop to work on Chrome on Mac and there will be no way to whitelist it by policy. 64 bit plugins however can still be whitelisted and will continue to work until overall NPAPI removal in Q2 2015.
With the deprecation of NPAPI, some developers have asked which modern technologies can be used to implement features which in the past would have relied on a platform-specific NPAPI plug-in. In answer to these questions we have composed the following list of common NPAPI use cases and web platform alternatives.
In general, the core standards-based web technologies (HTML/CSS/JS) are suitable for most client software development. If your application requires access to features outside the web sandbox, myriad Chrome Extension and App APIs offer access to OS features.
A common use case for NPAPI plug-ins on the modern web is embedded video and/or audio. A range of modern web technologies exist to facilitate media streaming. The basic building blocks are WebRTC and media elements:
Several features on top of these building blocks support more advanced use cases:
The ability to adapt media streaming to an individual consumer is critical in delivering high-quality content to a large audience. In the past this capability has been provided by technologies such as Silverlight’s smooth streaming and Quicktime’s HTTP live streaming. The Media Source Extensions to the HTML media element provide the capability to adapt a stream to an individual consumer on the modern web. Html5rocks has put together a great example of how to use the Media Source Extensions to implement some of these common use cases.
Encrypted Media Extensions give HTML5 video the DRM capabilities that previously would have required the use of a platform specific plug-in. The WebM project has provided a demo which performs video playback using the Encrypted Media Extensions of the video element. For more information, check out the EME HTML5 Rocks article.
WebVTT and the <track> element (a child element of <video>) enable web developers to add timed-text captioning capabilities to their HTML apps.
Try the Native Messaging API for Chrome Apps and Extensions.
Native Client (NaCL) provides a rich environment for cross-platform game development. Many games have already been ported to or designed for NaCL. A number of examples and detailed tutorials to get started with NaCL are available on the NaCL development site. The WebGL specification provides a high-performance platform for hardware-accelerated 3D graphics in the browser. Chrome experiments has an entire category dedicated to examples and demos of various WebGL use cases.
Some services have relied on NPAPI-based security techniques. We recommend switching to TLS or, soon, Web Crypto.
In the past it has often been necessary to write platform specific plug-ins to access system hardware such as webcams, microphones, USB devices, and bluetooth. Direct access to local media streams such as webcams and microphones can now be requested directly from the web via the WebRTC Media Capture specification. Chromium also provides an App API for access to USB hardware and another API for accessing Bluetooth devices.