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)
バージョン 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 がデフォルトになります。
2018 年に発売された Pixel 3 には、Titan M と呼ばれる新しい改ざん防止ハードウェア エンクレーブが搭載されました。これは、Pixel のソフトウェアとファームウェアの信頼の基点となるだけでなく、StrongBox を使った Android アプリ用の改ざんできない鍵ストレージも実現しています。StrongBox は、ハードウェアのセキュリティ モジュール内にある Keymaster HAL の実装です。これは Android デバイスにとっての重要なセキュリティ強化策であり、これまで実現できなかった機能を検討する道を開くものです。
StrongBox と改ざん防止ハードウェアは、新たに登場する次のようなユーザー機能の重要な要件になりつつあります。
こういった機能は、すべて改ざん防止ハードウェアで実行する必要があり、アプリケーションの実行ファイルやユーザーのデータ、鍵、財布などの整合性を守ります。現在、ほとんどの最新スマートフォンには、セキュア エレメント（SE）と呼ばれる個別の改ざん防止ハードウェアが含まれています。Google は、この SE こそが、上記のような新しい消費者向けのユースケースを Android に導入するための最善の道であると確信しています。
こういった新しい Android のユースケースの採用を加速するため、Android Ready SE Alliance を設立したことをお知らせします。SE ベンダーと Google は、すぐに使えるオープンソースの検証済み SE アプレットを作成するため、力を合わせています。今日（元記事公開当時）、SE 向け StrongBox の一般提供（GA）版を公開します。このアプレットは、OEM パートナーによって作成、認定されています。現在のところ、Giesecke+Devrient、Kigen、NXP、STMicroelectronics、Thales がこのアプレットを公開しています。
覚えておくべき重要な点は、これらの機能はスマートフォンやタブレットだけのものではないことです。StrongBox は、WearOS、Android Auto Embedded、Android TV でも利用できます。
OEM パートナーがデバイスで Android Ready SE を使うには、以下の作業が必要です。
Google はエコシステムと連携し、以下のアプレットと、対応する Android 機能のリリースを優先して作業を進めています。
いくつかの Android OEM パートナーは、すでにデバイスで Android Ready SE を採用しています。OEM パートナーと連携して、このような次世代の機能をユーザーに提供できることを楽しみにしています。
詳しくは、Android セキュリティとプライバシーのデベロッパー サイトをご覧ください。
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 API はシンプルで、Promise を返すメソッドが 1 つあるだけです。この Promise は、コホートの id と version を表すオブジェクトに解決されます。
id
version
document.interestCohort()
利用できるようになったコホートのデータは、次のように見えます。
{ "id": "14159", "version": "chrome.1.0" }
FLoC API は Chrome 89 以降で利用できますが、オリジン トライアルに参加していない場合は、フラグを設定してコマンドラインから Chrome を実行する必要があります。さまざまなオペレーティング システムで実行する方法は、フラグ付きで Chromium を実行するで説明されています。
次のフラグを使って Chrome を起動します。
--enable-blink-features=InterestCohortAPI --enable-features="FederatedLearningOfCohorts:update_interval/10s/minimum_history_domain_size_required/1,FlocIdSortingLshBasedComputation,InterestCohortFeaturePolicy"
サードパーティ Cookie がブロックされていないこと、広告ブロッカーが実行されていないことを確認します。
floc.glitch.me のデモを確認します。
FLoC API の説明でユースケースが提示されていますが、API の使用方法は定義されていません。FLoC を使って関連するコンテンツや広告を提供する場合、サイトやサービスによって制約や要件が異なります。
独自の技術によってお勧めコンテンツ、広告、マーケティングのサービスを提供している場合は、FLoC の知見を適用することで、特定のコホートに対して最適なコンテンツやマーケティング メッセージを提供できます。これらのサービスを提供するサードパーティ企業を利用している場合は、その企業がオリジン トライアルに参加し、皆さんのサイトや他のサイトを含めた実験をする方がよいかもしれません。
たとえば、関連コンテンツを選択する方法を探しているパブリッシャーがオリジン トライアルの期間中に FLoC を試すプロセスは、次のようになります。
サイトで宣言をすると、コホートを計算するためのユーザーのサイト一覧からそのサイトが除外されるようにする必要があります。新しい interest-cohort パーミッション ポリシーによって、これが可能になります。このポリシーは、デフォルトで allow となる予定です。
interest-cohort
allow
interest-cohort パーミッションが許可されていないフレームでは、document.interestCohort() を呼び出したときに返される Promise はリジェクトされます。メインのフレームに interest-cohort パーミッションがない場合、そのページへのアクセスは興味コホートの計算には使われません。
たとえば、次の HTTP レスポンス ヘッダーを送ると、すべての FLoC コホート計算をオプトアウトできます。
Permissions-Policy: interest-cohort=()
FLoC のオリジン トライアルの期間中、オプトアウトしていないウェブサイトは、そのサイトが広告関連のリソースを読み込んだことが Chrome によって検知されると、FLoC の計算に含まれます。
Chrome で広告検出メカニズムが動作する仕組みについては、Chromium での広告タグ付けで説明されています。
FLoC は、プライバシーを保護しつつ、興味ベースで広告を選択するメカニズムです。
ユーザーがウェブを動き回ると、ブラウザは FLoC アルゴリズムを使って、直近の閲覧履歴が似ているたくさんのブラウザで共通する「興味コホート」を割り出します。コホートはユーザーのデバイスで定期的に再計算されますが、個々の閲覧データがブラウザ ベンダーなどの他者と共有されることはありません。
FLoC は現在 Chrome オリジントライアルの最中です。詳しくは FLoC のオリジン トライアルに参加する方法をご覧ください。
現在の FLoC オリジントライアルでは、以下のいずれかの要因によりブラウザの FLoC 計算に取り込まれます:
他のクラスタリングアルゴリズムでは、今回のトライアルでは異なる取り込み基準で実験を行う可能性があります。これはオリジントライアルの実験手順の一部です。
広告主（お金を払って広告を出稿するサイト）は、自分のウェブサイトにコードを含めてコホートデータを収集し、アドテック プラットフォーム（広告を配信するソフトウェアやツールを提供する企業）に提供できます。たとえば、アドテック プラットフォームは、オンラインの靴店から、コホート 1101 と 1354 のブラウザはこの店のハイキング グッズに興味があるかもしれないことを把握できます。その他の広告主から、アドテック プラットフォームは各コホートのその他の興味を知ることができます。
次に、広告プラットフォームはこのデータを使って、これらのコホートのいずれかに属するブラウザが広告掲載サイト（ニュースサイトなど）のページをリクエストしたときに、関連性が高い広告（先ほどの靴店のハイキング シューズなど）を選択できます。
Privacy Sandbox は、サードパーティ Cookie などのトラッキング メカニズムを使わずにサードパーティ ユースケースを満たすための一連の提案です。各提案の概要については、Privacy Sandbox の詳細をご覧ください。
この提案について、皆さんからのフィードバックが必要です。コメントがある方は、FLoC Explainer リポジトリで Issue を作成してください。この提案に関連する Chrome の試験運用についてフィードバックがある方は、試験運用の目的に返信する形で投稿してください。
多くの企業は、サイトのトラフィックを増加するために広告を利用しています。そして多くのパブリッシャーのウェブサイトは、広告のインベントリを販売することで、コンテンツの資金を得ています。ユーザーは通常、関連性が高く有用な広告を見ることを好みます。また、広告の関連性が高いほど、広告主に多くのビジネスを、広告をホストしているウェブサイトに多くの収益をもたらします。言い換えれば、関連性の高い広告を表示すれば、広告スペースの価値が上がります。したがって、関連性の高い広告を選ぶことで、広告がサポートするウェブサイトの収益が上がります。つまり、関連性の高い広告は、ユーザーにメリットをもたらすコンテンツを制作するための資金源になります。
しかし、多くのユーザーは、関連性の高い広告が示唆するプライバシーの問題を心配しています。現在、このような広告は、Cookie によるトラッキングやデバイスのフィンガープリンティングなどの技術を利用しています。これらは、個人の閲覧動作を追跡するために使われる技術です。FLoC の提案は、プライバシーを侵害せずに広告選択の効率を高めることを目指しています。
下の例は、FLoC を使って広告を選択するうえでのそれぞれの役割について説明しています。
この例の広告主（お金を払って広告を出稿する企業）は、次のオンライン靴店です。shoestore.example
この例のパブリッシャー（広告スペースを販売するサイト）は、次のニュースサイトです。dailynews.example
アドテック プラットフォーム（広告を配信するソフトウェアやツールを提供する企業）は、次のサイトです。adnetwork.example
この例では、ユーザーを Yoshi と Alex と呼びます。最初の状態では、どちらのブラウザも同じコホート 1354 に属しています。
ここではユーザーを Yoshi と Alex と呼んでいますが、これは例示のみの目的です。FLoC では、広告主、パブリッシャー、アドテック プラットフォームに名前や個々の ID が明かされることはありません。
コホートをユーザーの集合と考えないでください。そうではなく、コホートは閲覧アクティビティをグループ化したものと考えてください。
次は Alex です。
現在の広告選択には、Cookie によるトラッキングやデバイスのフィンガープリンティングなどの技術が利用されています。これらは、広告主などのサードパーティが個人の閲覧行動を追跡するために使われる技術です。
FLoC では、ブラウザは FLoC サービスにも他の誰にも閲覧履歴を送信しません。ブラウザは、ユーザーのデバイス上でブラウザ自身が属するコホートを割り出します。ユーザーの閲覧履歴がデバイスを離れることは一切ありません。
各ブラウザ ベンダーは、それぞれにどのようにコホートを作り出すのかを選択する必要があります。Chrome は独自の FLoC サービスを運用していますが、他のブラウザは異なるクラスタリングアプローチを採った FLoC を実装し、独自のサービスを運用する可能性があります。
このプロセスのどの時点においても、ユーザーの閲覧履歴が FLoC サービスやサードパーティに送信されることはありません。ブラウザのコホートは、ユーザーのデバイス上でブラウザ自身が計算します。FLoC サービスは、ユーザーデータを取得することも、保管することもありません。
はい、ブラウザのコホートはもちろん変わることがあります。毎週同じウェブサイトにアクセスすることはないでしょう。ブラウザのコホートはそれを反映します。
コホートは、ユーザーの集まりではなく、閲覧アクティビティのクラスタを表します。通常、コホートの行動の特徴は時間が経っても一貫性があり、コホートは最近の閲覧行動が似ているグループなので、広告の選択に役立ちます。それぞれのユーザーのブラウザは、閲覧行動の変化とともにコホートを出入りします。まずは、7 日ごとにブラウザがコホートを再計算することを想定しています。
上の例では、Yoshi と Alex のブラウザのコホートはどちらも 1354 でした。将来的に興味が変われば、Yoshi のブラウザと Alex のブラウザが別のコホートに移動する可能性があります。下の例では、Yoshi のブラウザはコホート 1101 に移動し、Alex のブラウザはコホート 1378 に移動します。他のユーザーのブラウザも、閲覧の興味が変わるにつれてコホートを出入りします。
コホートは、ユーザーのグループではなく、閲覧アクティビティのグループを定義します。行動が変わるにつれて、ブラウザはコホートを出入りします。
前述のように、ユーザーのブラウザはコホートの数学モデルの詳細データを FLoC サービスから取得します。これは、すべてのユーザーの閲覧アクティビティを表す多次元空間です。その後、ブラウザはあるアルゴリズムを使い、この「コホート空間」のどの領域（すなわち、どのコホート）が最近の自身の閲覧行動に最も近いかを割り出します。
各コホートには、たくさんのブラウザが存在することになります。
コホートのサイズが小さい場合、広告のパーソナライズには役立つかもしれませんが、ユーザーのトラッキングをやめることにはなりません。逆もまた同様です。ブラウザをコホートに割り当てるメカニズムには、プライバシーと有用性との間でトレードオフが必要になります。Privacy Sandbox は、ユーザーが「集団の中に隠れる」ことができるように、k-匿名性を利用します。コホートは、少なくとも k 人のユーザーによって共有されれば、k-匿名性があります。k の数が大きくなるほど、コホートのプライバシーは高くなります。
FLoC のコホートモデルを作成するために使うクラスタリング アルゴリズムは、なぜ分類がプライベートなのかは知ることなく、コホートにプライベートな分類と相関関係があるかどうかを評価できるように設計されています。人種、性別、病歴など、プライベートな分類が明らかになる可能性があるコホートはブロックされます。言い換えれば、コホートを割り出すとき、ブラウザはプライベートな分類が明らかにならないようなコホートのみを選択します。
FLoC では、ユーザーのブラウザは他のたくさんのユーザーのブラウザとともに、たくさんのコホートのうちの 1 つに属します。サードパーティ Cookie やその他のターゲティング メカニズムとは異なり、FLoC はユーザーのブラウザが属するコホートしか明かさず、個々のユーザー ID が明らかになることはありません。そのため、他者がコホート内の個人を特定することはできません。さらに、ブラウザのコホートを割り出すために使われる閲覧アクティビティに関する情報は、ローカルのブラウザやデバイスに留まり続けて、他の場所にアップロードされることはありません。ブラウザは、差分プライバシーなどの他の手法を使ってさらに匿名化することもできます。
ウェブサイトは、FLoC をオプトインすることもオプトアウトすることもできます。そのため、プライベートなトピックを扱うサイトは、そのサイトへのアクセスを FLoC の計算に含めないようにすることもできます。さらなる保護として、FLoC サービスによる分析では、そのコホートがなぜプライベートであるかを知ることなく、コホートによってユーザーに関するプライベートな情報が明らかになる可能性があるかどうかを評価します。あるコホートで、サイトにアクセスしたユーザーのうちプライベートな分類に属するユーザーの数が典型的なユーザーの数を超えている可能性がある場合、そのコホート全体が削除されます。この分析で扱われるプライベートな分類には、負債状況やメンタルヘルスなどが含まれます。
ウェブサイトは Permissions-Policy ヘッダーに interest-cohort=() を設定すると、FLoC 計算からオプトアウトすることができます。オプトアウトしていないページでは、document.interestCohort() が使われていると、ブラウザの FLoC 計算に含まれることになります。FLoC のオリジントライアル期間中、広告や広告に関連するリソースを読み込むことが検知された場合も、ブラウザの FLoC 計算に含まれることになります（Chrome の広告検知メカニズムの仕組みは、Chromium での広告のタグ付けで説明しています）。イントラネットのサイトなど、プライベートな IP アドレスから提供されているページは、FLoC の計算対象に含まれません。
interest-cohort=()
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 を試す方法は、FLoC のオリジン トライアルに参加する方法で説明しています。
サイトで interest-cohort パーミッション ポリシーを使うと、コホートを計算するためのユーザーのサイト一覧から除外することを宣言できます。このポリシーは、デフォルトで allow となる予定です。interest-cohort パーミッションが許可されていないフレームでは、document.interestCohort() が返す Promise はリジェクトされます。メインのフレームに interest-cohort permission がない場合、そのページへのアクセスは興味コホートの計算には使われません。
interest-cohort permission
API に関するコメントがある方は、FLoC Explainer リポジトリで Issue を作成してください。
