Googleが提案する「プライバシーバジェット」が抱える大問題とは？

by ranveer cool

インターネット上で個人を追跡するCookieのうち、広告取引に多く使われてきたサードパーティーCookieは、個人情報保護の観点から近年規制対象となりつつあります。サードパーティーCookieに大きく依存してきたGoogleは代替案の開発を急いでいますが、その代替案の1つ「プライバシーバジェット」にはいくつかの問題があると、Mozillaのエリック・レスコーラCTO(最高技術責任者)が言及しています。

Technical Comments on Privacy Budget
(PDFファイル)https://mozilla.github.io/ppa-docs/privacy-budget.pdf

Google's Privacy Budget doesn't add up, says Mozilla • The Register
https://www.theregister.com/2021/10/11/googles_privacy_budge/

サードパーティーCookie規制の流れを受け、GoogleはChromeでのサードパーティーCookieのサポートを2023年末までに廃止すると発表しています。GoogleはサードパーティーCookieの代わりになる広告システム「プライバシーサンドボックス」を提案しており、具体的内容は未定ながら、Google版CAPTCHAのような「トラストAPI」でボットか人間かを判別することや、個人を識別可能になる情報ごとに予算(バジェット)を与えて、その予算内で情報取得を可能にする仕組み「プライバシーバジェットAPI」、広告配信をサーバーではなくブラウザ単位で行う「TURTLEDOVE」などが提案され、議論されています。

レスコーラ氏はGoogleが取り組んでいるプライバシーサンドボックスのうち、プライバシーバジェットについて解説し、問題点を述べています。プライバシーバジェットを理解する上で重要な要素が、使用しているデバイスやインストールされているフォントといった細かなブラウザの特徴を使ってユーザーを識別する「フィンガープリント」というもの。フィンガープリントはユーザーを追跡するための一意の識別子を作成できる追跡技術ですが、「Cookieと異なりユーザーはフィンガープリントを削除できず、ユーザーが識別されることを避けたくても開発者はその方法を提供できない」という理由から、サードパーティーCookieの代替案としての採用を見送られたものでもあります。

フィンガープリントの可用性を制限できるとされているものがプライバシーバジェットです。プライバシーバジェットはフィンガープリントが取得可能な「識別子を作成するためのデータポイントの数」を減らすことにより、識別子が一意になることを防ぎ、ユーザーのプライバシーを強化できるものとされています。しかし、レスコーラ氏は「プライバシーバジェットではユーザーの追跡を防ぎきれない」と指摘しています。

まず、レスコーラ氏は「フィンガープリントにより取得されたすべての値が同じ情報内容を持っているわけではない」という点を指摘。例えば、「Chromeを使用している」という情報は多くのChromeユーザーがいる中ではあまり価値がありませんが、「Torを使用している」という情報は、Torを使用しているユーザーが少ないために価値が高まるとのこと。このため、個人を識別可能になる情報にバジェットを与える際に、その計算が難しく、計算方法も変動していくことが考えられます。

2つ目の問題は、サイトの機能に不可欠なAPIすらもバジェット内でやりくりする可能性があるという点。Googleはページにアクセスしたユーザーの画面幅を読み取る「window.screen」のようなAPIをどのように処理するかを明かしておらず、仮にこのようなAPIがバジェットにカウントされる場合、すぐに制限に達してしまう可能性があります。制限に到達することで、各サイトがページの構築に不可欠なAPIを呼び出すことができなくなり、サイトが体を成さなくなってしまう可能性があるともレスコーラ氏は述べています。レスコーラ氏は「プライバシーバジェットが適用される順序はサイトのネットワークパフォーマンスなどの要因により決定されるため、サイトやユーザーごとにパフォーマンスに大きな開きが出てくる可能性がある」と述べています。

3つ目の問題として、レスコーラ氏は「プライバシーバジェットそのものが追跡に利用される」と指摘。プライバシーバジェットは識別子の読み取りと管理の両方が可能ですが、両者は分割されていないため、プライバシーバジェットを読み込むことでクロスサイト追跡に利用できてしまうとのこと。

レスコーラ氏は「フィンガープリントを封じ込めようとするよりも、新しいWeb APIが開発されたときにフィンガープリントを制限し、既存のフィンガープリントを徐々に削除して不正なパターンを監視する方がよい」と主張しています。