Reference needed for W3C TPWG DNT technical document TPE (Tracking Preference Expression) : https://www.w3.org/TR/tracking-dnt/

transactions_to_enrich = [
Plaid::ClientProvidedTransaction.new({
id: "1",
description: "PURCHASE WM SUPERCENTER #1700",
amount: 72.10,
direction: Plaid::EnrichTransactionDirection::OUTFLOW,
location: Plaid::ClientProvidedTransactionLocation.new({
city: "Poway",
region: "CA",
}),
iso_currency_code: "USD",
}),
Plaid::ClientProvidedTransaction.new({
id: "2",
description: "DD DOORDASH BURGERKIN 855-123-4567 CA",
amount: 28.34,
direction: Plaid::EnrichTransactionDirection::OUTFLOW,
iso_currency_code: "USD",
}),
]

transactions_enrich_get_request = Plaid::TransactionsEnrichRequest.new

transactions_enrich_get_request.account_type = "depository"
transactions_enrich_get_request.transactions = transactions_to_enrich

response = client.transactions_enrich(transactions_enrich_get_request)
enriched_transactions = response.enriched_transactions
transactions_to_enrich = [
Plaid::ClientProvidedTransaction.new({
id: "1",
description: "PURCHASE WM SUPERCENTER #1700",
amount: 72.10,
direction: Plaid::EnrichTransactionDirection::OUTFLOW,
location: Plaid::ClientProvidedTransactionLocation.new({
city: "Poway",
region: "CA",
}),
iso_currency_code: "USD",
}),
Plaid::ClientProvidedTransaction.new({
id: "2",
description: "DD DOORDASH BURGERKIN 855-123-4567 CA",
amount: 28.34,
direction: Plaid::EnrichTransactionDirection::OUTFLOW,
iso_currency_code: "USD",
}),
]

transactions_enrich_get_request = Plaid::TransactionsEnrichRequest.new

transactions_enrich_get_request.account_type = "depository"
transactions_enrich_get_request.transactions = transactions_to_enrich

response = client.transactions_enrich(transactions_enrich_get_request)
enriched_transactions = response.enriched_transactions

Browsers may be able to ensure navigator.globalPrivacyControl always reflects the value sent in the gpc-sec header, but browser extensions will not, unless they just assume it is always set.
History stuck us with a simple DOMString property in the TPE but it would have been much better if it had returned a Promise. If the value is ever imagined to support a consent indication e.g. like DNT:0 then it would be a good idea to go with a Promise now.

Even if the signal has no other value, some browser extensions might wish to give users per origin control i.e. so as not send sec-gpc to some sites. In that case a Promise would be better.

The current spec seems to define .globalPrivacyControl on the Window scope Navigator.
It might be useful to expose it also in workers (Dedicated, Shared and Service)

Does it make sense to append a version to signals to future proof the spec for iteration?

There is official interest in a brief consumer-facing explanation of GPC and pointing to browsers and extensions that implement it. I will prepare a document with such explanation.

As written, the current spec implies that:

• HTTP headers always reflect the current GPC preference
• JavaScript properties always reflect the preference when the top-level browsing context started loading

This is inconsistent, and seems like it will lead to weird edge cases if the preference is changed mid-load. I propose that we adopt the approach of JavaScript for HTTP so both return the preference cached at the time of the last top-level navigation.

I'm have a draft of this in #38

Since the gpc-spec repo was moved from the globalprivacycontrol org to the privacycg org, a few links to the deployed spec need updating.

Add .json to the end of the "well-known" URL, to facilitate implementation by sites with legacy web servers or shared hosting.

(This is what the IAB Tech Lab does with ads.txt and sellers.json)

It's easy to configure IndexDocument and MIME types if you have access to the web server config files but this is not always possible for the person responsible for adding 3rd-party JavaScript to a site.

Is there any way to ensure the relevant legal effects remain up to date? I would like to avoid stagnation of this section in particular, which is meant to reflect a non-technical description of the world's legal landscape. I have a lot of blind spots when it comes to consumer data protection laws, and the current list includes no reference to laws outside of the USA and Europe. I know a lot of countries have GDPR-like laws and opt-out clauses, so it may be the case that the current text has some blind spots as well.

I want to open discussion on this issue because some comments we have on this front indicate this issue is unclear. If an implementer has a user who has turned off the GPC or has not activated it, is it clear to everyone what behavior is expected from the user agent?

websites MAY interpret an expressed Global Privacy Control preference as they find most appropriate

This one might be unavoidable, but this is effectively a meaningless statement. Consider avoiding normative language and instead concentrate on the intended semantics of carrying the signal. The real teeth in this mechanism lies in the legal enforcement part, so explain that more directly rather than use a "In the absence of regulatory, legal, or other requirements" preface to this statement.

User agents SHOULD strive to represent what the user agent best believes to be the person's preference for the Global Privacy Control value.

This could easily be a "MUST".

Spinning off from comment on #61 I realized there is something that is not 100% clear.

Is it a concern that the navigator property is a behavior inconsistent with the header? Does this open an avoidable fingerprinting risk?

I had assumed that it would mirror the header behavior in being true or not present to avoid fingerprinting issues and maintain consistency with the header (pending #60), but I see the spec has a bool for that property, so if we want it to be 'true or not present' I think the spec needs to change? Opening an issue on this questions.

The spec mentions that Sec-GPC:1 isn't meant to opt out of local storage or direct marketing, but those are natural things to want to be able to configure in a browser. Other privacy laws and regulations are likely to define more things that users might want to opt out of. We should have a single architecture for all of this sort of opt-out thing, with do-not-sell as a particular case of it, rather than a whole spec and HTTP header for the single case.

ADPC has a reasonable design for this, where the browser sends Header: object=<strings>, and each string is defined to indicate a particular behavior. This isn't the only reasonable design.

This is related to #27, but isn't primarily motivated by human readability. The desire to cover more than one kind of privacy law was also mentioned in the discussion about adopting GPC into the Privacy CG.

There is already a DNT Do Not Track header. How does this relate to it?

Just curious given the spec is still listed as a draft, where is this proposal in regards to making it a standard at w3c? I see that Firefox is starting to implement it. Do you have commitment from other browser developers too?

The spec mentions the value of GPC to be:

A user agent MUST generate a Sec-GPC header field with a field-value that is exactly the numeric character "1" if the user's Global Privacy Control preference is set.

It does not specify:

(a) What should be the value if GPC is not set. IMO the 'absence' of GPC and GPC being explicitly turned off should be two different values to not conflate having set (some state of) GPC as opposed to not having GPC (supported) by the user-agent. This can be done through, e.g. Sec-GPC: 0

(b) If other values of GPC can be set and supported, such as in future specs, to indicate other interpretations or conditions for use of GPC. Through such additional values, GPC can become capable of specifying multiple 'preferences' - such as for different conditions, jurisdictions, or additional restrictions.

Filed on behalf of @yoavweiss: "Use https://httpwg.org/http-extensions/draft-ietf-httpbis-header-structure.html#boolean"

The spec text currently reads as follows:

Specifically, the value of Navigator.globalPrivacyControl for a given script is true if a Sec-GPC header set to 1 is sent in a request to a target resource at the effective script origin (the current document.domain of the script's responsible document) when that request is due to an embedded reference from this site (the document.domain of the top-level browsing context's active document). Otherwise, it is false.

It seems that this was a direct copy and paste from DNT. I believe that the wording about when the JS attribute should return true versus false was necessary under DNT due to the idea of user-granted exceptions. Given that there is no such notion under GPC (since it is a global control), it seems there's an opportunity to simplify this language:

Specifically, the value of Navigator.globalPrivacyControl for a given script is true if a user has requested that their data "not be sold or shared" via setting a Global Privacy Control preference.

Happy to submit a PR if folks agree to the wording above!

I'll merge this. If any devs think we should change the glob pattern instead we can change the behavior in a secondary PR.

Originally posted by @ReenigneArcher in LizardByte/Sunshine#1972 (comment)

I served across all the privacycg github repo but wasn't sure where to ask this question: I am just curious to learn where in the process the GPC proposal is. What time frame are we looking at when this will be a w3 standard. Thanks!

The Web Privacy Community Group aims to incubate privacy specifications for eventual standards track placement. GPC is implemented by numerous extensions and at least one browser (Brave) so it would fit.

This is particularly a problem with Typescript or any JS code using proper validation instead of 'truthiness'

navigator.globalPrivacyControl

Chrome returns 1
https://global-privacy-control.glitch.me/ says it should return 1
https://privacycg.github.io/gpc-spec/#javascript-property-to-detect-preference - says it should be a boolean
https://developer.mozilla.org/en-US/docs/Web/API/Navigator/globalPrivacyControl - says it should return true

https://developer.mozilla.org/en-US/docs/Web/API/Navigator/globalPrivacyControl also indicates it isn't supported anywhere except Firefox, which seems false. They are missing the specs as well so there seems a big gap

Right now the spec both says that the .well-known JSON text must be ordered and unordered.

Since there is no benefit for order here, and in order to maximize compatibility, lets just define this as a JSON object

Random question, but when looking through the spec I didn't see anything about what responses should be for rejecting requests which cannot be satisfied while respecting GPC headers.

I'm very new to this space, so maybe this question is stupid, but it seems like there would be some times where a server cannot guarantee that they are compliant with legal requirements of a request specifying Sec-GPC: 1. In those situations it may make sense to reject the request entirely, or indicate this information to clients in a standardized way. Is there any guidance about what a server responses (and response codes) should look like for that type of situation?

The JSON format specifies a version field, but not how it's used, beyond:

The value of the version member MUST be the number 1.

A recipient might read that if the version isn't 1, the format isn't valid, and ignore it -- is that the intent here?

If not, changes would be backwards-compatible, which means a version field isn't necessary, and incompatible changes could be introduced by changing the well-known resource name.

https://privacycg.github.io/gpc-spec/#user-interface-language currently says

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.

As discussed when we talked about adopting GPC into the Privacy CG, UAs aren't sure how to do this so that the header stays legally enforceable and has the intended effect across many jurisdictions. UAs also want to make it clear to users what happens when they turn on the header, and we need guidance about how that depends on where the user is, where the target site is based, the user's history of moving around, etc.

As far as I can tell, none of the existing implementations at https://globalprivacycontrol.org/#download have tackled this problem. I believe all of them except for Firefox turn the setting on by default, on the assumption that users are installing them because they want to turn on every privacy setting that exists. Firefox does it through about:config instead of through general-purpose UI.

Although browsers are usually opposed to standardizing UI, I think the legal implications of this one will make us more amenable to at least getting some hints in this case. I would actually lean toward standardizing the exact string, in one or more languages, that invokes particular rights within particular laws, but others might prefer just having some examples.

In Section 1,

This specification addresses the issue by providing a way to signal... user's assertion of their applicable rights to prevent selling their data to third parties or sharing data with them

What constitutes "user data" that can or cannot be shared?

For example, if a website uses a CDN for fonts, stylesheets or JavaScript libraries, then that site is implicitly sharing user information with the CDN (HTTP Referrer, IP address, user Agent string).

Likewise, what constitutes a "third party"?

• Users making a purchase will be implicitly sharing their information with payment services and possibly shipping services.

• If a website is an agent or reseller for other parties, then it will be sharing information about sales with those parties. For example, a site that sells artwork will notify the original artist who purchased their work (and it may be the responsibility of the artist to send the artwork to the buyer).

• Media companies may share purchase information with copyright enforcement agencies, e.g. an agency finds a copyrighted image or video on a website, notifies copyright holder, who then responds that that website is legit user.

• The user is acting on behalf of or granted access by a third party (e.g. their employer or school), and information will be shared with that third party.

All of the above will be spelled out clearly in a website's terms or privacy policies. But a binary true/false misses important exceptions.

Currently, the first sentence of section 3.1 reads:

A Global Privacy Control preference needs to be conveyed to all mechanisms that might collect data from or share data with third parties.

I think what is meant is:

A Global Privacy Control preference needs to be conveyed to all mechanisms that might collect data from a person or share a person's data with third parties.

This is a purely editorial change. I do not intend to change any meaning.

As mentioned, we will move the legal details from the spec to the explainer, keep some general remarks in the spec itself, and (non-normatively) link to the explainer from the spec.

As designed, I had to review the spec to understand thatSec-GPC: 1 means "do not sell or share".

The Sec-GPC would be more human readable if its name or value suggested the users specific preference.

Two quick suggestions:
Sec-GPC: no-sell-share
Sec-GPC-No-Sell-Share: 1

This adds at most one bit of information to the fingerprinting surface of browsers¹. That probably won't be an issue, but the specification can at least acknowledge that point.

The specification doesn't really make a very strong case for this feature and this is a specification that really needs to strongly justify every aspect of its design. More mechanisms = larger attack surface.

"YYYY-MM-DDTHH:MM:SS(?:0+)?TZ" is, I believe, incorrect. If this is supposed to be a regex, that's not clear, but if it is, there is a missing period in the optional grouping after the "SS", there is an extra "T" before the "Z" (or is that not a literal "Z", but a timezone - unclear), and I believe that it is customary to use different case for months and minutes (months and days are lowercase for POSIX date(1)/strftime(3) for instance).

Filed on behalf of @anssiko: It might be worthwhile to explain upfront the relationship with DNT given the shared broader problem space and similar API shape that might confuse some.

I have been doing some testing using a simple NGINX server and testing on Brave and Chrome browsers.

When I set Sec-GPC = 0 on a page these are the following results:

• Brave navigator.globalPrivacyControl is always true
• Chrome navigator.globalPrivacyControl is undefined

Shouldn't the client-side be reading the value of the header?

I think it would help if each of these paragraphs included a direct identification for the jurisdiction. That is "Mauritius DPA" and "European Union GDPR" and "California CCPA". That's not your fault necessarily, but an existing problem.

Originally posted by @martinthomson in #68 (comment)

Is it possible to change the lastUpdate field of /.well-known/gpc.json to RFC3339, rather than ISO8601?

The ISO8601 spec is behind a pay wall, which makes it difficult for implementers (particularly parsers) to know what possible values the lastUpdate field can take.

RFC3339 is a "profile" of ISO8601, so essentially describes the same thing, but is freely available, simpler/more specific, and is specifically intended as the "date and time format for use in Internet protocols".

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.

This makes it clear that defaulting to GPC being on might engage some additional obligations on the browser side. Does this make it impossible to default to enabling GPC in private browsing modes, only with appropriate interface affordances, or only in some jurisdictions?

Some more guidance here seems like it might be warranted as this particular choice imposes a burden on implementations that is potentially confusing or inconsistent. At worst, it means that implementations might need to choose universally safe options, which tend to result in transfer of the responsibility for privacy labour to their users.

Hi. The latest published version link in the specs at https://globalprivacycontrol.github.io/gpc-spec/ is https://www.w3.org/gpc/ which returns a 404.

If this is NOT an error on the W3 side, and that url has not been registered/provided by w3.org, then an alternative (if needed) for 'purl' is to use w3id e.g. to get https://w3id.org/gpc

There should be a Normative reference to the current EU ePrivacy Directive:
https://edps.europa.eu/sites/edp/files/publication/dir_2009_136_en.pdf