|This article needs additional citations for verification. (September 2009)|
||It has been suggested that LiveConnect and XPConnect be merged into this article. (Discuss) Proposed since February 2014.|
It was first developed for Netscape browsers, starting with Netscape Navigator 2.0, but was subsequently implemented by many other browsers, (although Internet Explorer only supported it through version 5.5SP2).
A plugin declares that it handles certain content types (e.g. "audio/mp3"). When the browser encounters that content type it loads the associated plugin, sets aside space within the browser context for the plugin to render and then streams data to it. The plugin is then responsible for rendering the data. The plugin runs in-place within the page, as opposed to older browsers that had to launch an external application to handle unknown content types.
The API requires each plugin to implement and expose approximately 15 functions for initializing, creating, destroying and positioning plugin content. The NPAPI also supports scripting, printing, full screen plugins, windowless plugins and content streaming.
|This section needs additional citations for verification. (September 2010)|
The origin of the Netscape plugin functionality started at Adobe Systems. John Warnock, CEO of Adobe, and Allan Padgett, one of the primary authors of Acrobat Reader, were hopeful that Adobe's fledgling PDF file format could play a role beyond the desktop. Soon after Netscape released the first version of Navigator, Padgett and fellow developer Eswar Priyadarshan tried to find a way to make PDF an integral part of the Web experience. The result was a live demo shown to Warnock and Netscape CEO Jim Clark. Prior to that demo, the only native file formats on the Web were HTML pages and embedded images. Links to other file type caused the user to be prompted to download the file, after which the user could open the appropriate application. In that demo, however, when a user clicked on a link to a PDF file, the file was rendered within the browser window, seamlessly blending HTML and PDF consumption. Clark excitedly asked who at Netscape had provided support for the integration, only to discover that the integration was done without Netscape involvement, but by reverse engineering the Netscape browser.
The companies set out the next week to bring what was known as "Allan's Hack" to market. While Netscape was ready to incorporate PDF directly into the browser, and certainly Adobe would have gained from that, Padgett proposed his plugin architecture. Adobe developers Gordon Dow and Nabeel Al-Shamma had recently added a plugin architecture to the Acrobat Reader to leverage the development efforts of developers outside of the Reader team. Padgett had been a part of that effort, and he expected that if given a chance, other companies (and hopefully teams within Adobe) would choose to extend the Web as well. Clark and team in the end were convinced and set off designing the API that would support the new model.
Both Google and Mozilla Foundation announced later in 2013 that their browsers will not support NPAPI plugins anymore, and will block plugins which use this technology. This includes Oracle's Java and Microsoft's Silverlight plugins, although these will be whitelisted during 5 months.
The disadvantage of LiveConnect was that it was heavily tied to the version of Java within the Netscape browser. This prevented the browser from using other Java runtimes, and added bloat to the browser download size since it required Java to script plugins.
Additionally, LiveConnect was tricky to program. The developer had to define a Java class for the plugin, run it through a specialised Java header compiler and implement the native methods. Handling strings, exceptions and other Java objects from C++ was non-obvious. To compound matters LiveConnect used an earlier and now obsolete API for invoking native C++ calls from Java called JRI. The JRI technology has long been supplanted by JNI.
LiveConnect was problematic for Mozilla. The dependency on an obsolete and proprietary Java runtime and the JRI API meant that LiveConnect never really worked.
Mozilla was already using XPCOM to define the interfaces to many objects implemented in C++. Each interface was defined by an IDL file, and run through an IDL compiler that produced header files and a language neutral type library that was a binary representation of the interface. This binary described the interface, the methods, the parameters, the data structures and enumerations.
XPConnect has no Java dependency, however the technology is based on XPCOM, which is similar to Microsoft COM. Thus the plugin developer must be familiar with reference counting, interfaces, IDL and more to implement scripting. The dependency on XPCOM led to certain dynamic linking issues (e.g. the fragile base class problem) which had to be solved before the plugin would work correctly with different browsers. XPCOM has since been changed to supply a statically linked version to address such issues. This approach also requires an .xpt file to be installed next to the DLL; otherwise the plugin will appear to work, but scripting won't, causing confusion.
At the end of 2004, all major browser companies using NPAPI agreed on NPRuntime as an extension to the original NPAPI to supply scripting, via an API that is similar in style to the old C-style NPAPI and is independent of other browser technologies like Java or XPCOM. It is supported by Mozilla (1.7.5+) / Firefox, Safari, Opera and Chrome.
The following web browsers support NPAPI plugins:
- Google Chrome / Chromium: In September 2013, Google announced that NPAPI support in Chrome would be phased out during 2014 because "NPAPI’s 90s-era architecture has become a leading cause of hangs, crashes, security incidents, and code complexity."
- WebOS Isis browser
- Mozilla project applications, including
- Netscape Navigator and Communicator
- Odyssey Web Browser on MorphOS
- Internet Explorer up to 5.5SP2
Internet Explorer for a time supported NPAPI plugins, allowing plugins that functioned in Netscape Navigator to also function in Internet Explorer. This was due to a small ActiveX control implemented within a "plugin.ocx" file that acted as a "shim" between ActiveX and the NPAPI plugin. IE would load the control and use it to host plugins specified within the page. However, Microsoft made the claim that this support was a security issue and dropped support in version 5.5 SP2 and later in MS03-015 for IE 5.01.
||This section possibly contains original research. (July 2012)|
On Microsoft Windows, a popular misconception concerning the NPAPI technology is that a plugin is somehow inherently safer than an ActiveX control. Both run native machine instructions with the same privileges as the host process. If the host processes have broad privileges, a malicious plugin can do as much damage as a malicious ActiveX control. It is important to note that NPAPI plugins can be made much safer by simply running in a limited user account. It is generally possible to install and run plugins with a limited user, while installing ActiveX controls requires administrative privileges (prior to IE8) even when the ActiveX runs in a limited account. When running with limited privileges, a plugin cannot do as much damage.
One important difference between NPAPI and ActiveX is that NPAPI is solely for Internet plugins, while ActiveX is used for a wide variety of purposes, including application composition in Windows applications. A typical Windows user has a vast array of ActiveX controls installed, a number of which are probably marked "safe for scripting", but are not actually secure. Any of these can be used as means to subvert the user's computer prior to the introduction of the ActiveX Opt-in feature in Internet Explorer 7.
Another difference is that NPAPI implementations (prior to Mozilla Firefox, see below) did not offer to automatically download or install missing plugins. A missing plugin caused the browser to display a jigsaw piece representing the plugin. If the user clicked on that they were directed to Netscape's plugin finder service where they could manually download and install the plugin for themselves. While this is inconvenient to the user, it is also an important security measure since it prevented the content using the browser as a vector for malware.
In Internet Explorer, the HTML content specifies the location where the ActiveX control resides. If the control is not already installed, IE offers to download and install the control from the specified source. For legitimate controls, this offers a more streamlined installation mechanism with minimal user interaction. However malicious content could convince the user with clever social engineering to ignore warnings (or their better judgement) and install something that might harm their privacy or the machine. A number of spyware, adware and malware sites use this mechanism to deploy executable content to machines. Microsoft has had to increase the default security settings for ActiveX and maintain blacklists of malicious controls in an attempt to mitigate this risk.
Mozilla Firefox attempts to occupy a middle ground. If a plugin is missing, it notifies the user that the plugin is missing and initiates a secure connection to a plugin finder service hosted on mozilla.org. The user can permit Firefox to download and install the plugin. This model prevents content specifying where a plugin should be downloaded from – the plugin finder service does. This enables Firefox to present a fairly seamless installation mechanism but limit the service to trusted and compatible plugins from reliable sources. This model implicitly trusts the plugin finder service to return "good" plugins, increasing the security required on the host site.
On August 12, 2009, a page on Google Code introduced a new project, Pepper with the associated Pepper Plugin API (PPAPI), "a set of modifications to NPAPI to make plugins more portable and more secure". This extension is designed specifically to ease the implementation of out-of-process plugin execution. Further, the goals of the project are to provide a framework for making plugins fully cross-platform. Topics considered include:
- Uniform semantics for NPAPI across browsers.
- Execution in a separate process from the renderer/browser.
- Standardize rendering using the browser's compositing process.
- Defining standardized events and 2D rasterization functions.
- Initial attempt at providing 3D graphics access.
- Plugin registry.
The following web browsers support PPAPI plugins:
- Google Chrome
Mozilla announced that it was "not interested in or working on Pepper at this time."
In February 2012, Adobe Systems announced that future GNU/Linux versions of Flash Player would only be provided via PPAPI, although the previous release, Flash Player 11.2, with NPAPI support, would receive security updates for five years.
- Netscape-style plug-ins do not work after upgrading Internet Explorer
- Giannandrea, J. (September 4, 2001) Microsoft breaks Web Plugins in Windows XP.
- Description of Internet Explorer Support for Netscape-Style Plug-ins
- Google Will Start Blocking Most Netscape Plug-In API Plug-Ins In January 2014, Will Whitelist Silverlight, Unity & Others
- CWE-623: Unsafe ActiveX Control Marked Safe For Scripting
- Pepper Plugin API (PPAPI)
- Google heats up native code for Chrome OS
- NPAPI:Pepper - MozillaWiki
- Plugin development documentation on Mozilla Developer Center, including the NPAPI API
- An ActiveX control that hosts plugins – A replacement for plugin.ocx that was removed from Internet Explorer.
- Book on Programming Netscape Plug-Ins by Zan Oliphant
- Nixysa: A glue code generation framework for NPAPI plugins. Apache 2.0 license.
- NPAPI Tutorial Building a Firefox Plugin (Part two, Part three, Part four)