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 を使用して高解像度タイマーをcreateできます。善意のコードに大きな影響を与えることなく、この問題を効果的に軽減することはできなかったため、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 を使用してオプトインする必要があります。

Google は、これらのレガシー API を回避するために、コンテンツが「正しくない」と思われる場合にウェブページのプロセスにコンテンツが入らないようにしました。これを「クロスオリジン読み取りブロック」と呼びます。そのため、上記のケースでは、JSON はこれらの API のいずれの形式でも有効ではないため、プロセスに入力されません。つまり、iframe を除きます。iframe の場合は、コンテンツを別のプロセスに配置します。

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

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

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

その後、2021 年 1 月に私がこの記事を書き、皆さんがそれを読んだわけです。こんにちは。

現時点では、Chrome 88 では、クロスオリジンで分離されたページに対して Android に SharedArrayBuffer が復元され、Chrome 92 では、一貫性と完全なクロスオリジン分離の実現のために、同じ要件がパソコンにも適用されます。

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

これは「オリジン トライアル」という形の一時的な例外であり、クロスオリジン分離ページの実装に時間を確保できます。ページをクロスオリジン分離しなくても SharedArrayBuffer を有効にできます。この例外は Chrome 113 で期限切れになり、PC 版 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）