トラストトークンの使用を開始する

Trust Tokensは、Webサイトが指定の量の情報を持つ閲覧コンテキストから別のブラウジングコンテキストに（たとえば、サイト間で）伝達できる新規APIであり、受動的な追跡なしで不正行為と戦うのに役立ちます。

Jun 22, 2020 — 更新済み Dec 10, 2021

Available in: English, Русский, 中文, and 한국어

Appears in: 安全とセキュリティ

Sam Dutton

Twitter GitHub

概要 #

Trust tokenで、オリジンは信頼を持つユーザーに暗号トークンを発行できます。トークンはユーザーのブラウザによって保存されます。その後、ブラウザは他のコンテキストでトークンを使用して、ユーザーの信頼性を評価できます。

Trust Token APIを使用すると、ユーザーを識別したり、2つのIDをリンクしたりせずに、あるコンテキストでのユーザーの信頼を別のコンテキストに伝達できます。

デモでAPIを試して、ChromeDevToolsのネットワークタブとアプリケーションタブでトークンを調べることができます。

Chrome DevToolsネットワークタブの信頼トークンを表示するスクリーンショット. — ChromeDevToolsの**ネットワーク**タブの信頼トークンNetwork tab.

Chrome DevToolsアプリケーションタブにTrust Tokenを表示するスクリーンショット. — ChromeDevToolsアプリケーションのタブのTrust Token

なぜTrust Tokenが必要なのですか？ #

Webには、ユーザーが本人であり、人間になりすましたボットや、実際の人やサービスをだましている悪意のあるサードパーティではないことを示す信頼信号を確立する方法が必要です。不正防止は、広告主、広告プロバイダー、およびCDNにとって特に重要です。

残念ながら、信頼性を測定して伝達するための既存のメカニズムは、たとえば、サイトとのやり取りが本当の人間によるものかどうかを判断するために、フィンガープリントの手法を利用しています。

重要な用語

フィンガープリントを使用すると、サイトは、デバイス、オペレーティングシステム、ブラウザの設定（言語設定、ユーザーエージェント、使用可能なフォントなど）やデバイスの状態の変化に関するデータを取得することで、個々のユーザーを識別および追跡できます。これは、サーバー上でリクエストヘッダーをチェックするか、クライアント上でJavaScriptを使用して実行できます。フィンガープリントは、ユーザーが認識しておらず、制御できないメカニズムを使用します。 Panopticlickやamiunique.orgなどのサイトでは、指紋データを組み合わせて個人を識別する方法を示しています。

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

トラストトークンの提案には何が含まれていますか？ #

Webには、詐欺やスパムを検出するために信頼信号を構築することが重要です。これを行うには、グローバルなクロスサイトのユーザーごとの識別子を使用してブラウジングを追跡することです。プライバシーを保護するAPIの場合、これは受け入れられません。

提案説明者から：

このAPIは、サードパーティのコンテキストでアクセス可能な「プライバシーパス」スタイルの暗号化トークン用の新しいオリジンごとのストレージ領域を提案します。これらのトークンは個人化されておらず、ユーザーの追跡には使用できないが、暗号化されているため、偽造することはできません。
オリジンがユーザーを信頼するコンテキストにある場合、ユーザーが不明または信頼性が低いコンテキストで次回で「使用される」可能のトークンのバッチをブラウザーに発行できます。トークンが互いに区別できないため、Webサイトがトークンを介してユーザーを追跡できないことは重要になります。
さらに、特定のトークン償還にバインドされたキーを使用して送信リクエストに署名するためのブラウザの拡張メカニズムを提案します。

サンプルAPIの使用法 #

以下は、API Explainerのサンプルコードを基にしています。

ユーザーがサードパーティの広告ネットワーク(foo.example)からの広告を埋め込んだニュースWebサイト(publisher.example)を想像してください。ユーザーは以前、trust tokenを発行するソーシャルメディアサイト(issuer.example)を使用しました。

以下のシーケンスは、trust tokenがどのように機能するかを示しています。

**1.**ユーザーはissuer.example に訪問し、アカウントアクティビティや、CAPTCHAチャレンジの通過など、自分が本物の人間であるとサイトに信じ込ませるアクションを実行します。

2. issuer.exampleは、ユーザーが人間であるかを確認し、次のJavaScriptを実行して、ユーザーのブラウザーにtrust tokenを発行します。

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

**3.**ユーザーのブラウザはtrust tokenを保存し、 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', ...]
  }
});

上記のコードで：

償還レコードは、リクエストheader Sec-Redemption-Recordとして含まれています。
foo.exampleは償還レコードを受け取り、レコードを解析して、 issuer.exampleがこのユーザーを人間であると見なしたかどうかを判断できます。
foo.exampleはそれに応じて応答します。

Webサイトは、あなたを信頼するかどうかをどのように判断できますか？

eコマースサイトでのショッピング履歴、ロケーションプラットフォームでのチェックイン、または銀行でのアカウント履歴を持っているようです。発行者は、あなたがアカウントを持っている期間や、あなたが本物の人間である可能性に対する信頼を高める他の相互作用（CAPTCHAやフォーム送信など）などの他の要因も調べる場合もあります。

トラストトークンの発行 #

ユーザーがissuer.exampleなどのtrust token発行者によって信頼できると見なされた場合、 trustTokenパラメーターとfetch()リクエストを行うことにより、ユーザーのtrust tokenを取得できます。

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

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

nonces呼ばれる疑似乱数のセットを生成します。
nonces をブラインドし（発行者がコンテンツを表示できないようにエンコードし）、 Sec-Trust-Tokenヘッダーでリクエストに添付します。
提供されたエンドポイントにPOSTリクエストを送信します。

エンドポイントはブラインドトークン（ブラインドナンスの署名）で応答し、トークンはブラインド解除され、ブラウザーによってtrust tokenとして関連するナンスと一緒に内部に保存されます。

trust tokenの償還 #

パブリッシャーサイト（ 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リクエストheaderとして含まれています。

プライバシーに関する考慮事項 #

トークンは「紐付け不可」の形で設計されています。発行者は、ユーザーがアクセスするサイトに関する集約情報を入手できるが、発行と償還を関連付けることはできません。ユーザーがトークンを償還するとき、発行者は、作成済みのトークンと区別することはできません。ただし、現在、trust tokenは空白の状態では存在しません。サードパーティのCookieや秘密の追跡技術など、発行者が現在（理論的には）サイト間でユーザーのIDを結合できる方法は他にもあります。サイトがサポートを計画する際には、このエコシステムの移行を理解することが重要です。これは、多くのプライバシーサンドボックスAPIの移行の一般的な側面であるため、ここではこれ以上説明しません。

セキュリティに関する考慮事項 #

Trust tokenの消耗： 悪意のあるサイトは、特定の発行者からのユーザーのトークンの供給を故意に消耗させる可能性があります。この攻撃には、発行者が一度に多くのトークンを提供できるようにするなど、いくつかの緩和策があります。そのため、ユーザーは、ブラウザがトップレベルのページビューごとに1つのトークンを引き換えることを保証する十分な供給があります。

二重利用の防止： マルウェアは、ユーザーのすべてのtrust tokenにアクセスしする意図を持ちます。ただし、すべての償還は同じトークン発行者に送信されるため、トークンは時間の経過とともに使い果たされます。これにより、各トークンが1回だけ使用されていることを確認できます。リスクを軽減するために、発行者はより少量のトークンに署名することもできます。

リクエストメカニズム #

たとえば、ナビゲーションリクエストfetch()外部で償還レコードを送信できる場合があります。サイトは、HTTP応答headerに発行者データを含めて、ページの読み込みと並行してトークンの引き換えを有効にできる場合があります。

繰り返しになりますが、この提案にはあなたのフィードバックが必要です。 コメントがある場合は、TrustToken説明リポジトリに問題を挙げてください。

詳細をご覧ください #

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

写真はZSun Fuに撮影され、Unsplashにアップロードされました。

最終更新

Dec 10, 2021 — 記事を改善する

Return to all articles

共有する

サブスクライブする