全球隐私控制(GPC)

W3C 工作草案

关于此文档的更多详细信息
本版本:
https://www.w3.org/TR/2026/WD-gpc-20260219/
最新发布的版本:
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 ([privacy-principles]). While data can be shared with service providers for limited operational purposes, it can also be shared or used for behavioral targeting in ways that many users find objectionable.

世界各地的司法管辖区已提出或颁布了若干不同的法律框架来应对这一问题。 有些模式依赖用户对跟踪的同意。 基于数据最小化原则的其他模型则干脆完全禁止某些数据共享或数据处理。

一些法律和提案授予用户请求保护其隐私的权利,包括 "opt out" 请求,要求其数据不 被出售或共享给超出其意图交互的企业。 然而,要求人们对他们访问的每个网站都手动表达其权利既不切实际,也给人们施加了 "privacy labor"([privacy-principles)。

本规范针对最后一类法律而设计,并通过 HTTP 头或 DOM 向所有网站发布者提供一种通用信号,传达个人声明其适用权利以阻止其数据被出售、与第三方共享以及用于跨上下文定向广告,从而解决了扩展用户选择难以实施的问题。 该信号使用户能够利用某些基于 "global opt-out" 的法律中的具体条款,例如加利福尼亚消费者隐私法案中关于 “opt out preferences signals” 的条款,以阻止个人信息的出售或共享,[CCPA-REGULATIONS],或科罗拉多及其他州法律中关于 “universal opt-out mechanisms” 的类似条款,使用户能够选择退出其信息的出售或将其用于跨组织定向广告。

然而,虽然 Global Privacy Control 的设计是让用户表达选择退出数据共享和跨上下文定向广告的偏好,但该控制并不打算行使所有可能的隐私权,甚至不涵盖关于广告或广告定位的所有选择退出权。 例如,GPC 并非用于行使删除权。 GPC 也不用于解决同一 context 内的数据收集或广告定位。 更多细节,请参见 Legal and Implementation Considerations Guide

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

2. 术语定义

一个 不出售或不共享的交互 是与网站的交互, 在该交互中,个人请求其数据不被出售给或与其打算交互的实体以外的任何方共享,或其数据不被用于跨上下文广告定位。 根据 W3C隐私原则,该人至少 请求只有一个 数据控制者 ,并且数据不得被用于在另一个 上下文 中进行广告定位, 即使该 上下文 属于 同一企业。

不出售或分享偏好,指的是用户通过激活全局隐私控制设置(或使用默认如此设置的工具,可能因为这符合该工具用户的普遍预期)提出其“数据不应被出售或分享”的请求。当该偏好被设置时,用户期望以不出售或分享交互的方式浏览Web。

3. 表达不出售或分享偏好

3.1 表达格式

所有HTTP请求(通过HTTP头)和所有网站(通过Web API属性)都应传达全局隐私控制偏好

若已设置,该偏好以单一值1或视上下文等效的true表达。

在没有监管、法律或其他要求的情况下,网站可以根据其认为最适合该特定个人的方式来解释所表达的 Global Privacy Control 首选项,尤其是考虑到该人的隐私期望、上下文 和 文化环境。 同样,网站也可能使用本协议范围之外的其他 首选项 信息, 例如特定站点的个人 偏好 或第三方注册服务,以在未通过本协议明确表达 首选项 时,通知或调整其行为。

用户代理应尽量准确传达用户的偏好。用户代理应当努力表达其对用户全局隐私控制值的最佳判断偏好

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"

用户代理不得生成Sec-GPC头字段,若顶层浏览上下文gpcAtNavigationfalse

用户代理必须顶层浏览上下文gpcAtNavigationtrue时,生成字段值为数字字符"1"的Sec-GPC头字段。

用户代理不得在同一HTTP请求中生成多个Sec-GPC不得在HTTP trailer中使用Sec-GPC字段。

服务器处理包含Sec-GPC头的HTTP请求时,必须忽略该字段并按未指定该头处理请求,除非字段值正好为"1"。若有多个Sec-GPC头且至少有一个值为"1",服务器必须视为只有一个值为"1"的Sec-GPC头;否则视为没有。

HTTP中间方不得移除值为"1"的Sec-GPC头,但可以移除其他值的Sec-GPC头。此外,若HTTP中间方有理由认为请求发起者有不出售或分享偏好可以插入值为"1"的Sec-GPC头。

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 属性可通过navigator对象在常规和worker环境下获取,可通过navigator.globalPrivacyControl读取。

4. GPC 支持资源

站点可以在 .well-known 路径下生成一个资源,以表明其遵守 GPC 请求,至少在法律要求的情况下。GPC 支持资源的目的是让站点表达其对全局隐私控制的知晓和支持。该支持资源并不用于表示站点是否遵守访问该资源的用户代理的 GPC 请求。默认情况下,源站的支持状态为未知

GPC 支持资源在源服务器的 URL 下具有专用标识符 /.well-known/gpc.json [RFC8615]。

收到指向其 GPC 支持资源的有效 GET 请求时,源服务器要么返回包含站点范围跟踪状态的机器可读响应(如下定义),要么返回一系列重定向,最终指向这样的响应(该响应可以由其他源服务器提供)。

4.1 GPC 支持表示

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

GPC 支持表示必须是一个 JSON 对象,否则源站的支持状态为未知。下列清单之外的成员在本规范中无意义,必须被忽略。成员包括:

6. 隐私注意事项

通过 HTTP 头字段或 navigator 对象公开用户偏好,可能会将用户分为两类,从而增加浏览器或设备指纹识别所需的信息量。除非该信号与其他信号完全相关,或为不可配置设置,否则这些额外信息始终可用。因此,视实现方式不同,GPC 信号可能带来隐私成本,尽管这是一种为了发送该信号而带来的合理隐私收益。

7. 安全注意事项

本规范中的功能目前无已知安全影响。

8. 自动化

为了支持用户代理自动化与应用测试,本文档定义了以下 扩展命令。[WebDriver]

8.1 设置全局隐私控制

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

设置全局隐私控制 扩展命令可修改当前会话的不出售或分享偏好

远端步骤,给定 sessionURL variablesparameters 如下:

  1. gpcparametersgpc 属性。

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

  3. 记录该 session 的用户偏好,使得浏览器在 gpc 为 true 时执行 不出售或分享交互,在 gpc 为 false 时不执行。

  4. 返回 success,数据为 null

8.2 获取全局隐私控制

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

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

远端步骤,给定 sessionURL variablesparameters 如下:

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

  2. 否则,令 gpc 为 false。

  3. result 为一个属性 "gpc" 值为 gpc 的 JSON 对象

  4. 返回 success,数据为 result

9. 一致性

本规范中被标记为非规范性的章节,以及所有编写指导、图表、示例和注释均为非规范性内容。规范中的其他内容均为规范性内容。

本文档中的 MAYMUSTMUST NOTSHOULD 等关键词,依照 BCP 14 [RFC2119] [RFC8174] 的定义进行解释,仅当其全部大写出现时按照上述含义解释。

A. 实现注意事项

需要考虑的是,GPC 信号会附加在对某个站点发起的每一个 HTTP 请求上。渲染一个网页通常需要发起数十次这样的请求。因此,如果每一次 GPC 交互都触发完整的选择退出流程并带有昂贵的审计跟踪,对于所有 GPC 交互都会导致大量的处理,包括那些必须尽可能高效执行的内容分发网络(CDN)资源,这在实际操作中可能并不现实。

鼓励意在支持 GPC 的监管规定考虑此类实现上的难点。应对这些难题的一种方式,是区分为用户在站点上持久请求不出售或分享交互 偏好而提供的用户界面手段,以及由用户代理维护状态的 不出售或分享交互信号。在后者情况下,可以将此交互视为用户此前已请求此不出售或分享交互 偏好且该用户正处于该偏好已激活的状态来处理。

B. 致谢

本规范大量借鉴了 追踪保护工作组 以及为 追踪偏好表达(DNT) 做出贡献的其他人员的发展成果。

C. 参考文献

C.1 规范性引用

[ABNF]
语法规范的增强 BNF:ABNF. D. Crocker, Ed.; P. Overell. IETF. January 2008. 互联网标准. URL: https://www.rfc-editor.org/rfc/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. 15 May 2025. STMT. URL: https://www.w3.org/TR/privacy-principles/
[RFC2119]
在 RFC 中用于表示要求级别的关键词. S. Bradner. IETF. March 1997. 最佳现行实践. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC3339]
互联网上的日期和时间:时间戳. G. Klyne; C. Newman. IETF. July 2002. 拟定标准. URL: https://www.rfc-editor.org/rfc/rfc3339
[RFC8174]
RFC 2119 关键字中大写与小写的歧义. B. Leiba. IETF. May 2017. 最佳现行实践. URL: https://www.rfc-editor.org/rfc/rfc8174
[RFC8259]
JavaScript 对象表示法(JSON)数据交换格式. T. Bray, Ed. IETF. December 2017. 互联网标准. URL: https://www.rfc-editor.org/rfc/rfc8259
[RFC8615]
众所周知的统一资源标识符(URIs). M. Nottingham. IETF. May 2019. 拟定标准. URL: https://www.rfc-editor.org/rfc/rfc8615
[WebDriver]
WebDriver. Simon Stewart; David Burns. W3C. 6 February 2026. 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?