Googleはプライバシーサンドボックスの一環として、Privacy Budgetという提案を発表しています。
簡単に言うと、得られる情報に上限を設けようというアイデアです。
使用できる予算(budget)をたとえば100点と決めておき、ユーザエージェントを取得したら10点、IPアドレスを取得したら30点、みたいなかんじで点数がたまっていき、上限の100点を超えたらもう識別情報は取り出せません、みたいなかんじです。
これによって取得できる情報を制限し、フィンガープリントの危険性を減らすわけですね。
以下は該当のRFC、Combating Fingerprinting with a Privacy Budgetの日本語訳です。
Combating Fingerprinting with a Privacy Budget
Current state of affairs
現状。
ブラウザによるCookieの扱いは大きく変わりつつあります。
Cookieをブロックするための大鉈が振るわれようとしており、それに対してユーザを追跡したい側はより地下に潜り、より検出されにくい方法を編み出そうとしています。
あるユーザのブラウザからユニークな情報を取り出すための様々な技術が、ブラウザフィンガープリントとして知られています。
ブラウザフィンガープリントは透明性がなく、またユーザのコントロール下にもないため、結果としてユーザの意志を無視したトラッキングが行われています。
End state to aim for
目指している着地点。
個々のユーザに関する情報をどれくらい公開するかを制限することで、個人を特定し追跡することができないようにし、集団の一員として程度の粒度の情報しか渡さないようにします。
サードパーティに共有する情報量から、ユーザを特定できる度合いを定量化する方法はいくつか知られています。
・k-anonymity kは同じ情報を持つユーザ数
・entropy 情報理論による不確実性の度合い
・differential privacy 集計結果から個人を抽出できないようにする技術
各ユーザの情報を公開する場合の最大許容量を、ここではプライバシーバジェット(privacy budget)と呼ぶことにします。
What is a fingerprinting surface?
フィンガープリントとは、ユーザもしくはデバイスごとに安定もしくは準安定した何らかの基準を取り出すことです。
明白な例としては、そのデバイスのモデルやハードウェアなどです。
これらはJavaScriptのAPI、ヘッダやIPアドレスなどのネットワーク識別子、言語、処理にかかる時間などから取得できます。
逆に言うと、ユーザに関するあらゆる情報がフィンガープリントとして利用できます。
ただし、大部分は単体では意味がなく、他の複数の情報源と組み合わせた場合にのみ有効になります。
How to get there
実装方針
Measure information exposed by each fingerprinting surface
フィンガープリントで取り出された情報を集める。
各ブラウザは、フィンガープリントで明らかにされた情報を収集し、テレメトリに渡します。
このデータは次フェーズで使用されます。
Measure total information exposed to each site
取り出された情報の総量を集計する。
テレメトリに渡されたデータを用いて、各サイトでどれだけのフィンガープリントが公開されたかの情報量を集計します。
これは、ほとんどのサイトが見れなくなるなどの障害を引き起こさないために、どの程度の制限を行えばよいかを決定するために使用します。
この測定は、ユーザとドメインとの情報のやり取りを全て含む必要があります。
また、個々のドメインに対してデータの報告が許可されれれば、制限を超えているサイトに対して制限を下回るように要求することも可能です。
Enforce the privacy budget
Privacy Budgetの適用。
Privacy Budgetの上限に引っかかった後は、対象のAPIコールは、エラーが発生するか、不正確なノイズの多い結果が返るか、実情に関わらず定数値を返すようになります。
また上限に引っかかった後は、ストレージやネットワークへのリクエストを拒否し、学習された新しい情報を流出させないようにします。
Exceptions
例外。
3Dゲームやビデオ会議など、Privacy Budgetの適用範囲内ではどうしても実行できないようなアプリケーションも存在するでしょう。
その場合は、特別にアクセスを許可するサイトをユーザが指定できるようにしなければなりません。
適切な言葉でユーザに許可を求めるプロンプトが必要となります。
また、ある種の許可プロンプトを求めるAPIコール(getUserMediaなど)は、それ自身が予算を超えるAPIコールになる可能性があります。
そのようなプロンプトには予算獲得の例外を与えますが、プロンプトにはそのことを示さなければなりません。
Passive surfaces
受動的な情報について。
ユーザエージェント、IPアドレス、Accept-Languageヘッダなど幾つかのフィンガープリントは、それらが要求されようがされまいが常に全てのWebサイトに公開され利用可能である受動的な要素です。
従って、それらはPrivacy Budgetの予算を無駄に浪費している、と考える必要があります。
多くの開発者は、ユーザのOSを知ることに予算を使うよりも、もっと有益なことに予算を使いたいと考えます。
従って、我々は受動的なフィンガープリントをできるだけ取り除き、開発者が必要とする情報を能動的に取得する方法に置き換えていかなければなりません。
OSバージョンの例では、たとえばダウンロードサイトなのでOSを知りたいといった場合は、ユーザエージェント文字列を使ってOS以外の情報までも引っ張ってきてしまうよりは、Client Hintsを通してOS情報のみを取得するようにすべきです。
同様に、言語による出し分けを必要とするWebサイトのみClient Hintsを使ってユーザの言語を照会するようにできるでしょう。
感想
アホか。
あまりにしょうもないアイデアなせいか、コミット数僅か19であり1年以上も更新されていないと、やる気が全く見えません。
ところがしかしThe Privacy Sandboxでは未だに堂々と記載されるなど、Googleはこのアイデアを諦めきってはいないようです。
Mozilla
このプロポーザルについて、Mozillaがレポートしています。
レポートのPDFはすごい分量になっていて読みきれません。
主張を簡単にまとめると、『プライバシー問題への対策にはなりそうもない』。
たとえばChromeはみんなが使っているので、Chromeを使っていることがわかっただけでは全く識別子になりません。
いっぽうFirefox Nightlyを使っているユーザはほとんどいないので、Firefox Nightlyを使っているというだけでほぼ特定できたに近い状態になります。
このように値ひとつをとってもその粒度が大きく異なるため、適切な予算を算出することが極めて困難です。
さらに複数要素による予算組み合わせ爆発問題もあります。
たとえば画面幅と画面の高さは異なる値ですが非常に相関性が高いので、それぞれが予算1としても足し合わせたら1.2くらいにしかなりません。
それに対して画面幅とOSは、足し合わせたら1.8くらいの予算にはなるでしょう。
このように組み合わせを考え始めたらきりがありません。
さらに、ブロッキングメカニズムがそれ自体フィンガープリントになるという指摘もあります。
すなわち、どこの時点で予算を使い切ったかを調べることで、識別要素がひとつ増えるというわけです。
その他にも様々な指摘がなされていますが、まとめるとMozillaとしてはこのアイデアは問題外という立場です。
そしてMozillaですら実装しないということは当然SafariやBraveやその他のブラウザが実装することもないので、Privacy BudgetはいつものようにChromeの独自仕様になることでしょう。
↧