XaxとNaCl

バタバタしてて読んでなかったCommunications of the ACMの2009年7月号（Vol. 52, No. 07）を見ると，マイクロソフトのXaxとGoogleのNaCl(Native Client)の記事が載っていました．
Toward Native Web Execution | July 2009 | Communications of the ACM

For years, the Netscape plug-in API and Microsoft's ActiveX have provided a way to use native code modules as part of a Web application. Along with enhanced browser functionality, these extension technologies provide full access to the OS's file and networking interfaces. But by relying on trust rather than strong technical measures for safety, these extension technologies are vulnerable to social-engineering attacks in which users are tricked into permitting malicious operations.

One software project that challenges this trust model yet still offers native performance is Xax, developed at Microsoft Research. Xax separates native instruction execution from native OS access, leveraging legacy code to deliver desktop applications on the Web. （中略）

"Rather than use a language-based isolation mechanism, why not instead use the well-evolved and ubiquitous memory management unit?" asks researcher Jon Howell, who developed Xax at Microsoft Research.
（中略）
In contrast to Xax, which relies on the memory management unit for memory isolation and a kernel system-call patch to prevent OS access, Google's Native Client takes a different approach. Using an OS-portable sandbox, Native Client relies on x86 segmentation hardware to enforce memory isolation and on a binary validator to isolate the OS interface, preventing direct access to the OS and resources such as the file system and the network.

適当な訳

もう何年も，NetscapeプラグインAPIとマイクロソフトActiveXは，Webアプリケーションの一部としてネイティブ・コードを実行可能にさせる方法を提供してきました． ブラウザの機能を拡張することによって，これらの拡張技術はOSのファイルやネットワークインターフェースへのフルアクセスを提供してきました．しかし，安全性に対する強力な技術対策よりも「信頼」に頼ることになった結果，このような拡張技術は，巧妙にユーザにファイルアクセスの許可を求めるようないわゆる「ソーシャル・エンジニアリング」攻撃に対し脆弱になっています．

ネイティブ・パフォーマンスを求めるために，敢えてこのような信頼モデルに基づくソフトウェアプロジェクトの一つが，マイクロソフト社によるXaxです．Xaxは，「Web上のデスクトップアプリケーション」の元々のコードに対し修正を加えることで，ネイティブな実行コードを，ネイティブなOSへのアクセスから分離します．

マイクロソフト研究所でXaxを開発した研究者ジョン・ハウエルは，「そのプログラミング言語の仕様に基づく隔離機構を使うよりも，むしろより改善されていて，汎用的に使えるメモリ管理機構を使うべきじゃありませんか？」と問う．
（中略）
Xaxに対し，OSへのアクセスを分離するために，メモリ隔離機能を有するメモリ管理機構とカーネルのシシテムコールのパッチを用いるGoogle Native Clientは異なるアプローチであると言える．
OSに依存しないサンドボックス機構によって，Native Clientは，OS・ファイルシステムやネットワーク資源への直接的なアクセスを避けるために，x86 CPU機能のメモリ分離やOSインターフェースを隔離するローレベルチェック機能を利用する．

訳が分かりにくくてすみません．
引用しなかった記事文章にもあるのですが，結局のところ，両者は似てると言えそうです．

あえて例えると，片方がVMware的で，片方がXen的というような違いのようです．
記事を読むと，XaxがVMware的でGoogle Native Client(NaCl)がXen的なようにも見えますが，逆なのかもしれません．使ってみないと，もしくはコードを見てみないと，完全には理解出来ないです．
ただ，面白そうなのは確かで，ブラウザとOSの融合に向かいざるを得ないでいるマイクロソフト社とGoogle社が，間違いなく強力に推進していく技術だろうと思われます．