Trust Tokens は、ウェブサイトがあるブラウジング コンテキストから別の閲覧コンテキスト(サイト間など)に限られた量の情報を転送できるようにする新しい API です。これにより、パッシブ トラッキングを行うことなく不正行為を防止できます。
まとめ
トラスト トークンを使用すると、オリジンは信頼できるユーザーに暗号トークンを発行できます。トークンはユーザーのブラウザに保存されます。ブラウザはトークンを他のコンテキストで使用して、ユーザーの真正性を評価できます。
Trust Token API を使用すると、あるコンテキストにおけるユーザーの信頼を別のコンテキストに伝達できます。その際、ユーザーを特定したり 2 つの ID をリンクしたりする必要はありません。
API をデモで試すことができます。また、Chrome DevTools の [Network] タブと [Application] タブでトークンを検査することもできます。
トラスト トークンが必要な理由
ウェブは、ユーザーが本人であることを表明し、人間になりすました bot や、実在の人物やサービスを欺く悪意のある第三者ではないことを示す、信頼シグナルを確立する方法を必要としています。不正行為からの保護は、広告主、広告プロバイダ、CDN にとって特に重要です。
残念なことに、信頼性を測定して伝播する既存のメカニズムの多くは、たとえば、サイトとのインタラクションが実際の人間によるものかどうかを判別するために、フィンガープリントにも使用できる手法を利用しています。
API はプライバシーを保護し、個々のユーザーをトラッキングすることなく、サイト間で信頼を伝播できるようにする必要があります。
トラスト トークンの提案の内容
ウェブは、信頼シグナルを構築して不正行為やスパムを検出しています。これを行う方法の 1 つは、グローバルでクロスサイト、ユーザーごとの ID でブラウジングをトラッキングすることです。プライバシー保護 API の場合、これは許容されません。
提案の説明から:
この API は、サードパーティのコンテキストでアクセスできる「プライバシー パス」スタイルの暗号トークン用に、オリジンごとの新しいストレージ領域を提案しています。これらのトークンはパーソナライズされておらず、ユーザーの追跡には使用できませんが、暗号で署名されているため、偽造はできません。
オリジンがユーザーを信頼できるコンテキストにある場合、ブラウザにトークンのバッチを発行できます。このトークンは、ユーザーが不明な場合や信頼性が低い状況で、後で「使用」される可能性があります。重要なのは、トークン同士を区別できないため、ウェブサイトがトークンを介してユーザーをトラッキングできないことです。
Google では、ブラウザが特定のトークンの利用にバインドされた鍵を使用して送信リクエストに署名するための拡張機能メカニズムも提案しています。
API の使用例
以下は、API 説明のサンプルコードから抜粋したコードです。
ユーザーが、第三者広告ネットワーク(foo.example
)からの広告が埋め込まれているニュース ウェブサイト(publisher.example
)を訪問したとします。このユーザーは、以前にトラスト トークン(issuer.example
)を発行するソーシャル メディア サイトを使用しました。
以下のシーケンスは、トラスト トークンの仕組みを示しています。
1.ユーザーが issuer.example
にアクセスし、アカウント アクティビティやキャプチャによる確認など、ユーザーが実在の人物であると信じ込ませるアクションを実行します。
2.issuer.example
はユーザーが人間であることを確認し、次の JavaScript を実行してユーザーのブラウザにトラスト トークンを発行します。
fetch('https://issuer.example/trust-token', {
trustToken: {
type: 'token-request',
issuer: 'https://issuer.example'
}
}).then(...)
3.トラスト トークンは、ユーザーのブラウザに issuer.example
と関連付けられて保存されます。
4.しばらくして、そのユーザーが publisher.example
にアクセスしました。
5.publisher.example
は、ユーザーが実在の人間かどうかを知りたいと思っています。publisher.example
は issuer.example
を信頼するため、ユーザーのブラウザにこのオリジンからの有効なトークンがあるかどうかを確認します。
document.hasTrustToken('https://issuer.example');
6.true
に解決される Promise が返された場合、ユーザーは issuer.example
のトークンを持っているため、publisher.example
はトークンの利用を試行できます。
fetch('https://issuer.example/trust-token', {
trustToken: {
type: 'token-redemption',
issuer: 'https://issuer.example',
refreshPolicy: {none, refresh}
}
}).then(...)
更新後のコード:
- 利用ユーザー
publisher.example
が利用をリクエストしています。 クーポンの利用に成功すると、カード発行会社の
issuer.example
はクーポン レコードを返します。これは、ある時点で有効なトークンがこのブラウザに発行されたことを示します。7.
fetch()
から返された Promise が解決されると、以降のリソース リクエストでクーポン利用レコードを使用できるようになります。
fetch('https://foo.example/get-content', {
trustToken: {
type: 'send-redemption-record',
issuers: ['https://issuer.example', ...]
}
});
更新後のコード:
- クーポン利用レコードは、リクエスト ヘッダー
Sec-Redemption-Record
として含まれます。 foo.example
は、クーポン利用レコードを受け取り、レコードを解析し、issuer.example
がこのユーザーが人間であると判断したかどうかを判断します。foo.example
はそれに応じて応答します。
たとえば、e コマースサイトでのショッピング履歴、ロケーション プラットフォームでのチェックイン、銀行の口座履歴などが考えられます。また、カード発行会社は、ユーザーが実在する人である可能性に対するカード発行会社の信頼を高める、アカウントの利用期間やその他の操作(キャプチャやフォームの送信など)など、その他の要素にも着目します。
トラスト トークンの発行
トラスト トークン発行者(issuer.example
など)によってユーザーが信頼できると見なされる場合、カード発行会社は trustToken
パラメータを使用して fetch()
リクエストを行うことで、ユーザーのトラスト トークンを取得できます。
fetch('issuer.example/trust-token', {
trustToken: {
type: 'token-request'
}
}).then(...)
これにより、新しい暗号プリミティブを使用して、プライバシー パス発行プロトコルの拡張が呼び出されます。
ノンスと呼ばれる擬似乱数のセットを生成します。
ノンスをブラインド化し(カード発行会社がコンテンツを表示できないようにエンコードします)、
Sec-Trust-Token
ヘッダーでリクエストに追加します。指定されたエンドポイントに POST リクエストを送信します。
エンドポイントはブラインド トークン(ブラインド ノンスの署名)で応答します。トークンはブラインド化解除され、関連するノンスとともにトラスト トークンとしてブラウザによって内部に保存されます。
トラスト トークンの利用
パブリッシャー サイト(上記の例の publisher.example
など)は、ユーザーが使用できるトラスト トークンがあるかどうかを確認できます。
const userHasTokens = await document.hasTrustToken('issuer.example/trust-token');
利用可能なトークンがある場合、パブリッシャーのサイトでトークンを利用してクーポン記録を取得できます。
fetch('issuer.example/trust-token', {
...
trustToken: {
type: 'token-redemption',
refreshPolicy: 'none'
}
...
}).then(...)
ニュース メディアは、次のように fetch()
呼び出しを使用して、トラスト トークンを必要とするリクエスト(コメントの投稿、ページの高評価、アンケートでの投票など)にクーポンの利用記録を含めることができます。
fetch('https://foo.example/post-comment', {
...
trustToken: {
type: 'send-redemption-record',
issuers: ['issuer.example/trust-token', ...]
}
...
}).then(...);
クーポン利用レコードは Sec-Redemption-Record
リクエスト ヘッダーとして含まれます。
プライバシーへの配慮
トークンは「リンク解除」できるように設計されています。カード発行会社は、ユーザーがアクセスしたサイトに関する集計情報を把握することはできますが、発行をクーポンの利用にリンクすることはできません。ユーザーがトークンを利用する際に、作成した他のトークンとトークンを区別することはできません。ただし、現在のところ、トラスト トークンは単独では存在しません。現在のところ、カード発行会社が(理論上は)サイトのユーザー ID と結合する方法は他にもあります(サードパーティ Cookie や隠れたトラッキング技術など)。サイトがサポートを計画する際には、このエコシステムの移行を理解することが重要です。これは多くのプライバシー サンドボックス API の移行における一般的な側面であるため、ここでは詳しく説明しません。
セキュリティ上の考慮事項
トラスト トークンの枯渇: 悪意のあるサイトによって、特定の発行元からのユーザーのトークンが意図的に枯渇する可能性があります。この種の攻撃には、いくつかの緩和策があります。たとえば、カード発行会社が一度に多くのトークンを提供できるようにすることで、ブラウザがトップレベルのページビューごとに 1 つのトークンのみを利用できるよう、ユーザーには十分な量のトークンを提供できます。
二重支出の防止: マルウェアがユーザーのトラスト トークンすべてにアクセスを試みる可能性があります。ただし、すべてのクーポンが同じトークン発行者に送信され、各トークンが 1 回だけ使用されていることを確認できるため、トークンは時間の経過とともに不足します。リスクを軽減するために、カード発行会社は署名するトークンの数を減らすこともできます。
リクエスト メカニズム
ナビゲーション リクエストなどで、fetch()
の外部でクーポン利用記録を送信できる場合があります。また、HTTP レスポンス ヘッダーにカード発行会社のデータを含めることで、ページの読み込みと並行してトークンを利用できるようにすることもできます。
繰り返しになりますが、この提案には皆様のフィードバックが必要です。ご意見がある場合は、信頼トークンの説明リポジトリで問題を作成してください。
補足説明
- トラスト トークンのデモ
- Chrome のオリジン トライアルのスタートガイド
- プライバシー サンドボックスの詳細
- Trust Token API の説明
- Chromium プロジェクト: Trust Token API
- 実装の目的: Trust Token API
- Chrome プラットフォームのステータス
- プライバシー パス
- プライバシー パスの拡張機能
この投稿の執筆およびレビューにご協力いただいたすべての方に感謝いたします。