FLoCネットワークのオプトアウト

[RGJ (Richard - Communiteq)]

Google は、サードパーティのクッキーが廃止されつつあるため、Chrome ブラウザを使ってユーザーのプロファイリングを行う「FLoC」という技術を考案しました。

この技術は 強く批判されています であり、ウェブサイトやアプリケーションは Permissions-Policy: interest-cohort=() ヘッダーを送信することで、この機能からオプトアウトできます。

私たちは 2021 年において広告がウェブの重要な基盤の一つだと考えていますが、もちろんこれを大きなプライバシー問題と捉えるコミュニティも数多く存在します。

Discourse インストールからこの機能をオプトアウトする最も簡単な方法は、テーマコンポーネントの /head に meta タグを追加することです：編集：@supermathie 氏が指摘した通り、これで動作するかどうかは確信が持てません。

<meta http-equiv="Permissions-Policy" content="interest-cohort=()"/>

ただし、これはコア機能のチェックボックスで制御される「実質的な」HTTP ヘッダーとして実装される可能性もあります。

[Ed_S]

ありがとうございます。ご同意いただき、これは標準的な選択肢であるべきだと考えます。

ここでヘッダーを確認できますが、このサイトは現在、オプトアウトを送信していません：
https://securityheaders.com/?q=https%3A%2F%2Fmeta.discourse.org%2F\u0026followRedirects=on

[supermathie (Michael Brown)]

@RGJ

Discourse インストールからこの機能を無効にする最も簡単な方法は、meta タグを追加することです

これでは「機能しない」と言っている人しか見たことがありません。これは実際にはヘッダーである必要があると思います。

[riking (Kane York)]

ウェブサイト側とユーザー側の両方からのオプトアウトは、新しいウェブプラットフォーム機能を導入するための現実的な手法ではありません。

特に、ヘッダーはすべてのリクエストで送信する必要があり、メインのフォーラムドメインへのアクセスと同等とみなされるすべての固有のCDN URLにも対応する必要があります。

cdn.forum.example.com は、forum.example.com と全く同じ予測能力を持っています。

現時点での変更は、本質的に無作為な動機に基づいています。Google が研究の機会や方針変更の可視性をほとんど与えずに、ウェブ全体を混乱させている状況は、合理的な意思決定を促すものではありません。

[jtbayly]

その通りです。私も全く同感です。

しかし…

Google がそんなことをしているのに、私たちが何もせずただ見ているだけなのでしょうか？Google は、私たちが好むかどうかに関係なく、実際にそのようなことをしています。それが良いことかどうかは別としてです。

[RGJ (Richard - Communiteq)]

FLoC の 議論（残念ながら、「どのように」するかという点に焦点が当たり、「するべきか」かという点がおろそかになっているようです）。

[RGJ (Richard - Communiteq)]

@supermathie

これは実際のヘッダーである必要があります。

ありがとうございます。調査を行いました：関連する議論はこちらで、重要な論点（私が強調）は以下の通りです。

これは行わない方が良いと思います。これではあらゆる種類の競合状態が発生し、HTTP レベルでのみ無効化できる機能も出てきてしまいます。CSP で生じた混乱を繰り返したくありません。すべてのホスティングプロバイダーが適切なヘッダー設定オプションを提供するよう促すべきです。

[TheDarkWizard]

FLoCはひどいものですが、WordPressでの提案も完璧ではないようです。多くのものがヘッダーを変更するため、それをすべてどのように考慮すればよいのでしょうか。

[neil (Neil Lalonde)]

現時点で信頼できる唯一の解決策は、Chrome 以外のブラウザを「任意に」使用することです。Google にクロールや追跡をしないよう指示するディレクティブを使用しても、Google が推奨する方法に従って設定しても、必ずしも尊重されるとは限らないという過去があります。

[Ed_S]

@RGJ

ありがとうございます。調査を行いました：関連する議論はこちら、重要な主張（強調は筆者）は以下の通りです。

これは行わない方が良いと思います。これではあらゆる種類の競合状態が発生し、HTTP レベルでのみ無効化できる機能も出てきてしまいます。CSP で生じた混乱を繰り返したくありません。すべてのホスティングプロバイダーに適切なヘッダー設定オプションを提供するよう促すべきです。

つまり、WordPress の世界では、ウェブマスターはヘッダーの設定についてホスティングプロバイダーとやり取りする必要があります。（編集：おっと、以下の訂正をご覧ください。）

しかし、Discourse の世界では、当社のサイトの Web プレゼンス全体（ヘッダーを含む）を設定する Docker イメージを持っています。

私は危険なほどに知識が浅いだけですが、ヘッダー設定が以下の場所にあるのを目にしました。
/var/discourse/shared/standalone/letsencrypt/http.header
/var/discourse/templates/web.ssl.template.yml
そのため、ウェブマスターのポリシーに従って適切なヘッダーを設定することは、Discourse の範囲内だと感じられます。

一部の Discourse 管理者は何もしないことを望むかもしれませんし、様子を見ることを望むかもしれません。また、コミュニティを代表して FLoC トラッキングを無効化し、Google へのシグナルとして機能させたいと考える管理者もいるでしょう。

私は無効化を希望します。

[supermathie (Michael Brown)]

Add a custom HTTP header to requests made to your Discourse ^[1] を参考に、このヘッダーを追加する変更をテストしています。動作が確認でき次第、お知らせします。

個人的には、FLOC ヘッダーが含まれるリクエストを 完全に拒否 して Chrome を機能不全に陥らせる という提案が大好きです。でも、それを提唱していた記事が見つからないんですよね…

---

1. GNU テリー・プラチェット、その名を呼べ ↩︎

[RGJ (Richard - Communiteq)]

@Ed_S

つまり、WordPressの世界では、ウェブマスターはヘッダーの設定についてホスティングプロバイダーに対応する必要があります。

いいえ、その引用はPermissions-Policyヘッダーに関する一般的な議論からのものです。WordPressの世界では、このヘッダーを追加するプラグインが存在します。

[Ed_S]

@RGJ

WordPressの世界では、ヘッダーを追加するプラグインがあります。

ありがとうございます。私の認識が間違っていました。

[supermathie (Michael Brown)]

これで大丈夫でしょう：

## ビルド後に実行するカスタムコマンド
run:
  - exec: echo "カスタムコマンドの開始"
  - replace:
     filename: "/etc/nginx/conf.d/discourse.conf"
     from: /location \\/ {/
     to: |
       location / {
           add_header X-Clacks-Overhead "GNU Terry Pratchett";
           add_header Permissions-Policy "interest-cohort=()";

Add a custom HTTP header to requests made to your Discourse を参考に変更

余談ですが、今日はとても話題にふさわしいですね：Terry Pratchett’s debut turns 50: ‘At 17 he showed promise of a brilliant mind’ | Books | The Guardian

結果は以下の通りです：

○ → curl -I https://testmachine/srv/status
HTTP/2 200 
server: nginx
date: Tue, 20 Apr 2021 17:48:15 GMT
content-type: text/plain; charset=utf-8
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
x-download-options: noopen
x-permitted-cross-domain-policies: none
referrer-policy: strict-origin-when-cross-origin
x-request-id: ef02ce7c-fabc-49b9-986e-c2c46e50f8e4
x-runtime: 0.004575
x-redis-calls: 1
x-redis-time: 0.000153
x-queue-time: 0.000952
x-clacks-overhead: GNU Terry Pratchett
permissions-policy: interest-cohort=()

[riking (Kane York)]

lobste.rs からの更新：ベータ版が完了したら、計算にサイトを含めることをオプトアウトすることはできなくなります。

GitHub - WICG/floc: This proposal has been replaced by the Topics API.

非シークレットモードでユーザーが訪問する、パブリックにルーティング可能な IP アドレスを持つすべてのサイトが、POC コホート計算に含まれます。

この「オプトアウト」は、トライアル期間が終了するとすぐに機能しなくなり、現在では広告を提供している場合のみ機能します。

Opting your Website out of Google's FLoC Network

[jtbayly]

つまり、このことに時間を費やすのはやめましょう。

[awesomerobot (Kris)]

個人として（現時点では）オプトアウトを選択することも可能です。

Chrome 90（4 月 13 日火曜日の安定版リリース）より、ユーザーは chrome://settings/privacySandbox から FLoC およびその他の Privacy Sandbox 提案をオプトアウトできます（現在は floc.glitch.me のデモで Canary 版にて試すことができます）。

出典: https://discourse.wicg.io/t/proposal-federated-learning-of-cohorts-floc/4473/26

[RGJ (Richard - Communiteq)]

@riking

ベータ版が終了すれば、サイトの計算への参加をオプトアウトすることはできません。

これについても理解するのに少し時間がかかりましたが、今では理解したと思います（もし間違っていたら訂正してください）。混乱のポイントは「計算」についてです。

ここには2 種類の計算があり、FLoC に「参加」する方法は 3 つあります。

1. （グローバルな）コホートを決定する「グローバル」アルゴリズム。オプトアウトは不可能です。実際「プライベートモードではない状態でユーザーがアクセスする、パブリックにルーティング可能な IP アドレスを持つすべてのサイトは、POC コホート計算に含まれます。」

2. ユーザーの閲覧履歴に基づいて、特定のユーザーのコホートを決定するアルゴリズム。ヘッダーによるオプトアウトが可能。サイトは、コホート計算におけるユーザーのサイトリストへの参加を望まないことを宣言できるはずです。これは新しい interest-cohort Permissions Policy を通じて実現できます。（引用元と同じドキュメント から 抜粋）

3. JavaScript を使用して、ターゲティング広告を取得する（またはその情報を悪用する）ために、サイトがユーザー固有のコホートを要求すること。その値は、新しい JavaScript API である cohort = await document.interestCohort(); を通じてウェブサイトに提供されます。
   この API は、#2 のヘッダーでオプトアウトされたページでは機能しません。ここが多くの混乱の原因となっています。interest-cohort の許可が与えられていないフレームは、document.interestCohort() を呼び出したときにデフォルト値を返します。

@riking

この「オプトアウト」は、トライアル期間が終了するとすぐに機能しなくなり、現在では広告を提供している場合のみ機能します。

これについての信頼できる情報源が見つかりません。

[riking (Kane York)]

@RGJ

これについての良い情報源が見つかりません。

ああ、あなたのリストの#2 と#3 を混同していましたね。

その場合、ヘッダーには価値がありますが、それでもヘッダーはこれを提供するには悪く、エラーが発生しやすい方法です。