ブログ

プライバシーサンドボックス、FLoC、FLEDGEとは、何か?

Facebookの決算が、良くなかったこと、特に、アップルのサードパーティクッキーの制限によって大きな影響を受けたこと、それは、アップルのATT枠組という、いわば、スラッジ(汚泥ナッジ)の抱合せを拘束することによると位置づけられるのではないか、というのは、「競争の武器としての「プライバシーのダークサイド」(Facebookの決算を見る)」でみました。

ブラウザとかをみるとき、社会的にインパクトがあるのは、グーグルの動きということになるわけですが、グーグルも「脱クッキー」時代に対応して、クロームで、サードパーティのクッキーを禁止して、プライバシーサンドボックスを採用して、FLoC(Federated Learning of Cohorts)を採用するという動きになっています。

個人的には、月末(11月27日の発表)までに、英国の「オンラインプラットフォームとデジタル広告市場研究」報告書(Online platforms and digital advertising market study)とオーストラリアの「デジタルプラットフォーム諮問」報告書(Digital Platforms Inquiry)は、みておきたいと思っています。でもって、それらの報告書の理解のために、グーグルの動きをみてみたいと思います。

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

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

サードパーティ Cookie などのトラッキング メカニズムを使わずにサードパーティ ユースケースを満たすための一連の提案

と定義することができます。

サードパーティクッキーなどの用語については、競争の武器としての「プライバシーのダークサイド」(Facebookの決算を見る)」でみました

ご本家のページは、「プライバシーサンドボックス」(リンク)

この詳細については、「Privacy Sandbox とは何ですか?」(オリジナルは、”Digging into the Privacy Sandbox” 2020年4月8日)で解説されています。

提案の背後にある原則

まずは、「提案の背後にある原則」とをみたいと思います。

2019年からは、オープンソースのブラウザのプロジェクトであるクロミウムのプロジェクトでのブログがでています。

2019年5月7日「ウエブのプライバシとセキュリティの改良」(Improving privacy and security on the web)

これは、同日に開かれたGoogle I/OでのChromeでのCookieの処理方法を変更する計画の発表についてのコメントのようです。「GoogleがI/O 2019で発表した100のコトまとめ」では、51から56までが、プライバシー関係。あと、クローム関係だと78。

日本語の翻訳は、「ウェブのプライバシーとセキュリティの強化」になります。ブログの内容は、

  • Cookieとプライバシー(一般論、クッキー消去の問題点、ヒューリスティックなアプローチの問題点)
  • ChromeでのCookieコントロールの改善(ウェブサイト間での動作を許可するCookieを開発者が明示的に指定しなければならないようにする)
  • フィンガープリンティングに対する保護(ブラウザが受動的にフィンガープリントを取得する方法を減らし、積極的なフィンガープリントの取得を検知して介入)
  • より良いウェブの実現に向けて

になります。

同日に発表された「徐々にいいクッキー( Incrementally Better Cookies draft-west-cookie-incrementalism-00)」の提案はこちらです。詳細に見る余裕はありませんが、

  •  規約と定義 (適合性について、シンタックス)
  •  RFC6265bisに対するモンキーパッチ (デフォルトでは “Lax (緩い)”である、 SameSite=None “に “Secure “を要求すること、
  •  セキュリティおよびプライバシーに関する考慮事項(csrf、セキュア・トランスポート 、トラッキング)
  •  実装上の考慮事項 ( シークエンス(配列)について、デプロイメント)
  •  IANAに関する検討事項
  • リファレンス

などについての提案がなされています。

2019年8月22日「よりプライベートなウエブを構築する」(Building a more private web)です(ブログは、グーグルのクローム内に掲載)

クロム エンジニアリングのディレクター Justin Schuh氏のこのブログは、プライバシーを拡張する開かれた標準群を開発するイニシアチブを明らかにしました。これが、プライバシーサンドボックスと呼ばれることになります。

このブログにおいては、

  • 合意された標準規格がないため、ユーザーのプライバシーを向上させようとする試みは、意図しない結果をもたらしうること
  • 大規模なクッキーのブロックは、フィンガープリンティングのような不透明な技術を助長することで、人々のプライバシーを損なうこことになること
  • 関連性の高い広告を配信する別の方法なしにCookieをブロックすることは、パブリッシャーの主要な資金調達手段を大幅に減少させ、活気あるウェブの将来を危うくすること

が指摘されており、そこでは

Cookieを削除して広告の関連性を低くすると、出版社の資金は平均で52%減少するという結果が出ています

と指摘されています。

そこで、

ユーザーのプライバシーを保護しつつ、コンテンツがウェブ上で自由にアクセスできるようにするためのソリューションを見つけたいと考えています

として、ユーザー情報を匿名で集約し、より多くのユーザー情報をデバイス上にのみ保持することで、ウェブサイトや広告主と共有するユーザーデータを最小限に抑える「プライバシー・サンドボックス」のアイディアを発表してきたことを述べています。そして、ウエブ標準作成の方式で、これらの手法を提案することを記載しています。

Chrome dev summitでの説明は、こちらです(Youtube)

2019年10月23日 「開発者 新しい同一サイトなし、安全なクッキーの設定の準備」(Developers: Get Ready for New SameSite=None; Secure Cookie Settings)になります。

日本語は、「新しい Cookie 設定 SameSite=None; Secure の準備を始めましょう」(同11月18日付)になります。

ここでふれられていることは

  • クロスサイトおよび同一サイトの Cookie コンテキストを理解する(要は、サードパーティ(クロスサイトクッキーの概念)
  • Cookie のセキュリティと透過性を実現するための新しいモデル(クロスサイト Cookie の明示的に宣言->セキュリティ/透過性が高まり、ユーザーの選択肢も増える)
  • Chrome は 2020 年 2 月より新しいモデルを適用(Chrome バージョン80 )

などです。

新しいクッキー設定

でもって、このバージョン80がどのようになったか、ということになります。

「ウェブのプライバシー強化: サードパーティ Cookie 廃止への道」(2020年1月23日)(元記事は、Building a more private web: A path towards making third party cookies obsolete)

プライバシー サンドボックスのようなプライバシーを保護するオープン標準メカニズムは、広告によってサポートされる健全なウェブを維持できること、そして将来的にサードパーティ Cookie が使われなくなることを確信しています

としています。そして、

ユーザーは、透明性や個人データの使用方法に関する選択と制御など、プライバシーの強化を求めています。ウェブのエコシステムが、この高まる要求を満たすように進化しなければならないのは明らかです。

ブラウザの中には、サードパーティの Cookie をブロックすることでこの懸念に対応しているものもあるとしてそれは、ユーザーとウェブのエコシステムの両方に悪影響を与える結果になると考えていますとしています。

サードパーティクッキーの廃止は、「 Flash や NPAPI を段階的に廃止した経験」と同様だとしています。

その後、Chrome 80は、2月下旬から、実現されていくことになるわけですが、結局、いったん、もとに戻るようになります。時系列的には、The Chromium Projectsの”SameSite Updates”が参考になります。同年2月10日にこれが導入されて、そのあと、4月3日にいったん戻っています。

同2月7日「2020 年 2 月の SameSite Cookie の変更: 知っておくべきこと」(もともとは、SameSite Cookie Changes in February 2020: What You Need to Know“(2月3日))

同2月21日「Google Chrome で安全でないダウンロードからユーザーを保護する」は、Chrome81からのスケジュールを明らかにしています。(もともとは、“Protecting users from insecure downloads in Google Chrome”(2月6日))。

これらの動向について記事としては、「いまさら聞けないSameSite CookieとGoogle Chrome 80」 があります。この記事で、

仕様が変更にある前まではSameSiteを指定していない場合、ブラウザ側ではNone(なし)として判断してWebサイトからのCookieの利用を許可しておりましたが、今回のGoogle Chrome 80からはSameSiteを指定しない場合、Lax(緩い)として取り扱う形となりました。

と説明がなされています。

あと、「Chrome 80が密かに呼び寄せる地獄 ~ SameSite属性のデフォルト変更を調べてみた」(2020年2月1日)もあります。

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

上述のように2020年4月8日には、プライバシーサンドボックスの全体像が整理されて明らかになっています。英語版(“Digging into the Privacy Sandbox” 2020年4月8日)のほうが参考になります。このページを見ていきます。

 ウエブの現状(The current state of privacy on the web #)-そしてミッション

ここでは、広告が、サードパーティクッキーによって含まれていること、クリックとコンバージョン(広告成功率)が、サードパーティクッキーによってなされること、サイトを訪問するときにが第三者がふくまれていることに気がつかないかもしれず、また、あなたのデータに対して何をしているかもわからないこと、がふれられています。その一方で、広告の選択、成功率、その他の利用例が、サイト間の利用者の同一性にかかっています。それかジレンマになっています。このジレンマを解消することが、ウエブのエコシステムのために重要であること、その結果、プライバシーサンドボックスのミッションは、

ユーザーを尊重し、デフォルトではプライベートである、繁栄するウェブのエコシステムを構築すること

とされています。

利用例とゴール

  • 成功率の測定(広告主に対して広告のパフォーマンスの測定を可能にすること)
  • 広告の選択(広告主に対して利用者に関連する広告を表示することを可能にすること)
  • フィンガープリンティングとの戦い(APIによって識別が可能なデータの量を減少させ、利用者によってコントール可能なデータをアクセス可能にし、測定可能にする)
  • IPアドレスセキュリティ(IPアドレスへのアクセスを制御することで、秘密のフィンガープリントを減らし、プライバシー予算を消費しないように、サイトがIPアドレスの表示をオプトアウトできるようにする)
  • スパム、不正行為、DoS攻撃との戦い(フィンガープリンティングを利用せずに利用者を検証する)
  • ドメインをファーストパーティと同一にすることを可能にする(関連するドメイン名が同一のファーストパーティによって所有されていることをエンティティが宣言できるようにする。)

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

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

プライバシー・サンドボックスのAPIは、ウェブブラウザに新たな役割を要求します。APIは、限られたツールや保護機能ではなく、ユーザのブラウザがユーザに代わって、ユーザのデバイス上でローカルに動作し、ユーザがウェブを閲覧する際にユーザの識別情報を保護することを可能にします。このAPIを利用することで、個人のプライベート情報や個人情報を開示することなく、広告の選択やコンバージョン測定などのユースケースが可能になります。サンドボックスとは、工学用語で保護された環境のことです。プライバシー・サンドボックスの主要な原則は、ユーザーの個人情報を保護し、サイト間でユーザーを識別できるような形で共有しないことです。

これは、ブラウザの方向性を変えるものです。プライバシー・サンドボックスの未来像は、ユーザーのプライバシーを守りつつ、特定のユースケースを満たすための特定のツールをブラウザが提供するというものです。A Potential Privacy Model for the Web(ウェブのための潜在的なプライバシーモデル)」では、APIの背後にあるコア・プリンシプルを示しています。

ユーザーのブラウザがウェブサイトで個人を単一のアイデンティティとして扱うことができるウェブ活動の範囲を確立すること。
アイデンティティの境界を越えて、その分離を損なうことなく情報を移動させる方法を特定する。

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

日本語版「Privacy Sandbox とは何ですか?」では、主な提案がピックアップされています。以下は、英語版であげられている提案です。これを図示するときに、以下のようになります。

 

 

 

 

 

 

 

 

—提案内容—–

(1)関連するコンテンツと広告

FLoC
ブラウザは、似たような閲覧履歴を持つ多くのユーザーをグループ(または「コホート」)にまとめます。広告主は、この大きなグループに対して、大量の観測データに基づいて広告を選択することができますが、グループ内の個々の人々を認識することはできません。

FLEDGE
リマーケティングのユースケースのためのソリューションを提供します。サードパーティがサイト間でユーザーの閲覧行動を追跡するために使用できないように設計されています。

(2)データ収集の制限

プライバシー予算(Privacy Budget)

サイトがアクセスできる潜在的に個人を特定できるデータの総量を制限する。識別可能なデータの公開量を減らすためにAPIを更新する。識別可能なデータへのアクセスを測定可能にする。

ナットキャッチャーGnatcatcher

IPアドレスにアクセスして個々のユーザーを特定する機能を制限する。

(3)測定とアトリビューション

アトリビューションレポート

イベントレベルのレポートや集計レポートにより、プライバシーを保護したクリック数やビュー数の測定を提供します。

(4)ファーストパーティの保護

ファースト・パーティ・セット(First-Party Sets)
同じエンティティが所有する関連するドメイン名が、同じファーストパーティに属していると宣言できるようにします。(高橋)これは、広告出していると感じるのですが、komazawalegal.orgとitresearchart.bizが同じファーストパーティーといってもいいよねと思ったりします。

(5)不正検出

トラストトークンAPI(Trust Token API)
ユーザーを信頼するオリジンが、ユーザーに暗号トークンを発行できるようにします。このトークンはユーザーのブラウザに保存され、ユーザーの信頼性を評価するために他のコンテキストで使用できます。

(6)その他

ウェブにおけるプライバシーモデル(Privacy Model for the Web)
ユーザのブラウザがウェブサイトで個人を単一のアイデンティティとして扱うことができるウェブ活動の範囲を確立する。情報がアイデンティティの境界を越えて、その分離を損なうことなく移動できる方法を特定する。

集約された報告(Aggregated Reporting)
ビュー・スルー・コンバージョン、ブランド、リフト、リーチの測定など、さまざまなユースケースをサポートするプライバシー保護メカニズムを提供します。


 

解説的な日本語のドキュメントだと「ゼロ知識の人でもわかる!Googleが提唱するCookieレス対策「Privacy Sandbox」とは?」とか、「「一問一答】Googleの「 プライバシーサンドボックス 」とは?:Cookieの代わりとされる5つのAPI」とかがあります。

「関連するコンテンツと広告」の検討

広告のいままでのサードラーティクッキーの代替としての機能を果たすことになるものとして準備されているのは、FLoCとFLEDGEなので、それらを見ていきます。Federated Learning of Cohorts (FLoC)によるとウェブページに表示する広告の選択は、一般的に3つの大まかなカテゴリーの情報に基づいて行われることがあります。

  • ファーストパーティ情報とコンテクスト情報(例:「バイクに関するウェブページにこの広告を表示する」など)
  • 広告を見ようとしている人の興味に関する一般的な情報(例:「クラシック音楽が好きな人にこの広告を表示する」など)
  • その人が過去に行った具体的な行動(例:「ショッピングカートに入れたままの靴を割引する」など)

カテゴリー2の一般的な関心事に基づく広告については、FLoC、カテゴリー3のパーソナライズド広告については、FLEDGEによることなります。

FLoC(Federated Learning of Cohorts)

 コホートの学習連合です。統計学で出てきましたコホートです。特に医学的論文を読むとでてきますね。コホート研究というのは、

異なる特性を持つ複数の患者群(コホート)を時間の流れに沿って観察し、その特性と疾患との関係を調べようとする研究方法のこと。

になります。これには、前向きのコホート研究(未来に向かって対象疾患がどのくらいの頻度で発生するかを観察)と後ろ向きのコホート研究(過去のある時点でのコホートを同定し、現在に向かって各コホートでの罹患率を調べる)があります。もともとの意味は、群れ、集団という意味になります。

なので、ユーザがどの群れなのかというのをブラウザに記録して、それを広告の配信に利用するという手法となります。

FLocについては、ご本家グーグルの記事は、「FLoC の概要」になります。テッククランチは、「GoogleがCookieに代わる広告ターゲティング手段FLoCをChromeでテスト開始」(2021年4月1日)

説明としては、Federated Learning of Cohorts (FLoC)がいいみたいです。

FLoCのコホートは、多数(数千人)の人々に共有される短い名前で、ブラウザがユーザーの閲覧履歴から導き出します。ブラウザは、ユーザーがウェブを閲覧するたびにコホートを更新していきます。この値は、新しいJavaScript APIを介してWebサイトに提供されます。

私たちは、ブラウザが似たような閲覧習慣を持つ人々をグループ化し、アドテクノロジー企業が個人の活動ではなく大きなグループの習慣を観察できるような方法を検討する予定です。そうすれば、広告会社は、個人の行動ではなく、大きなグループの行動を観察することができます。

ブラウザーには、有用かつプライベートなグループを形成する方法が必要です。「有用な」とは、似たような関心を持つ人々を集めて機械学習に適したラベルを作成することであり、「プライベート」とは、クラスターの作成時や使用時に個人的な情報を明かさないように大きなクラスターを形成することである。

具体的な動作の原理については、以下の図で現すことができます。

 

 

 

 

 

 

 

 

 

この図は、ブラウザは、機械学習アルゴリズムを使用して、個人が訪問したサイトに基づいてコホートを作成していることをしめします。ちなみに、FLOC APIのホワイトペーパーはこちらです

 

項目 コホートIDとの関係 場所 留意事項
(1)FLOCサービスによるコホートの作成 コホートの作成 サービス ・コホートとして、たくさんの類似した閲覧履歴のクラスタを分析・「集団の中に隠れる」ことができるように、k-匿名性を利用する
(2)ブラウザによるコホートの計算 コホートを割り出す ユーザのブラウザ ・FLoCモデルのアルゴリズムを使った、自分の閲覧履歴にもっとも近いものを突き止める・コホートIDを付す
(3)コホートIDの取得 コホートIDを取得する 広告主のページ アクセスしたブラウザにコホートIDを尋ね、IDが返される
(4)コホート活動の観察 特定コホートの追加情報の記録 広告主のページ 同IDが興味を示した製品についての追加情報を記録
(5)コホートIDの取得 コホートIDの取得 公表者のページ 公表者のサイトが、訪問者のブラウザにコホートを尋ねる
(6)アドテックとのコホートIDの共有 コホートIDの共有 公表者のアドテック・プラットフォームへのリクエスト アドテック・プラットフォームに広告をリクエストする際にコホートIDを含める
(7)コホートに関する広告の選択 コホートIDに関する広告の選択 アドテック・プラットフォーム (提供された)コホートIDと製品に対する興味に関するデータをもとに、そのコホートに相応しい広告を選択
(8)広告の表示 選択された広告の表示 ユーザのブラウザ

アルゴリズムは、訪問したサイトのURLやページのコンテンツ、その他の要素に基づいています。ウェブ履歴を含むアルゴリズムへのこれらの入力機能は、ブラウザ上でローカルに保持され、他の場所にアップロードされません。ブラウザは、コホートが数千人規模になるように適切に分散させます。

FLEDGE

開発者用のページは、こちらです

広告プラットフォームは、サイト間でのユーザーの行動を追跡することにより、ユーザーの興味を把握してきましたが、サイト間の追跡を行わずに、関連性の高い広告をユーザーに表示する方法が必要です。

として、FLoCとともに提案されているものです。事前に訪問したサイト人に他のサイトでリーチするリマーケティングといわれていますが、そのための手法として提案されています。

具体的な仕組みをみていきます。

FLEDGE の仕組み

図示すると以下のようになります。

 

 

 

 

 

 

 

 

  • (1)ユーザーが、オンライン ストアなど、自社の製品を宣伝したいサイトのページにアクセスします。
  • (2)広告主サイト (またはそのサイトが使用する広告技術) が joinAdInterestGroup()を呼び出してデータを渡し、ユーザーのブラウザーに「広告グループ」に参加するように要求します。
  • データにはユーザーが閲覧する内容に関連する広告、広告プラットフォームのホスト名、および入札ロジックと入札シグナルにアクセスするための URL が含まれています。
  • (3)ユーザーが広告を表示し、FLEDGE を使用して選択された広告を受け入れるように設定されているニュースなどのサイトにアクセスします。
  • (4)ユーザーのブラウザーが「オークション」の段階に移行します。
  • (5)FLEDGE が選択した広告を受け入れられる広告在庫 (広告枠) を選択します。
  • (6)売り手はデータを使用して runAdAuction() を呼び出し、広告オークションを開始します。データには、売り手のホスト名、買い手と売り手からのシグナル、およびオークション決定ロジックの URL が含まれます。
  • (7)オークションから落札した広告に関するデータが返されます。Fenced Frame (フェンスで囲まれたフレーム) に広告を表示することを除いて、サイト運営者はそのデータにはアクセスできません。
  • (8)広告が表示されます。

ユーザーのブラウザが広告の配信塔の役割をするということになるのでしょうか。このローカルでの処理というのが、ポイントになります。

広告主が広告グループのデータをユーザーに関する他の情報、特に個人を識別できる情報やユーザーがアクセスしたページの情報と組み合わせることはできません。広告主が、ユーザーがサイト運営者のサイトでどのページを表示しているかを確認することはできません。
Web サイト、およびそれらのサイトが使用する広告ネットワークは、訪問者の興味のある広告または広告グループの情報を利用することはできません。

ということが配慮されている仕組みです。

関連記事

  1. デシタルフォレンジックスの威力と実務-東芝総会調査報告書
  2. YoutubeでMPAセミナーの「ブロッキングと『通信のプライバ…
  3. 「プラットフォームにおけるプライバシーの保護に関する個人データ保…
  4. カーンFTC委員長は、トリックスターか、学者か?-「アマゾンの反…
  5. 仮想通貨はお金の未来を変えるのか
  6. 所長の高橋郁夫が第33回東京国際映画祭 共催企画 MPAセミナー…
  7. ダイナミック・ブロッキングの状況-欧州議会調査サービス「デジタル…
  8. ネットワーク中立性講義 その3 米国の議論(2008年まで)
PAGE TOP