-
お電話での問い合わせは03-6805-2586
- メールフォーム
お電話での問い合わせは03-6805-2586
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。
日本語の翻訳は、「ウェブのプライバシーとセキュリティの強化」になります。ブログの内容は、
になります。
同日に発表された「徐々にいいクッキー( Incrementally Better Cookies draft-west-cookie-incrementalism-00)」の提案はこちらです。詳細に見る余裕はありませんが、
などについての提案がなされています。
2019年8月22日「よりプライベートなウエブを構築する」(Building a more private web)です(ブログは、グーグルのクローム内に掲載)
クロム エンジニアリングのディレクター Justin Schuh氏のこのブログは、プライバシーを拡張する開かれた標準群を開発するイニシアチブを明らかにしました。これが、プライバシーサンドボックスと呼ばれることになります。
このブログにおいては、
が指摘されており、そこでは
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日付)になります。
ここでふれられていることは
などです。
新しいクッキー設定
でもって、このバージョン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を導入しています。
プライバシー・サンドボックスの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やページのコンテンツ、その他の要素に基づいています。ウェブ履歴を含むアルゴリズムへのこれらの入力機能は、ブラウザ上でローカルに保持され、他の場所にアップロードされません。ブラウザは、コホートが数千人規模になるように適切に分散させます。
開発者用のページは、こちらです。
広告プラットフォームは、サイト間でのユーザーの行動を追跡することにより、ユーザーの興味を把握してきましたが、サイト間の追跡を行わずに、関連性の高い広告をユーザーに表示する方法が必要です。
として、FLoCとともに提案されているものです。事前に訪問したサイト人に他のサイトでリーチするリマーケティングといわれていますが、そのための手法として提案されています。
具体的な仕組みをみていきます。
FLEDGE の仕組み
図示すると以下のようになります。
ユーザーのブラウザが広告の配信塔の役割をするということになるのでしょうか。このローカルでの処理というのが、ポイントになります。
広告主が広告グループのデータをユーザーに関する他の情報、特に個人を識別できる情報やユーザーがアクセスしたページの情報と組み合わせることはできません。広告主が、ユーザーがサイト運営者のサイトでどのページを表示しているかを確認することはできません。
Web サイト、およびそれらのサイトが使用する広告ネットワークは、訪問者の興味のある広告または広告グループの情報を利用することはできません。
ということが配慮されている仕組みです。
