全球隐私控制(GPC)

W3C 工作草案

关于此文档的更多详细信息
本版本:
https://www.w3.org/TR/2026/WD-gpc-20260924/
最新发布的版本:
https://www.w3.org/TR/gpc/
最新编辑草稿:
https://w3c.github.io/gpc/
历史:
https://www.w3.org/standards/history/gpc/
提交历史
编辑:
Sebastian Zimmeck (Wesleyan University)
Peter Snyder (Brave Software)
Justin Brookman (Consumer Reports)
Aram Zucker-Scharff (The Washington Post)
前任编辑:
Robin Berjon (Supramundane Agency) (The New York Times until Sep 2022)
Ashkan Soltani (Independent)
David Harbage (DuckDuckGo)
反馈:
GitHub w3c/gpc (拉取请求, 新建问题, 打开的问题)

摘要

本文档定义了一种通过 HTTP 和 DOM 传递的信号,用于传达个人请求网站和服务不要将其个人信息出售或分享给第三方的意愿。本标准旨在配合现有及即将实施的法律框架,使此类请求具有可执行性。

本文档状态

本节描述了本文档在发布时的状态。当前 W3C 出版物列表以及本技术报告的最新修订版可在 W3C 标准与草案索引中找到。

本文档由隐私工作组 以建议流程的工作草案形式发布。

作为工作草案发布,并不代表 W3C 及其成员的认可。

本文档为草案,可能随时被更新、替换或废弃。将本文档作为正式引用是不合适的,仅可视为工作进展。

本文档由遵守 W3C 专利政策 的小组制定。 W3C 维护着 与小组交付物相关的专利公开公示列表; 该页面还包含专利公开的说明。若个人实际知晓某项专利并认为其包含 必要声明 ,则须根据 W3C 专利政策第6节 披露相关信息。

本文档受 2025年8月18日 W3C 流程文档管理。

1. 简介

本节为非规范性内容。

如今构建网站通常需要依赖由用户选择与之交互的企业之外的其他企业所提供的服务。这一结果是 Web 技术日益复杂以及不同服务之间分工的结果。虽然这种架构可以用于提供更好的 Web 体验, 但它也可能被滥用,从而侵犯隐私([privacy-principles])。虽然数据可以出于有限的运营目的与服务 提供商共享,但也可能以许多用户认为不可接受的方式被共享或用于 行为定向。

世界各地的司法辖区已经提出或制定了若干不同的法律框架来解决这一问题。一些模式依赖用户同意进行跟踪。另一些 基于数据最小化原则的模式则直接完全禁止某些数据共享或 数据处理。

一些法律和提案赋予用户请求保护其隐私的权利,包括“选择 退出”请求,即要求其数据不得出售或共享给 用户打算与之交互的企业以外的主体。然而,要求人们针对其访问的每一个网站手动表达自己的 权利是不切实际的,同时也是将“隐私劳动”强加给 人们 ([privacy-principles])。

本规范针对上述最后一类法律而设计,并通过提供一种方式,使个人能够通过 HTTP 标头 或 DOM 向所有网站发布者普遍发送信号,表明其主张适用的权利,以阻止其数据被出售、 其数据与第三方共享,以及其数据被用于跨上下文定向 广告,从而解决用户选择难以规模化的问题。该信号允许用户利用其中一些基于全局 选择退出 的法律中的特定条款,例如《加利福尼亚消费者隐私法》中与“选择退出偏好 信号”相关的条款,用于阻止个人信息的出售或共享, [CCPA-REGULATIONS],或科罗拉多州 及其他州法律中针对“通用选择退出 机制”的类似条款,使用户能够选择退出其信息的出售或其信息被用于 跨组织定向广告。

然而,虽然全局隐私控制旨在允许用户表达选择退出 共享和跨上下文定向广告的偏好,但该控制并非用于行使所有可能的 隐私权,甚至也不是用于行使所有退出广告或广告定向的权利。例如,GPC 并非用于 行使删除权。GPC 也并非用于处理同一上下文内的数据收集或广告定向。 有关更多详细信息,请参阅 法律和实现考虑 指南。

本规范不应被解释为对基于选择退出的监管模式 ——或更广泛意义上的跨上下文跟踪——的认可,也不应被解释为对其他基于 同意或数据最小化模式的否定。相反,它旨在使用户能够行使某些司法辖区 赋予他们的积极权利。

2. 定义

不出售或共享交互是指与 网站之间的一种交互,其中 个人请求其数据不得出售给或共享给其打算与之交互的主体以外的任何主体, 或请求其数据不得用于跨上下文广告定向。 就 W3C 的 隐私 原则而言,该个人至少 请求只存在一个数据控制者, 并且数据不得用于另一个 上下文中的广告定向,即使 该上下文由 同一企业所有。

不出售或共享偏好是指 个人 请求 其数据“不得被出售或共享”,例如通过其用户代理启用全局隐私控制 设置,或者使用默认采用此类设置的工具(这可能 是因为该设置符合该工具大多数用户最普遍的预期)。 设置后,此偏好表示该个人期望使用 不出售或共享交互来浏览 Web。

3. 表达“不 出售或 共享”偏好

3.1 表达格式

应当为所有 HTTP 请求(以 HTTP 标头形式)和所有网站(以 Web API 属性形式)传达全局隐私控制偏好。

如果设置,则此偏好根据上下文表示为单一值 1 或 等效地表示为 true。

在不存在监管、法律或其他要求的情况下,网站可以按照其认为最适合 给定个人的方式解释已表达的全局隐私控制偏好, 尤其是在考虑该个人的隐私预期、上下文以及 文化环境时。同样,网站可能会使用本协议范围之外的其他偏好信息, 例如特定于网站的个人偏好或 第三方 注册服务,以便在没有通过本协议明确表达偏好时, 为其行为提供依据或进行调整。

用户代理应尽可能准确地传达个人的偏好。用户 代理应当努力表示其认为最能代表 个人 对全局隐私控制值的偏好的内容。

3.2 偏好缓存

在每次顶层 导航时必须缓存该偏好, 以确保在传达个人要求其数据“不得被出售或共享”的请求时保持一致。这意味着,如果该偏好在 顶层导航期间或之后发生变化,则在下一次导航之前不会反映该变化。

顶层 浏览上下文具有一个名为 gpcAtNavigation 的布尔值。 其初始值为 false。

gpcAtNavigation 的值必须 反映 偏好, 即当顶层 浏览上下文的活动 文档开始 加载时该个人的偏好。 如果该个人的偏好已启用,则其值为 true;如果 该个人的偏好已禁用或尚未设置,则其值为 false。

如果偏好被更改为与某个 顶层 浏览上下文中缓存的 gpcAtNavigation 不一致,用户代理应当向用户告知所有 不一致的标签页 并提供 重新加载这些标签页的选项,从而刷新缓存的 gpcAtNavigation 以反映当前偏好。

3.3 HTTP 请求的 Sec-GPC 标头字段

Sec-GPC 标头字段是一种机制,用于在 HTTP 请求 (针对任意请求方法)中表达个人针对不出售或共享交互的一般通用偏好。 在某些情况下,与该个人达成的特定安排可能允许 网站忽略普遍适用的偏好(请参见下文 § 5.3 以及 法律和实现 考虑指南)。

该字段的语法([ABNF])为:

Sec-GPC-field-name  = "Sec-GPC"
Sec-GPC-field-value = "1"

如果顶层 浏览上下文的 gpcAtNavigation 为 false,用户代理不得生成 Sec-GPC 标头字段。

如果顶层 浏览上下文的 gpcAtNavigation 为 true,用户代理必须生成一个 Sec-GPC 标头字段,其字段值 必须恰好为数字字符“1”。

用户代理在给定 HTTP 请求中不得生成多个 Sec-GPC, 并且不得在 HTTP 尾部字段中使用 Sec-GPC 字段。

处理包含 Sec-GPC 标头的 HTTP 请求的服务器必须 忽略该标头,并像未指定该标头一样处理请求,除非 字段值恰好为字符“1”。如果存在多个 Sec-GPC 标头,并且至少一个字段值恰好为“1”,则服务器必须 将 该 请求视为仅存在一个 Sec-GPC 标头且字段值为 “1”;否则视为不存在该标头。

HTTP 中间方不得移除设置为“1”的 Sec-GPC 标头,但它们 可以移除 包含其他值的 Sec-GPC 标头。此外,如果 HTTP 中间方有理由认为发起给定 HTTP 请求的个人具有不出售或共享偏好,则可以 插入一个 Sec-GPC 标头并将其设置为“1”。

3.3.1 Sec-GPC 字段值的可扩展性

Sec-GPC 被有意定义为不提供扩展机制。 使用以往类似标头的经验表明,人们在检测其是否存在时倾向于依赖字符串 相等性,而不是解析其值,尤其是在 尚不存在任何扩展的情况下。一旦存在 扩展内容,这类检查当然会失败,进而使该机制失去意义。如果 事实证明本标准有必要提供扩展,则需要通过其他 标头实现,而这些标头最终可能取代本标头。

3.4 用于 检测偏好的 JavaScript 属性

globalPrivacyControl 属性 使客户端 脚本能够确定加载顶层 浏览上下文的活动 文档时发送的 Sec-GPC 标头字段值。

WebIDLinterface mixin GlobalPrivacyControl {
  readonly attribute boolean globalPrivacyControl;
};
Navigator includes GlobalPrivacyControl;
WorkerNavigator includes GlobalPrivacyControl;

如果不会发送 Sec-GPC 标头字段,则该值为 false; 否则,该值为 true。

globalPrivacyControl 的值必须为 顶层 浏览上下文的 gpcAtNavigation。

globalPrivacyControl 属性 可在普通上下文和 worker 上下文中的 navigator 对象上使用,因此可以通过读取 navigator.globalPrivacyControl 来检查。

4. GPC 支持资源

源可以在 .well-known URL 处提供一个资源,用以表示其 遵守 GPC 请求这一事实,至少在被要求这样做的情况下如此。GPC 支持资源的目的 是让源表明其知晓并支持其所提供页面上的全局隐私控制。该 支持资源并非用于表示该源是否遵守访问该资源的用户代理发出的 GPC 请求。 默认情况下,源的支持状态为未知。

GPC 支持资源具有相对于源服务器 URL 的 well-known 标识符 /.well-known/gpc.json [RFC8615]。

收到以其 GPC 支持资源为目标的有效 GET 请求的源服务器 要么返回一个成功响应,其中包含机器可读的表示,说明 从该源提供的页面如何遵守 GPC, 要么返回一系列重定向,最终指向 这样的表示(该表示可以由另一个源上的服务器提供)。

4.1 GPC 支持表示

源服务器必须使用 application/json 媒体类型 [RFC8259] 将 GPC 支持资源作为有效表示返回, 否则 该源的支持状态为 未知。

GPC 支持表示必须是一个 JSON 对象,否则 该源的支持状态为未知。本规范未在下方列表中列出的该 JSON 对象成员不具有任何 含义,并且必须被忽略。成员包括:

6. 隐私考虑

暴露用户的偏好(通过 HTTP 标头字段或navigator 对象) 可能会以一种增加 可用于浏览器或设备指纹识别的信息的方式,将用户分成两个群体。除非该信号 与其他信号完全相关,或者在不可配置的设置中启用,否则这些附加信息 都是可用的。因此,根据具体实现,GPC 信号可能会带来 一定的隐私成本,不过这种成本旨在由发送该 信号所带来的隐私收益加以合理化。

7. 安全考虑

本规范中的功能不存在已知的安全影响。

8. 自动化

出于用户代理自动化和应用程序测试的目的,本文档定义了 以下扩展命令。[WebDriver]

8.1 设置全局隐私控制

HTTP 方法 URI 模板
POST /session/{session id}/privacy

设置全局隐私控制扩展命令修改当前会话的 不出售或共享偏好,并 返回 更新后的设置。

给定 session、URL variables 和 parameters,远端 步骤如下:

  1. 令 gpc 为 parameters 的属性 gpc。

  2. 如果 gpc 为 undefined 或不是布尔值,则返回错误,错误代码为 invalid argument。

  3. 为此 session 记录用户的偏好,使得 如果 gpc 为 true,浏览器将 执行 不出售或共享交互, 而如果 gpc 为 false,则不会执行不出售或共享交互。

  4. 令 result 为一个 JSON Object, 其 属性“gpc”设置为 gpc。

  5. 返回成功, 数据为 result。

8.2 获取全局隐私控制

HTTP 方法 URI 模板
GET /session/{session id}/privacy

获取全局隐私控制扩展命令返回当前会话的 不出售或共享偏好。

给定 session、URL variables 和 parameters,远端 步骤如下:

  1. 如果此 session 的用户偏好使浏览器将 执行不出售或共享交互, 则令 gpc 为 true。

  2. 否则,令 gpc 为 false。

  3. 令 result 为一个 JSON Object, 其 属性“gpc”设置为 gpc。

  4. 返回成功, 数据为 result。

9. 一致性

除标记为非规范性的章节之外,本规范中的所有创作指南、图表、示例和注释 均为非规范性内容。本规范中的其他所有内容均为规范性内容。

本文档中的关键字可以、必须、不得以及 应当 应按照 BCP 14 [RFC2119] [RFC8174] 中所述的方式解释,但仅限于这些关键字像此处所示那样全部以 大写形式出现时。

A. 实现考虑

值得考虑的是,GPC 信号将附加到向给定 网站发出的每个 HTTP 请求。渲染一个 Web 页面通常需要发出数十个这样的请求。因此, 如果每一次 GPC 交互都触发带有 高成本审计跟踪的完整选择退出程序,可能并不切实际,因为这会产生大量 处理工作,包括必须 尽可能高效执行的、由内容分发网络(CDN)提供的资源相关处理。

旨在支持 GPC 的法规应考虑此类实现 困难。解决这些困难的一种方式,是区分为用户提供、用于请求使不出售或共享交互偏好在网站上持续存在的用户界面 功能,以及提供由用户代理维持其状态的 不出售或共享交互信号。 在后一种情况下,可以像该个人先前已经请求过这样的不出售或共享 交互偏好, 并且正在与已经启用该偏好的状态交互一样处理该交互。

B. 致谢

本规范在很大程度上依赖于 跟踪保护工作组 以及其他为 跟踪偏好表达(DNT) 作出贡献的人所开发的概念。

C. 参考文献

C.1 规范性参考文献

[ABNF]
语法规范的增强 BNF: ABNF. D. Crocker, Ed.; P. Overell. IETF. 2008 年 1 月. 互联网标准. URL: https://www.rfc-editor.org/info/rfc5234/
[html]
HTML 标准. Anne van Kesteren; Domenic Denicola; Dominic Farolino; Ian Hickson; Philip Jägenstedt; Simon Pieters. WHATWG. 现行标准. URL: https://html.spec.whatwg.org/multipage/
[privacy-principles]
隐私原则. Robin Berjon; Jeffrey Yasskin. W3C. 2025 年 5 月 15 日. STMT. URL: https://www.w3.org/TR/privacy-principles/
[RFC2119]
RFC 中用于表示 要求 级别的关键字. S. Bradner. IETF. 1997 年 3 月. 最佳当前实践. URL: https://www.rfc-editor.org/info/rfc2119/
[RFC3339]
互联网上的日期和时间: 时间戳. G. Klyne; C. Newman. IETF. 2002 年 7 月. 提议标准. URL: https://www.rfc-editor.org/info/rfc3339/
[RFC8174]
RFC 2119 关键字中大写与小写的 歧义. B. Leiba. IETF. 2017 年 5 月. 最佳当前实践. URL: https://www.rfc-editor.org/info/rfc8174/
[RFC8259]
JavaScript 对象表示法(JSON)数据 交换格式. T. Bray, Ed. IETF. 2017 年 12 月. 互联网标准. URL: https://www.rfc-editor.org/info/rfc8259/
[RFC8615]
众所周知的统一资源标识符 (URI). M. Nottingham. IETF. 2019 年 5 月. 提议标准. URL: https://www.rfc-editor.org/info/rfc8615/
[WebDriver]
WebDriver. Simon Stewart; David Burns. W3C. 2026 年 7 月 2 日. W3C 工作草案. URL: https://www.w3.org/TR/webdriver2/
[webidl]
Web IDL 标准. Edgar Chen; Timothy Gu. WHATWG. 现行标准. URL: https://webidl.spec.whatwg.org/

C.2 资料性参考文献

[CCPA-REGULATIONS]
CCPA 法规. URL: https://www.oag.ca.gov/sites/all/files/agweb/pdfs/privacy/oal-sub-final-text-of-regs.pdf?