プライバシー サンドボックスの詳細

プライバシー サンドボックスは、サードパーティ Cookie やその他のトラッキング メカニズムを使用せずに、サードパーティのユースケースに対応するための一連の提案です。

まとめ

• この投稿では、プライバシー サンドボックスの提案での API とコンセプトについて概説します。
• 提案作成者は、コミュニティ、特に広告スペースの関係者（パブリッシャー、広告主、広告テクノロジー企業）からのフィードバックを募って、不足しているユースケースを提案し、ビジネス ユースケースをサポートする方法について情報を共有します。
• この提案についてコメントするには、以下のリンク先のリポジトリで問題を報告してください。
• この投稿の最後に、提案に関する用語集もご用意しています。

---

ウェブ上のプライバシーの現状

ウェブサイトでは、他社のサービスを利用して、分析や動画の配信など、さまざまなことを行っています。コンポーザビリティは、ウェブの特殊能力の一つです。特に注目すべきは、広告がサードパーティの JavaScript や iframe を使用してウェブページに含まれている点です。広告の表示、クリック、コンバージョンは、サードパーティの Cookie とスクリプトによってトラッキングされます。

しかし、ウェブサイトにアクセスしても、関与しているサードパーティや、そのサードパーティがデータをどのように使用しているかに気づかない可能性があります。パブリッシャーやウェブ デベロッパーでさえも、サードパーティのサプライ チェーン全体を理解していないかもしれません。

現在、広告選択、コンバージョン測定、その他のユースケースでは、安定したクロスサイト ユーザー ID を確立する必要があります。これまではサードパーティ Cookie が活用されていましたが、各ブラウザでの Cookie へのアクセスは制限され始めています。また、クロスサイト ユーザー トラッキングのための他のメカニズムの使用も増えています。たとえば、秘密のブラウザ ストレージ、デバイスのフィンガープリント、メールアドレスなどの個人情報のリクエストなどです。

これはウェブのジレンマですサイトをまたいでユーザーを追跡できるようにせずに、サードパーティの正当なユースケースをサポートするにはどうすればよいですか？

具体的には、サードパーティによる広告表示や広告パフォーマンスの測定は許可する一方、個々のユーザーのプロファイリングは許可しないようにすることで、コンテンツに資金を投じるにはどうすればよいのでしょうか。広告主やサイト所有者は、デバイスのフィンガープリントなどのダークパターンに頼ることなく、どのようにユーザーの真正性を評価できますか？

現在の状況は、ユーザーだけでなくウェブ エコシステム全体にとっても問題となる可能性があります。パブリッシャーや広告主にとって、ID をトラッキングし、標準以外のさまざまなサードパーティ ソリューションを使用すると、技術的負担、コードの複雑さ、データリスクが増大する可能性があります。ユーザー、デベロッパー、パブリッシャー、広告主は、ウェブがユーザーのプライバシーに関する選択を保護しているという確信を持つ必要があります。

広告はインターネットの中核的なビジネスモデルですが、広告はすべての人に有効でなければなりません。プライバシー サンドボックスの使命は、ユーザーに配慮し、プライバシーに配慮した、繁栄するウェブ エコシステムを構築するというものです。

プライバシー サンドボックスのご紹介

プライバシー サンドボックスは、サードパーティ Cookie のようなトラッキング メカニズムを使わずにオープンウェブで資金を調達するビジネスモデルをサポートするために、プライバシー保護に関する一連の API を導入します。

プライバシー サンドボックスの API では、ウェブブラウザが新しい役割を担う必要があります。この API は、限られたツールや保護機能を使用するのではなく、ユーザーのブラウザをユーザーの代わりに（ローカルのデバイス上で）動作させ、ウェブをナビゲートするユーザーの識別情報を保護できるようにします。この API により、個人の個人情報や個人情報を開示することなく、広告の選択やコンバージョンの測定などのユースケースに対応できます。エンジニアリングの観点から言うと、sandboxは保護された環境です。プライバシー サンドボックスの重要な原則は、ユーザーの個人情報を保護し、サイト間でユーザーを特定できる方法で共有しないことです。

これはブラウザの方向転換です。プライバシー サンドボックスの未来のビジョンは、ユーザーのプライバシーを保護しながら特定のユースケースに対応するための特定のツールをブラウザに提供することにあります。ウェブ向けのプライバシー モデルでは、API の背後にある基本原則を定めています。

• ウェブサイトが、1 人の人物を 1 つの ID を持つものとして扱えるようにするウェブ アクティビティの範囲を設定するため。
• アイデンティティの分離を損なうことなく、アイデンティティの境界を越えて情報を移動する方法を特定する。

プライバシー サンドボックスの提案

サードパーティ Cookie から効果的に移行するには、プライバシー サンドボックス イニシアチブへのご協力が必要です。この提案の説明では、不足しているユースケースを提案し、プライバシーに配慮した方法で目標を達成する方法に関する情報を提供するために、デベロッパー、パブリッシャー、広告主、広告技術企業からのフィードバックを必要としています。

各リポジトリに問題を提出することで、提案の解説にコメントできます。

• ウェブのプライバシー モデル
  ウェブサイトでユーザーが単一の ID を持つものとして扱われる、ユーザーのブラウザでのウェブ アクティビティの範囲を確立します。分離を損なうことなく、アイデンティティの境界を越えて情報を移動する方法を特定します。
• プライバシー バジェット
  サイトがアクセスできる、識別可能な可能性があるデータの合計量を制限します。API を更新して、開示される可能性のある個人を特定できるデータの量を減らす。測定可能な、識別可能なデータにアクセスできるようにします。
• Gnatcatcher
  IP アドレスにアクセスして、個々のユーザーを識別する機能を制限します。
• Trust Token API
  ユーザーを信頼するオリジンが、ユーザーのブラウザに格納された暗号トークンを発行できるようにします。これにより、ユーザーの真正性を評価するために他のコンテキストで使用できるようになります。
• ファーストパーティ セット
  同じエンティティが所有する関連するドメイン名は、同じファースト パーティに属するものとして宣言できます。
• 集計レポート
  ビュースルー コンバージョン、ブランド効果測定、ブランド効果測定、リーチ測定など、さまざまなユースケースをサポートするプライバシー保護メカニズムを提供します。
• アトリビューション レポート
  イベントレベル レポートと集計レポートを使用して、クリックとビューのプライバシー保護の測定を行うことができます。
• Topics API
  ユーザーがアクセスしたサイトをトラッキングすることなく、インタレスト ベース広告を有効にできます。API の設計は、以前の FLoC トライアルで得たコミュニティからのフィードバックを反映したものであり、FLoC の提案に代わるものです。
• FLEDGE
  リマーケティングのユースケースに対応するソリューションを提供します。サードパーティがユーザーのブラウジング行動をサイトをまたいでトラッキングするのを防ぐために設計されています。

API 提案に関する説明はすぐにご覧になれます。今後数か月にわたって、各提案について個別に投稿を公開する予定です。

また、各 API について簡単に説明する 5 分間の動画の再生リストにも追加する予定です。

ユースケースと目標

コンバージョンを測定する

目標: 広告主が広告のパフォーマンスを測定できるようにする。

Attribution Reporting API を使用すると、互いにリンクされた 2 つのイベントを測定できます。 1. パブリッシャーのウェブサイトで発生するイベント（ユーザーによる広告の閲覧やクリックなど）。 1. 広告主のサイトでその後のコンバージョン。

この API は、クリックスルーとビュースルーの測定に対応しています。

この API のその他の機能には、クロスデバイス アトリビューション レポートとアプリからウェブのアトリビューション レポートなどがあります。

また、API には次の 2 種類のアトリビューション レポートも用意されています。

• イベントレベル レポートでは、（広告側の）特定の広告クリックまたは広告ビューを、コンバージョン側のデータと関連付けます。ユーザーのプライバシーを保護するため、サイト間でのユーザー ID の結合を防ぐことで、コンバージョン側のデータは非常に限定され、データが「ノイズ」化されます（つまり、少数のケースでランダムなデータが送信されます）。プライバシー保護の強化のため、レポートはすぐには送信されません。

• 集計レポートは、広告側の特定のイベントには関連付けられません。これらのレポートは、イベントレベル レポートよりも豊富で忠実度の高いコンバージョン データを提供します。暗号、信頼の分散、差分プライバシーなどのプライバシー手法を組み合わせることで、サイト間で ID が結合されるリスクを軽減できます。

どちらのレポートタイプも補完的であるため、同時に使用できます。

Attribution Reporting の概要では、これらの機能のステータスと、この API を試す方法について詳しく説明しています。

広告を選択

目標: ユーザーと関連性の高い広告を表示できるようにする。

関連性の高い広告は、ユーザーにとって有利で、パブリッシャー（広告をサポートするウェブサイトの運営者）にとって収益性も高い。サードパーティの広告選択ツールを使用すると、広告主（ウェブサイトの広告スペースを購入するユーザー）にとって広告スペースの価値が高まるため、広告をサポートするウェブサイトの収益が増え、コンテンツの作成と公開が可能になります。

ユーザーとの関連性が高い広告を作成するには、次のような方法があります。

• ファーストパーティ データ: ユーザーが関心を示しているウェブサイトにアクセスしているトピックや、現在のウェブサイトでユーザーが以前に閲覧したコンテンツに関連する広告を表示します。
• コンテンツ: サイトのコンテンツに基づいて、広告を表示する場所を選択します。（「編み物に関する記事の横にこの広告を配置」など）。
• リマーケティング: 過去にサイトを訪れたことがあるものの、そのサイトを利用していないユーザーに広告を表示します。たとえば、「お客様の店舗を訪れ、編み物をショッピング カートに入れたまま、手作りのサイトを訪れたユーザーにウールの割引広告を表示する」といったことができます。
• インタレスト ベース: ユーザーの閲覧履歴に基づいて広告を選択します。たとえば、「編み物に興味があると示される閲覧行動のユーザーにこの広告を表示する」といった具合です。

ファーストパーティ データとコンテキスト広告の選択は、サイト内でのアクティビティ以外、ユーザーについて何も知らなくても行うことができます。これらの手法では、クロスサイト トラッキングは必要ありません。

リマーケティングでは、通常、Cookie などを使ってウェブサイト全体でユーザーを識別し、ユーザーをリストに追加してから、そのユーザーに広告を表示する特定の広告を選択します。

現在、インタレスト ベース広告選択では Cookie を使用して、できるだけ多くのサイトでユーザー行動をトラッキングしています。多くのユーザーは、広告選択がプライバシーに及ぼす影響を懸念しています。プライバシー サンドボックスでは、リマーケティングとインタレスト ベースの選択という 2 つの代替方法が提案されています。

• FLEDGE: リマーケティングのユースケース向け。
  この API は、第三者がユーザーの閲覧行動をトラッキングできないように設計されています。つまり、広告主や広告テクノロジー プラットフォームではなく、ユーザーのブラウザが、ユーザーのブラウザが関連付けられている広告主が定義したインタレスト グループを保存します。第三者とデータを共有するのではなく、インタレスト グループ データを広告購入者/販売者のデータおよびビジネス ロジックと組み合わせ、ユーザーのデバイスでローカルの「オークション」を実施して広告を選択します。

• Topics API: インタレスト ベースのオーディエンス向け。
  ユーザーがアクセスしたサイトをトラッキングすることなく、インタレスト ベース広告を有効にできます。この API は、ホスト名からトピックを推測する機械学習の使用と、最近アクセスしたサイトのホスト名に基づいて、ユーザーが現在興味を持っている大まかなトピックを返す JavaScript API の使用を提案します。

コンバット フィンガープリント

目標: API によって公開される可能性がある、識別可能なデータの量を減らし、識別可能な可能性があるデータへのアクセスを、ユーザーによる制御と測定を可能にする。

ブラウザはサードパーティ Cookie を廃止する措置を講じてきましたが、個々のユーザーの行動を特定してトラッキングする技術（フィンガープリント）は進化し続けています。フィンガープリントには、ユーザーが認識しておらず、制御できないメカニズムが使用されています。

• プライバシー バジェットの提案は、JavaScript API やその他の「サーフェス」（HTTP リクエスト ヘッダーなど）によって公開される指紋データの量を特定し、このデータにアクセスできる範囲を制限することで、フィンガープリントの可能性を制限することを目的としています。

• User-Agent ヘッダーなどのフィンガープリントのサーフェスは対象範囲が縮小され、Client Hints などの代替メカニズムによって提供されるデータには、プライバシー バジェットの制限が適用されます。デバイスの向き API やバッテリー レベル API などの他のサーフェスは、情報の露出を最小限に抑えるために更新されます。

IP アドレスのセキュリティ

目標: IP アドレスへのアクセスを制御して秘密のフィンガープリントを減らし、サイトでプライバシー バジェットを消費しないよう IP アドレスの表示をオプトアウトできるようにする。

ユーザーの IP アドレスは、インターネット上のコンピュータのパブリック「アドレス」です。ほとんどの場合、ユーザーがインターネットに接続するネットワークによって動的に割り当てられます。ただし、動的 IP アドレスでも、かなり長期間にわたって安定した状態を保つことができます。当然のことながら、これは IP アドレスが指紋データの重要なソースであることを意味します。

Gnatcatcher 提案は、プライバシー バジェットの消費を回避しつつ、不正使用防止などの正当な目的で IP アドレスへのアクセスを必要とするサイトが認証と監査を条件として、それを確実に行えるようにするプライバシー保護アプローチを提供する試みです。

この提案は、次の 2 つの部分で構成されます。 * Willful IP Blindness は、IP アドレスをユーザーに接続していないことをウェブサイトがブラウザに知らせる方法を提供します。 * Near-Path NAT を使用すると、ユーザーのグループは、同じプライベート化サーバーを介してトラフィックを送信し、サイトホストから IP アドレスを実質的に隠すことができます。

スパム、不正行為、サービス拒否攻撃に対処する

目標: フィンガープリントを使用せずにユーザーの真正性を検証します。

不正行為対策は、ユーザーの安全性を確保し、広告主とサイト所有者が広告のパフォーマンスを正確に測定できるようにするために不可欠です。広告主とサイト所有者は、悪意のある bot と本物のユーザーを区別できなければなりません。広告クリックが実際の人間によるものかどうかを確実に区別できない場合、広告主が支払う費用が少なくなり、パブリッシャー様の収益も減少します。現在、多くのサードパーティ サービスでは、不正行為に対処するためにデバイス フィンガープリントなどの手法が使用されています。

残念なことに、正規のユーザーを特定し、スパマー、詐欺師、bot をブロックするために使用する手法は、プライバシーを損なうフィンガープリント手法と同様に機能します。

• Trust Tokens API は代替アプローチを提案しており、ユーザーを特定したり 2 つの ID を関連付けたりすることなく、あるコンテキスト（ソーシャル メディア サイトなど）でユーザーに対して確立された真正性を別のコンテキスト（ニュースサイトに掲載される広告など）に伝えることができます。

ドメインが同じファースト パーティに属することを有効にする

目標: 関連するドメイン名が同じファースト パーティによって所有されていることをエンティティで宣言できるようにする。

多くの組織は、複数のドメインにまたがるサイトを所有しています。これは、「サードパーティ」と認識されていても実際には同じ組織に属するサイト間でユーザー ID のトラッキングに制限が課されている場合に、問題になる可能性があります。

• ファーストパーティ セットは、複数のドメインが同じファーストパーティに属すると宣言できるようにすることで、ウェブのファーストパーティ / サードパーティの概念を現実世界の概念に近づけることを目的としています。

補足説明

プライバシー サンドボックスの提案の説明

プライバシー サンドボックス イニシアチブにはあなたのサポートが必要です。API 提案の説明にはフィードバックが必要です。特に、不足しているユースケースや、目的を達成するためのよりプライバシーに配慮した方法を提案します。

• プライバシー バジェット
• Trust Token API
• グナットキャッチャー
• Aggregated Reporting API
• コンバージョンの測定
• Topics API
• FLEDGE

ウェブ向けのプライバシー モデルは、API の基盤となる基本原則を定めています。

プライバシー サンドボックス

• 技術概要: プライバシー サンドボックス
• 技術以外の概要: privacysandbox.com
• プロジェクトの原則: よりプライバシーに配慮したウェブの構築
• サードパーティ Cookie の今後

ディスカッションと参加

• プライバシー サンドボックス イニシアチブへの参加方法
• プライバシー サンドボックス イニシアチブに関する最新情報
• プライバシー サンドボックス デベロッパー サポート: ディスカッションに参加したり、質問したりできます。

ユースケース、ポリシー、要件

• 広告のユースケース
• Mozilla 追跡防止ポリシー
• WebKit トラッキング防止ポリシー
• プライバシー保護広告クリック アトリビューション（ウェブ向け）
• Brave、フィンガープリント、プライバシー バジェット

---

付録: 提案の説明で使用される用語

クリック率（CTR）

広告を見たことのある、広告をクリックしたユーザーの割合。（インプレッションもご覧ください）。

クリックスルー コンバージョン（CTC）

「クリック」された広告に結び付けられたコンバージョン。

コンバージョン

過去に広告主の広告と接点を持ったユーザーが、広告主のウェブサイトでアクションを完了すること。たとえば、広告主のサイトにリンクしている広告をクリックした後の、商品の購入やニュースレターの登録などが該当します。

差分プライバシー

個人に関する個人情報や個人がデータセットに属しているかどうかを開示することなく、データセットに関する情報を共有して行動パターンを明らかにします。

ドメイン

トップレベル ドメインと eTLD をご覧ください。

eTLD、eTLD+1

「有効」なトップレベル ドメインは、パブリック サフィックス リストで定義されます。次に例を示します。

co.uk
appspot.com
glitch.me

有効な TLD があると、foo.appspot.com を bar.appspot.com とは別のサイトにすることができます。この場合の有効なトップレベル ドメイン（eTLD）は appspot.com で、サイト名全体（foo.appspot.com、bar.appspot.com）は eTLD+1 として知られています。

トップレベル ドメインもご覧ください。

エントロピー

データ項目が個人のアイデンティティをどの程度明らかにするかの尺度です。

データ エントロピーはビット単位で測定されます。データが主体であることが明らかになるほど、そのエントロピー値は高くなります。

データを組み合わせて個人を特定することはできますが、新しいデータがエントロピーに加わるかどうかを判断するのは困難です。たとえば、オーストラリア出身だとわかっても、その人がすでにカンガルー島出身であることがわかっている場合、エントロピーは減少しません。

フィンガープリント

個々のユーザーの行動を識別して追跡する手法。フィンガープリントには、ユーザーが認識しておらず、制御できないメカニズムが使用されています。Panopticlick や amiunique.org などのサイトでは、指紋データを組み合わせて個人を特定する方法を紹介しています。

指紋が付く面

特定のユーザーやデバイスを識別するために（おそらく他のサーフェスと組み合わせて）使用できるもの。たとえば、navigator.userAgent() JavaScript メソッドと User-Agent HTTP リクエスト ヘッダーは、フィンガープリント サーフェス（ユーザー エージェント文字列）へのアクセスを提供します。

自社

アクセスしているサイトのリソース。たとえば、今見ているページは web.dev のサイトにあり、そのサイトのリソースが含まれています。サードパーティもご覧ください。

インプレッション

広告のビュー。（クリック率もご覧ください）。

k-匿名性

データセット内の匿名性の尺度。k の匿名性がある場合、データセット内の k-1 人の他の個人と区別することはできません。つまり、k 人のユーザー（あなたを含む）が同じ情報を持っています。

ノンス

暗号通信で一度だけ使用される任意の番号。

原点

リクエストの送信元。サーバー名を含みますが、パス情報は含まれません。例: https://web.dev。

パッシブ サーフェス

ユーザー エージェント文字列、IP アドレス、承認言語ヘッダーなどのフィンガープリント表示サーフェスは、サイトが要求しているかどうかにかかわらず、すべてのウェブサイトで使用できます。つまり、パッシブ サーフェスはサイトのプライバシー バジェットを簡単に消費する可能性があります。

プライバシー サンドボックス イニシアチブでは、受動的サーフェスを、特定の情報を取得する能動的な方法に置き換えることを提案しています。たとえば、すべてのサーバーへのすべてのレスポンスに Accept-language ヘッダーを用意するのではなく、Client Hints を 1 回使用してユーザーの言語を取得するなどです。

パブリッシャー

プライバシー サンドボックスの提案の解説は主に広告に関するものであるため、ここで紹介するのはウェブサイトに広告を掲載しているパブリッシャー様です。

リーチ

広告が表示されたユーザーの合計数。

リマーケティング

過去にサイトを訪れたユーザーに向けた広告。たとえば、オンライン ショップでは、サイトでおもちゃを閲覧したユーザーに対して、玩具のセールに関する広告を表示できます。

サイト

トップレベル ドメインと eTLD をご覧ください。

画面

フィンガープリント サーフェスとパッシブ サーフェスをご覧ください。

サードパーティ

アクセスしているウェブサイトとは異なるドメインから提供されるリソース。たとえば、ウェブサイト foo.com は、google-analytics.com の分析コード（JavaScript を使用）、use.typekit.net のフォント（リンク要素を使用）、vimeo.com の動画（iframe 内）を使用する場合があります。自社もご覧ください。

トップレベル ドメイン（TLD）

.com や .org などのトップレベル ドメインは、ルートゾーン データベースにリストされています。

一部の「サイト」は実際にはサブドメインにすぎません。たとえば、translate.google.com と maps.google.com は、google.com（eTLD + 1）の単なるサブドメインです。

.well-known

リクエストを行う前に、ホストに関するポリシーやその他の情報にアクセスすると便利です。たとえば、robots.txt は、アクセスするページと無視するページをウェブ クローラーに指示します。IETF の RFC8615 は、サイト全体のメタデータを /.well-known/ サブディレクトリ内の標準的な場所でアクセスできるようにするための標準化された方法を概説しています。その一覧は iana.org/assignments/well-known-uris/well-known-uris.xhtml で確認できます。

---

この投稿の執筆とレビューにご協力いただいたすべての方に感謝いたします。

写真撮影: Pierre Bamin（出典: Unsplash）