Global Privacy Control (GPC)

W3C Working Draft

More details about this document
This version:
https://www.w3.org/TR/2024/WD-gpc-20241203/
Latest published version:
https://www.w3.org/TR/gpc/
Latest editor's draft:
https://w3c.github.io/gpc/
History:
https://www.w3.org/standards/history/gpc/
Commit history
Editors:
Sebastian Zimmeck (Wesleyan University)
Peter Snyder (Brave Software)
Justin Brookman (Consumer Reports)
Aram Zucker-Scharff (The Washington Post)
Former editors:
Robin Berjon (Protocol Labs) (The New York Times until Sep 2022)
Ashkan Soltani (Independent)
David Harbage (DuckDuckGo)
Feedback:
GitHub w3c/gpc (pull requests, new issue, open issues)

Abstract

This document defines a signal, transmitted over HTTP and through the DOM, that conveys a person's request to websites and services to not sell or share their personal information with third parties. This standard is intended to work with existing and upcoming legal frameworks that render such requests enforceable.

Status of This Document

This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.

This document was published by the Privacy Working Group as a Working Draft using the Recommendation track.

Publication as a Working Draft does not imply endorsement by W3C and its Members.

This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 03 November 2023 W3C Process Document.

1. Introduction

This section is non-normative.

Building websites today often requires relying on services provided by businesses other than the one which a person choses to interact with. This result is a natural consequence of the increasing complexity of Web technology and of the division of labor between different services. While this architecture can be used in the service of better Web experiences, it can also be abused to violate privacy ([privacy-principles]). While data can be shared with service providers for limited operational purposes, it can also be shared with third parties or used for behavioral targeting in ways that many users find objectionable.

Several legal frameworks exist — and more are on the way — within which people have the right to request that their privacy be protected, including requests that their data not be sold or shared beyond the business with which they intend to interact. Requiring that people manually express their rights for each and every site they visit is, however, impractical.

Given the ease and frequency by which personal information is collected and sold when a consumer visits a website, consumers should have a similarly easy ability to request to opt-out globally. This regulation offers consumers a global choice to opt-out of the sale of personal information, as opposed to going website by website to make individual requests with each business each time they use a new browser or a new device. [CCPA-AG-FINAL-STATEMENT]

This specification addresses the issue by providing a way to signal, through an HTTP header or the DOM, a person's assertion of their applicable rights to prevent the sale of their data, the sharing of their data with third parties, and the use of their data for cross-site targeted advertising. This signal is equivalent, for example, to the "global privacy control" in the CCPA [CCPA-REGULATIONS].

2. Definitions

A do-not-sell-or-share interaction is an interaction with a website in which the person is requesting that their data not be sold to or shared with any party other than the one the person intends to interact with, or to have their data used for cross-site ad targeting, except as permitted by law.

A do-not-sell-or-share preference is when a person requests that their data "not be sold or shared" for instance by activating a Global Privacy Control setting with their user agent or by using tools that default to such a setting (possibly because this setting matches the most common expectations of that tool's users). When set, this preference indicates that the person expects to browse the Web with do-not-sell-or-share interactions.

3. Expressing a Do Not Sell Or Share Preference

3.1 Expression Format

A Global Privacy Control preference should be conveyed for all HTTP requests (in the form of the HTTP header) and all websites (in the form of the Web API property).

If set, this preference is expressed as a single value of 1 or equivalently true according to context.

In the absence of regulatory, legal, or other requirements, websites MAY interpret an expressed Global Privacy Control preference as they find most appropriate for the given person, particularly as considered in light of the person's privacy expectations, context, and cultural circumstances. Likewise, websites might make use of other preference information outside the scope of this protocol, such as site-specific person preferences or third-party registration services, to inform or adjust their behavior when no explicit preference is expressed via this protocol.

User agents are expected to convey person preferences as accurately as they can. User agents SHOULD strive to represent what the user agent best believes to be the person's preference for the Global Privacy Control value.

3.2 Preference Caching

The preference MUST be cached on each top-level navigation to ensure consistency in communication of the person's request that their data "not be sold or shared." This means that if the preference changes during or after a top-level navigation, it will not be reflected until the next navigation.

A top-level browsing context has a gpcAtNavigation boolean. It is initially false.

The value of gpcAtNavigation MUST reflect the preference of the person when the top-level browsing context's active document began loading. It will be true if the person's preference was enabled, and false if the person's preference was disabled or had not been set.

If preference is changed to be inconsistent with some gpcAtNavigation cached in a top-level browsing context, the user agent SHOULD inform the user of any inconsistent tabs and provide the option to reload them, refreshing the cached gpcAtNavigation to reflect the current preference.

3.3 The Sec-GPC Header Field for HTTP Requests

The Sec-GPC header field is a mechanism for expressing the person's preference for a do-not-sell-or-share interaction in an HTTP request (for any request method).

The syntax ([ABNF]) of the field is:

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

A user agent MUST NOT generate a Sec-GPC header field if top-level browsing context's gpcAtNavigation is false.

A user agent MUST generate a Sec-GPC header field with a field-value that is exactly the numeric character "1" if top-level browsing context's gpcAtNavigation is true.

A user agent MUST NOT generate more than one Sec-GPC in a given HTTP request and MUST NOT use a Sec-GPC field in an HTTP trailer.

A server processing an HTTP request that contains a Sec-GPC header MUST ignore it and process the request as if that header had not been specified unless the field value is exactly the character "1". If there are multiple Sec-GPC headers and at least one has a field value of exactly "1" then the server MUST treat the request as if there were only one Sec-GPC header with a field value of "1"; and as if there were none otherwise.

HTTP intermediaries MUST NOT remove a Sec-GPC header set to "1", but they MAY remove Sec-GPC headers that contain other values. Additionally, an HTTP intermediary that has reasons to believe the the person originating a given HTTP request has a do-not-sell-or-share preference, MAY insert a Sec-GPC header set to "1".

3.3.1 Extensibility of the Sec-GPC Field Value

The Sec-GPC is deliberately defined without an extension mechanism. Experience with previous similar headers shows that people tend to rely on string equality instead of parsing the value when testing for their presence, especially when extensions do not yet exist. Such checks would of course fail in the presence of extension content, which would in turn render the mechanism moot. Should extensions prove necessary to this standard, they will need to be implemented through other headers, which may in time supersede this one.

3.4 JavaScript Property to Detect Preference

The globalPrivacyControl property enables a client-side script to determine what Sec-GPC header field value was sent when loading the top-level browsing context's active document.

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

The value is false if no Sec-GPC header field would be sent; otherwise, the value is true.

The value of globalPrivacyControl MUST be the top-level browsing context's gpcAtNavigation.

The globalPrivacyControl property is available on the navigator object in both regular and worker contexts, and so can be checked reading from navigator.globalPrivacyControl.

4. GPC Support Resource

A site MAY produce a resource at a .well-known URL in order for a site to represent the fact that it abides by GPC requests, at least where required to do so. The purpose of a GPC support resource is for a site to convey its awareness of and support for the Global Privacy Control. The support resource is not intended to convey whether the site abides by GPC requests from the user agent accessing the resource. By default, an origin's support is unknown.

A GPC support resource has the well-known identifier /.well-known/gpc.json relative to the origin server's URL [RFC8615].

An origin server that receives a valid GET request targeting its GPC support resource responds either with a successful response containing a machine-readable representation of the site-wide tracking status, as defined below, or a sequence of redirects that leads to such a representation (which MAY be provided by a server at another origin).

4.1 GPC Support Representation

The origin server MUST return the GPC support resource as a valid representation using the application/json media type [RFC8259], otherwise the origin's support is unknown.

The GPC support representation MUST be an JSON object, otherwise the origin's support is unknown. Members of this JSON object not in the list below have no meaning in this specification and MUST be ignored. Members include:

6. Privacy Considerations

Exposing a user's preference (in the HTTP header field or

navigator
object) potentially divides users into two groups in a way that might increase the information available for fingerprinting. This extra information is available unless the signal perfectly correlates with other signals. Depending on the browser and implementation, the GPC signal may impose a privacy cost, though one intended to be justified by the privacy benefit of sending the signal.

7. Conformance

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words MAY, MUST, MUST NOT, and SHOULD in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

A. Implementation Considerations

It is worth considering that a GPC signal will be attached to every HTTP request made to a given site. Rendering a page on the Web often requires making dozens such requests. As such it can prove impractical for GPC signals to trigger full-blown opt-out procedures with costly audit trails for every single GPC interaction as that will cause a large amount of processing, including for resources served from a content delivery network (CDN) that must be executed as efficiently as possible.

Regulations that intend to support GPC are encouraged to consider such implementation difficulties. One way of addressing them is to differentiate between user interface affordances given to people for the purpose of requesting a do-not-sell-or-share interaction preference to persist on the site, and the provision of a do-not-sell-or-share interaction signal the state of which is maintained with the user agent. In the latter case, the interaction can be processed as if the person had previously requested such a do-not-sell-or-share interaction preference and were interacting with that preference already active.

B. Acknowledgments

This specification relies on concepts developed in large part by the Tracking Protection Working Group and others who contributed to Tracking Preference Expression (DNT).

C. References

C.1 Normative references

[ABNF]
Augmented BNF for Syntax Specifications: ABNF. D. Crocker, Ed.; P. Overell. IETF. January 2008. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc5234
[html]
HTML Standard. Anne van Kesteren; Domenic Denicola; Dominic Farolino; Ian Hickson; Philip Jägenstedt; Simon Pieters. WHATWG. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC3339]
Date and Time on the Internet: Timestamps. G. Klyne; C. Newman. IETF. July 2002. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc3339
[RFC8174]
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174
[RFC8259]
The JavaScript Object Notation (JSON) Data Interchange Format. T. Bray, Ed. IETF. December 2017. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc8259
[RFC8615]
Well-Known Uniform Resource Identifiers (URIs). M. Nottingham. IETF. May 2019. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc8615
[webidl]
Web IDL Standard. Edgar Chen; Timothy Gu. WHATWG. Living Standard. URL: https://webidl.spec.whatwg.org/

C.2 Informative references

[CCPA-AG-FINAL-STATEMENT]
California Attorney General CCPA Final Statement of Reasons. URL: https://oag.ca.gov/sites/all/files/agweb/pdfs/privacy/ccpa-fsor.pdf
[CCPA-REGULATIONS]
CCPA Regulations. URL: https://www.oag.ca.gov/sites/all/files/agweb/pdfs/privacy/oal-sub-final-text-of-regs.pdf?
[COLORADO-REGULATIONS]
Colorado Regulations. URL: https://coag.gov/app/uploads/2023/03/FINAL-CLEAN-2023.03.15-Official-CPA-Rules.pdf
[CPPA-REGULATIONS]
CPPA Regulations. URL: https://cppa.ca.gov/regulations/pdf/cppa_regs.pdf
[privacy-principles]
Privacy Principles. Robin Berjon; Jeffrey Yasskin. W3C. 20 November 2024. W3C Working Group Note. URL: https://www.w3.org/TR/privacy-principles/