同一サイト環境間での WebAssembly モジュールの共有は、同一オリジンのみに制限されます。
エージェント クラスタのスコープをオリジンに長期的に設定できるようにするため、同一サイトとクロスオリジンの環境間で WebAssembly（Wasm）モジュールを共有することは非推奨になります。この方法で Wasm モジュールを使用しているデベロッパーは、Chrome 95 以降を引き続き使用するために、モジュールを同じオリジンでインスタンス化する必要があります。
Wasm モジュールの概要とその仕組み
WebAssembly プログラムは、デプロイ、読み込み、コンパイルの単位であるモジュールに編成されています。
次のサンプルコードでは、https://iframe.site.example からインポートされた Wasm モジュールが、postMessage() を介して https://main.site.example と共有されます。これらのドメインは同一サイトのクロスオリジンです。
https://iframe.site.example の Wasm モジュール:
(async () => {
const instance = await WebAssembly.instantiateStreaming(fetch('./add.wasm'), {});
iframe.contentWindow.postMessage(instance.module, `https://main.site.example`);
})();
Chrome 95 以降では、センダーとレシーバーは同じオリジンである必要があります。上記のケースでは、https://iframe.site.example を https://main.site.example にするか、その逆にする必要があります。
これが必要な理由
Chrome はこれまで、サイトキー エージェント クラスタのさまざまなドキュメント、タブ、フレームを内部で処理してきました。つまり、同一サイトのドキュメントは同じプロセスで処理されます（この動作はブラウザによって異なります）。最近、Chrome では、オリジンというより詳細な単位でこうした処理を行うようになりました。Google では、これをオリジンキー エージェント クラスタと呼びます。ただし、この方法ではリソースを大量に消費するため、オリジンキー エージェント クラスタはヒューリスティックに基づいて限られたウェブサイトのみに適用されていました。
計画では、すべてのエージェント クラスタをデフォルトでオリジンキーにする予定です。これを実現するには、サイトキー送信元クラスタを必要とする機能を制限する必要があります。
- （Chrome のみ）
SharedArrayBufferオブジェクトまたはWebAssembly.Memoryオブジェクトを他の同一サイトのクロスオリジン ページに送信できなくなりました。この機能は Chrome 92 以降ですでに実装されています。 postMessage()を使用してWebAssembly.Moduleオブジェクトを他の同一サイトのクロスオリジン ページに送信することはできなくなりました。この変更について、以下で詳しく説明します。document.domainは設定できなくなりました。これは以前の機能であり、通常は同一サイトのクロスオリジン ページが互いの DOM に同期的にアクセスできるようにしていますが、オリジンキー エージェント クラスタでは無効になっています。
上記のすべての変更に対処することで、Chrome はデフォルトでオリジンキー エージェント クラスタを使用するように移行します。
オリジンキー エージェント クラスタの詳細については、Origin-Agent-Cluster ヘッダーを使用したパフォーマンス分離のリクエストをご覧ください。
次のステップとリソース
Chrome をデフォルトでオリジンキー エージェント クラスタと連携させるために、document.domain を読み取り専用にします。Chrome チームは 2022 年に
この変更を適用する予定です
写真撮影: Markus Winkler、Unsplash