Android Chrome 88 とパソコン版 Chrome 92 での SharedArrayBuffer の更新

Jake Archibald
Eiji Kitamura

SharedArrayBuffer のウェブへの進出は多少悪化していますが、状況は定着しています。必知事項は次のとおりです。

概要

  • SharedArrayBuffer は現在 Firefox 79 以降でサポートされており、Android Chrome 88 で導入される予定です。ただし、これを使用できるのはクロスオリジン分離のページのみです。
  • SharedArrayBuffer は現在、パソコンの Chrome で利用できますが、Chrome 92 以降はクロスオリジン分離されたページに制限されます。この変更が間に合わないと思われる場合は、オリジン トライアルに登録して、少なくとも Chrome 113 まで現在の動作を維持できます。
  • クロスオリジン分離を有効にして SharedArrayBuffer を引き続き使用する場合は、これがウェブサイトの他のクロスオリジン要素（広告プレースメントなど）に与える影響を評価します。影響とガイダンスを把握するには、SharedArrayBuffer がサードパーティ リソースで使用されているかどうかを確認します。

クロスオリジン分離の概要

次のヘッダーでページを配信すると、ページをクロスオリジン分離にできます。

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin

これを行うと、リソースが Cross-Origin-Resource-Policy ヘッダーまたは CORS ヘッダー（Access-Control-Allow-* など）を使用して明示的に許可しない限り、ページでクロスオリジン コンテンツを読み込めなくなります。

Reporting API を使用すると、Cross-Origin-Embedder-Policy と Cross-Origin-Opener-Policy の結果として失敗したリクエストのデータを収集できます。

Chrome 92 でこれらの変更を行うことが難しいと思われる場合は、オリジン トライアルに登録することで、少なくとも Chrome 113 まで現在のパソコン向け Chrome の動作を維持できます。

クロスオリジン分離に関する詳細なガイダンスと情報については、このページの下部にある参考資料をご覧ください。

どのような経緯でこの時代にたどり着いたのでしょうか？

SharedArrayBuffer が Chrome 60 に実装されました（Chrome のバージョンではなく日付で時間を考える方にとっては 2017 年 7 月のことです）。6 か月間有効。

2018 年 1 月、いくつかの一般的な CPU に脆弱性があることが明らかになりました。詳細はお知らせをご覧ください。これは基本的に、コードが高解像度のタイマーを使用して、アクセスすべきでないメモリを読み取ることができることを意味します。

これはブラウザ ベンダーにとって問題でした。サイトが JavaScript と WASM の形式でコードを実行できるようにする一方で、このコードがアクセスできるメモリは厳密に制御したいからです。私のウェブサイトにたどり着いたら、私が開いているインターネット バンキング サイトの何も読めないはずです。インターネットバンキングのサイトが 開いているかどうかもわかりませんこれらはウェブセキュリティの基本です

これを軽減するために、performance.now() などの高解像度タイマーの解像度を下げました。ただし、ワーカー内のタイトなループでメモリを変更し、別のスレッドで読み返すことで、SharedArrayBuffer を使用して高解像度タイマーを作成できます。これは、善意のコードに大きく影響することなく効果的に軽減できなかったため、SharedArrayBuffer を完全に無効にしました。

一般的な対策は、ウェブページのシステム プロセスに他の場所の機密データが含まれないようにすることです。Chrome は当初からマルチプロセス アーキテクチャに投資していましたが（コミック）、次のように複数のサイトのデータが最終的に同じプロセスになる可能性もありました。

<iframe src="https://your-bank.example/balance.json"></iframe>
<script src="https://your-bank.example/balance.json"></script>
<link rel="stylesheet" href="https://your-bank.example/balance.json" />
<img src="https://your-bank.example/balance.json" />
<video src="https://your-bank.example/balance.json"></video>
<!-- …and more… -->

これらの API には、他のオリジンからのオプトインなしに、他のオリジンのコンテンツを使用できる「レガシー」の動作があります。これらのリクエストは他の送信元の Cookie を使用して作成されているため、完全に「ログイン中」のリクエストとなります。現在、新しい API では、CORS を使用して他のオリジンをオプトインする必要があります。

こうした従来の API を回避するため、コンテンツが「不適切」に見えるウェブページのプロセスに入るのを防ぐとともに、これをクロスオリジン読み取りブロックと名付けました。したがって、上記のケースでは、JSON はこれらの API で有効な形式ではないため、プロセスに入力できません。つまり iframe は除きます。iframe の場合、コンテンツを別のプロセスに配置します。

これらの緩和策を実装したため、Chrome 68（2018 年 7 月）で SharedArrayBuffer を再度導入しましたが、これはパソコンでのみ可能です。追加のプロセス要件により、モバイル デバイスでは同じことを行えませんでした。また、ブロックしているデータ形式が「不適切な」だけであったため、Chrome のソリューションは不完全でしたが、推測可能な URL で有効な CSS/JS/画像に非公開データが含まれている可能性（珍しいこと）もありました。

ウェブ標準関係者が集まり、より完全なクロスブラウザ ソリューションを開発しました。解決策は、ページに「オプトインせずに他のオリジンのコンテンツをこのプロセスに導入する権限を放棄します」と示せるようにすることでした。この宣言は、ページとともに提供される COOP ヘッダーと COEP ヘッダーを介して行われます。ブラウザがそれを適用すると、ページは SharedArrayBuffer や同様の機能を持つ他の API にアクセスできるようになります。他のオリジンは、Cross-Origin-Resource-Policy または CORS を介してコンテンツの埋め込みをオプトインできます。

Firefox はバージョン 79（2020 年 7 月）で、この制限を含む SharedArrayBuffer を初めてリリースしました。

そして、2021 年 1 月に私がこの記事を書き、皆さんも読んでくれたのです。こんにちは。

それが今の始まりですChrome 88 では、クロスオリジン分離されたページに対して SharedArrayBuffer が Android に戻されます。Chrome 92 では、整合性と完全なクロスオリジン分離を実現するために、パソコンに対しても同じ要件が適用されます。

パソコン版 Chrome の変更を遅らせる

これは「オリジン トライアル」という一時的な例外で、クロスオリジンで分離されたページを実装するための時間的猶予が与えられます。これにより、ページをクロスオリジンで分離することなく、SharedArrayBuffer が可能になります。この例外は Chrome 113 で期限切れになり、パソコン版 Chrome にのみ適用されます。

  1. 送信元のトークンをリクエストします。
  2. トークンをページに追加します。これには次の 2 つの方法があります。
    • 各ページのヘッダーに origin-trial <meta> タグを追加します。たとえば、次のようになります。
      <meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">
    • サーバーを構成できる場合は、Origin-Trial HTTP ヘッダーを使用してトークンを追加することもできます。結果のレスポンス ヘッダーは次のようになります。
      Origin-Trial: TOKEN_GOES_HERE

関連情報

バナー写真（作成者: Daniel Gregoire、出典: Unsplash）