以下は、ChromiumのサイトからFLoCについてのページを飜訳しました。

FLoC Origin トライアル＆クラスタリング

FLoCは現在、ChromeのOriginトライアルとして提供されています。 この実験的な新しい広告関連のブラウザAPIの背景にあるアイデアについては、web.dev/flocを参照してください。このAPIは、ユーザー追跡なしでウェブ広告をサポートするChromeのプライバシー サンドボックスの取り組みの一環です。 開発プロセスへの参加は、FLoCのGitHubリポジトリをご覧ください。

Origin TrialsやサードパーティのOrigin Trialsに慣れている開発者にとっても、FLoC OTはちょっとした違いがあります。 それは、FLoCが、インタレストベースの広告のターゲティングに役立つと期待されるシグナルを提供するJavaScript APIと、そのシグナルを生成するオンデバイスのクラスタリングアルゴリズムという2つの異なるものだからです。

クラスタリングを行うための適切な方法を見つけ出すことは、まだ未解決の問題です。 Originのトライアル期間中、私たちは複数の可能なクラスタリングアルゴリズムを紹介し、生成されたクラスタのプライバシーと実用性の両方に関するフィードバックを求めています。 Origin Trialの期間中に、アドテクノロジーのコミュニティが、FLoCのアプローチがどのようなタスクに適しているかをまとめて把握してくれることを期待しています。 その結果、FLoCがより優れていると思われる分野が見つかり、クラスタリングにどのような変更を加えれば、それらの用途に役立つかについて、一般の方々と議論できることを楽しみにしています。

複数のクラスタリング アルゴリズムがFLoCの割り当てを行っている場合、どのアルゴリズムが割り当てられているのかをどうやって知ることができるのか、という疑問があるかもしれません。 API のドラフト仕様によると、cohort = await document.interestCohort(); で返されるオブジェクトは、ブラウザがどのクラスタに属しているかを示す id と、その id を算出するために使用されたアルゴリズムを示すラベルである version の 2 つのキーを持っています。 (このAPIは、安全でない状況、Permissions-Policyによってブロックされている状況、Chromeの設定でCookieをブロックしているサイトでは許可されません)

このように、一つのAPIが複数の異なるアルゴリズムに囲まれているという奇妙な状況は、FLoCのOrigin Trialが気の弱い人には向いていないことを意味しています。 それでも、この初期の実験段階に参加したいという方は、このページで参加方法を確認してください。

FLoCアルゴリズムのバージョン

バージョン “chrome.2.1”
このアルゴリズムはChrome 89で導入されました。 これは、2020年10月にGoogle Research and Adsの同僚によって説明されたSortingLSHと呼ばれるアプローチに似ており、彼らの実験によると、いくつかのタイプの広告ターゲティングではかなり良いパフォーマンスを発揮するとのことです。”Affinity Audiences”（”Cooking Enthusiasts “など）や “In-Market Audiences”（”Consumer Electronicsを積極的に調べている人 “など）です。

このクラスタリング手法では、同じWebサイトを閲覧している人は、同じコーホートに入る可能性が高いとされています。 サイトのドメインのみが使用され、URLやページの内容などは使用されません。

ブラウザインスタンスのコーホート計算は、以下の入力に基づいています。

・コホート計算までの 7 日間にブラウザの Chrome 履歴に登録された登録可能なドメイン名（eTLD+1）のサブセット。

・ドメイン名が含まれるのは、そのドメイン上のページが以下のいずれかの場合です。

・document.interestCohort() API を使用している、または

・広告関連のリソースを読み込んでいることが検出された場合（Chromium の Ad Tagging を参照）。

・HTTP レスポンスヘッダ Permissions-Policy: interest-cohort=() で提供されているページでは、API は無効で、ドメイン名は無視されます。

・公開されていないルーティング可能なIPアドレスのドメイン名は決して含まれません。

入力された情報は、PrefixLSHと呼ばれる技術を用いて、コホートIDに変換されます。 これは、昨年10月にGoogle ResearchとGoogle Adsの同僚が説明したSortingLSHと呼ばれるSimHashの亜種に似ています。

・このブラウザは、入力に含まれる各ドメイン名を使用して、ガウス分布から擬似乱数を抽出した座標を持つ50次元の浮動小数点ベクトルを決定論的に生成します。 疑似乱数生成器はドメイン名のハッシュをシードとしたガウス分布から疑似乱数を抽出したものです（注：ここで説明する50次元ベクトルは、最終的に最初の20個の座標のみが使用されます。

・ブラウザは、ドメイン名の全入力を使用して、50 ビットの Locality-Sensitive Hash ビットベクトルを決定論的に生成します。

・Chrome-operated server-side pipelineは、対象となるユーザー（同期データとともにコホート計算を記録したユーザー）の間で、各50ビットのハッシュが何回発生したかをカウントします。

・50ビットのハッシュは、最初のビットが0であるすべてのハッシュと、最初のビットが1であるすべてのハッシュという、2つの大きなコホートから始まります。そして、各コホートは、ハッシュ値の連続するビットを見て、少なくとも2000人の対象ユーザーを持つ2つのコホートになるまで、繰り返し2つの小さなコホートに分割されます。 各コホートには、コホートデータが同期されていないChromeユーザーを含めると、合計で数千人が含まれます）。

・結果として、Locality-Sensitive Hash のビットベクトル接頭辞で表現されたコホートのリストが得られます。これを辞書順に番号付けして、すべての Chrome ブラウザに配布します。 どのブラウザでも、独自の50ビットハッシュを計算し、コホートのリストに表示されているベクターの固有のプレフィックスを見つけ、対応するコホートIDを読み取ることができます。

・なお、この手法は教師なしのクラスタリングであり、（名前に「FL」が付いていますが）Federated Learningは使われていません。 クラスタリングモデルのパラメータは、疑似乱数生成の詳細と、最小クラスタサイズの閾値のみです。

Locality-Sensitive Hash のビットベクターの接頭辞に基づいてコホートのリストを作成した後、追加のフィルタリング基準を課します。 ブラウザインスタンスのコホートがフィルタリングされると、document.interestCohort()によって返されるプロミスは、拒否の理由を示すことなく拒否します。

・フィルタリングの一部はサーバー側のパイプラインで計算され、その結果は、すべての Chrome インスタンスに配布されるコホート プレフィックスのリストに含まれます。

・対象となるユーザー数が少なすぎる場合、そのコホートはフィルタリングされます。 サーバー側のクラスタリング パイプラインではサイズの小さいコホートは生成されないため、最初からこのようなことはありませんが、ユーザーの閲覧行動が時間とともに変化すると、このようなことが起こる可能性があります。 コホートのサイズが変わっても、LSH接頭辞のリストを再計算することで対処することはしない。これは、既存のコホートIDの意味が変わってしまうからである)。

・あるコホートは，対象となるユーザーの閲覧行動が，センシティブなトピックに関するウェブページへの訪問率が通常よりも高い場合にフィルタリングされます． t-closenessの計算方法については、こちらの論文を参照してください。

・その他のフィルタリングは、個々のブラウザインスタンスで行われます。

・個々のブラウザインスタンスのコホートは、コホートID計算の入力が7つ以下のドメイン名の場合にフィルタリングされます。

・個々のブラウザインスタンスのコホートは、ユーザーが閲覧履歴データやその他のサイトデータを消去した時点でフィルタリングされ、消去された履歴を除いた新しいコホートIDが最終的に再計算されます。

・個々のブラウザインスタンスのコホートは、シークレット（プライベートブラウジング）モードでフィルタリングされます。

すべての詳細は、このバージョンのFLoCクラスタリングに特有のものであり、将来のクラスタリング・アルゴリズムでは変更される可能性があります。

このクラスタリング アルゴリズムによって作成されたコホートの統計情報（対象となる Chrome ユーザーのデータに基づく）。

フィルターをかける前のコホートの数 33,872

コホートの定義に使用したLSHビットの数：13～20個

1 つのコホート内の対象となる Chrome ユーザーの最小数：2000 人

対象となる Chrome ユーザーの閲覧履歴（訪問したドメインのセット）の数が 1 つのコホート内で最も少ない場合：735 個

センシティブブラウジングによるフィルタリングを行ったコホートの数 t-closeness test (t=0.1): 792 (約 2.3%)

出典：https://www.chromium.org/Home/chromium-privacy/privacy-sandbox/floc

付記：下訳にhttps://www.deepl.com/translatorを用いました。