Netscape Plugin Application Programming Interface ( NPAPI ) は、 Web ブラウザのプラグイン用の非推奨のアプリケーション プログラミング インターフェイス(API)であり、1995 年にNetscape Navigator 2.0向けに最初に開発され、その後他のブラウザにも採用されました。
NPAPIアーキテクチャでは、プラグインは処理可能なコンテンツタイプ(例:「audio/mp3」)を宣言します。ブラウザがネイティブに処理できないコンテンツタイプに遭遇すると、適切なプラグインをロードし、ブラウザコンテキスト内にプラグインがレンダリングするための領域を確保してから、データをストリーミングします。データのレンダリングはプラグインが担当します。プラグインはページ内で直接実行されます。これは、未知のコンテンツタイプを処理するために外部アプリケーションを起動する必要があった従来のブラウザとは異なります。NPAPIでは、各プラグインがプラグインコンテンツの初期化、作成、削除、配置を行うための約15個の関数を実装して公開する必要があります。NPAPIは、スクリプト、印刷、フルスクリーンプラグイン、ウィンドウレスプラグイン、コンテンツストリーミングもサポートしています。
NPAPIは、 Adobe Flash PlayerやMicrosoft Silverlightなどのビデオプレーヤーといった、高度な低レベルパフォーマンスを必要とするプラグインや、Java Runtime EnvironmentなどのWebアプリケーションプラットフォームで頻繁に使用されていました。
主要ブラウザにおけるNPAPIのサポートは2015年から衰え始め、その後7年間かけて徐々に廃止されました。主要なウェブブラウザはすべて、セキュリティとメンテナンス上の理由からサードパーティのNPAPIプラグインのサポートを終了しました。[ 1 ]
Netscape プラグイン API の起源は Netscape 内ではなく、Mattias Andersson の著書 PDF Printing and Publishing で説明されているように Adobe Systems 内にありました。[ 2 ] Adobe の CEO である John Warnock と Acrobat 開発者の Allan Padgett は、PDF をデスクトップ以外の場所でも使えるようにする方法を探しており、Netscape が Navigator をリリースしたことでその機会が生まれました。Padgett と同僚のエンジニア Eshwar Priyadarshan は Netscape ブラウザをリバースエンジニアリングし、PDF ファイルがネイティブの Web 要素として表示され、クリックすると Navigator 内で開くようにしました。彼らのデモは Warnock と Netscape の CEO である Jim Clark に提示されました。
クラークは「アランズ・ハック」をNavigatorに追加することに熱心だったが、パジェットは別の案を提案した。それは、あらゆるファイル形式をネイティブ形式として扱えるプラグインアーキテクチャだった。Adobeのエンジニアであるゴードン・ダウとナビール・アル・シャマは、サードパーティがPDFを拡張できるように、Acrobatにプラグインアーキテクチャを追加したばかりだった。クラークはこの提案に同意し、Netscapeは、そのモデルをサポートするAPIの設計に着手した。
スクリプティングとは、ウェブページ内のJavaScriptコードがプラグインと連携できるようにする機能です。NetscapeやMozillaの様々なバージョンが、LiveConnect、XPConnect、NPRuntimeなど、異なる技術を用いてこの機能をサポートしていました。
LiveConnect は、Web ページ内でJavaおよび JavaScript ソフトウェアが相互に通信できるようにする Web ブラウザの機能です。LiveConnect の最初のバージョンは、カーネギーメロン大学 (CMU) のインターン生の大学院生によって作成されました。 [ 3 ] Java 側からは、スクリプトと同様に、アプレットがページの埋め込みスクリプトを呼び出したり、組み込みの JavaScript 環境にアクセスしたりすることができます。逆に、JavaScript 側からは、アプレットと同様に、スクリプトがアプレットのメソッドを呼び出したり、Java ランタイム ライブラリにアクセスしたりすることができます。[ 4 ] [ 5 ]
Netscape 4では、NPAPIプラグインのスクリプト機能を実装するためにLiveConnectが使用されました。
LiveConnect のOpen Java Interfaceに依存する実装は、 Mozilla 2 のクリーンアップ作業の一環として、2009 年 6 月下旬に Mozilla のソース コード ツリーから削除されました。 [ 6 ] Sun Microsystems から再設計されたJava Runtime Environmentがリリースされたため、もはや必要ありません。しかし、Apple がまだ新しい JRE を Mac OS X に移植していなかったため、古い実装は Gecko 1.9.2 用に復元されました。[ 7 ]
再設計された Java Runtime Environment でサポートされている Java-JavaScript 機能は、Open Java Interface固有のアプローチが放棄されたにもかかわらず、依然として「LiveConnect」と呼ばれています。[ 8 ] Netscape 4 では、プラグインをスクリプト化できるように NPAPI が拡張されました。この拡張機能は LiveConnect と呼ばれています。プラグインはJavaクラスを実装し、そのインスタンスを公開できます。このクラスは、ページ内で実行されているJavaScript およびJava アプレットから呼び出すことができます。
LiveConnectの欠点は、Netscapeブラウザに組み込まれているJavaのバージョンに大きく依存している点です。このため、ブラウザは他のJavaランタイムを使用できず、プラグインのスクリプト作成にJavaが必要となるため、ブラウザのダウンロードサイズが肥大化しました。さらに、LiveConnectのプログラミングは複雑です。開発者はプラグイン用のJavaクラスを定義し、専用のJavaヘッダーコンパイラでコンパイルし、ネイティブメソッドを実装する必要があります。C ++から文字列、例外、その他のJavaオブジェクトを扱うのは容易ではありません。加えて、LiveConnectは、JavaからネイティブC++呼び出しを行うための、JRIと呼ばれる、現在では廃止された古いアプリケーションプログラミングインターフェース(API)を使用しています。JRI技術は、 JNIによって既に置き換えられています。
XPConnect (クロスプラットフォーム接続)は、 XPCOMとJavaScript間の簡単な相互運用を可能にする技術です。
XPConnectを使用すると、JavaScriptオブジェクトからXPCOMオブジェクトに透過的にアクセスして操作できます。また、JavaScriptオブジェクトがXPCOM準拠のインターフェースを提供し、XPCOMオブジェクトから呼び出すことも可能です。主な目的は、XPCOMスタイルのインターフェースを介して通信するオブジェクトは、インターフェースの反対側にあるオブジェクトの実装言語について、一般的に知る必要も気にする必要もないということです。
XPConnectの主な目的は、ネイティブコードとJavaScriptコードが連携する必要がある箇所で使用されている手書きコードを置き換えることです。DOMモジュールはその一例です。
デフォルトでは、アプリケーションまたは拡張機能の一部であるChromeスクリプト(つまり、Chromeスクリプト)にのみ、完全な権限が付与されます。リモートのHTML / XHTML / XULドキュメントの場合、セキュリティ上の理由から権限が制限されているため、ほとんどのXPCOMオブジェクトはスクリプトからアクセスできません。たとえアクセスできたとしても(例えばXMLHttpRequestオブジェクトなど)、通常のセキュリティ制限(例えば、他のドメインのURLを開くことができないなど)が適用されます。
Mozillaは既にXPCOMを使用して、C++で実装された多くのオブジェクトのインターフェースを定義していました。各インターフェースはIDLファイルで定義され、IDLコンパイラによってヘッダーファイルと、インターフェースのバイナリ表現である言語非依存のタイプライブラリが生成されました。このバイナリには、インターフェース、メソッド、パラメータ、データ構造、列挙型が記述されていました。
XPConnectは、型ライブラリ情報を使用して、異なるスレッドコンテキスト間、およびJavaScriptとネイティブコンパイルされたC++間の呼び出しをマーシャリングします。XPConnectはMozilla全体で広く使用されています。Netscape 6.1およびMozilla 0.9.2以降、NPAPIが拡張され、プラグインがスクリプト可能なインターフェースを自身に返すことができるようになり、XPConnectはJavaScriptおよびC++実装からの呼び出しをマーシャリングするようになりました。
XPConnectはJavaに依存していません。ただし、その技術はXPCOMに基づいています。そのため、プラグイン開発者はスクリプトを実装するために、参照カウント、インターフェース、およびIDLに精通している必要があります。XPCOMへの依存により、動的リンクに関するいくつかの問題(例えば、脆弱な基底クラスの問題)が発生し、プラグインがさまざまなブラウザで正しく動作するようにするには、これらの問題を解決する必要がありました。その後、XPCOMはこれらの問題に対処するために、静的リンク版を提供するように変更されました。このアプローチでは、動的リンクライブラリ(DLL)の隣に.xptファイルをインストールする必要があります。そうしないと、プラグインは動作しているように見えますが、スクリプトが動作せず、混乱を招きます。
2004年末、NPAPIを使用している主要なブラウザ企業はすべて、オリジナルのNPAPIの拡張機能としてNPRuntime [ 9 ]に合意しました。これは、古いCスタイルのNPAPIに似たスタイルのAPIを介してスクリプト機能を提供し、JavaやXPCOMなどの他のブラウザ技術とは独立しています。これはFirefox ESR(Extended Support Release)とSafariのみでサポートされています。
API の古さ、セキュリティ上の問題、HTML5などの代替技術の採用により、多くのソフトウェアベンダーは 2013 年に NPAPI のサポートを段階的に廃止し始めました。[ 10 ] [ 11 ]
Internet Explorerバージョン 3 から 5.5 SP2 までは NPAPI をサポートしており、Netscape Navigator で動作するプラグインを Internet Explorer で動作させることができました。サポートは、 ActiveX と NPAPI プラグインの間のシムとして機能する小さなActiveXコントロール (" plugin.ocx" という名前)を介して提供されました。Microsoft は、セキュリティ上の理由からバージョン 5.5 SP2 以降でサポートを終了しました。[ 12 ] [ 13 ] [ 14 ] [ 15 ]
Google Chrome は2015 年 9 月にすべてのプラットフォームで NPAPI のサポートを完全に終了しました。[ 16 ] 2013 年 9 月に、Google は Google Chrome ブラウザで NPAPI のサポートを 2014 年中に段階的に終了すると発表し、「その 90 年代のアーキテクチャがハング、クラッシュ、セキュリティ インシデント、コードの複雑さの主な原因となっている」と述べています。[ 17 ] [ 18 ] 2014 年 5 月に、 Linux版 Chrome 35 以降から NPAPI のサポートが削除されました。 [ 19 ] 2015 年 4 月に、 WindowsおよびOS X版Chrome (バージョン 42 以降) でデフォルトで NPAPI のサポートが無効になりました。ただし、2015 年 9 月 (バージョン 45) までは、ユーザーは NPAPI を再度有効にすることができました。
Operaは2016年5月にバージョン37でサポートを終了しました。
Mozilla Firefoxリリース 52.0 (2017 年 3 月) では、Flash を除く NPAPI のサポートがすべて削除されました。[ 20 ] [ 21 ] [ 22 ]一方、ESR チャネルでは、バージョン 52 ESR が NPAPI の最後の手段となり、この機能の一般的なサポートが維持されました。Firefox 69.0 では、Flash NPAPI がデフォルトで無効になりました。[ 23 ] [ 24 ] 2021 年 1 月にリリースされた Firefox 85.0 では、NPAPI のサポートが完全に削除されました。[ 25 ] [ 26 ] ESR チャネルでは、Flash NPAPI のサポートは、2021 年 10 月にリリースされたバージョン 78.15.0 で終了しました。[ 27 ] [ 28 ]
Safariは、2018年9月にリリースされたバージョン12でFlashを除くすべてのNPAPIプラグインのサポートを終了しました。[ 29 ] Flashのサポートは、2020年9月にリリースされたSafari 14から削除されました。[ 30 ]
SeaMonkey [ 31 ] は、Flash を除いて、バージョン 2.53.1 から NPAPI プラグインのサポートを終了しました。NPAPI のサポートは、2021 年 3 月にリリースされた SeaMonkey 2.53.7 で完全に削除されました。[ 32 ]
以下のウェブブラウザは、すべてのNPAPIプラグインをサポートしています。
Internet Explorer およびInternet Explorer をベースにしたブラウザーは、ActiveX コントロール、ActiveX ドキュメント、および ActiveX スクリプトを使用して、NPAPI と同等のページ内拡張性を提供します。ActiveX は一般的に Internet Explorer に関連付けられていますが、このような統合をサポートする他のコンピューター プログラムの一部を統合できるようにする統合テクノロジーです。[ 40 ]ただし、Internet Explorer はサポートが終了しており、後継の Microsoft Edge は ActiveX をサポートしていません。
2009年8月12日、Google Codeのページ[ 41 ]で、Pepperという新しいプロジェクトと、それに関連するPepperプラグインAPI(PPAPI)[ 42 ]が紹介されました。PPAPIは、プラグインの移植性とセキュリティを向上させることを目的としたNPAPIの派生版です。[ 43 ]この拡張機能は、プロセス外でのプラグイン実行の実装を容易にするために特別に設計されています。
PPAPIは当初、Google ChromeとChromiumのみでサポートされていました。その後、 OperaやVivaldiといった他のChromiumベースのブラウザもPPAPIプラグインのサポートを追加しました。
2012年2月、Adobe Systemsは、将来のLinux版Adobe Flash PlayerはPPAPI経由でのみ提供されると発表した。NPAPIをサポートする以前のリリースであるFlash Player 11.2は、5年間セキュリティアップデートを受け取ることになった。[ 44 ] 2016年8月、Adobeは、以前の声明とは異なり、Linux上でNPAPI Flash Playerを再びサポートし、新しいバージョンをリリースし続けると発表した。[ 45 ]
2020年8月、GoogleはPPAPIのサポートを2022年6月にGoogle ChromeとChromiumから削除すると発表した。[ 46 ]
ブレンダン・アイクがLex Fridman Podcastで述べた通り。