Loading article…
| Googleネイティブクライアント | |
|---|---|
| 開発者 | Google、その他 |
| リリース | 2011年9月16日 （2011-09-16）[ 1 ] |
| 安定放出 | |
| 執筆 | C、C++ |
| オペレーティング·システム | Windows、Linux、macOS、ChromeOS |
| プラットフォーム | x86、ARM、MIPS |
| 後継 | WebAssembly |
| タイプ | ネイティブコード用のWebブラウザのサンドボックス |
| ライセンス | 新しいBSD |
| Webサイト | developer.chrome.com/docs/native-client/ |
| リポジトリ |
|
Google Native Client ( NaCl ) は、 Intel x86、ARM、またはMIPSネイティブ コードの一部、またはポータブル実行可能ファイルをサンドボックス内で実行するための、現在は廃止されたサンドボックス技術です。Google Chromeやその他のChromiumベースのWeb ブラウザは、 NaCl を組み込んで、 Web アプリやブラウザ拡張機能内でネイティブ コードを安全に実行し、ユーザーのオペレーティングシステムにほとんど依存せず、ネイティブに近い速度で実行できるようにしていました。この機能は、Google がChromeOSを汎用コンピューティング プラットフォームとして計画する上で不可欠でした。NaCl は、 Adobe Flash Playerなどのブラウザプラグインや、 ZeroVMなどの他のアプリケーションの一部または完全なアプリケーション[ 2 ]を保護するためにも使用されていました。[ 3 ]
NaCl（Webブラウザでネイティブコードを実行する）の基本的な概念は、以前からActiveXで実装されていましたが、NaClはコンテンツをサンドボックス内で実行するのに対し、ActiveXアプリケーションはシステム（ディスク、メモリ、ユーザーインターフェース、レジストリなど）へのフルアクセス権限を持っています。Mozillaは、ActiveXとNaClの両方の代替としてasm.jsを提案しました。asm.jsは、 CまたはC++で記述されたアプリケーションをコンパイルしてブラウザで実行できるようにするだけでなく、事前コンパイルもサポートしていますが、JavaScriptのサブセットであるため、直接サポートしていないブラウザとの下位互換性があります。
2016 年、Google は Pepper と Native Client の機能開発の優先順位を下げました。2017 年 5 月 30 日、Google はWebAssemblyを優先して PNaCl の非推奨化を発表しました。[ 4 ] [ 5 ]その後数年間、Google Chrome はさまざまなプラットフォームで NaCl を徐々に非推奨化し、削除しました。ChromeOS バージョン 138 は、2025 年 7 月の ChromeOS 139 のリリースで Native Client のサポートが終了するまで、Native Client をサポートする最後の Google プラットフォームおよびバージョンとなりました。[ 6 ] [ 7 ] [ 8 ]
Native Client はGoogleが開発したオープンソースプロジェクトです。[ 9 ] Quake 、[ 10 ] XaoS、Battle for Wesnoth、[ 11 ] Doom、[ 12 ] Lara Croft and the Guardian of Light、[ 13 ] From Dust、[ 14 ] MAMEなどのゲームや、サウンド処理システムCsoundが Native Client に移植されています。Native Client は、 Google Chromeウェブ ブラウザのバージョン 14 から利用可能で、Portable Native Client (PNaCl、発音: pinnacle) がリリースされたバージョン 31 以降はデフォルトで有効になっています。[ 15 ] [ 16 ] [ 17 ] Native Client は、Dæmon ゲーム エンジンなど、ウェブ ブラウザ以外のソフトウェアでダウンロードしたコードを安全に実行するためにも使用されています。[ 18 ]
ARM実装は2010年3月にリリースされた。[ 19 ] x86-64、 IA -32、MIPSもサポートされた。
PNaCl でアプリケーションを移植可能に実行するには、 LLVM中間表現バイトコードのアーキテクチャ非依存かつ安定したサブセットにコンパイルする必要があります。[ 20 ]実行可能ファイルは PNaCl 実行可能ファイル (pexe) と呼ばれます。PNaCl ツールチェーンは .pexe ファイルを作成し、NaCl ツールチェーンは .nexe ファイルを作成します。.nexeファイルのマジックナンバーは 0x7F 'E' 'L' 'F' で、これはELFです。Chrome では、実行できるようにアーキテクチャ固有の実行可能ファイルに変換されます。
NaCl は、x86-64 および ARM 上でのサンドボックス化にソフトウェア障害検出および分離を使用します。[ 21 ] Native Client の x86-32 実装は、x86 アーキテクチャのあまり使用されていないセグメンテーション機能を利用する斬新なサンドボックス化手法で注目に値します。 [ 22 ] Native Client は、サンドボックス化されたコードがアクセスできるメモリ範囲を制限するために x86 セグメントを設定します。システムコールを実行する命令などの安全でない命令の使用を防ぐために、コード検証器を使用します。コードが安全な命令の途中に隠された安全でない命令にジャンプするのを防ぐために、Native Client は、すべての間接ジャンプが 32 バイト境界に揃ったブロックの先頭へのジャンプであることを要求し、命令がこれらのブロックをまたぐことは許可されていません。[ 22 ]これらの制約のため、C および C++ コードは Native Client で実行するために再コンパイルする必要があり、Native Client は、 GNU ツールチェーンのカスタマイズされたバージョン、具体的にはGNU Compiler Collection (GCC)、GNU Binutils、およびLLVM を提供します。
Native ClientはBSDスタイルのライセンスに基づいてライセンスされています。
Native Client はC ライブラリとしてNewlib を使用していますが、 GNU C ライブラリ(GNU libc)の移植版も利用可能です。[ 23 ]
2008年12月8日、GoogleはGoogle Chromeの9月の発表直後にNative Clientを一般に公開した。[ 24 ] NaClは2011年9月に安定版Chromeとしてリリースされた際に、ウェブ上で一般に利用可能になった。[ 1 ]
2011 年 12 月 9 日、Google は、リッチでプロセッサ負荷の高いグラフィックで知られるゲームの Chrome 専用バージョンをいくつか発表し、この技術の準備が整っていることを示しました。これにはBastion ( Chrome Web ストアではサポートされなくなりました) も含まれます。NaCl は、ハードウェア アクセラレーションされた3D グラフィックス ( OpenGL ES 2.0経由)、サンドボックス化されたローカル ファイル ストレージ、動的ロード、フルスクリーン モード、マウスキャプチャを実行します。NaCl をハンドヘルド デバイスでも利用できるようにする計画もありました。[ 25 ] [ 26 ]
2013年にGoogleは、 NaClのアーキテクチャ非依存の事前コンパイル版であるPortable Native Client（PNaCl）を発表しました。 [ 27 ] Portable Native Client（PNaCl）はアーキテクチャ非依存のバージョンです。PNaClアプリは事前にコンパイルされます。ほとんどのユースケースではNaClよりもPNaClが推奨されます。[ 28 ] NaClの一般的な概念（Webブラウザーでネイティブコードを実行する）は、 ActiveXで以前に実装されていましたが、ActiveXは現在も使用されていますが、システム（ディスク、メモリ、ユーザーインターフェイス、レジストリなど）へのフルアクセス権限を持っています。Native Clientは、サンドボックスを使用することでこの問題を回避します。
Mozillaが提案した代替案はasm.jsで、これもCやC++で書かれたアプリケーションをブラウザで実行できるようにコンパイルすることを可能にし、事前コンパイルもサポートしているが、JavaScriptのサブセットであるため、直接サポートしていないブラウザとの下位互換性がある。
2016 年 10 月 12 日、Chromium の課題追跡ツールへのコメントで、Google の Pepper および Native Client チームの人員が削減されたことが示されました。[ 29 ] 2017 年 5 月 30 日、Google はWebAssemblyを優先して PNaCl の非推奨化を発表しました。[ 4 ] [ 5 ]当初、Google は PNaCl を 2018 年の第 1 四半期に削除する予定でしたが、[ 4 ]その後 2019 年の第 2 四半期に削除する予定でしたが、[ 30 ] 2022 年 6 月に ( Chrome Appsと共に) 削除されました。[ 31 ] [ 32 ] ChromeOS でのサポートは ChromeOS 138 まで続き、Native Client のサポートが終了し、2025 年 7 月に ChromeOS 139 がリリースされたことで終了しました。[ 6 ] [ 7 ] [ 8 ]
2026年2月にリリースされたLLVM 22は、NaClバイナリのビルドのサポートを失った最初のバージョンとなった。[ 33 ]
NaCl は塩化ナトリウム、一般的な食塩を意味します。言葉遊びとして、コショウの名前も使用されました。Pepper API は、Native Client モジュールを作成するためのクロスプラットフォームのオープンソース API です。[ 34 ] Pepper Plugin API、または PPAPI [ 35 ] [ 36 ]は、Native Client で保護された Web ブラウザ プラグイン用のクロスプラットフォーム API で、最初は Netscape のNPAPIに基づいていましたが、その後ゼロから書き直されました。これは Chromium とGoogle Chromeで、 Adobe Flash [ 37 ]の PPAPI バージョンと組み込みのPDFビューア[ 38 ]を有効にするために使用されました。
2009年8月12日、Google Codeのページで、新しいプロジェクトPepperと、それに関連するPepper Plugin API（PPAPI）[ 39 ]が紹介されました。PPAPIは「プラグインの移植性とセキュリティを向上させるためのNPAPIへの一連の変更」です。[ 40 ]この拡張機能は、プロセス外でのプラグイン実行の実装を容易にするために特別に設計されています。さらに、このプロジェクトの目標は、プラグインを完全にクロスプラットフォームにするためのフレームワークを提供することです。検討されたトピックには、次のものがあります。
Pepper APIはゲームパッド（バージョン19）とWebSocket（バージョン18）もサポートしています。[ 41 ]
2010年5月13日現在 GoogleのオープンソースブラウザであるChromiumは、新しいブラウザプラグインモデルを採用した唯一のウェブブラウザでした。[ 42 ] 2020年現在、PepperはChrome、Chromium、OperaやMicrosoft EdgeなどのBlinkレイアウトエンジンベースのブラウザでサポートされています。
2020年8月、GoogleはPPAPIのサポートを2022年6月にGoogle ChromeとChromiumから削除すると発表した。[ 43 ]
Firefox の開発者は 2014 年に、Pepper の API の完全な仕様が Chrome での実装以外に存在せず、Chrome 自体もBlink レイアウト エンジンでのみ使用するように設計されており、Flash Player プラグインに固有のプライベート API があり、ドキュメント化されていないため、Pepper をサポートしないと表明しました。[ 44 ] 2016 年 10 月、Mozilla は、Pepper API と PDFium を Firefox の将来のリリースに組み込むかどうかを再検討し、検討していると発表しましたが、[ 45 ]そのような措置は取られませんでした。2017 年 7 月、Adobe は Flash を非推奨とし、2020 年末にサポートを終了すると発表しました。 [ 46 ] 2021 年 1 月までに、Adobe Flash Player、Google Chrome、Firefox、Safari、および Windows [ 47 ]は、 Flash を無効にするか完全に削除するアップデートを受け取りました。
あるウェブサイト[ 48 ]は、サーバー上でNaClを使用して、ユーザーがブラウザからGoプログラミング言語を試せるようにした。 [ 49 ]
オープンソースのUnvanquishedゲームは、Q3VM（Quake III仮想マシン）の代わりに、Dæmonゲームエンジン[ 50 ]でNative Clientを使用しています。 [ 51 ] [ 52 ]このようなゲームエンジンでは、Native Clientサンドボックスを使用して、ゲームサーバーからダウンロードした任意のゲームコード（mod）を安全に実行します。Native Clientテクノロジーを使用すると、ゲームプレイ開発者は、仮想マシンで実行されるゲームにC++言語を使用したり、C++ライブラリを使用したり、ゲームとエンジン間でコードを共有したり、Q3VMよりも優れたパフォーマンスを得ることができます。[ 18 ]
ブラウザ開発者グループの中には、ネイティブクライアント技術を支持したグループもあれば、支持しなかったグループもあった。
IMVUのチャド・オースティンは、ネイティブクライアントが（ネイティブコードと比較して約5%のペナルティで）高性能アプリケーションを安全な方法でウェブにもたらすことができる点を高く評価し、さらに（JavaScript以外の）プログラミング言語の選択肢を提供することでクライアントサイドアプリケーションの進化を加速させている点も評価した。[ 53 ]
Id SoftwareのJohn D. CarmackはQuakeCon 2012でNative Clientを称賛し、「ブラウザ内で何かをする必要がある場合、Native Clientは、ユーザーモードでこれらすべてを興味深い方法でサンドボックス化できるという、非常に巧妙なx86ハックとして始まったため、はるかに興味深いものになります。現在は動的再コンパイルですが、CまたはC++でプログラムすると、完全にネイティブコードである-O4最適化レベルではありませんが、ネイティブコードに非常に近いものにコンパイルされます。悪質なポインタ追跡や、メタルまでゲーム開発者としてやりたいことは何でもできます。」と述べています。[ 54 ]
他のIT専門家は、このサンドボックス技術には重大な、あるいは実質的な相互運用性の問題があったため、より批判的だった。
Mozillaの製品担当副社長であるジェイ・サリバン氏は、ブラウザ内でネイティブコードを実行する計画はないと述べ、「これらのネイティブアプリは、ウェブページ内の小さなブラックボックスに過ぎません。[...] 私たちはHTMLを本当に信じており、ここに注力したいと考えています。」[ 55 ]
Mozillaのクリストファー・ブリザードはNaClを批判し、ネイティブコードはソースコード駆動のウェブと同じように進化することはできないと主張した。彼はまた、NaClをDLL地獄に悩まされているMicrosoftのActiveXテクノロジーと比較した。[ 2 ]
OperaのCTOであるHåkon Wium Lie氏は、「NaClは『ウェブ以前の悪い時代を懐かしんでいる』ように見える」とし、「Native Clientは新しいプラットフォームを構築するか、古いプラットフォームをウェブに移植することであり、複雑さやセキュリティの問題を引き起こし、ウェブプラットフォームから注意をそらすことになる」と述べた。[ 2 ]
Googleで開発された第2世代のサンドボックスはgVisorです。[ 56 ] [ 57 ]これはGoogle Cloud、より正確にはGoogle App EngineのNaClを置き換えることを目的としています。GoogleはWebAssemblyも推進しています。[ 58 ]
138は、ChromeOSにおけるNaClテクノロジーのサポート終了を意味します。
ネイティブ クライアント (NaCl) の非推奨化
Native Client (NaCl) の非推奨化
ゲームプレイ開発者は仮想マシン内で最新の C++ および C/C++ ライブラリを直接使用でき、エンジンコードとゲームロジック間のコード共有が向上します。また、PNaCl はオリジナルの Quake III 仮想マシンよりも優れたパフォーマンスを提供すると報告されています。
彼らはオープンソースのゲームとデーモンエンジンの開発を継続している。 […] libRocket の実装は NaCl VM に移行した。
Quake III QVM を置き換えるために Google の Portable Native Client (PNaCl) を使用するサポートの作業を続けています。
内部的には、ゲーム ロジックを QVM から Portable Native Client (PNaCl) に移植する作業が引き続き精力的に行われている。
代替として、Googleは現在WebAssemblyを推進している。