摘要

  • W3C 隐私工作组于 2026 年 9 月 24 日发布《Global Privacy Control》工作草案；9 月 17 日已有上一版本，因此不能把本次刊发说成首次提出 GPC，更不能称其为正式推荐标准。
  • Sec-GPC: 1 与脚本可读的属性承载用户请求；网站可选的 /.well-known/gpc.json 则说明其一般支持态度，不回答某一次请求是否得到遵守。
  • 请求、声明与实际数据处理应保留各自的证据链。把公开声明当成个体请求的合规回执，会掩盖真正需要核实的数据去向。

一个人打开网页后才在浏览器中启用 GPC。此时屏幕上的设置已经改变，原有标签页向网站表达过的偏好却不会自动追溯修改。草案规定，用户代理在每次顶层导航时缓存偏好；加载过程中或之后变更设置，要等下次导航才体现。对于设置与旧标签页不一致的情形，浏览器应提示并提供重新加载选项。由此可见，核查信号不能只拍一张设置截图，还要知道页面何时加载。

GPC 想解决的是逐站表达拒绝出售或分享个人信息过于费力的问题。草案以 HTTP 标头和 DOM 属性传递请求：导航时缓存值为真，用户代理发送 Sec-GPC: 1；值为假则不发送这个标头。navigator.globalPrivacyControl 反映的也是那次导航的缓存状态。它们说明用户提出了什么要求，并不说明网站、服务商或其下游接收方后来做了什么。

网站另可在 /.well-known/gpc.json 发布支持资源。文件中的 gpc: true 表示服务器打算至少在法律要求范围内遵守 GPC，lastUpdate 则标出声明时间。规范特意划出边界：这份资源表达的是站点对 GPC 的认识和支持，不是对读取该文件的用户代理所发请求的逐次处理报告。文件是可选的；默认支持状况未知。没有文件，不能直接推断违规；有文件，也不能推断每条数据流均已按请求处理。

真正的责任问题发生在两者之后。站点是否把信号纳入适用的判断规则？相关数据是否仍流向第三方或跨场景定向广告用途？单凭浏览器标头和网站自述，外部观察者无法得到完整答案。草案没有制定普遍适用的审计回执，也没有测量现有网站的执行比例。本文建议保留“收到的信号—适用决策—后续处理路径”的有日期记录；这是编辑性的运营建议，并非 W3C 新增的强制字段。

还须防止扩大 GPC 的法律含义。草案指出，它并不代表删除请求，也不涵盖所有广告、同一场景内的数据利用或一切隐私权。法律效果取决于适用法、个人所在地及其他协议。工作草案仍可能修改，发布本身也不意味着 W3C 或其成员已正式背书。可扩展的偏好表达值得重视，但接收方的行为仍需单独举证。

来源