Origin-Agent-Cluster ヘッダーを使用したパフォーマンス分離のリクエスト

ドメイン全体のスクリプトを制限したり、専用リソースをブラウザからリクエストしたりするための新しい HTTP レスポンス ヘッダー。

ドメニック デニコラ
ドメニック デニコラ

Origin-Agent-Cluster は、同一サイトのクロスオリジン ページ間の同期スクリプト アクセスを防ぐようブラウザに指示する新しい HTTP レスポンス ヘッダーです。ブラウザでは、オリジンが専用のプロセスなど、独自の個別のリソースを取得する必要があることを示すヒントとして、Origin-Agent-Cluster を使用することもあります。

ブラウザの互換性

現在、Origin-Agent-Cluster ヘッダーは Chrome 88 以降でのみ実装されています。Mozilla Firefox の代表者と緊密に連携して設計され、プロトタイピングに値すると評価しました。また、Safari で使用されているブラウザ エンジンである WebKit の代表者からも肯定的な評価が寄せられています。

ただし、現時点ですべてのユーザーに Origin-Agent-Cluster ヘッダーをデプロイしても問題はありません。認識できないブラウザは単に無視します。オリジンキー エージェント クラスタ内のページで実際に実行できる処理はサイトキー エージェント クラスタ内のページ(デフォルト)よりも少ないため、相互運用性の問題を心配する必要はありません。

ブラウザで同一サイトのオリジンを自動的に分離できない理由

ウェブは同一オリジン ポリシーに基づいて構築されています。これは、ドキュメントやスクリプトが別のオリジンのリソースとやり取りする方法を制限するセキュリティ機能です。たとえば、https://a.example でホストされているページは、https://b.examplehttps://sub.a.example とは異なるオリジンにあります。

ブラウザはバックグラウンドで、オリジンから提供される分離をさまざまな形で使用しています。以前は、別々のオリジンが互いのデータにアクセスできなかったとしても、オペレーティング システムのスレッド、プロセス、メモリ割り当てなどのリソースは引き続き共有されていました。つまり、1 つのタブの動作が遅いと、他のすべてのタブの動作も遅くなっていました。1 つのタブでメモリの使用量が多すぎると ブラウザ全体がクラッシュします

最近のブラウザはより高度化しており、さまざまなオリジンを異なるプロセスに分割しようとします。動作はブラウザによって異なります。ほとんどのブラウザではタブがある程度分離されていますが、1 つのタブ内の異なる iframe でもプロセスが共有されている場合があります。プロセスにはメモリのオーバーヘッドがあるため、過剰な生成を回避するためにヒューリスティックを使用します。たとえば、Firefox にはユーザーが構成可能なプロセス制限があり、Chrome では動作がパソコン(メモリが多い)とモバイル(メモリが少ない)で異なります。

このようなヒューリスティックは完全ではありません。また、https://sub.a.examplehttps://a.example などのサブドメインの相互通信を許可する同一オリジン ポリシーの例外があるため、ブラウザはサブドメインを自動的に分離できません。

このデフォルトの動作は「サイトキー エージェント クラスタ」と呼ばれます。つまり、ブラウザはサイトに基づいてページをグループ化します。新しい Origin-Agent-Cluster ヘッダーは、特定のページのこのデフォルトの動作を変更するようブラウザに求めます。そのページを「オリジン」キーのエージェント クラスタに入れ、まったく同じオリジンを持つ他のページとだけグループ化します。特に、同一サイトのクロスオリジン ページはエージェント クラスタから除外されます。

このオプトインの分離により、ブラウザはこれらの新しいオリジンキー エージェント クラスタに、他のオリジンのリソースと組み合わされない専用の専用リソースを提供できます。たとえば、このようなページは独自のプロセスを取得したり、別のスレッドでスケジュールしたりできます。Origin-Agent-Cluster ヘッダーをページに追加すると、その専用リソースからそのページのメリットをブラウザに示すことができます。

ただし、分離を行ってこうしたメリットを得るには、ブラウザで従来の機能を無効にする必要があります。

オリジンキー ページではできないこと

ページがオリジンキー エージェント クラスタにある場合、以前は利用可能だった同一サイトのクロスオリジン ページと通信する機能が一部使用できなくなります。具体的には、次のとおりです。

  • document.domain は設定できなくなりました。これは、通常は同一サイトのクロスオリジン ページが互いの DOM に同期的にアクセスできるようにする古い機能ですが、オリジンキー エージェント クラスタでは無効になっています。

  • postMessage() を使用して WebAssembly.Module オブジェクトを他の同一サイトのクロスオリジン ページに送信することはできなくなりました。

  • (Chrome のみ)SharedArrayBuffer オブジェクトまたは WebAssembly.Memory オブジェクトを他の同一サイトのクロスオリジン ページに送信できなくなりました。

オリジンキー エージェント クラスタを使用する場合

Origin-Agent-Cluster ヘッダーのメリットを最も得られるオリジンは次のとおりです。

  • 可能であれば、専用のリソースを使用して最大限のパフォーマンスを発揮する。たとえば、高パフォーマンスを必要とするゲーム、ビデオ会議サイト、マルチメディア作成アプリなどです。

  • オリジンが異なるが同じサイトの、リソースを大量に消費する iframe が含まれています。たとえば、https://mail.example.comhttps://chat.example.com iframe を埋め込む場合、オリジンキーに https://mail.example.com/ を設定すると、チャットチームが作成したコードがメールチームが作成したコードに誤って干渉することがなくなります。また、ブラウザに対し、プロセスを個別にスケジュールして、互いのパフォーマンスへの影響を軽減するように促すことができます。

  • オリジンが異なる同一サイトのページに埋め込まれるが、多くのリソースが必要。たとえば、https://customerservicewidget.example.com がビデオチャットに多くのリソースを使用することを想定しており、https://*.example.com のさまざまなオリジンに埋め込まれる場合、そのウィジェットを管理するチームは Origin-Agent-Cluster ヘッダーを使用して、エンベダーのパフォーマンスへの影響を軽減できます。

また、前述の使用頻度の低いクロスオリジン通信機能を無効にしても問題ないことと、サイトで HTTPS を使用していることを確認してください。

これらはあくまでもガイドラインにすぎません。オリジンキー エージェント クラスタがサイトに役立つかどうかは、最終的には測定値によって決まります。特に、ウェブに関する指標を測定し、場合によってはメモリ使用量を測定して、送信元キーイングが与える影響を確認する必要があります。(特に、実行中のプロセスの数が増えるとプロセスごとのメモリ オーバーヘッドが増加するため、メモリ使用量が潜在的な懸念事項となります)。オリジンキーイングを展開して最善を尽くすだけでは不十分です。

クロスオリジン分離とどのような関係がありますか?

Origin-Agent-Cluster ヘッダーを介したエージェント クラスタのオリジンキーイングは、Cross-Origin-Opener-Policy ヘッダーと Cross-Origin-Embedder-Policy ヘッダーを介したクロスオリジン分離に関連していますが、それとは別のものです。

サイトをクロスオリジン分離すると、Origin-Agent-Cluster ヘッダーを使用した場合と同じ同一サイトのクロスオリジン通信機能も無効になります。ただし、ブラウザがリソース割り当てのヒューリスティックを変更するための追加のヒントとして、Origin-Agent-Cluster ヘッダーはクロスオリジン分離に加えて引き続き役立ちます。そのため、すでにクロスオリジン分離されているページであっても、Origin-Agent-Cluster ヘッダーを適用し、結果を測定することを検討してください。

Origin-Agent-Cluster ヘッダーの使用方法

Origin-Agent-Cluster ヘッダーを使用するには、次の HTTP レスポンス ヘッダーを送信するようにウェブサーバーを構成します。

Origin-Agent-Cluster: ?1

?1 の値は、ブール値 true構造化ヘッダー構文です。

このヘッダーは、一部のページだけでなく、オリジンからのすべてのレスポンスに送信することが重要です。そうしないと、結果に一貫性がなくなる可能性があります。ブラウザがオリジンキーのリクエストを認識していることを「記憶」し、リクエストしていないページでもオリジンキーを行うことになります。逆に、ユーザーが最初にアクセスしたページにヘッダーがない場合、ブラウザはオリジンがオリジンキーの使用を希望していないことを記憶し、後続のページでヘッダーを無視します。

ブラウザがヘッダーを常に考慮できないのはなぜですか?

この「メモリ」を使用する理由は、オリジンのキー設定の整合性を確保するためです。オリジンの一部のページがオリジンキーで、それ以外のページがオリジンキーだった場合、2 つの同一オリジン ページは異なるエージェント クラスタに配置され、相互に通信できない可能性があります。これは、ウェブ デベロッパーにとってもブラウザ内部にとっても、非常に奇妙なことでしょう。したがって、Origin-Agent-Cluster の仕様は、特定のオリジンで以前に参照されたものと一致しない場合、ヘッダーを無視します。これにより、Chrome ではコンソールの警告が表示されます。

この整合性のスコープはブラウジング コンテキスト グループです。ブラウジング コンテキスト グループは、window.openerframes[0]window.parent などのメカニズムを介してすべて相互にアクセスできるタブ、ウィンドウ、iframe のグループです。つまり、オリジンのオリジンキーまたはサイトキーが(ブラウザがヘッダーを認識するかどうかのいずれかで)確定すると、変更を行うには、古いタブに接続せずに、まったく新しいタブを開く必要があります。

これらの詳細は、Origin-Agent-Cluster ヘッダーのテストで重要となる場合があります。初めてサイトに追加するときは、ページを再読み込みするだけでは機能しません。タブを閉じて、新しいタブを開く必要があります。

Origin-Agent-Cluster ヘッダーが適用されているかどうかを確認するには、JavaScript の window.originAgentCluster プロパティを使用します。ヘッダー(またはクロスオリジン分離などのメカニズム)によってオリジンキーイングが発生した場合は true、発生していない場合は falseOrigin-Agent-Cluster ヘッダーを実装していないブラウザでは undefined になります。このデータを分析プラットフォームにロギングすると、サーバーが正しく構成されていることを確認できます。

なお、Origin-Agent-Cluster ヘッダーは安全なコンテキスト(HTTPS ページまたは http://localhost)でのみ機能します。localhost 以外の HTTP ページは、オリジンキー エージェント クラスタをサポートしていません。

オリジンキーイングはセキュリティ機能ではない

オリジンキー エージェント クラスタを使用すると、同一サイトのクロスオリジン ページからの同期アクセスからオリジンが分離されますが、Cross-Origin-Resource-PolicyCross-Origin-Opener-Policy などのセキュリティ関連ヘッダーは保護されません。特に、Spectre のようなサイドチャネル攻撃に対する信頼性の高い保護ではありません。

オリジンキーの使用により、オリジンが独自のプロセスを取得することがあり、個別のプロセスがサイドチャネル攻撃に対する重要な防御となるため、これは少し驚くかもしれません。ただし、Origin-Agent-Cluster ヘッダーは、その点に関するヒントにすぎません。ブラウザは、送信元に別のプロセスを提供する義務を負いません。また、さまざまな理由から、そうならない場合があります。

  • ブラウザにそのような技術が実装されていない場合があります。たとえば、現在の Safari と Firefox では個別のタブをそれぞれのプロセスに配置できますが、iframe ではまだできません。

  • ブラウザは、別のプロセスのオーバーヘッドに値しないと判断することもあります。たとえば、メモリの少ない Android デバイスや Android WebView では、Chrome で使用されるプロセスが最小限に抑えられます。

  • ブラウザは、Origin-Agent-Cluster ヘッダーが示すリクエストを優先したい場合がありますが、プロセスとは異なる分離技術を使用してこれを行うことができます。たとえば、Chrome はこのようなパフォーマンスの分離のためにプロセスではなくスレッドを使用して探索を行っています。

  • ユーザーまたは別のサイトで実行されているコードが、オリジンのサイトキーページにすでに移動している可能性があります。その場合、整合性の保証が開始され、Origin-Agent-Cluster ヘッダーが完全に無視されます。

このような理由から、オリジンキー エージェント クラスタをセキュリティ機能とはみなさないことが重要です。ブラウザがリソース割り当ての優先順位付けを行えるようにするための手段であり、送信元が専用リソースのメリットを得られる(そして特定の機能は引き換えにあきらめる)ことをほのめかします。

フィードバック

Origin-Agent-Cluster ヘッダーを使用されている方、または使用を検討されている方のご意見、ご感想をお待ちしています。Google では、皆様からの一般のご関心とサポートをもとに、機能に優先順位を付け、他のブラウザ ベンダーがどれほど重要であるかを示しています。@ChromiumDev でツイートして、Chrome DevRel でご意見をお聞かせください。

仕様や機能の詳細についてご質問がある場合は、HTML 標準 GitHub リポジトリに問題を提出できます。Chrome の実装で問題が発生した場合は、new.crbug.com で [Components] フィールドを Internals>Sandbox>SiteIsolation に設定してバグを報告できます。

詳細

オリジンキー エージェント クラスタについて詳しくは、以下のリンクをご覧ください。