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

ファーストパーティ セットの最新バージョンでは、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 の導入が難しくなる可能性があります。こうした課題に対処するために、Google はデベロッパーの皆様がこの変更を簡単に導入できるように、新しい API requestStorageAccessForOrigin を提案しました。この API はテストにも使用できます。

送信の設定

正規の FPS リストは、一般公開されている JSON ファイル形式のリストで、新しい FPS GitHub リポジトリに格納され、すべてのセットの信頼できる情報源として機能します。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）を有効にします。これにより、サードパーティ 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

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 でセット提出プロセスをテストすることは、プロセスと検証ステップの経験を共有する機会でもあります。更新された提案について意見交換し、フィードバックを共有するには: