トラスト トークンを使ってみる

Trust Tokens は、ウェブサイトがあるブラウジング コンテキストから別の閲覧コンテキスト（サイト間など）に限られた量の情報を転送できるようにする新しい API です。これにより、パッシブ トラッキングを行うことなく不正行為を防止できます。

Sam Dutton

まとめ

トラスト トークンを使用すると、オリジンは信頼できるユーザーに暗号トークンを発行できます。トークンはユーザーのブラウザに保存されます。ブラウザはトークンを他のコンテキストで使用して、ユーザーの真正性を評価できます。

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(...)

更新後のコード:

1. 利用ユーザー publisher.example が利用をリクエストしています。

2. クーポンの利用に成功すると、カード発行会社の issuer.example はクーポン レコードを返します。これは、ある時点で有効なトークンがこのブラウザに発行されたことを示します。

   7.fetch() から返された Promise が解決されると、以降のリソース リクエストでクーポン利用レコードを使用できるようになります。

fetch('https://foo.example/get-content', {
  trustToken: {
    type: 'send-redemption-record',
    issuers: ['https://issuer.example', ...]
  }
});

更新後のコード:

1. クーポン利用レコードは、リクエスト ヘッダー Sec-Redemption-Record として含まれます。
2. foo.example は、クーポン利用レコードを受け取り、レコードを解析し、issuer.example がこのユーザーが人間であると判断したかどうかを判断します。
3. foo.example はそれに応じて応答します。

トラスト トークンの発行

トラスト トークン発行者（issuer.example など）によってユーザーが信頼できると見なされる場合、カード発行会社は trustToken パラメータを使用して fetch() リクエストを行うことで、ユーザーのトラスト トークンを取得できます。

fetch('issuer.example/trust-token', {
  trustToken: {
    type: 'token-request'
  }
}).then(...)

これにより、新しい暗号プリミティブを使用して、プライバシー パス発行プロトコルの拡張が呼び出されます。

1. ノンスと呼ばれる擬似乱数のセットを生成します。

2. ノンスをブラインド化し（カード発行会社がコンテンツを表示できないようにエンコードします）、Sec-Trust-Token ヘッダーでリクエストに追加します。

3. 指定されたエンドポイントに 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 プラットフォームのステータス
• プライバシー パス
• プライバシー パスの拡張機能

この投稿の執筆およびレビューにご協力いただいたすべての方に感謝いたします。

写真撮影: ZSun Fu（Unsplash）