同一サイト環境間での 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 ではよりきめ細かい単位（オリジン）で処理を開始しました。これをオリジンキー エージェント クラスタと呼びます。ただし、この方法はリソースを大量に消費するため、オリジンキーによるエージェント クラスタは、限定されたウェブサイトにのみヒューリスティクスで適用されていました。
すべてのエージェント クラスタをデフォルトでオリジンキーにすることを計画しています。これを実現するには、サイトキーによる送信元クラスタを必要とする機能を制限する必要があります。
- （Chrome のみ）
SharedArrayBufferオブジェクトまたはWebAssembly.Memoryオブジェクトを、同一サイトのクロスオリジンの他のページに送信できなくなりました。これは Chrome 92 以降にすでに導入されています。 postMessage()を介して、同じサイトのクロスオリジン ページにWebAssembly.Moduleオブジェクトを送信することはできなくなりました。この変更について、以下で詳しく説明します。document.domainを設定できなくなりました。これは従来の機能で、通常は同一サイトのクロスオリジン ページが互いの DOM に同期的にアクセスできるようにしますが、オリジンキー エージェント クラスタでは無効になります。
上記の変更をすべて対応することで、Chrome はデフォルトでオリジンキー付きエージェント クラスタを使用するようになります。
オリジンキー エージェント クラスタの詳細については、Origin-Agent-Cluster ヘッダーを使用してパフォーマンスの分離をリクエストするをご覧ください。
次のステップとリソース
Chrome がデフォルトでオリジンキー エージェント クラスタで動作するように、document.domain を読み取り専用にします。Chrome チームは、この変更を 2022 年中にリリースする予定です。
写真提供: Markus Winkler（Unsplash）