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-* など）で明示的に許可しない限り、ページはクロスオリジン コンテンツを読み込めなくなります。

レポート 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 のいずれにも有効な形式ではないため、JSON がプロセスに入ることが許可されません。つまり、iframe を除くすべての要素です。iframe の場合、コンテンツは別のプロセスに配置されます。

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

ウェブ標準の担当者が集まり、より完全なクロスブラウザ ソリューションを考案しました。この解決策として、ページに「他のオリジンのコンテンツをオプトインなしでこのプロセスに組み込む機能を放棄します」と宣言する方法が与えられました。この宣言は、ページとともに提供される COOP ヘッダーと COEP ヘッダーを介して行われます。ブラウザはこれを強制し、その代わりにページは SharedArrayBuffer や同様の機能を持つ他の API にアクセスできるようになります。他のオリジンは、Cross-Origin-Resource-Policy または CORS を介してコンテンツの埋め込みをオプトインできます。

この制限付きの SharedArrayBuffer を最初にリリースしたのは Firefox で、バージョン 79（2020 年 7 月）でした。

そして、2021 年 1 月に私がこの記事を書き、あなたがそれを読んだのです。こんにちは。

これが現在の状況です。Chrome 88 では、クロスオリジン分離されたページで Android に SharedArrayBuffer が復活し、Chrome 92 では、一貫性とクロスオリジン分離の完全な実現のため、パソコン版でも同じ要件が導入されました。

パソコン版 Chrome の変更の延期

これは、クロスオリジン分離ページの実装に時間を要するユーザー向けの一時的な例外措置として、オリジン トライアルの形で提供されます。これにより、ページをクロスオリジン分離する必要なく SharedArrayBuffer を有効にできます。この例外は Chrome 113 で期限切れとなり、例外はパソコン版 Chrome にのみ適用されます。

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

関連情報

バナー写真: Daniel Gregoire（Unsplash）