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.
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]].
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=].
A Global Privacy Control [=preference=] needs to be conveyed to all mechanisms that might collect data from or share data with third parties.
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.
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 the person's Global
Privacy Control [=preference=] is not enabled or defaulted to.
A user agent MUST generate a [=Sec-GPC=] header field with a field-value that
is exactly the numeric character "1" if the person's Global Privacy Control [=preference=]
is set.
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".
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.
The {{GlobalPrivacyControl/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 [=navigable/active document=].
interface 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.
Specifically, the value of {{GlobalPrivacyControl/globalPrivacyControl}} for a given script is
true if a person has requested that their data "not be sold or shared" via
setting a Global Privacy Control [=preference=].
The value of {{GlobalPrivacyControl/globalPrivacyControl}} MUST reflect the [=preference=] of the person when the [=top-level browsing context=]'s [=navigable/active document=] began loading.
The {{GlobalPrivacyControl/globalPrivacyControl}} property is available on the
navigator object in both regular and worker contexts, and so can be checked
reading from navigator.globalPrivacyControl.
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. The purpose of a GPC Support Resource is for a site to convey its support for the Global Privacy Control. 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).
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:
gpc member. The value of the gpc member MUST be either
true, to indicate that the server intends to abide by GPC requests, or
false, to indicate that it does not. For any other value the origin's
support is unknown.
lastUpdate member. The value of the lastUpdate
member MUST be an RFC3339 full-date (YYYY-MM-DD) or date-time
(YYYY-MM-DDTHH:MM:SS(?:0+)?TZ) [[RFC3339]]. This indicates the time at
which the statement of support was made, such that later changes to the meaning of the
GPC standard should not affect the interpretation of the resource for legal purposes.
If the member is not in a valid RFC3339 format, the last update date and time is
unknown.
Receiving a GPC signal may have legal effects, depending on factors such as the location of the individual sending the signal, the scope of the applicable law, as well as any separate agreement between the recipient of the signal and the individual.
For example, the use of the GPC signal by an individual will be intended to communicate the individual's intention to invoke the following rights, as applicable:
Under the CCPA, the GPC signal will be intended to communicate a Do Not Sell request from a global privacy control, as per [[?CCPA-REGULATIONS]] §999.315 for that browser or device, or, if known, the consumer.
Where the GPC signal conflicts with the existing privacy settings a consumer has with the business, the business shall respect the GPC signal but may notify the consumer of the conflict and give the consumer an opportunity to confirm the business-specific privacy setting or participation in the financial incentive program [[?CCPA-REGULATIONS]] §999.315(c)(2).
GPC could potentially be used to indicate rights in other jurisdictions as well. For example:
Under NRS 603A, a GPC signal will be intended to communicate a Do Not Sell My Personal Information request [[?SB220]].
The GDPR requires that "Natural persons should have control of their own personal data" ([[?GDPR]], Recital 7). The GPC signal is intended to convey a general request that data controllers limit the sale or sharing of the person's personal data to other data controllers ([[?GDPR]] Articles 7 & 21). This request is expressed with every interaction that the user agent has with the server.
Note that this request is not meant to withdraw a person's consent to local storage as per the ePrivacy Directive ("cookie consent") ([[?EPRIVACY-DIRECTIVE]]) nor is it intended to object to direct marketing under legitimate interest ([[?GDPR]]).
However, GPC is not necessarily intended to invoke every new privacy right in every jurisdiction. For example, GPC is not intended to globally invoke data deletion rights on every website visited by the user. GPC is also not intended to limit a first party’s use of personal information within the first-party context (such as a publisher targeting ads to a user on its website based on that user’s previous activity on that same site). For that reason, GPC should not be interpreted as exercising the CCPA’s right to limit the use of sensitive information in a first-party context.
Given the complexities of existing consent frameworks, publishers who accept the GPC signal should disclose how they treat the GPC signal in that jurisdiction and how they deal with conflicts between the signal and other specific privacy choices that the person has already made directly with the publisher, including instances where third party sharing may be permitted such as sharing to service providers/processors, sharing at law or at the direction of the individual.
Studies have shown that people do not want their data sold or shared. However, in some jurisdictions they can only avail themselves of that [=preference=] by explicitly asserting control.
User agents are expected, where required, to present all the appropriate notices to people to ensure that the rights they wish to avail themselves of are effectively binding.
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.