このページは Cloud Translation API によって翻訳されました。

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

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

Sam Dutton

概要

この投稿では、プライバシーサンドボックスの提案に記載されている 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 の基礎となる基本原則が説明されています。

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

ディスカッションと参加

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

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

付録: 提案の解説で使用する用語

クリック率（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

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

概要