Trust Tokens に現状どのような問題があるか
ここ数日で Trust Tokens について、Google が公開しているガイド、仕様、課題を読みました。Trust Tokens を読んだ理由は Cookie 規制に向けてどのように対応しようとしているのかキャッチアップするためです。
各種情報を読み進めていく中で、提言されておりまだ未解決な課題、私が個人的に抱いている疑念がありましたのでこの記事でまとめておきたいと思います。
なお、この記事では Trust Tokens についての概念や仕様は書いていません。最初はこのあたりの説明を書こうかと思っていたのですが、読み進めていくうちに Trust Tokens が本当に導入されるのか疑わしくなったため、それよりは課題を書いていった方がいいだろうという判断です。Trust Tokens については公開されているドキュメントをご覧ください。
とりあえず概念を掴みたい場合は以下の記事をお読みください。
仕様の詳細を読みたい場合は以下の記事をお読みください。
Trust Tokens の根幹をなしている Privacy Pass については以下の記事をお読みください。特にゼロ知識証明のくだりなど、Privacy Pass がどのように『プライバシー原則』を満たそうとしているのかは把握したほうがいいと思います。
ここから先は課題や疑念について説明しますが、全てのドキュメントを完全に読み切っている自信がないため、内容に誤りがある可能性があります。
また Trust Tokens は今後も改善が続けられるため、課題が解消される可能性があります。その点ご了承いただければと思います。
誰がどのサイトを訪れたかばれてしまう可能性
ある人が facebook.com と note.com の２つのサイトを使用しているとしたら「facebook.com の運営者に note.com を使っていることをバラしたくない」と期待する人はいると思います。
※いや自分はそんなことない、という人は上記の２つのサイトを他のサイトに置き換えてみてください。
現時点の Trust Tokens の仕様はこのプライバシー保護が壊れる可能性があります。同様の Issue が GitHub に投稿されています。
Trust Tokens はあるサイトに訪れてある操作を行った時にトークンを発行します。この時に発行されたトークンを所有しているか否かを判定するファンクションが新たに追加されます。それが document.hasTrustToken です。
hasTrustToken は既に Google Chrome に実装されていますが、特定のテスト用サイト以外では動作しないようになっています。現在はデモサイト（https://trust-token-redeemer-demo.glitch.me/）で動作します。
hasTrustToken の引数には発行者の URL を指定します。例えば今後 Facebook でトークンが発行されると仮定すると document.hasTrustToken("https://issuer.trusttoken.facebook.com") というパラメータになるかもしれません。
この hasTrustToken ですが今のところ呼び出すこと自体に制限は無いようです。また、パラメータについても制約は見つけられませんでした。この前提に基づくと、あるサイトが総当たりする形でどんなサービスのトークンを持っているのか調べることができてしまいます。
またトークンを発行して保存する際も特に同意画面などは出ないようです。2022年4月に施行される改正個人情報保護法では個人関連情報を含む Cookieを第三者に送る前に同意が必要になりますが、これを強制するメカニズムは無いようです。
つまり、自分の知らないうちにトークンが発行され、さらに他のサイトからどの発行者のトークンを持っているのか調べられてしまう可能性がある、ということです。「トークンの所持」が持つ意味合いはいろいろあり「単にサイトを訪れただけ」であったり「サイトにログインした」であったりします。
GitHub の Issue は未だ Open の状態であり、課題は解決されていません。私自身もこの課題は正式に Chrome へ取りこまれる前に解決すべき課題だと思います。
少なくともトークンを発行する時とトークンを参照するときはユーザの同意があって然るべき、というのが私の考えです。
これに関連する情報として、トークン展開の形態を整理したドキュメントがあります。
このドキュメントで説明されている形態で Third-Party Issuance, Public Redemption という形態に対して、説明したリスクがあります。このリスクについてはキャッチアップしたいと考えています。
なお、Microsoft Edge のチームからも Trust Tokens に関する同様の質問が出されています。
Trust Tokens 起因のフィンガープリントを取得され個人を追跡される可能性
先ほどの疑念に関連する内容になります。
先ほどの例では単一のサイトについて、訪れたかそうでないかを確認できるのでは？という問題でした。
今度は、非常に多くのトークンが発行されたら、そのトークンの有無で特定の個人を追跡できる可能性があります。
例えば I1 から I100 までの 100 の発行者があり、それらが全てトークンを生成するとします。つまりユーザは 100 ビットの情報を hasTrustToken というファンクションを経由して、他のサイトに晒すことになります。
この問題に関連するのが以下の Issue です。
GitHub の Issue では単一のサイトが大量の Token Issuer を持つケースについて懸念しています。
「発行」と「償還」時にリンクされる可能性
これは特に議論が見つからなかったのですが、Privacy Pass を読んでいた際に疑問だったので、備忘録として残しておこうと思ったものです。
まず Trust Tokens は「発行」と「償還」というフローがあります。発行（Issue）はトークンの生成を行う手続きです。償還（Redeem）はトークンと引き換えにアクティビティの証明を返すという手続きになります。
Privacy Pass のフローにも同様の内容が書かれています。
このフローにおいて「償還」の際に渡したトークンを基に「発行」した人が誰か判別できるべきではない、という工夫が Privacy Pass になされています。
この「発行」と「償還」のリンクを切り離すために、ハッシュやゼロ知識証明が用いられています。
ですが、実運用としては結局のところIPアドレスを使えば、やはり紐づけできるのでは？という懸念があります。
デモンストレーションサイトでは「発行」も「償還」も相手は一つのサイトであり、IP アドレスを記録しておけばその二つをリンクさせることが可能です。もちろん IP アドレスは変動しますので、必ずしもリンクされるわけではないのですが、短時間で「発行」と「償還」が行われた場合は高確率でリンクされてしまいます。
※ Privacy Pass はあくまで暗号論的に、リンクの切り離しを実現する方法を提示しているだけですので、Privacy Pass のフローを変える必要は無いと思います。
まとめ
いくつか気になった課題・疑念を簡単に書いてみました。GitHub の Issues を読むと分かりますが、いくつかのクリティカルな課題が未解決であり、Trust Tokens の正式導入はまだ時間がかかるという印象を持ちました。
Trust Tokens は広告を配信する際にボットに配信せず人間に配信するという、トラフィックの効率化に貢献する良い試みだと思います。ただし Trust Tokens を導入することによって、Cookie が始まったばかりの頃のカオスな状態に戻ってしまうことが無いよう、ウォッチが必要な仕様だと考えています。