Mozillaは先頃、あらゆるデバイス、マシン、オペレーティングシステムで同じWebAssemblyコードを実行することを目的とした、新たな標準化の取り組みを発表した。新標準のWebAssembly System Interface（WASI）では、複数の実際のオペレーティングシステムで実装可能な、概念的な単一のオペレーティングシステムインターフェイスを定義する。Javaのような従来の"Run Anywhere"の取り組みとは異なり、WASIは、ブラウザベンダとチップやデバイス、コンピュータ、オペレーティングシステムの製造業者という、これまでにないコラボレーションによって生み出された、特許フリーのオープンスタンダードであるWebAsemblyの上に構築されている。WASI標準は、標準インタフェースのモジュールセットを通じたWebAssemblyの移植性とセキュリティの提供と、エコシステムのための堅牢な基盤の提供を目標とする。MozillaとFastlyがすでに、WASI実装のプロトタイプを提供している。
WASIが目指すのは、WebAssemblyプラットフォーム（現在主要な４ブラウザエンジンによって実装されている）のシステムインタフェースになることだ。WebAssembly(Wasm)は、それ自体を"スタックベースの仮想マシン用のバイナリ命令フォーマット"であると定義して、"広範なプラットフォームで利用可能な共通ハードウェア機能を利用することによる、ネイティブスピードの実行"を目標に設計されている。WasmはC、C++、Rustといった高級言語のコンパイルターゲットとして使用される。WebAssemblyはOpen Web上での動作を中心に設計されていたが、Mozillaは現在、その範囲をWeb埋め込み以外の、"テスト用の最小限のシェルから、データセンラのサーバ上やIoTデバイス上、あるいはモバイル/デスクトップアプリといった本格的なアプリケーション環境まで"拡張しようとしている。Lin Clark氏の見解によれば、
ブラウザ外のコードには、システムと対話する手段、すなわちシステムインターフェースが必要です。WebAssemblyプラットフォームには、まだそれがありません。
WASIの標榜する目標は、Javaの最初の約束である"Write Once, Run Anywhere"に通じるものがある。Java Virtual Machine(JVM)は確かにこれと同じような目的を持っており、WebAssemblyプラットフォームが提供するものと同じような言語の柔軟性が、GraalVMを通じてJavaで実現されている。しかしながら、Javaはデファクト標準に留まっている上に、所有者であるOracleは、GoogleがJavaのAPIを違法に使用しているとして訴訟を起こしており、現在も係争中である。対照的にWebAssemblyは、Microsoft、Google、Apple、Mozilla、Intel、Samsungなどのブラウザベンダや主要企業による前例のないコラボレーションなのだ。Jay Phelps氏は2018年のQCon San Franciscoで、次の点を強調している。
（...）このような企業が集結しました。最初の標準化バイトコードは、これら業界の主要企業がすべて参加して開発されたのです。すべて無償です。プロプライエタリなプログラムではありません。疑問の余地なく、完全にオープンです。特許法や、それに類するものに妨げられることはまったくないのです。
さらにWasmはメモリセーフであり、バリデーションを備えているため、Javaに対してセキュリティ上のメリットがあると考えられる。Till Schneidereit氏はさらなる意見で、Wasmを支持している。
(...) WebAssemblyは、小規模デバイスから大規模なサーバーファームやCDNにまで拡張できるように設計されています。 Javaよりも言語非依存であり、実装上のフットプリントもはるかに小さいのです。
WASIは、システム機能の抽象化を基盤として、複数のシステムに対する共通インタフェースを規定することによって、移植性のあるバイナリを実現しようとしている。このような抽象化はモジュールにまとめられており、wasi-coreが中核的な役目を担っている。Lin Clark氏が詳しく説明する。
wasi-coreには、すべてのプログラムに必要な基本部分が含まれていて、ファイルやネットワーク接続、クロック、乱数など、POSIXと同じ分野の大半をカバーしています。
その他の3Dグラフィックスやスマートコントラクトといった機能は、専用のモジュールを用意して対処することになる。標準化の活動は、WebAssemblyのパフォーマンス上の目標を維持しつつ、数多くのオペレーティングシステムとアーキテクチャに対応するために、システム機能の抽象化を慎重に規定することを目標としている。
WASIは、機能ベースのセキュリティモデルを採用することによって、Wasmのセキュリティ面に目を向けている。WASIアプリケーションには、リソースに対する適切なアクセス権を指定しない、(ファイルパスのような)偽造可能なリファレンスに代えて、ケーパビリティによるリソース識別機能が提供される。偽造可能なリファレンスでは、オペレーティングシステムによる、要求したプログラムの周囲権限(ambient authority)に基づく検証の実施が必須となる。Lin Clark氏は、WASIアプリケーションがファイルをオープンする権限を事前に付与されている場合にのみ、そのファイルをオープンできる方法について説明する。
（...）
/etc/passwdを適当に開くことはできません。プログラムが操作できるのは、それに渡されたディレクトリに限定されます。(...) そのためにランタイムは、アプリが操作可能なファイルディスクリプタをトップレベルのコードに渡します。そのファイルディスクリプタが、必要に応じてシステムの他の部分に伝搬されるのです。
WASI対応アプリケーションは、現時点ではpolyfillを備えたブラウザ内か、あるいはMozillaのWasmtimeまたはFastlyのLucetを使ってブラウザ外で動作可能である。
WASIは現在開発中である。Lin Clark氏は次のように振り返る。
しかしながら、wasi-codeが完全に標準化された後に対処しなければならない、次のような問題が残っています。
- 非同期I/O
- ファイル監視
- ファイルロック
リスクは高い。Dockerの共同設立者であるSolomon Hikes氏は言う。
WASM+WASIが2008年に存在していれば、Dockerを開発する必要はありませんでした。それほど重要なものなのです。サーバにおけるWebassemblyは、コンピューティングの未来です。標準化されたシステムインターフェースはミッシングリンク(missing link)でした。WASIがその役割を果たすことを期待しましょう！