その初めての発表から約1年経った後、Googleは、Webブラウザからネイティブコードを安全に実行することができるようにするNative Client （NaCl） SDKの新バージョンをリリースした。とはいえ、この野心的なプロジェクトが製品にまで到達するのか、はたまたWaveやGearsのような他のプロジェクトと同じ運命を持っているのかは不透明である。
新しいSDKの特徴は、Chromeの新しいプラグインインターフェース（Pepper）、よりよいセキュリティ、その他の改善のサポートにある。
今回SDKは、演算、オーディオ、2Dネイティブクライアントのモジュールに対するPepperインターフェースの広範囲なサポートを含んでいます。これらのインターフェースはリリースノートにリストアップされているいくつかの重要な例外を除いて、かなり安定に近づいています。
加えて、私たちはセキュリティの改善に焦点を絞ってきました。自動更新と外部サンドボックスを有効化しています。これにより、私たちが以前の調査目的のリリースで採用していた使用期限とローカルホストセキュリティ制限を取り除くことができました。セキュリティ以外にも、私たちは対象となるマシンの命令セットアーキテクチャに基づいてNative Clientモジュールを取得するためのメカニズムも改善し、開発者はこのことについてこれ以上気にかける必要がなくなります。
Native Clientの起源はRobert Wahbe氏などによる“ソフトウェアをベースとした効果的な障害分離（Efficient software-based fault isolation）”にまでさかのぼる。
協調するソフトウェアモジュールの間に障害分離を提供する1つの方法はそれぞれを独自のアドレス空間に配置することである。しかしながら、密結合したモジュールに対しては、この解決策は法外なコンテキストスイッチのオーバーヘッドを引き起こす。この論文では、障害分離を単一のアドレス空間に実装するソフトウェア手法を提示する。私たちの手法は2つの部分に分かれる。最初に、信頼できないモジュールのコードとデータをフォルトドメイン（fault domain）、すなわち論理的に分離されたアプリケーションのアドレス空間の一部、にロードする。次に、信頼できないモジュールのオブジェクトコードをそのフォルトドメインの外に書き込んだりジャンプしたりすることができないように書き換える。これらのソフトウェア操作は移植性が高く、プログラミング言語に依存しない。私たちの手法はハードウェアによる障害分離に関連したトレードオフを引き起こす：信頼できないモジュールの実行時間のわずかな増加というコストによる、フォルトドメイン間の非常に高速な通信である。私たちは、頻繁に通信するモジュールに対しては障害分離をハードウェアではなくソフトウェアで実装する方が全体のアプリケーションパフォーマンスを大きく改善しうることをデモンストレーションする。
今回のNaClのリリースには次のような制限がある。
- MacではSnow Leopardが必要となり、
- Windows XP 64-bitシステムでは動作せず、
- すべてのLinuxディストリビューションでは利用できず、
- すべての利用可能なPepper関数はPepper/Javascriptのメイン実行スレッドから呼び出されなければならない。これまでのChromeプラグインはプロセスの外でのみ実行されるが、Pepperプラグインはプロセス内でのみ実行され、将来的にはPepperプラグインはNacl内でのみサポートされる。
- 3Dグラフィックス、ファイルIO、P2Pネットワークはサポートせず、
- カメラやマイクのようなデバイスのサポートもない。
NaClを試してみたいなら、最初にabout:flags設定ページでChrome バージョン10上で有効化し、ビルトインPython HTTPサーバを利用する必要がある。
Mono開発者もNative Clientをすぐに対象にすることができる:
Native ClientのサポートによってMono仮想マシンはガベージコレクター、ジャストインタイム（Just-in-Time）コンパイラをNative Clientサンドボックス内部で利用することができます。
GoogleはNative ClientエンジンにJITのサポートを追加し、Native Clientを利用する際の大きな柔軟性をユーザに提供します。これまでは、Native Clientは静的にコンパイルされたコードを実行するよう制限されていましたが（AOTモードのMono）、これによって興味深いシナリオ、System.Reflection.Emit、スクリプト言語、それ以外の動的なケースが動かなくなっていました。私たちはGoogleの仕事とElijah氏のこの領域への貢献に信じられないくらいの興奮を覚えています。
同様に、Qt開発者はNaClをQtベースUIを展開するために利用する方法を調査することに興味があるかもしれない。
サンドボックス化されたIntelのx86ネイティブコードをブラウザにもたらすというNative Clientのミッションは非常に野心的であり、コミュニティがGoogleが実際にうまくやってのけることができるかどうか疑うのも不公平な話ではない。
あなたはこれが今のように真剣に取り組まれ続け、Waveのようにはプラグを引き抜かれることはないと保証できますか？
Waveの中止の他にも、非常に評価が高く、Googleやサードパーティの両方から注目されるような展開もいくつかあったにもかかわらず同じくGoogleが中止したGearsプロジェクトについて思い出すものもいるだろう。特に、リレーショナルブラウザストレージを目的としたGearsの一部は同様に最近HTML5仕様としてもW3Cによって打ち切られている。
このような実績があるが、あなたはGoogleがNative Clientを最後の段階まで到達させると考えるだろうか？