Google Open Source Live イベントシリーズを開催いたします。

第 8 回目の今回のイベントは「Open data lake day」です。

 

Google に在籍するデータ アナリティクスのエキスパートが、オープンテーブル フォーマットや、イノベーションとクラウドのバリアの克服方法などについてお話しします。

 

セッション中には質問を投稿できるフォーラムが立ち上がります。Google 社員に直接質問ができるチャンスとなりますのでぜひ、ご活用ください。

 

また、セッション終了後に Google Meet にてアフターパーティーを開催いたします。他の参加者の方達と交流したり、Google オリジナルグッズが当たるクイズゲームなどをご用意しておりますのでぜひ、ご参加ください。

 

日本語版のイベントでは、日本語での MC、日本語の字幕付きセッション、そして日本語開催のアフターパーティーとなります。

英語版をご希望の方は太平洋時間の 9:00 am PST、日本語版をご希望の方は日本時間の 9:00 am JST にご参加ください。



事前お申込み受付中 : http://goo.gle/OpenDataLakeDayJP


開催概要

名 称 『Open data lake day』

日 程 日本語版 : 5 月 7 日(金)9:00 am - 11:00 am JST (日本時間)

    英 語 版 : 5 月 6 日(木)9:00 am - 11:00 am PST (太平洋時間)

対 象 開発エンジニア、インフラ エンジニア、運用エンジニア

参加費 無料(事前登録制)

登 録 http://goo.gle/OpenDataLakeDayJP


基調講演

オープンソースによってイノベーションとクラウドの壁を取り除く

アマー・アワダラ

クラウド・デベロッパー・リレーションズ 担当 副社長 (Google)


この記事は Chrome チーム、Shweta Panditrao、Mustafa Emre Acer による Chromium Blog の記事 "A safer default for navigation: HTTPS" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

バージョン 90 より、Chrome のアドレスバーで https:// がデフォルトとして使われるようになります。これによってプライバシーが向上し、HTTPS をサポートするウェブサイトにアクセスしたときの読み込み速度も上がります。Chrome ユーザーが手動で URL を入力してウェブサイトを開くとき、多くの場合は “http://” や “https://” を含めません。たとえば、アドレスバーに “https://example.com” ではなく “example.com” と入力することがよくあります。このとき、ユーザーが初めてそのウェブサイトを訪れる場合は、これまでの Chrome の動作ではデフォルトのプロトコルとして http:// が選択されていました 1。これは、ウェブの多くが HTTPS をサポートしていなかった過去においては、現実的なデフォルトでした。

今後は、プロトコルを指定せずに入力されたほとんどのナビゲーションで、Chrome のデフォルトが HTTPS になります 2。HTTPS は、安全性が向上しているだけでなく、すべての主要プラットフォームの Chrome で最も広く使われているスキームです。この変更により、セキュリティとプライバシーが明らかに向上することに加え、HTTPS をサポートするサイトの初回読み込み速度も上がります。Chrome が HTTPS エンドポイントに直接接続し、http:// から https:// にリダイレクトする必要がなくなるからです。まだ HTTPS をサポートしていないサイトでは、HTTPS による試行が失敗した後、HTTP にフォールバックします(名前の不一致、信頼できない自己署名証明書などの証明書エラーや、DNS の解決失敗などの接続エラーが発生した場合も含みます)。この変更は、まずバージョン 90 の Chrome デスクトップ版と Android 版にロールアウトされ、その後近いうちに iOS 版の Chrome にもリリースされます。

HTTPS では、ユーザーがウェブサイトに入力した機密情報が攻撃者や盗聴者によって傍受または改ざんされないように、ネットワークに送られるトラフィックを暗号化してユーザーを保護します。Chrome では、HTTPS をウェブのデフォルトのプロトコルにするための取り組みが行われています。今回の変更で、デフォルトで常に安全な接続を使うことに一歩近づきます。

1 主な例外の 1 つは、HSTS プリロード リストに含まれるサイトです。これらのサイトでは、常にデフォルトが HTTPS になります。
2 IP アドレス、シングルラベル ドメイン、test/ や localhost/ などの予約されているホスト名では、引き続き HTTP がデフォルトになります。


Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Google Trust Services、プロダクト マネジメント、Ryan Hurst による Google Online Security Blog の記事 "Google, HTTPS, and device compatibility" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

世界中の情報を整理し、強固なセキュリティとプライバシーで保護しつつ広くアクセスできるようにするというミッションにおいて、暗号化は基本的な構成要素です。今から 4 年少し前に、公的に信頼できる認証局(CA)として Google Trust Services を設立したのはそのためです。

公的に信頼される認証局になるまでの道のりは長く、インターネットで特にアクセスの多いサイトの証明書を発行しているなら、なおさらです。

この歩みが始まったときの目標は、5 年以内にルート証明書が十分多くのデバイスに組み込まれ、1 回で長期ルート証明書に移行できるようにすることでした。

現在も、Google のルート証明書の更新が行われていない中古のデバイスがたくさん使われています。

Google Trust Services の証明書を使う際、できる限り多くのクライアントが確実に安全な接続を続けられるようにするには、クロス署名を取得する必要がありました。クロス署名を使うと、すでにデバイスから信頼されている認証局が、そのデバイスの互換性を別の認証局に拡大できます。

パブリック CA の運用における規則では、クロス署名された CA は、クロス署名を提供する側の認証局と厳密に同一の運用、技術、監査の各基準を満たす必要があると規定されています。Google Trust Services は高水準で運用されており、すでに公的に信頼されている CA です。また、すべての主要なブラウザのトラストストアに格納されています。そのため、すでに別の CA からのクロス署名要件を満たしていました。重要な点は、Google の証明書を検証できるようにしたいデバイスで、すでに信頼されている認証局を見つけることでした。そこで、このクロス署名に関して GMO GlobalSign と連携することにしました。現在広く使われているルート証明書の中でも、特に古くから運用されているためです。

なぜここでこのような話をしているかというと、2021 年 12 月 15 日に、現在使用しているプライマリ ルート証明書(Google Trust Services が所有、運用している GlobalSign R2)の有効期限が切れるためです。

Google が発行する証明書を搭載した古いデバイスが問題なく動作を続けられるようにするため、新たな証明書を発行するタイミングで、新しいクロス署名証明書のサービスへの送信を開始します。

ありがたいことに、ユーザーはこの変更に気づくことはないはずです。これは、Google がデプロイしているクロス証明書(GTS Root R1 Cross)は 20 年以上前に作成されたもので、ほとんどのデバイスにおいて信頼されているルート証明書で署名されているからです。

つまり、Google Trust Services の証明書を使用している方やそのお客様は、業界最大級のデバイスの互換性というメリットを引き続き活用できます。

この変更について、質問がある方もいらっしゃるでしょう。特に多く寄せられる質問について、以下に回答を記載します。

デベロッパーまたは ISV として Google API を使用しています。何をする必要がありますか?

認証局は使用するルート CA 証明書を随時変更しています。そのため、Google は現在使用している、または今後使用する可能性がある証明書のリストを常に提供しています。このリストを使っている方は、何も変更する必要はありません。このリストを使っておらず、Google が公開しているガイドに基づく更新をしていない方は、ユーザーが今後の変更にスムーズに対応できるように、これらのルートを使うようにアプリケーションを更新し、定期的にリストを更新する必要があります。

Google Trust Services の証明書を使ってウェブサイトを運用しています。何か変更は必要ですか?

何もありません。Google Trust Services は、多くの Google Cloud のサービスを含む Alphabet のプロダクトやサービスに証明書を提供しています。TLS の設定や管理はこれらのサービスが行ってくれます。

変更が反映されるのはいつですか? 

このクロス証明書を使う証明書チェーンのロールアウトは、2021 年 3 月から始まります。この変更は今年いっぱいをかけてゆっくりとロールアウトし、2021 年 12 月 15 日までに終える予定です。

Google Trust Services を使っているサービスやプロダクトを使用しています。何か変更は必要ですか?ありません。エンドユーザーはこの変更に気づかないはずです。

デバイスがこのクロス署名を使った証明書を信頼していることは、どうすればテストできますか? 

このクロス証明書を使ったテストサイトを作成しています。テストサイトには、こちらからアクセスできます。追加の証明書情報とともに "Google Trust Services Demo Page - Expected Status: good" と表示される場合、そのデバイスで新しい証明書チェーンが正しく動作しています。エラーが表示される場合は、テストしているデバイスの信頼されたルートのリストを更新する必要があります。

このクロス証明書の有効期限はいつですか?また、その有効期限が切れるとどうなりますか? 

クロス証明書の有効期限は、2028 年 1 月 28 日です。今後、クロス証明書がなくても多くのデバイスとの互換性を確保できるようになったと考えられれば、この追加の証明書は不要になるため、証明書要求者への提供を停止する予定です。

クロス署名を信頼しない古いデバイスを使っています。どうすればよいですか? 

多くのデバイスは、セキュリティ パッチ処理の一環としてルート証明書の更新をします。そのようなデバイスを使っている場合は、関連するすべてのセキュリティ アップデートを確実に適用してください。お使いのデバイス向けのセキュリティ アップデートをメーカーがもう提供していない場合もあるかもしれません。その場合は、プロバイダに連絡するか、デバイスを換えることを検討してください。

これは Google Trust Services のルートを使えなくなるということですか?Google Trust Services ルートは今後も使用されます。単にそれがクロス署名されるということです。クロス署名を使う必要がなくなれば、証明書要求者にクロス署名を配布することはなくなります。

詳細は、Google Trust Services をご覧ください。

Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Android チーム、Sudhi Herle、Jason Wong による Google Online Security Blog の記事 "Announcing the Android Ready SE Alliance" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

2018 年に発売された Pixel 3 には、Titan M と呼ばれる新しい改ざん防止ハードウェア エンクレーブが搭載されました。これは、Pixel のソフトウェアとファームウェアの信頼の基点となるだけでなく、StrongBox を使った Android アプリ用の改ざんできない鍵ストレージも実現しています。StrongBox は、ハードウェアのセキュリティ モジュール内にある Keymaster HAL の実装です。これは Android デバイスにとっての重要なセキュリティ強化策であり、これまで実現できなかった機能を検討する道を開くものです。

StrongBox と改ざん防止ハードウェアは、新たに登場する次のようなユーザー機能の重要な要件になりつつあります。

  • デジタルキー(自動車、家、オフィス)
  • モバイル運転免許証(mDL)、国民識別番号、e パスポート
  • 電子マネー ソリューション(Wallet など)

こういった機能は、すべて改ざん防止ハードウェアで実行する必要があり、アプリケーションの実行ファイルやユーザーのデータ、鍵、財布などの整合性を守ります。現在、ほとんどの最新スマートフォンには、セキュア エレメント(SE)と呼ばれる個別の改ざん防止ハードウェアが含まれています。Google は、この SE こそが、上記のような新しい消費者向けのユースケースを Android に導入するための最善の道であると確信しています。

こういった新しい Android のユースケースの採用を加速するため、Android Ready SE Alliance を設立したことをお知らせします。SE ベンダーと Google は、すぐに使えるオープンソースの検証済み SE アプレットを作成するため、力を合わせています。今日(元記事公開当時)、SE 向け StrongBox の一般提供(GA)版を公開します。このアプレットは、OEM パートナーによって作成、認定されています。現在のところ、Giesecke+DevrientKigenNXPSTMicroelectronicsThales がこのアプレットを公開しています。

覚えておくべき重要な点は、これらの機能はスマートフォンやタブレットだけのものではないことです。StrongBox は、WearOS、Android Auto Embedded、Android TV でも利用できます。

OEM パートナーがデバイスで Android Ready SE を使うには、以下の作業が必要です。

  1. SE ベンダーから適切な検証済みハードウェア パーツを取得する
  2. ブートローダーから SE を初期化できるようにし、SPI インターフェースまたは暗号化バインディングを通して信頼の基点(RoT)パラメータを提供する
  3. Google と連携し、SE の製造現場で構成証明鍵・証明書をプロビジョニングする
  4. SE の用途に対応する、SE 向け StrongBox アプレットの GA 版を使用する
  5. HAL コードを組み込む
  6. SE アップグレード メカニズムを有効化する
  7. StrongBox で CTS/VTS テストを実行し、組み込みが正常に行われていることを検証する

Google はエコシステムと連携し、以下のアプレットと、対応する Android 機能のリリースを優先して作業を進めています。

  • モバイル運転免許証と ID 認証情報
  • 自動車のデジタルキー

いくつかの Android OEM パートナーは、すでにデバイスで Android Ready SE を採用しています。OEM パートナーと連携して、このような次世代の機能をユーザーに提供できることを楽しみにしています。

詳しくは、Android セキュリティとプライバシーのデベロッパー サイトをご覧ください。


Reviewed by Eiji Kitamura - Developer Relations Team

Posted by
フリービット株式会社が開発し株式会社ドリーム・トレイン・インターネットが販売する TONE e20 TONE e21 は TensorFlow を活用した未成年の自撮り被害を防ぐ画像認識機能を実装したスマートフォンです。


子供向けスマートフォンの課題

インターネット上のトラブルに十分な知識を持たない子供に高性能なカメラを搭載したスマートフォンの所有がに広がることにより、不適切な自撮りによる被害が発生するようになっています。


この問題は保護者にとって深刻です。問題を避けるために子供にスマートフォンを持たせいないという選択肢もありますが、昨今、子供の日常生活でもスマートフォンが必要とされることも多く、いかに安全なスマートフォンを子供に持たせるかが課題となっています。


TONE e20 はこの問題を技術で解決するために、TensorFlow を活用した画像検知機能を実装しています。

通信せずに不適切な画像を TensorFlow を使用して検知

TONE e20 と TONE e21 にはフリービット株式会社によって開発された特定の画像を AI により自動検知するカメラアプリが標準カメラとしてインストールされています。


この標準カメラは自動で裸などの不適切な画像や映像を検知して規制し、あらかじめ設定された保護者の端末に通知する機能を有しています。




この AI による自動検知は TensorFlow のモバイル向けフレームワークである TensorFlow Lite を使い、端末内で処理されています。


画像の認識には通信機能を使いクラウド上にサーバー側で処理する、という実装方法もありますがセンシティブな内容を含む写真や映像を通信に乗せるコストやリスクを考慮して TONE e20 と TONE e21 では端末内で処理する方式としています。


端末内での処理は AI 専用のチップや GPU を使うことなく、CPU を使用しています。カメラアプリとして快適に利用できるよう処理速度はチューニングされ、画像についてはシャッターを押してからおおよそ 200 ミリ秒 から 1 秒以内、平均で 400 - 600 ミリ秒で処理が完了します。 映像については Android Jetpack の カメラ ライブラリをもとに作成し、一定間隔でキャプチャした画像を検知する仕組みとしてます。


写真、映像ともに不適切な画像を検知した場合は保存させないように規制するとともに保護者の端末に通知する流れとなっています。

モデルは既存のものを活用

TONE e20 と TONE e21 に実装した、不適切な画像を検知する学習モデルは独自に開発したものではありません。

Yahoo が開発していた Caffe をベースとした open nsfw model を TensorFlow Lite のモデルに変換することで利用しています。Caffe はカリフォルニア大学バークレー校が中心となって開発しているオープンソースのディープラーニング ライブラリです。Caffe は TensorFlow のために開発されたモデルではありませんが、さまざまなオープンソースやデベロッパーがブログで公開していたノウハウを活用して変換しています。
  

検知機能への反応と評価

フリービット株式会社は 2013 年からスマートフォン事業をスタートし、2015 年からは トーンモバイル を運営しています。


回線インフラ・ SIM ・サービス・端末を一貫して手掛けることができるのは、トーンモバイルを運営する株式会社ドリーム・トレイン・インターネットを含むフリービットグループで垂直統合しているためです。


トーンモバイルでは単に端末を販売するのではなく、独自の付加価値をもった端末を自社で開発しています。今回ご紹介した AI による不適切な画像の自動検知もその付加価値の一つです。


すでに TONE e20 を購入した保護者の方々からは良い反応を得ています。不適切な自撮り画像の検知だけでなく、AI を活用したいくつかの子供向けの見守り機能が評価されています。安心して子供に渡せるスマートフォンとして評価され、いくつかの自治体では子供向けの推奨スマートフォンとして認証されています。


自撮り画像の検知機能については端末依存の機能ではなく、アプリとして開発されたものです。今後はカメラ機能そのものを向上させるとともに、他の Android スマートフォンや iPhone でも利用できるアプリとしての展開も検討しています。


Posted by Khanh LeViet - Developer Relations Team

この記事は Sam Dutton による developer.chrome.com の記事 "How to take part in the FLoC origin trial" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Federated Learning of Cohorts(FLoC)は、プライバシーを保護しつつ、興味ベースで広告を選択するメカニズムです。ユーザーがウェブを動き回ると、ブラウザは FLoC アルゴリズムを使って「興味コホート」を割り出します。これは、直近の閲覧履歴が似ているたくさんのブラウザで共通するものです。ユーザーのブラウザは一度に 1 つの興味コホートと関連付けられますが、コホートはユーザーのデバイスで定期的(今回の最初のオリジン トライアルの時点では、7 日ごと)に再計算されます。個々の閲覧データがブラウザ ベンダーなどの他者と共有されることはありません。

FLoC の詳細については、Federated Learning of Cohorts(FLoC)の概要をご覧ください。

オリジン トライアルに参加する

トライアルは、サードパーティ オリジン トライアルとして Chrome 89 で始まる予定です(元記事公開当時。すでに開始されています)。
FLoC オリジン トライアル トークンを取得するには、登録する必要があります。

ファーストパーティ コンテキスト

自分のサイトで興味コホートのデータにアクセスするには、以下の方法のどちらかを使ってウェブページにオリジン トライアル トークンを追加します。

  • 各ページの <head> 内のメタタグに次を含める :

    <meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">

  • HTTP ヘッダーに次を含める :

    Origin-Trial: TOKEN_GOES_HERE

これをすると、ファーストパーティ コンテキストで FLoC を試すことができます。たとえば、サイトにアクセスしたユーザーのコホートを確認できます。

サードパーティ コンテキスト

サードパーティのサイトで自分のコードから FLoC API をテストするには、メタタグにオリジン トライアル トークンを注入する必要があります。具体的な方法は、ウェブ デベロッパー向けオリジン トライアル ガイドで説明されています。

フィードバックを送信する

Chrome のオリジン トライアル サイトから行ってください。このフィードバックは公開されず、Chrome チームの一部のグループのみが利用します。
トークンの有効期限が切れると、メールで更新リンクが送られます。トークンを更新する前に、フィードバックの送信を促すメッセージが表示されます。

ウェブ デベロッパーとして FLoC を試す

FLoC API はシンプルで、Promise を返すメソッドが 1 つあるだけです。この Promise は、コホートの idversion を表すオブジェクトに解決されます。

document.interestCohort()

利用できるようになったコホートのデータは、次のように見えます。

    {
"id": "14159",
"version": "chrome.1.0"
}

FLoC API は Chrome 89 以降で利用できますが、オリジン トライアルに参加していない場合は、フラグを設定してコマンドラインから Chrome を実行する必要があります。さまざまなオペレーティング システムで実行する方法は、フラグ付きで Chromium を実行するで説明されています。

  1. 次のフラグを使って Chrome を起動します。

    --enable-blink-features=InterestCohortAPI 
    --enable-features="FederatedLearningOfCohorts:update_interval/10s/minimum_history_domain_size_required/1,FlocIdSortingLshBasedComputation,InterestCohortFeaturePolicy"
  2. サードパーティ Cookie がブロックされていないこと、広告ブロッカーが実行されていないことを確認します。

  3. floc.glitch.me のデモを確認します。

パブリッシャー、広告主、アドテック プラットフォームとして FLoC を試す

FLoC API の説明でユースケースが提示されていますが、API の使用方法は定義されていません。FLoC を使って関連するコンテンツや広告を提供する場合、サイトやサービスによって制約や要件が異なります。

独自の技術によってお勧めコンテンツ、広告、マーケティングのサービスを提供している場合は、FLoC の知見を適用することで、特定のコホートに対して最適なコンテンツやマーケティング メッセージを提供できます。これらのサービスを提供するサードパーティ企業を利用している場合は、その企業がオリジン トライアルに参加し、皆さんのサイトや他のサイトを含めた実験をする方がよいかもしれません。

たとえば、関連コンテンツを選択する方法を探しているパブリッシャーがオリジン トライアルの期間中に FLoC を試すプロセスは、次のようになります。

  1. サイトの利用状況とコホート ID のデータを収集する。
  2. データを分析して相関関係を抽出する。データを使って関連コンテンツを選択する。
  3. FLoC によるアプローチと他のメカニズムを比較する。期待どおりに動作したかを確認する。
  4. コンテンツを選択するための FLoC の使い方を調整する。
  5. オリジン トライアルのフィードバックを提供する。
  6. 以上を繰り返す。

ウェブサイトで FLoC の計算をオプトアウトする方法

サイトで宣言をすると、コホートを計算するためのユーザーのサイト一覧からそのサイトが除外されるようにする必要があります。新しい interest-cohort パーミッション ポリシーによって、これが可能になります。このポリシーは、デフォルトで allow となる予定です。

interest-cohort パーミッションが許可されていないフレームでは、document.interestCohort() を呼び出したときに返される Promise はリジェクトされます。メインのフレームに interest-cohort パーミッションがない場合、そのページへのアクセスは興味コホートの計算には使われません。

たとえば、次の HTTP レスポンス ヘッダーを送ると、すべての FLoC コホート計算をオプトアウトできます。

Permissions-Policy: interest-cohort=()

FLoC のオリジン トライアルの期間中、オプトアウトしていないウェブサイトは、そのサイトが広告関連のリソースを読み込んだことが Chrome によって検知されると、FLoC の計算に含まれます。

Chrome で広告検出メカニズムが動作する仕組みについては、Chromium での広告タグ付けで説明されています。

関連情報



Reviewed by Eiji Kitamura - Developer Relations Team


この記事は Sam Dutton による web.dev の記事 "What is Federated Learning of Cohorts (FLoC)?" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


概要

FLoC は、プライバシーを保護しつつ、興味ベースで広告を選択するメカニズムです。

ユーザーがウェブを動き回ると、ブラウザは FLoC アルゴリズムを使って、直近の閲覧履歴が似ているたくさんのブラウザで共通する「興味コホート」を割り出します。コホートはユーザーのデバイスで定期的に再計算されますが、個々の閲覧データがブラウザ ベンダーなどの他者と共有されることはありません。

広告主(お金を払って広告を出稿するサイト)は、自分のウェブサイトにコードを含めてコホートデータを収集し、アドテック プラットフォーム(広告を配信するソフトウェアやツールを提供する企業)に提供できます。たとえば、アドテック プラットフォームは、オンラインの靴店から、コホート 1101 と 1354 のブラウザはこの店のハイキング グッズに興味があるかもしれないことを把握できます。その他の広告主から、アドテック プラットフォームは各コホートのその他の興味を知ることができます。

次に、広告プラットフォームはこのデータを使って、これらのコホートのいずれかに属するブラウザが広告掲載サイト(ニュースサイトなど)のページをリクエストしたときに、関連性が高い広告(先ほどの靴店のハイキング シューズなど)を選択できます。

Privacy Sandbox は、サードパーティ Cookie などのトラッキング メカニズムを使わずにサードパーティ ユースケースを満たすための一連の提案です。各提案の概要については、Privacy Sandbox の詳細をご覧ください。

この提案について、皆さんからのフィードバックが必要です。コメントがある方は、FLoC Explainer リポジトリで Issue を作成してください。この提案に関連する Chrome の試験運用についてフィードバックがある方は、試験運用の目的に返信する形で投稿してください。

FLoC が必要になる理由

多くの企業は、サイトのトラフィックを増加するために広告を利用しています。そして多くのパブリッシャーのウェブサイトは、広告のインベントリを販売することで、コンテンツの資金を得ています。ユーザーは通常、関連性が高く有用な広告を見ることを好みます。また、広告の関連性が高いほど、広告主に多くのビジネスを、広告をホストしているウェブサイトに多くの収益をもたらします。言い換えれば、関連性の高い広告を表示すれば、広告スペースの価値が上がります。したがって、関連性の高い広告を選ぶことで、広告がサポートするウェブサイトの収益が上がります。つまり、関連性の高い広告は、ユーザーにメリットをもたらすコンテンツを制作するための資金源になります。

しかし、多くのユーザーは、関連性の高い広告が示唆するプライバシーの問題を心配しています。現在、このような広告は、Cookie によるトラッキングやデバイスのフィンガープリンティングなどの技術を利用しています。これらは、個人の閲覧動作を追跡するために使われる技術です。FLoC の提案は、プライバシーを侵害せずに広告選択の効率を高めることを目指しています。

FLoC の利用目的

  • 広告主のサイトに頻繁にアクセスしたコホートや、それに関連するトピックに興味を示したコホートに属するブラウザを使うユーザーに広告を表示する。
  • 機械学習モデルを使用して、ユーザーをコンバージョンできる可能性をコホートに基づいて予測し、広告オークションの入札動作に反映する。
  • ユーザーにコンテンツをお勧めする。たとえば、あるニュースサイトで、スポーツのポッドキャスト ページの人気がコホート 1234 と 7 のユーザーの間で特に高い場合、同じコホートの他のユーザーにもそのコンテンツをお勧めできる。

FLoC の動作の仕組み

下の例は、FLoC を使って広告を選択するうえでのそれぞれの役割について説明しています。

  • この例の広告主(お金を払って広告を出稿する企業)は、次のオンライン靴店です。
    shoestore.example

  • この例のパブリッシャー(広告スペースを販売するサイト)は、次のニュースサイトです。
    dailynews.example

  • アドテック プラットフォーム(広告を配信するソフトウェアやツールを提供する企業)は、次のサイトです。
    adnetwork.example

FLoC を使って広告を選択して配信するうえでのそれぞれの役割について、順を追って説明する図。FLoC サービス、ブラウザ、広告主、パブリッシャー(コホートの観測)、アドテック、パブリッシャー(広告の表示)

この例では、ユーザーを YoshiAlex と呼びます。最初の状態では、どちらのブラウザも同じコホート 1354 に属しています。

ここではユーザーを Yoshi と Alex と呼んでいますが、これは例示のみの目的です。FLoC では、広告主、パブリッシャー、アドテック プラットフォームに名前や個々の ID が明かされることはありません。

コホートをユーザーの集合と考えないでください。そうではなく、コホートは閲覧アクティビティをグループ化したものと考えてください。

1. FLoC サービス

  1. ブラウザによって利用される FLoC サービスは、たくさんの「コホート」を持つ数学的なモデルを作成します。各コホートは、最近の閲覧履歴が似ているたくさんのウェブブラウザに対応しています。この処理については、後ほど詳しく説明します。
  2. それぞれのコホートに番号が付けられます。

2. ブラウザ

  1. Yoshi のブラウザは、FLoC サービスから FLoC モデルの詳細データを取得します。
  2. Yoshi のブラウザは、FLoC モデルのアルゴリズムを使ってどのコホートが自分の閲覧履歴に最も近いかを計算し、自分のコホートを割り出します。この例では、コホート 1354 とします。Yoshi のブラウザは、FLoC サービスに何のデータも送信していない点に注目してください。
  3. 同じように、Alex のブラウザもコホート ID を計算します。Alex の閲覧履歴は Yoshi の履歴とは違いますが、かなり似ているので、どちらのブラウザもコホート 1354 に属すると判断されます。

3. 広告主 : shoestore.example

  1. Yoshi が shoestore.example にアクセスします。
  2. サイトが Yoshi のブラウザにコホートを尋ねます。1354 が返されます。
  3. Yoshi がハイキング シューズのページを閲覧します。
  4. サイトは、コホート 1354 のブラウザがハイキング シューズに興味を示したことを記録します。
  5. サイトは後ほど、コホート 1354 が興味を示した製品についての追加情報も記録します。他のコホートについても同様です。
  6. サイトは、コホートと興味が示された製品についての情報を定期的に集計し、アドテック プラットフォーム adnetwork.example に送信します。

次は Alex です。

4. パブリッシャー : dailynews.example

  1. Alex が dailynews.example にアクセスします。
  2. サイトは Alex のブラウザにコホートを尋ねます。
  3. その後、アドテック プラットフォーム adnetwork.example に広告をリクエストしますが、その際に Alex のブラウザのコホート 1354 を含めます。

5. アドテック プラットフォーム : adnetwork.example

  1. adnetwork.example は、Alex に適した広告を選択できます。その際に、パブリッシャー dailynews.example と 広告主 shoestore.example からの以下のデータを組み合わせて利用します。
    • Alex のブラウザのコホート(1354)。dailynews.example から提供されたもの。
    • コホートと製品に対する興味に関するデータ。shoestore.example から提供されたもの。「コホート 1354 のブラウザはハイキング シューズに興味がある可能性がある」
  2. adnetwork.example は Alex に適した広告を選択します。ハイキング シューズの広告で、shoestore.example によるものが選ばれます。
  3. dailynews.example が広告 🥾 を表示します。

現在の広告選択には、Cookie によるトラッキングやデバイスのフィンガープリンティングなどの技術が利用されています。これらは、広告主などのサードパーティが個人の閲覧行動を追跡するために使われる技術です。

FLoC では、ブラウザは FLoC サービスにも他の誰にも閲覧履歴を送信しません。ブラウザは、ユーザーのデバイス上でブラウザ自身が属するコホートを割り出します。ユーザーの閲覧履歴がデバイスを離れることは一切ありません。

FLoC モデルを作るバックエンド サービスは誰が運用するのか?

各ブラウザ ベンダーは、それぞれにどのようにコホートを作り出すのかを選択する必要があります。Chrome は独自の FLoC サービスを運用していますが、他のブラウザは異なるクラスタリングアプローチを採った FLoC を実装し、独自のサービスを運用する可能性があります。

FLoC サービスがブラウザにコホートを割り出す方法

  1. ブラウザによって利用される FLoC サービスは、すべての潜在的なウェブ閲覧履歴を表す多次元数学的表現を作成します。このモデルを「コホート空間」と呼びます。
  2. サービスはこの空間をたくさんのセグメントに分割します。各セグメントは、たくさんの類似した閲覧履歴のクラスタを表します。このグループ分けは、実際の閲覧履歴に基づくものではありません。単に「コホート空間」でランダムな中心を選んだり、空間をランダムな線で分割したりしたものです。
  3. それぞれのセグメントにコホート番号が与えられます。
  4. ウェブブラウザは、FLoC サービスから「コホート空間」を示すこのデータを取得します。
  5. ユーザーがウェブを動き回ると、ブラウザはあるアルゴリズムに基づき、「コホート空間」内でのブラウザ自身の閲覧履歴に最も近い領域を定期的に計算します。
FLoC サーバーが作成した「閲覧履歴空間」の図。コホート番号が振られた複数のセグメントが存在する。
FLoC サービスは「コホート空間」をたくさんのセグメントに分割する(ここに示すのは一部のみ)。

このプロセスのどの時点においても、ユーザーの閲覧履歴が FLoC サービスやサードパーティに送信されることはありません。ブラウザのコホートは、ユーザーのデバイス上でブラウザ自身が計算します。FLoC サービスは、ユーザーデータを取得することも、保管することもありません。

ブラウザのコホートは変わることがあるか

はい、ブラウザのコホートはもちろん変わることがあります。毎週同じウェブサイトにアクセスすることはないでしょう。ブラウザのコホートはそれを反映します。

コホートは、ユーザーの集まりではなく、閲覧アクティビティのクラスタを表します。通常、コホートの行動の特徴は時間が経っても一貫性があり、コホートは最近の閲覧行動が似ているグループなので、広告の選択に役立ちます。それぞれのユーザーのブラウザは、閲覧行動の変化とともにコホートを出入りします。まずは、7 日ごとにブラウザがコホートを再計算することを想定しています。

上の例では、Yoshi と Alex のブラウザのコホートはどちらも 1354 でした。将来的に興味が変われば、Yoshi のブラウザと Alex のブラウザが別のコホートに移動する可能性があります。下の例では、Yoshi のブラウザはコホート 1101 に移動し、Alex のブラウザはコホート 1378 に移動します。他のユーザーのブラウザも、閲覧の興味が変わるにつれてコホートを出入りします。

FLoC サーバーが作成した「閲覧履歴空間」の図。コホート番号が振られた複数のセグメントが存在する。時間とともに閲覧の興味が変わるにつれて、ユーザーの Yoshi と Alex に属するブラウザが別のコホートに移動する様子を示した図。
興味が変われば、Yoshi と Alex のブラウザのコホートは変わる可能性がある。

コホートは、ユーザーのグループではなく、閲覧アクティビティのグループを定義します。行動が変わるにつれて、ブラウザはコホートを出入りします。

ブラウザはどのようにしてコホートを割り出すのか

前述のように、ユーザーのブラウザはコホートの数学モデルの詳細データを FLoC サービスから取得します。これは、すべてのユーザーの閲覧アクティビティを表す多次元空間です。その後、ブラウザはあるアルゴリズムを使い、この「コホート空間」のどの領域(すなわち、どのコホート)が最近の自身の閲覧行動に最も近いかを割り出します。

FLoC はどのようにしてコホートの適切なサイズを割り出すのか

各コホートには、たくさんのブラウザが存在することになります。

コホートのサイズが小さい場合、広告のパーソナライズには役立つかもしれませんが、ユーザーのトラッキングをやめることにはなりません。逆もまた同様です。ブラウザをコホートに割り当てるメカニズムには、プライバシーと有用性との間でトレードオフが必要になります。Privacy Sandbox は、ユーザーが「集団の中に隠れる」ことができるように、k-匿名性を利用します。コホートは、少なくとも k 人のユーザーによって共有されれば、k-匿名性があります。k の数が大きくなるほど、コホートのプライバシーは高くなります。

プライベートな分類に基づいてユーザーをグループ化するために FLoC を使えるか

FLoC のコホートモデルを作成するために使うクラスタリング アルゴリズムは、なぜ分類がプライベートなのかは知ることなく、コホートにプライベートな分類と相関関係があるかどうかを評価できるように設計されています。人種、性別、病歴など、プライベートな分類が明らかになる可能性があるコホートはブロックされます。言い換えれば、コホートを割り出すとき、ブラウザはプライベートな分類が明らかにならないようなコホートのみを選択します。

FLoC はオンラインでユーザーを分類するための別の方法にすぎないのか

FLoC では、ユーザーのブラウザは他のたくさんのユーザーのブラウザとともに、たくさんのコホートのうちの 1 つに属します。サードパーティ Cookie やその他のターゲティング メカニズムとは異なり、FLoC はユーザーのブラウザが属するコホートしか明かさず、個々のユーザー ID が明らかになることはありません。そのため、他者がコホート内の個人を特定することはできません。さらに、ブラウザのコホートを割り出すために使われる閲覧アクティビティに関する情報は、ローカルのブラウザやデバイスに留まり続けて、他の場所にアップロードされることはありません。ブラウザは、差分プライバシーなどの他の手法を使ってさらに匿名化することもできます。

ウェブサイトは参加して情報を共有する必要があるのか

ウェブサイトは、FLoC をオプトインすることもオプトアウトすることもできます。そのため、プライベートなトピックを扱うサイトは、そのサイトへのアクセスを FLoC の計算に含めないようにすることもできます。さらなる保護として、FLoC サービスによる分析では、そのコホートがなぜプライベートであるかを知ることなく、コホートによってユーザーに関するプライベートな情報が明らかになる可能性があるかどうかを評価します。あるコホートで、サイトにアクセスしたユーザーのうちプライベートな分類に属するユーザーの数が典型的なユーザーの数を超えている可能性がある場合、そのコホート全体が削除されます。この分析で扱われるプライベートな分類には、負債状況やメンタルヘルスなどが含まれます。

ウェブサイトは Permissions-Policy ヘッダーに interest-cohort=() を設定すると、FLoC 計算からオプトアウトすることができます。オプトアウトしていないページでは、document.interestCohort() が使われていると、ブラウザの FLoC 計算に含まれることになります。FLoC のオリジントライアル期間中、広告や広告に関連するリソースを読み込むことが検知された場合も、ブラウザの FLoC 計算に含まれることになります(Chrome の広告検知メカニズムの仕組みは、Chromium での広告のタグ付けで説明しています)。イントラネットのサイトなど、プライベートな IP アドレスから提供されているページは、FLoC の計算対象に含まれません。

ウェブ デベロッパーとして FLoC を試すにはどうすればよいか

FLoC API はシンプルで、Promise を返すメソッドが 1 つあるだけです。この Promise は、コホートの idversion を表すオブジェクトに解決されます。

const { id, version } = await document.interestCohort();
console.log('FLoC ID:', id);
console.log('FLoC version:', version);

利用できるようになったコホートのデータは、次のように見えます。

{
"id": "14159",
"version": "chrome.1.0"
}

FLoC を使うサイトは、version の値を使って、コホート ID が参照するブラウザと FLoC モデルを知ることができます。以下の説明のとおり、interest-cohort パーミッションが許可されていないフレームでは、document.interestCohort() が返す Promise はリジェクトされます。

FLoC API は Chrome 89 以降で利用できますが、オリジン トライアルに参加していない場合は、フラグを設定してコマンドラインから Chrome を実行する必要があります。さまざまなオペレーティング システムで実行する方法は、フラグ付きで Chromium を実行するで説明されています。

  1. 次のフラグを使って Chrome を起動します。

    --enable-blink-features=InterestCohortAPI  
    --enable-features="FederatedLearningOfCohorts:update_interval/10s/minimum_history_domain_size_required/1,FlocIdSortingLshBasedComputation,InterestCohortFeaturePolicy"
  2. サードパーティ Cookie がブロックされていないこと、広告ブロッカーが実行されていないことを確認します。

  3. floc.glitch.me のデモを確認します。

ファーストパーティとサードパーティのそれぞれのコンテキストで FLoC を試す方法は、FLoC のオリジン トライアルに参加する方法で説明しています。

ウェブサイトで FLoC の計算をオプトアウトするにはどうすればよいか

サイトで interest-cohort パーミッション ポリシーを使うと、コホートを計算するためのユーザーのサイト一覧から除外することを宣言できます。このポリシーは、デフォルトで allow となる予定です。interest-cohort パーミッションが許可されていないフレームでは、document.interestCohort() が返す Promise はリジェクトされます。メインのフレームに interest-cohort permission がない場合、そのページへのアクセスは興味コホートの計算には使われません。

たとえば、次の HTTP レスポンス ヘッダーを送ると、すべての FLoC コホート計算をオプトアウトできます。

  Permissions-Policy: interest-cohort=()

提案やフィードバックをするにはどうすればよいか

API に関するコメントがある方は、FLoC Explainer リポジトリで Issue を作成してください。

関連情報


Reviewed by Eiji Kitamura - Developer Relations Team