こんにちは。@otolabです。

Webのプライバシー保護について大きな動きが続いています。

現在の中心的な議論は、主に広告目的で行われるクロスサイトのトラッキング防止です。SafariのITPは有名ですが、ブラウザベンダー各社がさまざまな取り組みを行っており、なかでもトップシェアを占めるChromeを開発するGoogleが発表しているのがPrivacy Sandboxです。

Privacy Sandboxを簡単に説明すると、ユーザのクロスサイトラッキングによるプライバシー問題を解消するための一連の機能・技術開発を行うプロジェクトです。プライバシー保護と同時に、Webの大きな収益元である広告システムを破壊しないという観点を持っていることが特徴です。

大きなタイムスケジュールとしては「二年以内の3rd party cookieの廃止」を掲げており、それまでに代替機能群の提供を行うことがPrivacy Sandboxの目指すところとなります。

ニュースサイトなどでも簡単に紹介はされているものの、プロジェクトの各要素について深く解説している記事があまりないので、PLAID Engineer Blog初の連載として解説していきたいと思います。

第一回である今回は、Privacy Sandboxの全体像について読み解いて行きましょう。

全体像を読みとく

全体像に関する情報としては、以下の4つが挙げられます。

Building a more private web
- Privacy Sandboxを公表した記事（2019年8月22日公開）
Potential uses for the Privacy Sandbox
- Building a more private webを補強するblog記事（2019年8月22日公開）
A Potential Privacy Model for the Web
- プライバシーモデルの解説ページ
The Privacy Sandbox
- プロジェクトのページ

ここではそれぞれのページの概要と、ポイントとなる箇所を解説します。

Building a more private web

「Privacy Sandbox」の取り組みの表明を行っている記事です。

まず、プライバシーが最優先の問題であるとおき、問題に対するオープンスタンダードを開発するイニシアチブとして、Privacy Sandboxを発表するとあります。

現行の技術がプライバシーに対するユーザの期待に一致していないとした上で、他のブラウザでの対応については、取り組みが標準化されていないこと、Cookieのブロックがfingerprint技術に向かってしまうこと、Webサイト運営のための広告収入が減ってしまうことを問題点として挙げています。

広告収入に関しては、Cookieを廃することで平均52%の財源を失うと具体的な数字も挙げてるところが面白いですね。

Googleのこれまでの取り組みとして、cookieの分類と制限の強化、fingerprint技術に対する制限を挙げており、この先の取り組みとして、パーソナライゼーションとプライバシー保護を両立する一連の標準技術を開発するとしています。

開発についてはweb標準のプロセスを経て数年掛かりでとりくむこと、フィードバックを求めていることなどを表明して締めています。

Potential uses for the Privacy Sandbox

Building a more private webと同時に発表されたChromiumのブログ記事です。基本的な論調は同じですが、具体的な内容について触れています。

まず、広告エコシステムがどのようにユーザ情報を使っているかについて「広告の選択（Ad Selection）」「効果測定（Conversion Measurement）」「不正防止（Fraud Prevention）」の3つに分類しています。

「広告の選択（Ad Selection）」は広告のパーソナライズについて。現在の3rd party cookieを使う閲覧履歴からのターゲティング・リターゲティング広告などを想定していると思われます。

ここでの課題は、ブラウザから個人を特定できない形でいかにグルーピングできるか。これについて差分プライバシー（Differential Privacy）技術をベースに、連携学習（Federated Learning）のような新しい技術を使って、実現できるとしています。

「効果測定（Conversion Measurement）」は広告の効果測定について。広告を改善するために重要であり、これは広告主・ユーザの双方に利益があるとしています。これについてはユーザをトラッキングせずに効果測定を行う方法をApple（Safari）も発表しているとあり、おそらくこのあたりを指しているのではないかと思います。

「不正防止（Fraud Prevention）」は広告詐欺への対処について。偽のユーザによる広告配信水増し等の問題を指しているようです。これについてはCloudFlareのPrivacyPass tokenが標準化のプロセスにのっていると紹介しています。

以上、広告エコシステムでのいわばフェアユースについての解説の後には、「サンドボックス境界の保護（Protecting the Sandbox Boundary）」としてフィンガープリント技術への対策について述べています。

ここでは他のブラウザのように単純に個人を特定する機能を除外すると、フィンガープリントなど回避策の開発に向かわせてしまうこと、またフィンガープリントはクッキーと異なり消すことのできないので、より問題が大きいと主張しています。

対策として提案しているのが「プライバシー予算（Privacy budget）」です。ユーザによって異なる小さな情報を組み合わせて個人を特定するのがフィンガープリントの技法であるため、一定の回数内（予算内）でしか情報の取得を行えないようにするというのがその考え方のようです。

A Potential Privacy Model for the Web

Webシステム上でのユーザの識別子（identity）について何が守られ、どのように活用されるべきかという原則について考察しています。Privacy Sandboxのプロジェクトのページで、課題にアプローチする原則を解説したもの、と紹介されている文章です。

まず現在のWebのidentityモデルでは、相互作用する2つのブラウザ機能「CookieやWeb Storageなどある範囲で共有・保持されるidentity」と「ブラウザ内でのjs, redirect, postMessageなどによる情報のやり取り」の相互作用によって、広く共有された識別子（widely-shared cross-site identities）を実現し、ウェブ全体での追跡（web-wide tracking）を可能にしていると説明しています。（フィンガープリント等も同様の目的で使われるとあります）

このようなグローバルな識別子（global identity）は閲覧履歴をまとめることに利用できるため、プライバシー上の懸念を引き起こしており、反面、広告のエコシステムに対しても重要な役割を果たしていると続きます。

そして、新しいモデルについての議論では「どの範囲まで個人の識別を許可するか？」「どのように分離を損なうことなく、境界を越えて情報を移動させるか？」の2つの質問に答える必要がある。と議論の前提部分をまとめています。

そこからは各テーマについて箇条書き（？）のスタイルで議論を進めています。以下、簡単にまとめていきます。

identityはFirst Party Siteごとに分かれるべき

サイトごとにidentityは分離されているべきだという話です。Cookieやフィンガープリントのようなものは、クロスサイトで統合できないように制限されます。

「First Party」はeTLD+1より広いのが合理的であるとしています。このあたりはFirst-Party Setsの話につながっていくようですね。

また「PayPalで支払う」や「Facebookでログイン」のようなサービスは、First Party間でのidentity結合にあたり、このときブラウザは適切にユーザを補助する必要があるとしています。

3rd partyに1st partyのidentityへのアクセスを許可できる

ある特定の3rd partyへの特権として、1st partyごとのidentityへのアクセスを許可できるべきだとしています。理由としては、composabilityがWebの中心であり、たとえばanalyticsやad serverを1st partyとして持つことはリーズナブルではないということを挙げています。

Google Analyticsなどのサービスを提供しているGoogleならではという感じがしますね。外部サービスの自社ドメイン内への組み込み（いわゆるCNAME Cloaking）に対する考え方にも関わってきそうです。

3rd partyがどのように情報を持てるか（例えばdouble-keyingにすべきかどうか）や、どのように許可・不許可を与えるかについては未解決の問題であるとしています。

1st partyごとのidentityは、少量のクロスサイト情報とだけ関連付けられる

1st party間でのidentityの結合を制限することは前提として、有用な情報は流す余地があるという主張が最初の項目となっています。少量の情報（small amounts of information）という曖昧さは、user privacyとweb platform usabilityの間をケースバイケースでバランスさせる必要があることを表しているとのこと。

「It may be OK」「It would not be OK」の書き出しでいくつかのケースを挙げています。

It may be OK
- 十分に特徴が匿名化できる場合
- 重要でまれなクロスサイトイベント、コンバーションなどの場合
- ユーザが存在するという証明など
It would not be OK
- ユーザの訪問ドメインを学習出来てしまう状況（サイト横断で表示される広告などを取っ掛かりにするケースなど）

「少量」以上の情報については、1st partyごとのidentityを関連付けることができないようにすべきとしています。例として、Conversion Measurement with Aggregation Explainerについて触れていて、これは集計処理を使って個人の特定から逃れようとする試みである、とのこと。

最後に、related workとして下記が挙げられています。

The Tor Browser design's "Privacy Requirements", particularly the clear emphasis on "Unlinkability".
Mozilla has published an anti-tracking policy: https://wiki.mozilla.org/Security/Anti_tracking_policy
WebKit published a related tracking prevention policy: https://webkit.org/tracking-prevention-policy/

The Privacy Sandbox

Privacy Sandboxのプロジェクトページです。

概略として、ミッションを「ユーザを尊重しデフォルトが非公開になる、繁栄するWebエコシステムの構築（Create a thriving web ecosystem that is respectful of users and private by default.）」、克服すべき主な課題はクロスサイト・トラッキングであると明言しています。

Webの魅力の一部（part of the magic of the web）について、コンテンツのクリエーターがゲートキーパーなしに公開できユーザが自由（freely）にアクセスできることであるとおき、その上で、そこでの広告は広告主などにとって価値があり、ユーザにとっても関連性があるものならば魅力的で困らせることはない。としています。

プランとして、健全なユースケースについて代替手段を用意して3rd party cookieは最終的に廃止すること、また並行してフィンガープリンティングなどのクロスサイトトラッキングの技術と戦うと説明しています。

これ以降はそれぞれの要素技術のリンクと解説が、目的・内容別にリストアップされています。目的の大分類としては下記の3つです。

クロスサイトトラッキングが提供する機能の置き換え
サードパーティのCookieを無効にする
（フィンガープリント等の）回避策の鎮静化

また、フィンガープリント対策に関しては、サブページが存在しています。

本連載で取り上げる予定の構成要素に関しては、ざっくりですが次の項で。

構成要素

Privacy Sandboxは、新しい技術の提案と従来から進められている開発の集合です。構成する要素について、いくつか注目すべきものについてリストアップしてみました。

Federated Learning of Cohorts（FLoC）
- https://github.com/jkarlin/floc
- ブラウザが作るユーザのグルーピング
TURTLEDOVE
- https://github.com/michaelkleber/turtledove
- ブラウザ内で「どの広告を出すべきか」判定できるようにする
Trust Token API Explainer
- https://github.com/WICG/trust-token-api
- 広告の水増しのための不正アクセスなどを除外するための仕組み
Click Through Conversion Measurement Event-Level API Explainer
- https://github.com/csharrison/conversion-measurement-api
- 広告のクリックスルー、購入をそれぞれ計測し、ブラウザが集計してサイトにhook的にレポートする仕組み
Aggregated Reporting API
- https://github.com/csharrison/aggregate-reporting-api
- 書き込みは任意のタイミングで、読み込みは複数クライアントの集計のみをhook的に行うAPIの提案
First-Party Sets
- https://github.com/krgovind/first-party-sets/
- ドメイン(origin)≠組織である場合に対して、明示的にグルーピングする仕組み
Combating Fingerprinting with a Privacy Budget
- https://github.com/bslassey/privacy-budget
- fingerprintに使える情報の取得を制限する
WebID
- https://github.com/samuelgoto/WebID
- 連合（Federated）ログイン

これから何が起きるのか

さて、Googleが目指すところは以下のようにまとめられるかと思います。

広告エコシステムを維持したうえで、プライバシー・セキュリティを担保する
3rd party cookieで実現していたユースケースを新しい専用APIで置き換える
3rd party cookie、fingerprintその他のトラッキング手法は許容しない

この方針に沿って必要になる技術・アイデアをまとめたのがPrivacy Sandboxの正体です。

気になるのは、これがどのように実現される、あるいは実現されないのか。あくまで個人的な予測に過ぎませんが、少し先の展望を書いてみたいと思います。

大きな流れとして、3rd party cookieの廃止はすでに既定路線です。現在求められているプライバシーのレベルに、性善説で成り立っている古典的なcookieの仕様がマッチしていないといえます。Safariではいち早くこれを廃止することを宣言しました（Full Third-Party Cookie Blocking and More）。Fingerprintについても同様で、これを防止することについては、方法や時期はともあれ各社足並みがそろっているといえます。

同時に、3rd party cookie廃止で「出来なくなること」をどうするかというのは課題です。現在、緩い規制によって様々な機能の起点として働いている3rd party cookieを廃止するために、Webというプラットフォーム・ブラウザの責任範囲を変更するという捉え方もできるかと思います。

First-Party Setsのような、あまり文句の付け所のない仕様については採用は進むのではないかと思われます。また、広告の効果測定（コンバーション測定）に関しては、Safariも対応を（Chromeより先に）用意しているくらいですので、今までとは違った方法ではあるものの、測定自体はできるようになるのではないでしょうか。形式が統一されることは望みたいところですが……。

Mozilla PersonasのBrowserIDによく似たWebIDの分野も、仕様が支持されれば広く実装される可能性があるかもしれません。

そしてPrivacy Sandboxでは広告に関してそれ以上のこと、FLoCやTURTLEDOVEなど、広告のパーソナライズや出し分けに関わる部分まで仕様化しようとしています。ただ、複雑な仕様ですし、他のブラウザがどこまで追従してくるか、あるいは追従するモチベーションがあるかは難しいところではないかと思います。braveやFirefox Better Webなどの現状の広告の仕組みを無効化した上で別の収益モデルを確立しようという試みも（もしかすると）ライバル関係になってくるかもしれません。

現在のChromeが一強といえるシェアを占めるなかで、実装が進んだとき、どの程度エコシステムが回るか注目です。Googleが実装や仕様ではなく、アイデア段階の提案を公開して意見を募っているのも、本当に受け入れられるかを確認しながら進めたいという意図なのではないかと感じました。

今後の連載について

今後この連載は、2週に一回程度の不定期更新で進めたいと思っています。

次回は、FLoCとTURTLEDOVEについての記事を予定しています。どちらも提案レベルで実装が見えていない段階のものですが、Googleらしいアグレッシブな提案となっています。

その先はまだ未定ですが、First-Party SetsとWebIDは早めに記事にしたいと考えています。

また、追加の情報や内容の問題点の指摘、記事のリクエストなど、ご意見いただけると幸いです。

参考

いつもの

CX（顧客体験）プラットフォーム「KARTE」を運営するプレイドでは、Webの未来を考えたい！ KARTEの開発に興味がある！というエンジニア（インターンも！）を募集しています。

詳しくは弊社採用ページまたはWantedlyをご覧ください。もしくはお気軽に、下記の「話を聞きに行きたい」ボタンを押してください！

Privacy Sandboxはなにを語るのか