これまでサードパーティ Cookie は、ログイン ステータス、ユーザーが使用しているデバイスに関する情報、ユーザーが認識していて信頼できるかどうかなど、ユーザーの状態に関する情報の保存と伝達に使用されてきました。たとえば、ユーザーが SSO でログインしているかどうか、ユーザーが特定の種類の互換デバイスを使用しているかどうか、ユーザーが既知で信頼できるかどうかなどです。サードパーティ Cookie のサポート終了に伴い、これらのユースケースの多くは他の方法で対応する必要があります。
プライベート ステート トークンは、ウェブ全体で情報を共有する方法を提供しますが、実際に共有できるデータの量を制御することによって、プライバシーを保護しながら情報を共有します。
プライベート ステート トークン（旧称トラスト トークン）を使用すると、ユーザーの信頼性の信頼をあるコンテキストから別のコンテキストに伝えることができ、サイトはパッシブ トラッキングなしで不正行為に対処し、bot と実際の人間を区別できます。
このドキュメントでは、プライベート ステート トークン（PST）の実装に関する技術的な詳細について説明します。大まかな概要については、PST の概要をご覧ください。
プライベート ステート トークンの仕組み
PST で理解すべき重要な関係は、カード発行会社と利用者の間のものです。発行者と利用者は同じ会社に所属できます。
- 発行元 - これらのエンティティは、ユーザーに関するなんらかのシグナル（ユーザーが bot であるかどうかなど）を持ち、ユーザーのデバイスに保存されているトークンにそのシグナルを埋め込みます（詳細については次のセクションで説明します）。
- 利用ユーザー - これらのエンティティはユーザーに関するシグナルを持っていなくても、ユーザーに関する情報（ユーザーが bot であるかどうかなど）を知る必要があり、ユーザーの信頼性を把握するためにカード発行会社のトークンを利用するよう要求します。
PST のすべてのやり取りでは、カード発行会社と利用者が連携してウェブ全体でシグナルを共有する必要があります。これらのシグナルは大まかな値であり、個人を特定するには十分な詳細ではありません。
プライベート ステート トークンの使用に適しているか
信頼に関する意思決定を行い、その情報をコンテキスト全体で利用できるようにしたい企業には、PST が役立つ可能性があります。PST の潜在的なユースケースについて詳しくは、PST のユースケースに関するドキュメントをご覧ください。
トークンの発行と利用
PST の実装は次の 3 つのフェーズで行われます。
- トークンの発行
- トークンの利用
- クーポン利用レコードの転送
最初のフェーズでは、ブラウザにトークンが発行されます（通常はなんらかの検証後）。2 番目のフェーズでは、別のエンティティが、トークンの値を読み取るために発行されたトークンの利用をリクエストします。最終フェーズで、利用当事者は、トークンに含まれていた金額を含む利用レコード（RR）を受け取ります。利用当事者は、さまざまな目的でそのレコードをユーザーの証明書として使用できます。
トークン戦略を定義する
トークン戦略を定義するには、PST の主要なコンセプト（トークンとクーポンレコード）、変数、動作、制限を理解し、ユースケースでの使用の可能性について考える必要があります。
トークンとクーポン利用記録: 両者の間にはどのような関係がありますか？
各デバイスには、トップレベル ウェブサイトと発行者ごとに最大 500 個のトークンを保存できます。また、各トークンには、カード発行会社がどの鍵の発行に使用したかを示すメタデータも含まれます。この情報を使用して、利用プロセス中にトークンを利用するかどうかを判断できます。PST データは、ユーザーのデバイス上のブラウザによって内部的に保存され、PST API によってのみアクセスできます。
トークンが利用されると、クーポンレコード（RR）がデバイスに保存されます。このストレージは、今後の特典利用のためのキャッシュとして機能します。トークンの利用には、デバイス、ページ、発行者ごとに 48 時間ごとに 2 つのトークンという制限があります。新しいクーポン利用呼び出しでは、カード発行会社にリクエストを発生させるのではなく、キャッシュされた RR を可能な限り使用します。
- 新しいトークンが発行されます（発行元、サイト、デバイスごとに最大 500 個）。
- すべてのトークンはデバイス上のトークンストア（Cookie ストアと同様）に保存されます。
- 有効な RR が見つからない場合、発行後に新しい RR を生成できます（48 時間ごとに最大 2 個）。
- RR は期限切れになるまでアクティブとみなされ、ローカル キャッシュとして使用されます。
- クーポンの利用に関する新しい呼び出しはローカル キャッシュにヒットします（新しい RR は生成されません）。
ユースケースを定義したら、RR の有効期間を慎重に定義する必要があります。これは、そのケースで RR を何回使用できるかを定義するためです。
戦略を定義する前に、次の重要な動作と可変要素を理解しておいてください。
| 変動 / 動作 | 説明 | 想定される用途 |
|---|---|---|
| トークンキーのメタデータ | 各トークンは 1 つの暗号鍵を使用してのみ発行できます。PST では、カード発行会社ごとに 6 つの鍵という制限があります。 | この変数を使用する 1 つの方法は、暗号鍵に基づいてトークンの信頼範囲を定義することです（たとえば、鍵 1 = 高信頼、鍵 6 = 信頼なし）。 |
| トークンの有効期限 | トークンの有効期限はキーの有効期限と同じです。 | 鍵は少なくとも 60 日ごとにローテーションでき、無効な鍵で発行されたトークンもすべて無効と見なされます。 |
| トークンの利用レート制限 | トークンの利用には、デバイスおよびカード発行会社ごとに 48 時間ごとに 2 回という制限があります。 | ユースケースで 48 時間ごとに必要となる推定利用回数によって異なります。 |
| トップレベル オリジンごとの発行者の最大数 | 現在、トップレベルのオリジンあたりの発行者の最大数は 2 です。 | 各ページの発行者を慎重に定義します。 |
| デバイス上のカード発行会社ごとのトークン | 現時点では、特定のデバイスのカード発行会社ごとのトークンの最大数は 500 です。 | トークンの数は発行者あたり 500 個未満にしてください。 トークンを発行する場合は、ウェブページのエラーを処理してください。 |
| 鍵コミットメントのローテーション | すべての PST 発行元は、60 日ごとに変更可能な鍵コミットメントを持つエンドポイントを公開する必要があります。このコミットメントは 60 日ごとに変更され、それより短いローテーションは無視されます。 | 鍵が 60 日未満で期限切れになる場合は、中断を避けるため、その日までに鍵のコミットメントを更新する必要があります（詳細をご覧ください）。 |
| クーポン利用記録の有効期間 | RR の有効期間を定義して、有効期限を決定できます。RR は、カード発行会社への不要な新しいクーポン利用呼び出しを回避するためにキャッシュに保存されるため、十分なクーポン利用シグナルを最新の状態に保つことが重要です。 | 利用レートには 48 時間ごとに 2 つのトークンという上限があるため、RR の有効期間を定義して、少なくともこの期間に利用呼び出しを正常に実行できるようにすることが重要です（RR の有効期間はそれに応じて設定する必要があります）。この有効期間は週単位で設定することをおすすめします。 |
シナリオ例
シナリオ 1: RR の有効期間が 24 時間未満（t=t）で、48 時間の期間中に複数回利用が行われている。
シナリオ 2: RR の有効期間は 24 時間で、48 時間の間に利用が複数回実行される。
シナリオ 3: RR の有効期間は 48 時間で、その 48 時間の期間中にクーポンが複数回実行されます。
デモの実施
PST を導入する前に、まずデモで設定することをおすすめします。PST デモを試すには、デモ発行者の鍵コミットメントを有効にするフラグを指定して Chrome を実行する必要があります（デモページの手順に沿って操作してください）。
このデモを実行することで、ブラウザはデモ発行者とクーポン利用者サーバーを使用してトークンを提供、消費します。
技術的な注意事項
デモは、以下の手順を実装すると最適に実行されます。
- フラグを指定して Chrome を実行する前に、すべての Chrome インスタンスを停止してください。
- Windows マシンで実行している場合は、Chrome の実行バイナリにパラメータを渡す方法について このガイドをご覧ください。
- デモ アプリケーションの使用中に [Applications] > [Storage] > [Private State Tokens] で Chrome DevTools を開き、デモ発行元によって発行または使用されたトークンを確認します。
導入に向けて設定する
発行者になる
発行元は PST で重要な役割を果たします。トークンに値を割り当てて、ユーザーが bot かどうかを判断します。発行者として PST の使用を開始する場合は、発行者の登録プロセスを完了して登録する必要があります。
カード発行会社になるための申請を行うには、カード発行会社のウェブサイトの運営者が「New PST Issuer」テンプレートを使用して、GitHub リポジトリで新しい問題を開く必要があります。リポジトリのガイダンスに沿って問題を入力します。エンドポイントが検証されると、このリポジトリにマージされ、Chrome サーバーサイド インフラストラクチャがこれらの鍵の取得を開始します。
発行元サーバー
PST では、発行元と利用者が主要なアクターであり、サーバーとトークンは PST の主要なツールです。トークンの詳細については、GitHub のドキュメントですでに説明しましたが、PST サーバーについてもう少し詳しく説明したいと思います。PST の発行者として設定するには、まず発行サーバーを設定する必要があります。
環境をデプロイする: 発行元のサーバー
トークン発行者サーバーを実装するには、HTTP エンドポイントを公開する独自のサーバーサイド アプリケーションを構築する必要があります。
発行者コンポーネントは、（1）発行者サーバー、（2）トークン発行者の 2 つのメイン モジュールで構成されています。
すべてのウェブ公開アプリケーションと同様に、発行者のサーバーに追加の保護レイヤを追加することをおすすめします。
発行元サーバー: この実装例では、発行サーバーは Express フレームワークを使用して発行元 HTTP エンドポイントをホストする Node.js サーバーです。GitHub にあるサンプルコードをご確認ください。
トークン発行者: カード発行会社の暗号化コンポーネントは特定の言語を必要としませんが、このコンポーネントのパフォーマンス要件により、例として C 実装を用意しています。ここでは、Boring SSL ライブラリを使用してトークンを管理します。GitHub で発行者コードの例とインストールの詳細を確認する
鍵: トークン発行者コンポーネントはカスタム EC 鍵を使用してトークンを暗号化します。これらの鍵を保護し、安全なストレージに保存する必要があります。
カード発行会社のサーバーの技術要件
プロトコルに従って、発行者のサーバーに少なくとも 2 つの HTTP エンドポイントを実装する必要があります。
- 鍵コミットメント（
/.well-known/private-state-token/key-commitmentなど）: このエンドポイントでは、サーバーが正規であることを確認するために、暗号化公開鍵の詳細をブラウザに提供します。 - トークン発行（例:
/.well-known/private-state-token/issuance）: すべてのトークン リクエストが処理されるトークン発行エンドポイント。このエンドポイントは、トークン発行者コンポーネントの統合ポイントになります。
前述のように、このサーバーは大量のトラフィックを処理する可能性があるため、スケーラブルなインフラストラクチャ（クラウド環境など）を使用してデプロイし、変動する需要に基づいてバックエンドを調整できるようにすることをおすすめします。
発行元のサーバーに呼び出しを送信する
新しいトークンを発行するために、カード発行会社のスタックにウェブサイトの取得呼び出しを実装します。
// issuer request
await fetch("/.well-known/private-state-token/issuance", {
method: "POST",
privateToken: {
version: 1,
operation: "token-request"
}
});
クーポン利用サーバー
独自のサーバーサイド アプリケーションを作成して、トークン利用サービスを実装する必要があります。これにより、カード発行会社が送信するトークンを読み取ることができます。次の手順では、トークンを利用する方法と、それらのトークンに関連付けられているクーポン利用レコードを読み取る方法について説明します。
カード発行会社と利用者を同じサーバー（またはサーバーのグループ）で実行することもできます。
クーポン利用者サーバーの技術要件
プロトコルに従って、利用者サーバーに少なくとも 2 つの HTTP エンドポイントを実装する必要があります。
/.well-known/private-state-token/redemption: すべてのトークンの利用が処理されるエンドポイント。このエンドポイントに、トークンクーポン利用コンポーネントが統合されます。
クーポン利用元のサーバーに呼び出しを送信します
トークンを利用するには、以前に発行されたトークンを利用するために、利用ユーザー スタックに対してウェブサイト取得呼び出しを実装する必要があります。
// redemption request
await fetch("/.well-known/private-state-token/redemption", {
method: "POST",
privateToken: {
version: 1,
operation: "token-redemption",
refreshPolicy: "none"
}
});
コードサンプルをご覧ください。
トークンを利用した後、別のフェッチ呼び出しを行ってクーポン利用レコード（RR）を送信できます。
// attach redemption records from the issuers to the request
await fetch("<DESTINATION_RESOURCE>", {
method: "POST",
privateToken: {
version: 1,
operation: "send-redemption-record",
issuers: [<ISSUER_DOMAIN>]
}
});
コードサンプルをご覧ください。
実装をデプロイする
実装をテストするには、まず呼び出し元の呼び出しが行われたウェブページに移動し、トークンがロジックに従って作成されていることを確認します。バックエンドで、呼び出しが仕様に従って行われたことを確認します。次に、利用呼び出しが行われるウェブページに移動し、ロジックに従って RR が作成されていることを確認します。
実際のデプロイ
特定のユースケースに含まれるターゲット ウェブサイトを選択することをおすすめします。
- 1 か月のアクセス数が少ない（1 か月あたりのアクセス数が 100 万件未満）: まず、少数のユーザーに API をデプロイする必要があります。
- お客様が所有し、管理する: 必要に応じて、複雑な承認を行うことなく、実装をすばやく無効にできます。
- 複数の発行者を排除する: テストを簡素化するためにトークンの数を制限します。
- 利用者が 3 人以下の場合: 問題が発生した場合のトラブルシューティングを簡素化する必要があります。
トラブルシューティング
PST は Chrome DevTools の [Network] タブと [Application] タブで検査できます。
[Network] タブで次の操作を行います。
![DevTools の [Network] タブの検査。](https://developers.google.cn/static/privacy-sandbox/protections/private-state-tokens/images/pstdevelopergu--u49gd5id2.png?hl=ja)
[Application] タブで次の操作を行います。
![[Application] タブの DevTools 検査。](https://developers.google.cn/static/privacy-sandbox/protections/private-state-tokens/images/pstdevelopergu--bl7phyzjw3o.png?hl=ja)
詳細については、DevTools の統合をご覧ください。
サーバーのベスト プラクティスとトラブルシューティング
発行者と利用元のサーバーが効果的に動作するには、PST でアクセス、セキュリティ、ロギング、トラフィックの課題が発生しないように、次のベスト プラクティスを実装することをおすすめします。
- エンドポイントでは、TLS 1.3 または 1.2 を使用した強力な暗号化を適用する必要があります。
- インフラストラクチャは、変動するトラフィック量（急増を含む）を処理できる必要があります。
- アクセス制御ポリシー、鍵管理戦略、事業継続計画に合わせて、鍵が保護され安全であることを確認してください。
- オブザーバビリティ指標をスタックに追加して、本番環境に移行した後の使用状況、ボトルネック、パフォーマンスの問題を可視化できるようにします。
詳細
- デベロッパー ドキュメントを確認します。
- GitHub の問題または W3C 呼び出しから会話に参加します。
- 各用語の理解を深めるには、プライバシー サンドボックスの用語集をご覧ください。
- 「オリジン トライアル」や「Chrome フラグ」など、Chrome のコンセプトについて詳しくは、goo.gle/cc の短い動画や記事をご覧ください。