ファーストパーティ セットのテスト手順

First-Party Sets の最新版は、Chrome 108 以降でデベロッパー向け機能フラグによるテストが可能です。Google は、ファーストパーティ セットのリリースに向けて積極的に取り組んでおります。そのため、3 月上旬（2023 年 3 月 7 日）の Chrome 111 リリースまで、このフェーズのデベロッパー テストに関するフィードバックをお待ちしております。

エコシステムからのフィードバックでは、Chrome でサードパーティ Cookie のサポートが終了すると影響を受けるクロスサイト ユースケースが指摘されています。ファーストパーティ セットの提案では、相互依存するサイトがブラウザに表現できる関係を共有し、ブラウザがユーザーに代わって適切なアクションを実行したり、その情報をユーザーに効果的に提示したりできる、クロスサイトのユースケースのクラスを検討し、対処します。

更新された提案では、2 つの API（Storage Access API と、requestStorageAccessForOrigin という暫定的な名前の新しい API）を使用して、ファーストパーティ セット内の Cookie のクロスサイト アクセスをリクエストするアクティブな方法をサイトに提供します。以下の手順では、サイトに作成するセットと、2 つの異なる API を呼び出す適切なポイントをテストして検証します。

ファーストパーティ セットの概要

ファーストパーティ セット（FPS）は、デベロッパーがサイト間の関係を宣言するためのウェブ プラットフォーム メカニズムです。これにより、ブラウザは、この情報を使用して、ユーザー向けの特定の目的のために、制限付きのクロスサイト Cookie アクセスを有効にできます。Chrome は、これらの宣言された関係を使用して、サードパーティ コンテキストでサイトが Cookie にアクセスするタイミングを許可または拒否します。

大まかに言えば、ファーストパーティ セットはドメインの集合体であり、1 つの「セットのプライマリ」と複数の「セットのメンバー」が存在する場合があります。ドメインをセットに登録できるのはサイト作成者のみです。また、各「セット メンバー」と「セット プライマリ」の関係を宣言する必要があります。セットのメンバーには、ユースケースに基づくサブセットを含むさまざまなドメインタイプを含めることができます。

各サブセットのプライバシーへの影響に応じて、ブラウザが各サブセットを処理できるようにするため、Storage Access API（SAA）と requestStorageAccessForOrigin を活用して、FPS 内で Cookie アクセスを有効にすることを提案しています。

SAA を使用すると、サイトはクロスサイト Cookie へのアクセスを積極的にリクエストできます。リクエスト元のサイトと最上位ウェブサイトが同じ FPS 内にある場合、Chrome はリクエストを自動的に承認します。SAA の呼び出しが他のブラウザでどのように処理されるかについては、Storage Access API（SAA）のドキュメントをご覧ください。

現在、SAA では、ドキュメントが API のメソッドを呼び出す前にユーザーの有効化を取得することが義務付けられています。

これにより、Cookie を必要とするクロスサイトの画像やスクリプトタグを使用するトップレベル サイトでは、FPS の導入が困難になる可能性があります。こうした課題の一部に対処するため、デベロッパーがこの変更をより簡単に導入できるように、新しい API である requestStorageAccessForOrigin を提案しました。この API はテストにも使用できます。

提出を設定する

正規の FPS リストは、新しい FPS GitHub リポジトリに格納された JSON ファイル形式の一般公開リストで、すべてのセットの信頼できる情報源として機能します。Chrome はこのファイルを使用して動作に適用します。

セットの送信プロセスと要件について詳しくは、送信ガイドラインをご覧ください。セットを送信して、送信内容を検証するさまざまな技術的なチェックをテストすることもできます。Chrome の安定版で FPS が利用可能になる前に、すべての送信内容が削除されます。

セットの送信プロセスはまだ開発中であるため、ローカルテストでは、コマンドラインでセットを作成し、ブラウザに直接渡すのみとなります。ローカルテストでは、特徴フラグでテストするために GitHub リポジトリにセットを送信する必要はありません。

ローカルでテストする方法

前提条件

FPS をローカルでテストするには、コマンドラインから起動した Chrome 108 以降を使用します。

リリースに先駆けて Chrome の新しい機能をプレビューするには、Chrome の Beta 版または Canary 版をダウンロードしてください。

例

google-chrome \
--enable-features="FirstPartySets,StorageAccessAPI,StorageAccessAPIForOriginExtension,PageInfoCookiesSubpage,PrivacySandboxFirstPartySetsUI" \
--use-first-party-set="{\"primary\": \"https://first-party-sets.glitch.me\", \"associatedSites\": [\"https://fps-member-1.glitch.me\"]}" \

詳しくは、フラグを使用して Chromium を実行する方法をご覧ください。

手順

ローカルで FPS を有効にするには、このセクションで説明するフラグのカンマ区切りリストを指定して Chrome の --enable-features オプションを使用し、関連するサイトのセットを JSON オブジェクトとして宣言して --use-first-party-set に渡す必要があります。

FPS を有効にする

FirstPartySets: Chrome で FPS を有効にします。

FirstPartySets

Storage Access API を有効にする

StorageAccessAPI

Chrome で Storage Access API（SAA）を有効にします。これにより、埋め込まれた iframe は、サードパーティ Cookie がブラウザによってブロックされている場合でも、requestStorageAccess() を使用してクロスサイト コンテキストで Cookie へのアクセスをリクエストできます。

requestStorageAccess() を呼び出すと、解決するためにユーザーの操作が必要になります。SAA 仕様は現在も進化しているため、今後の Chrome のバージョンでは、異なる要件が適用される可能性があります。Chrome での SAA の実装に関する予定の改善点については、こちらをご覧ください。

StorageAccessAPIForOriginExtension

最上位のサイトが requestStorageAccessForOrigin() を使用して、特定のオリジンに代わってストレージ アクセスをリクエストできるようにします。これは、Cookie を必要とするクロスサイト画像やスクリプト タグを使用するトップレベルのサイトに役立ち、SAA の導入に関する課題の一部に対処します。

ローカルでセットを宣言する

ファーストパーティ セットはドメインの集合であり、1 つの「セットのプライマリ」と複数の「セットのメンバー」が存在する場合があります。セットのメンバーには、ユースケースに基づくサブセットを含むさまざまなドメインタイプを含めることができます。

セットのメンバーである URL を含む JSON オブジェクトを作成し、それを --use-first-party-set に渡します。

次の例では、primary にプライマリ ドメインが、associatedSites に関連するサブセットの要件を満たすドメインが一覧表示されます。

{
     "primary": "https://primary.com",
    "associatedSites": ["https://associate1.com", "https://associate2.com", "https://associate3.com"]
}

例:

--use-first-party-set="{\"primary\": \"https://first-party-sets.glitch.me\", \"associatedSites\": [\"https://fps-member-1.glitch.me\"]}"

ローカルテストでは、コマンドラインでセットを作成し、ブラウザに直接渡すことができます。ローカル テストではセットの検証は行われませんが、FPS が安定版としてリリースされる場合は、すべてのセットを FPS GitHub リポジトリに送信し、検証基準を満たす必要があります。

FPS UI を有効にする

PageInfoCookiesSubpage

URL バーからアクセスできる PageInfo セクションに FPS を表示できるようにしました。

PrivacySandboxFirstPartySetsUI

Chrome の設定で、[プライバシーとセキュリティ] > [Cookie と他のサイトデータ]（chrome://settings/cookies）の FPS UI の [関連サイトにグループでのアクティビティの確認を許可する] オプションを有効にします。

サードパーティ Cookie がブロックされていることを確認する

  1. Chrome の設定で、[プライバシーとセキュリティ] > [Cookie とその他のサイトデータ] に移動するか、chrome://settings/cookies にアクセスします。
  2. [全般] で、[サードパーティの Cookie をブロックする] が有効になっていることを確認します。
  3. サブオプションの [関連サイトにグループ内のアクティビティの確認を許可する] も有効になっていることを確認します。

セキュリティ上の考慮事項

Storage Access API を使用すると、ウェブサイトは特定のケースでサードパーティ Cookie へのアクセスを再取得できるため、ウェブ アプリケーションがクロスサイト攻撃や情報漏洩の危険にさらされる可能性があります。クロスサイト コンテキストで Cookie に依存するサイトは、CSRF などの攻撃のリスクに注意する必要があります。

今後予定されている機能改善

これを改善するため、今後の Chrome リリースでは、埋め込みコンテンツの明示的なオプトインを確実に行うための追加のセキュリティ管理が必要になります。提案されている改善点は、フレーム単位でのみアクセス権を付与し、認証情報リクエストで CORS を必須とし、アクセス範囲をオリジンに限定することです。詳しくは、最近のセキュリティ分析をご覧ください。

Chrome の SAA 実装に関する予定されている改善点のリストをご覧ください。

Chrome は、Storage Access API が関連するクロスサイト埋め込みコンテキストでのみ、SameSite=None とマークされた Cookie を送信します。ただし、すべてのブラウザでこれらの Cookie へのデフォルト アクセスが非推奨になるまで、Cookie が使用される場所について推測することはできません。FPS 内でのみアクセスが許可されると想定することは安全ではありません。サイトは、標準のセキュリティのベスト プラクティスを引き続き使用する必要があります。

意見交換とフィードバックの提供

ローカルテストでは、FPS を有効にする Storage Access API メカニズムを試し、フィードバックや発生した問題を共有できます。また、GitHub でセットの送信プロセスをテストすることで、プロセスと検証手順に関する経験を共有できます。更新された提案について意見交換を行い、フィードバックを共有するには: