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

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

Sam Dutton

まとめ

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

Trust Token API を使用すると、ユーザーを特定したり 2 つの ID をリンクしたりすることなく、あるコンテキストにおけるユーザーの信頼を別のコンテキストに伝達できます。

デモで API を試し、Chrome DevTools の [ネットワーク] タブと [アプリケーション] タブでトークンを検査できます。

Trust Token が必要な理由

ウェブには、ユーザーが本人であることを示す信頼シグナルを確立する手段が必要です。人間のふりをする bot や、悪意のある第三者が実際の人物やサービスを不正に利用するものであってはなりません。不正からの保護は、広告主、広告プロバイダ、CDN にとって特に重要です。

残念ながら、サイトとのやり取りが実在の人間によるものかどうかを調べるなど、信頼性を測定して伝播する既存のメカニズムの多くは、フィンガープリントにも使用できる手法を利用しています。

API はプライバシーを保護し、個々のユーザーを追跡することなく信頼をサイト間で伝播できるようにする必要があります。

Trust Token の提案の内容

ウェブは、信頼シグナルを構築して不正行為やスパムを検出します。これを行う方法の一つとして、グローバルでクロスサイトごとのユーザー識別子を使用してブラウジングをトラッキングする方法があります。プライバシー保護 API の場合、これは許容されません。

プロポーザルから:

この API は、サードパーティのコンテキストでアクセスできる「プライバシー パス」スタイルの暗号トークン用に、オリジンごとの新しいストレージ領域を提案しています。このトークンはパーソナライズされておらず、ユーザーの追跡には使用できませんが、暗号署名されているため、偽造はできません。

オリジンがユーザーを信頼しているコンテキストにある場合、ブラウザに一連のトークンを発行できます。トークンは、本来はユーザーが不明であるか信頼性が低いコンテキストで「使用」される可能性があります。重要なのは、2 つのトークンを区別できないため、ウェブサイトがトークンを使用してユーザーをトラッキングできない点です。

さらに、特定のトークン利用にバインドされた鍵でブラウザが送信リクエストに署名できる拡張メカニズムも提案します。

API の使用例

以下は、API 説明のサンプルコードから編集したものです。

あるユーザーが、第三者の広告ネットワーク（foo.example）の広告が埋め込まれたニュース ウェブサイト（publisher.example）にアクセスしたとします。このユーザーは、トラスト トークン（issuer.example）を発行するソーシャル メディア サイトを以前に利用しました。

以下のシーケンスは、トラスト トークンの仕組みを示しています。

1.ユーザーが issuer.example にアクセスし、アカウント アクティビティや CAPTCHA チャレンジを通過するなど、サイトに対して人間であると判断させるアクションを実行します。

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 リクエスト ヘッダーとして含まれます。

プライバシーへの配慮

トークンは「リンク解除不可」に設計されています。カード発行会社は、ユーザーがアクセスしたサイトに関する集計情報を取得できますが、発行とクーポンの利用をリンクすることはできません。カード発行会社は、ユーザーがトークンを利用した際、作成済みの他のトークンとトークンを区別することはできません。ただし、トラスト トークンは現在単独では存在しません。発行元が理論的には、サードパーティ Cookie や秘密トラッキング技術など、サイト間でユーザーの ID に参加させる方法は他にもあります。サイトがサポートを計画する際には、このエコシステムの移行を理解することが重要です。これは、多くのプライバシー サンドボックス API の移行の一般的な側面であるため、ここでは詳しく説明しません。

セキュリティ上の考慮事項

トラスト トークンの枯渇: 悪意のあるサイトにより、特定の発行元からのトークンが意図的に枯渇する可能性があります。この種の攻撃に対する緩和策はいくつかあります。たとえば、カード発行会社が一度に多くのトークンを提供できるようにすることで、ブラウザがトップレベル ページビューごとに 1 つのトークンのみを利用するように、ユーザーが十分な供給を確保できるようにするなどです。

二重支出の防止: マルウェアがユーザーのトラスト トークンすべてにアクセスを試みる可能性があります。ただし、すべてのクーポンが同じトークン発行者に送信され、各トークンが 1 回だけ使用されていることが検証されるため、トークンは時間が経つとなくなります。リスクを軽減するため、カード発行会社は署名するトークンの数を減らすこともできます。

リクエスト メカニズム

ナビゲーション リクエストなどで、利用記録を fetch() の外部で送信できる場合があります。また、HTTP レスポンス ヘッダーにカード発行会社のデータを含めて、ページの読み込みと並行してトークンを利用可能な場合もあります。

繰り返しになりますが、この提案には皆様のフィードバックが必要です。コメントがある場合は、Trust Token の説明リポジトリでイシューを作成してください。

補足説明

• Trust Token のデモ
• Chrome のオリジン トライアルのスタートガイド
• プライバシー サンドボックスの詳細
• Trust Token API の説明
• Chromium プロジェクト: Trust Token API
• 実装の目的: Trust Token API
• Chrome プラットフォームのステータス
• プライバシー パス
• プライバシー パスの拡張機能

この投稿の作成とレビューにご協力いただいたすべての皆様に感謝いたします。

写真撮影: ZSun Fu、Unsplash