- Netscape Plugin Application Programming Interface
Netscape Plugin Application Programming Interface (NPAPI) is a
cross-platform pluginarchitecture used by many web browsers.
It was first developed for the Netscape family of browsers starting with
Netscape Navigator2.0 but has subsequently been implemented in other browsers including Mozilla Application Suite, Mozilla Firefox, Safari, Opera, Konqueror, Google Chrome, and some versions of Microsoft Internet Explorer.
Its success can be partly attributed to its simplicity. A plugin declares that it handles certain content types (e.g. "audio/mp3") through exposed file information. When the browser encounters such content 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 plugin is then responsible for rendering the data as it sees fit, be it visual, audio or otherwise. So a 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 a comparatively small number of functions. There are approximately 15 functions in total for initialising, creating, destroying, and positioning plugins. The NPAPI also supports scripting, printing, full screen plugins, windowless plugins and content streaming.
The origin of the Netscape plugin functionality started not within Netscape, but 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. Therefore, soon after Netscape released the first version of Navigator, Padgett and fellow engineer Eshwar 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 Jim Clark, the CEO of Netscape. Prior to that demo, the only native file formats on the Web were HTMLpages and the images embedded within them. Links to any other file type caused the user to be prompted to download the file, after which the user could open the file in the appropriate application. In that demo, however, when a user clicked on a link to a PDF file, the file was instantly opened 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 with a bit of reverse engineeringof 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 a different approach, a plugin architecture. Adobe engineers Gordon Dow and Nabeel Al-Shamma had recently added a plugin architecture to the Acrobat Reader to leverage the development efforts of engineers 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. And while PDF was the pioneer, one could argue that later plugins like
Macromedia Flash, ActiveX controls, and Java applets have changed the Web landscape far more.
With Netscape 4, the NPAPI was extended to allow plugins to be scripted. This ability was known as
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 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 fraught and 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 proved extremely 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
This removed the Java dependency, however there are issues with XPConnect. In particular, the technology is heavily based on XPCOM, which is similar to Microsoft COM. Thus the plugin developer must be familiar with reference counting, interfaces, IDL and so forth to implement scripting. Additionally, 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 so that it supplies 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.
End of 2004, all major browser companies except Microsoft agreed on [http://developer.mozilla.org/en/docs/Gecko_Plugin_API_Reference:Scripting_plugins 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 the latest generation of Mozilla (1.7.5+) / Firefox, Safari, and Opera. All new plugins should use this API.
NPAPI vs ActiveX controls
Microsoft developed OLE2 (
Object Linking and Embedding) as a way to create compound documents in applications such as Microsoft Word. For example a word processor document might contain an embedded spreadsheet that could be launched within the confines of the word processor window. OLE2 was based on COM and defined interfaces for the various tasks that the container and the object needed to perform. An OLE2 control (sometimes known as an OCX) was a light OLE2 object that could be embedded into a container but did not save large amounts of data or require menus or toolbars to function.
A control was implemented as a DLL and loaded into the address space of the host container such as
Visual Basic. Earlier versions of Visual Basic used a similar technology called Visual Basic Extensions but OCX controls were seen as superior. Each OCX implemented a well defined subset of the OLE2 interfaces that the container could use to manipulate the control, such as repositioning it, or to provide information about the container. The OCX also implemented an "automation interface" which allowed it to expose methods and properties that could be manipulated, and used mechanism in the other direction to fire events to the container.
OLE2 was extremely complicated and support for COM in MFC was poor. So Microsoft rationalised the specification to make it simpler, and rebranded the technology as
ActiveX. Even after simplification controls were still required to implement about 6 core interfaces. In response to this complexity, Microsoft produced wizards, ATL base classes, macros and C++ language extensions to make it simpler to write controls.
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 (using non-W3C syntax), 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 has 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 within a "plugin.ocx" file that acted as a shim between the ActiveX based browser and the NPAPI plugin. The IE browser would load the control and use it to host plugins specified within the page. However, Microsoft made the claim that the NPAPI plugins (or the IE implementation of the API) were a security issue and dropped support for them in version 5.5 SP2. [ [http://support.microsoft.com/kb/303401 Netscape-style plug-ins do not work after upgrading Internet Explorer] ] [Giannandrea, J. (
September 4, 2001) [http://www.meer.net/jg/broken-plugins.html Microsoft breaks Web Plugins in Windows XP] .] [ [http://support.microsoft.com/kb/306790 Description of Internet Explorer Support for Netscape-Style Plug-ins] ]
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. Thus a malicious plugin can do as much damage as a malicious ActiveX control.
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 Visual Basic. 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 angles to subvert the user's computer.
Another difference for the NPAPI is that implementations (prior to
Mozilla Firefox, see below) did not 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 will automatically download and install the control from the specified source, pausing only to show the digital signature to the user and obtain their consent for installation to start. 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, adwareand malwaresites 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 Firefoxattempts to present a middle ground. If a plugin is missing, it will notify the user that the plugin is missing and initiate 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. Of course this model implicitly trusts the plugin finder service to return "good" plugins, increasing the security required on the host site.
Adobe Flash Player
Java Runtime Environment
VLC media player
Windows Media Player
* [http://developer.mozilla.org/en/docs/Plugins Plugin development documentation] on Mozilla Developer Center
* [http://www.mozilla.org/projects/plugins/ Older plugin development homepage]
* [http://git.webvm.net/?p=npsimple Hello World of NPAPI plugins]
* [http://www.mozilla.org/projects/plugins/npruntime.html Writing scripting plugins with Mozilla]
* [http://www.mozilla.org/projects/plugins/plugin-host-control.html An ActiveX control that hosts plugins] – A replacement for plugin.ocx that was removed from Internet Explorer.
* [http://news.com.com/IE+competitors+mull+ActiveX+alternative/2100-1032_3-5253504.html?tag=nl IE competitors mull ActiveX alternative – CNET]
Wikimedia Foundation. 2010.
Look at other dictionaries:
Программный интерфейс подключаемых модулей Netscape — (англ. Netscape Plugin Application Programming Interface, NPAPI кросс платформенная архитектура разработки плагинов, поддерживаемая многими браузерами. Интерфейс был разработан для семейства браузеров Netscape Navigator, начиная с Netscape… … Википедия
Rich Internet application — Articleissues article =September 2008 OR = July 2008 refimprove = July 2008 advert = July 2008 cleanup = July 2008Rich Internet applications (RIAs) are web applications that have the features and functionality of traditional desktop applications … Wikipedia
NPAPI — Netscape Plugin Application Programming Interface (NPAPI) is a cross platform plugin architecture used by many web browsers. It was first developed for the Netscape family of browsers starting with Netscape Navigator 2.0 but was subsequently… … Wikipedia
NPAPI — Netscape Plugin Application Programming Interface (Computing » Software) … Abbreviations dictionary
Google Chrome — This article is about the web browser. For the operating system, see Google Chrome OS. Google Chrome … Wikipedia
ActiveX — ActiveX фреймворк для определения программных компонентов, пригодных к использованию из программ, написанных на разных языках программирования. Программное обеспечение может собираться из одного или более таких компонентов, чтобы… … Википедия
Google Chrome — Este artículo trata sobre un navegador web. Para el sistema operativo, véase Google Chrome OS. Google Chrome … Wikipedia Español
Document Object Model — Not to be confused with Domain Object Model. HTML HTML and HTML5 Dynamic HTML XHTML XHTML Mobile Profile and C HTML Canvas element Character encodings Document Object Model Font family HTML editor HTML element HTML Fr … Wikipedia
Java (Technologie) — Java Logo Java Technik (englisch Java Technology) ist eine hauptsächlich von Sun Microsystems entwickelte Sammlung von Spezifikationen, die einerseits die Programmiersprache Java und andererseits verschiedene Laufzeitumgebungen für… … Deutsch Wikipedia
Web 2.0 — A tag cloud (a typical Web 2.0 phenomenon in itself) presenting Web 2.0 themes The term Web 2.0 is associated with web applications that facilitate participatory information sharing, interoperability, user centered design, and collaboration on … Wikipedia