ファーストパーティ セットの最新イテレーションでは、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 リストは、一般公開される JSON ファイル形式のリストで、新しい FPS GitHub リポジトリに格納され、すべてのセットの信頼できる情報源として機能します。Chrome はこのファイルを使用して動作に適用します。
セットを送信する際に提案されるプロセスと要件について詳しくは、提出に関するガイドラインをご覧ください。また、提出内容を検証するさまざまな技術チェックをテストするためのセットを提出することもできます。Chrome の安定版で FPS が利用可能になる前に、すべての送信内容が消去されます。
セット送信プロセスはまだ開発中のため、ローカルテストの場合は、コマンドラインでセットを作成して、ブラウザに直接渡すことのみ可能です。ローカルテストでは、フィーチャー トグルを使用してテストするために、GitHub リポジトリにセットを送信する必要はありません。
ローカルでのテスト方法
前提条件
FPS をローカルでテストするには、コマンドラインから起動した Chrome 108 以降を使用します。
Chrome のリリース前に新機能をプレビューするには、Chrome のベータ版または 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)を有効にします。これにより、サードパーティの Cookie がブラウザによってブロックされていても、埋め込み iframe が 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
FPS UI を有効にします。[関連サイトにグループ内のアクティビティの確認を許可する]Chrome 設定の [プライバシーとセキュリティ] → [Cookie と他のサイトデータ](chrome://settings/cookies)で有効にできます。

サードパーティ Cookie がブロックされることを確認する
- Chrome の設定で、[プライバシーとセキュリティ] → [Cookie と他のサイトデータ] または [chrome://settings/cookies] に移動します。
- [全般設定] で [サードパーティの Cookie をブロックする] を有効になります。
- [グループ内のアクティビティの確認を関連サイトに許可します] サブオプションをオンにします。有効になります。
セキュリティ上の考慮事項
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 でセット送信プロセスをテストすることで、プロセスと検証ステップの経験を共有することもできます。更新された提案について対応し、フィードバックを共有するには:
- GitHub で問題を報告し、ディスカッションをフォローできます。
- プライバシー サンドボックス デベロッパー サポート リポジトリで、質問したりディスカッションに参加したりできます。
- プライバシー サンドボックスの提案に関するフィードバックを提供するためのさまざまな方法を検討する。