谷歌发明了一项名为 FLoC 的技术，该技术利用 Chrome 浏览器对用户进行画像，因为第三方 Cookie 似乎正在被淘汰。
这项技术 备受争议，网站或应用程序可以通过发送 Permissions-Policy: interest-cohort=() 响应头来选择不参与。
我们认为广告是 2021 年网络的重要基石，但当然也有许多社区将其视为重大的隐私问题。
让 Discourse 安装快速选择不参与的最快方法是在主题组件的 /head 部分添加一个 meta 标签：编辑：正如 @supermathie 指出的，不确定这种方法是否有效。
<meta http-equiv="Permissions-Policy" content="interest-cohort=()"/>
不过，这或许可以作为一个“真正的”HTTP 响应头，通过核心设置中的复选框来控制。
谢谢，我同意，这应该是一个标准选项。
你可以在这里检查你的标头，而该网站目前并未发送 opting-out 信号：
https://securityheaders.com/?q=https%3A%2F%2Fmeta.discourse.org%2F\u0026followRedirects=on
我只看到有人说这不会起作用，我认为这必须是一个实际的 HTTP 头。
在网站端和用户端同时提供退出选项，对于引入新的 Web 平台功能而言并非可行方案。
特别是，该标头必须在每次请求中发送，并且您还需要考虑每个等同于访问您主论坛域名的唯一 CDN URL。
cdn.forum.example.com 的预测能力与 forum.example.com 完全相同。
在此阶段进行的任何更改本质上都是随意驱动的。Google 迫使整个 Web 仓促应对，几乎没有机会研究该机制或洞察政策变化，这不利于做出理性决策。
确实如此，我完全赞同。
然而……
难道我们就只能袖手旁观，任由谷歌如此行事吗？因为无论我们是否喜欢，无论这样做是好是坏，谷歌确实在这么做。
WordPress 项目中的 FLoC 讨论（不幸的是，讨论似乎更多地围绕“如何”实施，而非“是否”应该实施）。
谢谢，我进行了一些搜索：相关讨论 在此，以及重要论点（重点为我所加）
我更倾向于不这样做。这会导致各种竞态条件，而且你还会得到一些只能在 HTTP 层面禁用的功能。我不希望重蹈 CSP 所引发的混乱。我们只需鼓励所有托管提供商提供充分的头配置选项即可。
虽然 FLoC 很糟糕，但 WordPress 上的建议似乎也不完美，因为许多插件和配置都会修改 HTTP 头，你如何全面应对这些情况？
目前唯一可靠的解决方案是使用除 Chrome 之外的任何浏览器。通过指令“请求”Google 不抓取或追踪，历史上存在即使按照 Google 建议的方式操作，也未能始终得到遵守的情况。
因此，在 WordPress 的世界里，网站管理员必须就其 HTTP 头部配置问题与其托管服务提供商打交道。（编辑：哎呀，见下文更正。）
但在 Discourse 的世界里，我们拥有一个 Docker 镜像，它配置了我们网站在线存在的所有方面，包括 HTTP 头部。
我只懂得一点皮毛，但这足以惹麻烦。我注意到在以下位置有头部设置：
/var/discourse/shared/standalone/letsencrypt/http.header
/var/discourse/templates/web.ssl.template.yml
因此，在我看来，根据网站管理员的政策，Discourse 设置适当的头部配置是在其职责范围内的。
一些 Discourse 管理员可能不在乎做任何事情，一些人可能想观望一下，而另一些人则可能希望代表其社区退出 FLoC 跟踪，以此向 Google 发出信号。
我希望退出。
我正在测试一项基于 Add a custom HTTP header to requests made to your Discourse [1] 的更改，以添加此标头。一旦我验证其有效，我会告知您。
就我个人而言，我赞同有人提出的建议，即直接拒绝发送了 FLOC 标头的请求，从而让 Chrome 失效。但我找不到那篇倡导该做法的文章了…… 
谨以此纪念特里·普拉切特，请呼唤他的名字 ↩︎
不——那段引文是关于 Permissions-Policy 头部设置的通用讨论。在 WordPress 的世界里，有一个 插件 可以添加该头部设置。
谢谢——我收回之前的说法。
这应该能帮到你：
## 构建后运行的任何自定义命令
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=()
来自 lobste.rs 的更新：一旦测试版完成，将不再有选项可以排除您的网站参与计算。
所有在用户非隐身模式下访问的、具有可公开路由 IP 地址的网站，都将被纳入 POC 群组计算。
一旦试验阶段结束，此“退出”机制将停止生效；而目前，它仅在您投放广告时才起作用。
换句话说，别再浪费时间琢磨这件事了。
您（目前）可以以个人身份选择退出。
从 Chrome 90（将于 4 月 13 日星期二发布的稳定版）开始，用户可以通过 chrome://settings/privacySandbox 选择退出 FLoC 及其他隐私沙盒提案。（您现在即可在 Canary 版本中通过 floc.glitch.me 演示进行尝试。）
来源：https://discourse.wicg.io/t/proposal-federated-learning-of-cohorts-floc/4473/26
这也花了我一些时间才理解，我想我现在明白了（但如果我理解有误，请指正）。困惑点在于“计算”具体指什么。
这里实际上有两种计算，而网站参与 FLoC 的方式有三种：
确定**全局群组（cohorts）**的“全局”算法。无法选择退出。确实如此：所有用户在不使用无痕模式时访问的、拥有可公开路由 IP 地址的网站，都会被纳入 POC 群组计算中。
基于用户浏览习惯确定特定用户所属群组的算法。可通过 HTTP 头选择退出。网站应能声明不希望被纳入用户用于群组计算的网站列表中。这可以通过新的 interest-cohort 权限策略来实现。（引自同一文档，即你引用的来源）
cohort = await document.interestCohort();。interest-cohort 权限的框架，在调用 document.interestCohort() 时将返回默认值。我找不到关于这一点的可靠来源。
啊——我把你列表中的第 2 点和第 3 点搞混了。
如果是这样，那么标头确实有其价值，不过再次强调，使用标头来传递此类信息是一种糟糕且容易出错的方法。