名前は聞くがどういうものか把握していないので、ざっくりサマリとして理解する。
そもそもプライバシーサンドボックス（Privacy Sandbox）とは
Googleが提唱する仕組みで、今現在Cookieを利用してトラッキングや個人情報が容易に取得できてしまう状況を改善すべく考えられた概念。公式サイトから説明を抜粋すると以下。
プライバシー サンドボックス イニシアチブは、ユーザーのオンラインでのプライバシーを保護しながら、デジタル ビジネスの成功につながるツールを企業や開発者に提供することを目的としています。プライバシー サンドボックスは、クロスサイトやクロスアプリの追跡を制限しながら、オンラインのコンテンツやサービスをすべてのユーザーが無料で利用し続けられるようにします。 - プライバシーサンドボックス: プライバシー保護を強化したウェブのための技術です
かなり抽象的な概念なのだが、ウェブ向けにはもう少し具体が書いてある、同じく抜粋すると以下
ウェブ向けのプライバシーサンドボックスは、サードパーティ Cookieを段階的に廃止し、隠されたトラッキングも制限します。新しいウェブ基準を策定することで、データのプライバシー保護を強化しながらデジタル事業の構築を可能にします - プライバシーサンドボックス: プライバシー保護を強化したウェブのための技術です
Googleの書き方だとわかりにくい部分は多いが、上記の表現を言い換えると「3rdPartyCookieで様々なプライバシー情報が提供されている現状のため、それを廃止する。しかしそれをしてしまうとトラッキング広告などのWeb広告の市場としては死活問題になってしまうので、3rdPartyCookieよりもプライバシーを守る形でWeb広告の仕組みを維持できるための活動」と解釈するとわかりやすいかもしれない。
プライバシーサンドボックスを通して提供されるウェブ向けAPI
このプライバシーサンドボックスを実現するためにいくつかのAPIをChromeで提供しようとしている大きくは以下のもの
- Private State Tokens API
- Topics API
- Protected Audience API
- Attribution Reporting API
- First-Party Sets API
- Shared Storage API
- CHIPS
- Fenced Frames API
- Federated Credential Management API
1つずつざっくり見ていく
Private State Tokens API
「アクセスしてきたのが本当の人間か、botなどの人間ではないものかわかるようにしたい」という旨のニーズが原点にある機能。公式ドキュメントの内容を噛み砕くと以下。
- ログイン認証などを行った際にログインしたサイトから
TrustTokenを発行し、ユーザのブラウザに保存してもらう。（発行したサイトを発行者サイトという） - "発行者サイト"を信じている他サイトで、アクセスしてきた人が本当に人間か？ということを判定するために発行者サイトの
TrustTokenを持っているかブラウザに尋ねる TrustTokenがある場合は、そちらを利用し発行者サイトとやり取りをして本当にその人であるかを確認する。
元々はTrustTokenという名前で展開されていたものなので、その名称で説明されているサイトも多い。
関連リンク
Topics API
「ブラウザの閲覧情報からユーザの興味がある情報を第三者に渡したいが、プライバシーも守りたい」というニーズが原点にある機能。
予め用意された「トピックのリスト」があり、ブラウザは閲覧情報に基づいてそのユーザがどのトピックのサイトにアクセスしたかを記録する。その記録した情報をサードパーティは閲覧ができるのでそれらをつかってユーザへのコンテンツの出し分けなどを行ってもらう。このトピックの割り出しの仕組みなどはGitHubを参照のこと。
関連リンク
Protected Audience API
「広告主が再度同じユーザにアプローチをさせたいが、プライバシーを侵害したくない」というニーズが原点にある機能。いわゆるリターゲティングを行う仕組み。
いままではCookieを受け取り広告提供側が過去その広告に触れたことがあるかなどをチェックしながらリターゲティングを行っていたが、Protected Audience APIではいままでサーバ側に持たせていたそれらの仕組みをブラウザ上に移すことにより、広告事業者側に情報を渡さずブラウザでいままでの機構を代替しようとしている。細かい仕組みはGoogleのページを参考のこと。
なお、こちらも改名された機能で、いままでは FLEDGE と呼ばれていた仕組みではある。
関連リンク
Attribution Reporting API
「広告のクリック数などを計測したいが、プライバシーを侵害したくない」というニーズが原点にある機能。
広告のクリックや表示、サードパーティの提供するiframeの広告表示数などに関してブラウザを介すことで、サードパーティCookieを使わなくても実現することができる仕組み。具体としては関連リンク参照のこと。
関連リンク
First-Party Sets API
「ドメインの異なるサイトだが企業としては同じサイトで、それらのサイトに関してログイン状態やセッションを維持する際に、プライバシーを守りながら実現したい」というようなニーズが原点にある機能。本来はサードパーティCookieを使って再現していたがそこを機能化している。
情報を共有するサイトであるかどうかは事前にFirstPartySetのリストへの追加を依頼することで実現する仕様として策定している。
ただし、この仕組み自体にには過去に反対意見もあり現在も議論がされている模様
関連リンク
Shared Storage API
「複数のサイトで区切りのないデータの受け渡しをしたいが、意図しない相手へのデータ漏洩はさせたくない」というようなニーズが原点にある機能。
サードパーティCookieで実現していた複数サイト間で共有するような情報を代替できる機能というところで、具体の実装例はGitHub にある。
関連リンク
CHIPS(Cookies Having Independent Partitioned State)
「サードパーティCookieをトップレベルサイト別で扱うようにしてまたがないようにしたい」というようなニーズの機能。
AのサイトにCのサイトのiframe、BのサイトにもCのサイトのiframeのような実装のときに、AのサイトでCのサイトの某かを操作したかのサードパーティCookieの情報はBのサイトに移動したときにも取得できてしまう。このCHIPSはAのサイトでのCookie,BのサイトでのCookieにとそれぞれのサイトに情報を閉じ込めるような機能。
関連リンク
- Google Chromeが勧めるプライバシーサンドボックス技術のひとつ、CHIPSってなんぞ - Qiita
- Cookies Having Independent Partitioned State (CHIPS) - Chrome Developers
Fenced Frames API
「iframeのように他のサイトの内容を埋め込みたいけど、埋め込み元には情報を取得できないようにさせたい」というようなニーズが原点の機能。
文字通り、フェンスのような機能で fencedframe で宣言した「埋め込まれたサイト」から「埋め込み呼び出ししたサイト」情報取得もできなければ、逆の経路の「埋め込み呼び出ししたサイト」が「埋め込まれたサイト：の情報も取得できない。
これら2つのサイトが安全かつ適切なデータをやり取りするためには前述のSharedStorageAPIやProtectedAudienceAPIを利用することが想定に入っている。
関連リンク
Federated Credential Management API(FedCM)
「ID連携でサードパーティCookieを使うような仕組みではないものに」というニーズもありつつ、全体としてIDプロバイダとそれを利用する側が安全にID連携できるようにするための仕様。
サンプル実装などの例を見るに、ブラウザの機能として介すことでシームレスかつ安全にID連携を行えるようにしている。
もともとはWebIDと呼ばれていたときもある様子。
