プライバシー サンドボックスは、サードパーティ Cookie やその他のトラッキング メカニズムを使用せずに、サードパーティのユースケースに対応するための一連の提案です。
概要
- この投稿では、プライバシー サンドボックスの提案に記載されている API とコンセプトについて概説します。
- 提案の作成者は、コミュニティ、特に広告分野の人々(パブリッシャー、広告主、広告テクノロジー企業)からのフィードバックを募り、不足しているユースケースを提案し、ビジネス ユースケースをサポートする方法に関する情報を共有します。
- 以下のリンク先のリポジトリで問題を報告することで、提案にコメントできます。
- この投稿の最後に、提案の用語集をご覧ください。
ウェブ上のプライバシーの現状
ウェブサイトでは、他の企業のサービスを利用して、分析や動画の提供など、さまざまな便利なサービスを活用しています。コンポーザビリティはウェブの強みの一つです。特に注目すべきは、サードパーティの JavaScript や iframe を介してウェブページに広告が追加されることです。広告ビュー、クリック、コンバージョンは、サードパーティ Cookie とスクリプトを使用してトラッキングされます。
ただし、ウェブサイトを訪問したときに、そのサードパーティがユーザーのデータをどのように使用しているかに気が付かない場合があります。ニュース メディアやウェブ デベロッパーでさえ、サードパーティのサプライ チェーン全体を理解しているわけではありません。
現在、広告選択、コンバージョン測定、その他のユースケースでは、安定したクロスサイト ユーザー ID を確立する必要があります。これは従来、サードパーティ Cookie を使用して行われてきましたが、ブラウザではこれらの Cookie へのアクセスを制限し始めています。また、ブラウザ ストレージ、デバイス フィンガープリント、メールアドレスなどの個人情報のリクエストなど、クロスサイト ユーザー トラッキングの他のメカニズムの使用も増加しています。
これはウェブにとってジレンマです。サイトをまたいでユーザーをトラッキングできないようにして、サードパーティの正当なユースケースをサポートするにはどうすればよいでしょうか。
特に、第三者が広告を表示して広告のパフォーマンスを測定できるようにしつつ、個々のユーザーのプロファイリングは許可しないようにすることで、ウェブサイトでコンテンツを収益化するにはどうすればよいでしょうか。広告主やサイト所有者が、デバイスのフィンガープリントなどのダークパターンに頼ることなく、ユーザーの真正性を評価するにはどうすればよいですか。
現在の仕組みは、ユーザーだけでなく、ウェブ エコシステム全体にとって問題となる可能性があります。パブリッシャーと広告主は、ID をトラッキングし、さまざまな標準以外のサードパーティ ソリューションを使用することで、技術的負担、コードの複雑さ、データリスクを増大させる可能性があります。ユーザー、デベロッパー、パブリッシャー、広告主は、ウェブがユーザーのプライバシーに関する選択を保護していることを確信する必要があります。
広告はインターネットの主要なウェブ ビジネスモデルですが、広告はすべての人のために機能しなければなりません。そうすると、プライバシー サンドボックスの使命は、ユーザーに配慮し、デフォルトでプライバシーが確保された、活発なウェブ エコシステムを構築することです。
プライバシー サンドボックスのご紹介
プライバシー サンドボックスは、プライバシーに配慮した一連の API を導入し、サードパーティ Cookie のようなトラッキング メカニズムのないオープンウェブを支えるビジネスモデルをサポートします。
プライバシー サンドボックス API では、ウェブブラウザが新しい役割を担う必要があります。この API では、限られたツールや保護機能ではなく、ユーザーのブラウザがユーザーに代わって(ユーザーのデバイス上でローカルに)動作し、ウェブを閲覧するユーザーの識別情報を保護できます。この API を使用すると、個人の個人情報や個人情報を明らかにすることなく、広告選択やコンバージョン測定などのユースケースを実現できます。エンジニアリング用語では、サンドボックスとは保護された環境を指します。プライバシー サンドボックスの主な原則は、ユーザーの個人情報を保護し、サイト間でユーザーを特定できるような方法で共有しないことです。
つまり、ブラウザの方向性が変わります。プライバシー サンドボックスの未来を見据えて、ブラウザでユーザーのプライバシーを保護しつつ、特定のユースケースに対応する特定のツールを提供することになります。ウェブ向けのプライバシー モデルの可能性では、API の背後にある基本原則が規定されています。
- ウェブサイトが個々のユーザーを単一の ID として扱えるよう、ユーザーのブラウザで使用できるウェブ アクティビティの範囲を設定する。
- 情報の分離を損なうことなく、ID の境界を越えて情報をどのように移動できるかを特定する。
プライバシー サンドボックスの提案
プライバシー サンドボックス イニシアチブがサードパーティ Cookie から適切に移行するには、皆さんの支援が必要です。提案の説明者は、デベロッパー、パブリッシャー、広告主、広告技術会社からのフィードバックを必要としており、不足しているユースケースを提案したり、プライバシーに配慮した方法で目標を達成する方法を共有したりする必要があります。
各リポジトリに対して問題を報告することで、提案の解説にコメントできます。
- ウェブ向けのプライバシー モデル
ウェブサイトで個人を単一の ID として扱えるよう、ユーザーのブラウザで使用できるウェブ アクティビティの範囲を確立します。情報の分離を損なうことなく、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 が参加する際のリスクを軽減できます。
どちらの種類のレポートも併用可能です(相互補完関係にあります)。
これらの機能のステータスとこの API の使用方法について詳しくは、Attribution Reporting の概要をご覧ください。
広告を選択
目標: 広告主がユーザーに関連性の高い広告を表示できるようにする。
関連性の高い広告は、ユーザーにとって有利になり、パブリッシャー様(広告に支えられたウェブサイトを運営するユーザー)にとっては収益性も高くなります。サードパーティの広告選択ツールを使用すると、広告主(ウェブサイトの広告スペースを購入するユーザー)にとって広告スペースの価値がより高まり、広告をサポートするウェブサイトの収益が増え、コンテンツの作成と公開が可能になります。
ユーザーと関連性の高い広告を作成するには、次のような方法があります。
- 自社データ: ユーザーが関心を持っているウェブサイトと伝えたトピックや、ユーザーが過去にそのウェブサイトで閲覧したコンテンツに関連する広告を表示します。
- コンテンツ ターゲティング: サイトのコンテンツに基づいて広告を表示する場所を選択します。例: 「編み物に関する記事の横にこの広告を配置」
- リマーケティング: 過去にサイトを訪れたことのあるユーザーのうち、過去にサイトを訪れていないユーザーに広告を表示します。たとえば、「お客様のショップを訪れ、編み物の商品をショッピング カートに入れたままクラフトサイトを閲覧しているユーザーに対して、ウールの割引広告を表示」といった情報を表示します。
- インタレスト ベース: ユーザーの閲覧履歴に基づいて広告を選択します。たとえば、「閲覧行動から編み物に関心がある可能性が高いユーザーにこの広告を表示する」といった具合です。
ファーストパーティ データとコンテキスト広告の選択は、サイト内でのユーザーの行動以外のユーザーについて把握していなくても行うことができます。これらの手法では、クロスサイト トラッキングは必要ありません。
リマーケティングでは、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 アドレスであっても、長期間にわたって安定したままである可能性があります。当然のことながら、これは IP アドレスが指紋データの重要なソースであることを意味します。
Gnatcatcher プロポーザルは、 プライバシー バジェットの消費を避けながら、サイトのプライバシーを保護しながら、 不正使用防止などの正当な目的で IP アドレスへのアクセスを要求することは、 認証と監査です
この提案は、次の 2 つの部分で構成されています。 * 意図的な IP ブラインドネス を使用すると、ウェブサイトがユーザーに IP アドレスを接続していないことをブラウザに知らせることができます。 * ニアパス NAT を使用すると、 トラフィックを同じプライベート化サーバー経由で送信し、 取得します。
スパム、不正行為、サービス拒否攻撃の防止
目標: フィンガープリントを使用せずにユーザーの真正性を検証します。
不正防止は、ユーザーの安全を維持し、広告主とサイト所有者が広告のパフォーマンスを正確に測定できるようにするために不可欠です。広告主とサイト所有者は、悪意のある bot と本物のユーザーを区別できなければなりません。広告クリックが実際の人間によるものかどうかを広告主が確実に見分けられないと、広告主の支払いが減るため、サイト パブリッシャーの収益が減ります。現在、多くのサードパーティ サービスが、不正行為を防ぐためにデバイス フィンガープリントなどの手法を使用しています。
残念ながら、正当なユーザーを識別し、スパマー、不正行為者、bot をブロックするために使用される手法は、プライバシーを侵害するフィンガープリント手法と同様に機能します。
- Trust Tokens API は、ソーシャル メディア サイトなど、あるコンテキストでユーザーに設定された真正性を別のコンテキスト(ニュースサイトに掲載される広告など)に伝えられる代替アプローチです。ユーザーを特定したり 2 つの ID を関連付けたりする必要はありません。
ドメインを同じ自社に属するものにする
目標: エンティティが、関連するドメイン名が同じファースト パーティによって所有されていることを宣言できるようにします。
多くの組織では、複数のドメインでサイトを所有しています。「サードパーティ」とみなされるサイト間でユーザー ID のトラッキングに制限が課せられている場合、これは問題になることがあります。実際には同じ組織に所属しています
- ファーストパーティ セットは、複数のドメインが同じファーストパーティに属するものを宣言できるようにすることで、ウェブにおけるファーストパーティとサードパーティのコンセプトを現実世界のものに近づけることを目的としています。
補足説明
プライバシー サンドボックスの提案の解説
プライバシー サンドボックス イニシアチブには皆様の支援が必要です。API 提案の説明者にはフィードバックが必要です。特に、不足しているユースケースや、よりプライバシーに配慮した方法で目標を達成するための提案です。
ウェブ用のプライバシー モデルの可能性では、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 と呼ばれます。
トップレベル ドメインもご覧ください。
エントロピー
データ項目が個人のアイデンティティをどの程度明らかにするかを示す尺度。
データ エントロピーはビット単位で測定されます。データがより多くの ID を明らかにするほど、エントロピー値は高くなります。
データを組み合わせて個人を特定することはできますが、新しいデータがエントロピーに加算されるかどうかを判断するのが難しい場合があります。たとえば、その人物がオーストラリアの出身だとわかっても、その人物がカンガルー島の出身だとすでにわかっている場合は、エントロピーは減少しません。
フィンガープリント
個々のユーザーの行動を識別して追跡する手法。フィンガープリントでは、ユーザーが認識していない、制御できないメカニズムが使用されています。
フィンガープリントの表面
特定のユーザーまたはデバイスを識別するために、(おそらく他のサーフェスと組み合わせて)使用できるもの。たとえば、navigator.userAgent()
JavaScript メソッドと User-Agent
HTTP リクエスト ヘッダーは、フィンガープリント サーフェス(ユーザー エージェント文字列)へのアクセスを提供します。
自社
アクセスしているサイトのリソース。たとえば、お読みになっているページは web.dev サイト上にあり、そのサイトのリソースが含まれています。第三者もご覧ください。
インプレッション
広告の視聴。(クリック率もご覧ください)。
k-匿名性
データセット内の匿名性の尺度。匿名性が k の場合、データセット内の他の k-1 の個人と区別できません。言い換えれば、k 人の個人(個人を含む)が同じ情報を持っているということです。
ノンス
暗号通信で 1 回だけ使用される任意の番号。
出発地
リクエストの送信元(サーバー名が含まれますが、パス情報は含まれない)。例: https://web.dev
。
パッシブ サーフェス
ユーザー エージェント文字列、IP アドレス、Accept-language ヘッダーなどの一部のフィンガープリント サーフェスは、サイトが要求しているかどうかにかかわらず、すべてのウェブサイトで利用できます。つまり、パッシブなサーフェスはサイトのプライバシー バジェットを消費しやすいということです。
プライバシー サンドボックス イニシアチブでは、パッシブなサーフェスを、特定の情報を取得するための能動的な方法に置き換えることを提案しています。たとえば、すべてのサーバーに対するレスポンスごとに accept-language ヘッダーを使用するのではなく、Client Hints を一度使用してユーザーの言語を取得するなどです。
パブリッシャー
プライバシー サンドボックスの提案の解説は主に広告に関するものであるため、ここで言及されるパブリッシャーは、ウェブサイトに広告を掲載するパブリッシャーです。
リーチ
広告が表示されたユーザーの合計数。
リマーケティング
過去にサイトを訪れたことのあるユーザーに広告を表示する。たとえばオンライン ショップなら、サイトでおもちゃを以前に見たことのあるユーザーを対象に、玩具のセールの広告を表示できます。
サイト
トップレベル ドメインと 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