Jump to content

NPAPI

From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by Adamlock (talk | contribs) at 16:56, 29 March 2005 (NPAPI article). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
(diff) ← Previous revision | Latest revision (diff) | Newer revision → (diff)

The NPAPI (or Netscape Plugin Application Program Interface) is the cross-platform plugin architecture used by many web browsers. It was first developed for the [Netscape] family of browsers staring with Netscape Navigator 3.0 but has subsequently been implemented in other browsers including Mozilla, Mozilla Firefox, Opera, Konqueror and even Microsoft Internet Explorer.

Its success can be partly attributed to its simplicity. A plug-in declares that it handles certain content types (e.g. "audio/mp3") through exposed file information. When the browser encounters an EMBED or OBJECT tag of that type it loads the associated plugin, sets aside the space within the browser content for the plugin to render itself and then streams data to it.

The API requires each plugin to implement and expose a comparatively small number of methods. For example the browser will call NPP_Initialize and NPP_Destroy when loading and unloading the plugin respectively. When the browser creates a plugin window it calls NPP_New and NPP_Destroy.

Other functionality within the NPAPI exists to support printing, full screen plugins, windowless plugins and content streaming.

LiveConnect

With Netscape 4, the NPAPI was extended to allow plugins to be scripted. This ability was known as LiveConnect. A plugin could implement and return an instance to a [Java] class. The public methods exposed by this class was the scriptable interface for the plugin. The class could be called from JavaScript and even from other Java applets running within the page with the browser marshalling the calls between the various contexts.

The disadvantage of LiveConnect was that it was tied heavily to the built-in version of Java within the Netscape browser. This prevented the browser from using other Java runtimes, and added a massive amount of bloat to the browser download size since it required Java to script plugins.

Additionally, LiveConnect was tricky to programme. 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 fraught and non-obvious. To compound matters LiveConnect used an earlier and now obsolete API for invoking native C++ calls from Java called JRI. This has long be supplanted by JNI.

XPConnect

LiveConnect proved extremely problematic for Mozilla. The dependency on the obsolete Java runtime and an obsolete JRI API meant that LiveConnect never really worked in Mozilla.

In the meantime however, Mozilla was using XPCOM to define the interfaces to many objects implemented in C++. Each interface was defined by an IDL (Interface Definition Language) 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.

The type library contained sufficient information that it became possible to marshal calls between JavaScript and plugins just as with LiveConnect.

Thus starting with Netscape 6.5 and Mozilla 1.0, the NPAPI was extended so that a plugin could return a scriptable interface to itself. Unlike LiveConnect however, this technology did not require Java and is considerably better supported and understood.

However there are issues with XPConnect. In particular, the technology is heavily based on XPCOM which is in turn based on COM. Thus the plugin developer must be familiar with reference counting, interfaces, IDL and so forth to implement scripting. Additionally, the dependency on XPCOM lead to certain linking issues which had to be solved before the plugin would work correctly with different browsers.

NPAPI vs ActiveX controls

Microsoft developed ActiveX initially as a way to embed components within Visual Basic forms, supplanting the older VBX format. Controls are essentially "lite" OLE 2 objects that are hosted in a DLL and that implement a well defined set of COM interfaces that the container can use to manipulate them. Over time this API became exceedingly complicated so the requirements for certain interfaces was rationalised but there are still about 6 core interfaces that must be implementd. In response to this complexity, Microsoft has had to produce wizards and ATL base classes to make it simpler.

Starting with Internet Explorer 3.0, support was added to host ActiveX controls within HTML content. If the browser encountered a page specifying an ActiveX control via an OBJECT tag, it would automatically download and install the control with little or no user intervention. This made the web experience "richer" but was perceived as divisive (since controls only ran on Windows) and a security risk due to the lack of user intervention. Microsoft have been forced to introduce security measures to address its shortcomings. For example:

  • Control installation packages (Cabinet files and executables) must be digitally signed.
  • Controls must explicitly declare themselves safe for scripting.
  • The default security settings have become increasingly more stringent.
  • Internet Explorer maintains a blacklist of bad controls.

Internet Explorer did for a time support NPAPI plugins. Plugins that functioned in the Netscape browser also functioned in Internet Explorer. This was due to a small ActiveX control implemented with a plugin.ocx file that acted as a shim between the ActiveX based browser and the NPAPI plugin. The IE browser would invoke the plugin OCX to host an plugins specified within the page. However, Microsoft made the unlikely claim that supporting plugins was too difficult and they dropped support altogether for the OCX.

Critics might claim that this was to promote their own ActiveX technology by killing off support to the only viable alternative.

Future versions of Internet Explorer are more likely to promote a .NET based model using a sandbox and finegrained security to control what the control can and cannot do.

Security

A popular misconception concerning the NPAPI technology is that it is somehow inherently safer than ActiveX. This is not the case at all. Both the NPAPI and ActiveX run machine instructions with the same privileges as the host process. Thus a malicious plugin can do as much damage as a malicious ActiveX control.

The difference for the NPAPI is that no implementation attempts to automatically download or install missing plugins. Thus the user is prompted to manually download and install the plugin if the browser detects content it cannot handle. While this is inconvenient to the user, it is also an important security measure since it prevents the browser from acting as a vector for malware.

Many plugins exist to support different content. Amongst the most well known are:

  • Adobe Acrobat Viewer
  • Shockwave Player
  • Real Player
  • Quicktime Player
  • Microsoft Media Player
  • Videolan Player
Retrieved from "https://en.wikipedia.org/w/index.php?title=NPAPI&oldid=11653971"