Give UAs more help in establishing user intent

[jyasskin]

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.

[bvandersloot-mozilla]

I agree that setting a norm for a string, if not a requirement, would be useful given the legal implications.

I am working internally in Firefox to get language set now. One idea we have had that I am partial to is "Tell websites not to sell or share my data" with a link to learn more.

[arichiv]

"Tell websites not to sell or share my data" might be tailored to the scope of opt-outs for some laws, but not others that have broader opt-outs, for example. If the GPC field sticks to a boolean value, the language might need to clarify other ways it could be interpreted (in addition to the ‘learn more’ link with more complete information). We flag these questions to consider, as many actors in the ecosystem will be required to figure out how to parse and respond to these signals.

[j-br0]

I submitted PR #57 to try to provide more information about existing legal guidance on UI requirements. I do not think it is practical to get browsers to agree on specific disclosures since at least some user agents have stated an intent to continue to turn GPC on by default (which is allowable under certain conditions under at least both California and Colorado regulations). And even if W3C were to agree on consensus language, there is no certainty that regulators (who have the final say in their jurisdictions) would agree with our interpretation of what is or is not legally required. I think it is unlikely that regulators are going to require or even bless specific language formulations, though if any do we should certainly update our documentation to reflect that.

Because legal guidance will continue to evolve, I agree with the proposal from @AramZS to set up an explainer document with more detail about legal requirements that can be updated more regularly than this spec (see Issue #56).

[SebastianZimmeck]

We have a paper at the Privacy Enhancing Technologies Symposium next year that may be relevant,
Generalizable Active Privacy Choice: Designing a Graphical User Interface for Global Privacy Control.

The question we address is how GPC can be integrated into the browser without default settings, compliant with the law, and in a usable way. The main idea is to generalize settings, e.g., apply the GPC opt out on site towards all future sites people visit.

[AramZS]

@jyasskin Does the latest state of the explainer satisfy your questions here enough that we can close the issue?

[jyasskin]

Looking at https://github.com/privacycg/gpc-spec/blob/main/explainer.md#6-user-experience-considerations-and-recommendations, I don't see clear answers to the questions in my original post.

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.

For example, if Chrome were to start sending the header by default, with no indication from the user that they intended to opt out of sale/sharing, would that remove sites' obligations in some jurisdictions to respect the header when it came from Chrome? And so is it something that the specification or explainer should tell Chrome not to do?

I also don't see anything in the explainer yet that covers the concern about how we make the effects clear to users. I see the link to Robin's speculation about the effects under the GDPR, but our legal folks aren't convinced he's right. This might be a task to leave to the WG.

[SebastianZimmeck]

I see the link to Robin's speculation about the effects under the GDPR, but our legal folks aren't convinced he's right.

I'd say @darobin's point is a bit more than speculation. Notably, the Landgericht Berlin required LinkedIn to honor DNT signals based on GDPR, Article 21(5) (in German).

[j-br0]

I created PR #99 to try to address this based on the conversation at the 3.20.25 Privacy Working Group meeting.

[michaelkleber]

Thank you Justin for starting on a PR to address our discussion from 2025-03-20, but I feel this went in a different direction from than that meeting.

There are three elements I was advocating for:

(a) The spec currently has several different points of view of what GPC is supposed to mean. That worries me: we surely don't want the spec to keep changing as a result of new regulator interpretations. I think that we should unify all the descriptions of GPC's intent. Personally, I'd opt to say clearly that it is meant to be a "Do Not Sell or Share" signal, in line with its CCPA roots.

(b) The Legal Effects section should explicitly recognize that laws are not uniform in that interpretation — and in particular that some jurisdictions have decided to also use it as a prohibition against cross-site targeted advertising, even when such advertising does not involve the selling or sharing of data. I really hope we can try to not sweep this under the rug. Let's be clear to regulators that the signal had a particular intent, whether or not they choose to expand on that in their rulemaking.

(c) Finally, the UI section. Of course we need to tread lightly here, because browsers get to make their own choices. But perhaps we could suggest that browser UI should acknowledge both the sell-or-share intent and the variation in interpretation.

Sorry for suggesting-bombing your PR; of course it would be more productive to have just offered up a separate PR along these lines. I'm about to be OOO for a bit, but I'll talk to @jyasskin about keeping on moving this forward while I'm away.

[j-br0]

The existing spec is quite clear that GPC is intended to invoke both rights to limit the sale of personal information as well as rights to limit cross-site targeting. This is not swept under the rug, the text is abundantly clear.

PR #102 would undo that and declare that GPC isn't meant to stop cross-site targeting. This would be an unacceptable outcome both for users who want to use GPC for its stated purpose as well as for regulators who have relied upon GPC as a way to offer easy-to-use tools to exercise their legal rights (every state that allows for a universal opt-out for sales also allows for universal opt-outs for cross-site targeting).

GPC is designed to be simple and universal. We do not need to make a different signal for every slightly different invocation of similar rights. As the spec is clear, GPC is not designed to invoke every privacy right (such as a right to delete data), but both opt-out of sale and opt-out of cross-site targeting are clearly within the scope of what GPC is designed to let users turn off.

[dmarti]

So far there is only one jurisdiction that has gone through a "universal opt out mechanism" (UOOM) registration process—the state of Colorado: https://coag.gov/opt-out/

The Colorado opt-out includes "the Sale of their Personal Data or use of their Personal Data for Targeted Advertising" and Colorado law defines "Targeted Advertising" using its own definition. https://coag.gov/app/uploads/2022/01/SB-21-190-CPA_Final.pdf

I agree that the spec can't capture every GPC meaning in every jurisdiction. But it would be counterproductive to change the spec to make it inconsistent with a known opt-out requirement that's already well documented and that sites and services are already complying with.

[michaelkleber]

Thank you all for the discussion here and on #102 — it provides some clarity about the editors' thinking.

My goal is still the same as it was before: I am looking for some description of GPC that a browser can present to a user that gives the user an accurate sense of what GPC is supposed to do. If we're going to give people a checkbox to turn this feature on or off, then we must do our best to make that an informed choice.

I agree with the editors that we don't want this meaning to change retroactively: if a person made a choice at some point, then it's hard to argue with a straight face that we can change our spec and therefore change the meaning of what the person meant in the past. But because of a change made in 2022, we're in that situation no matter how the spec changes today.

When GPC first appeared in October 2020, it was described as a "request to websites and services to not sell or share their personal information with third parties," in line with California's legislation. That's still how it was still being described when the Colorado Privacy Act was passed in July 2021, and even today the Colorado AG's explanation of "What is GPC?" says it's a way "to allow the user to notify businesses of their privacy preferences, such as whether or not they want their personal information to be shared or sold." The do-not-sell-or-share meaning is also how it is described to users today in Firefox, and in Privacy Badger, and on the GPC's own website.

The language in the spec was expanded to include targeted advertising in Oct 2022 in this commit, with title "editorial updates to front matter". There was no pull request and no discussion of the retroactive change to the meaning of the control. During the Privacy CG meeting the following week, we had a whole discussion of the signal's meaning, in which the fact that the editors had just unilaterally and dramatically changed the answer did not come up.

I understand that you want to explicitly cover some types of targeted advertising as in the Colorado law — sure, let's find some consistent description of GPC that makes that clear. But ultimately, we need to pick one answer and then stick with it. Let's tell the answer to our users, and let's tell the regulators that that's what we're doing. The browser's ability to accurately convey the user's intent depends on it.

[j-br0]

The October 2022 revisions to the spec did not expand or change of the meaning of GPC --- as you note, it has always been designed to limit the sharing of personal data. The edits were in response to new laws that were derived from the CCPA but which framed the rights slightly differently. For example, Connecticut (the first such law I believe) offers consumers the ability to opt out of the sale of personal data and targeted advertising based on nonaffiliated website/app data. Targeted advertising based on data from different websites is squarely within the scope of what GPC was designed to address.

I believe we included the term "cross-context" to differentiate from other types of targeted advertising that the spec should NOT be interpreted as invoking. For example, if a state law mandated an opt-out for first party advertising, I don't think that GPC should be interpreted as invoking that right (at some point we updated the spec to say this specifically). Many of these new state laws also include an opt out for "profiling" which I don't think GPC should be interpreted as invoking (I don't think the spec currently talks about these profiling rights but I'd be open to it).

[dmarti]

I agree with @michaelkleber that capturing the user's intent is important. In this case, though, that would mean sticking with "context" as much as possible and avoiding "organization".

Many users are not aware of which contexts are co-owned by which organizations, so a user might encounter unexpected patterns of how their data is used depending on how well they keep up with business news. The definition of contest in W3C Privacy Principles is based on user understanding so tends to reduce this confusion.

Using "context" is also helpful in the case where the same company owns a browser and multiple web contexts. If the company only applied GPC to cross-"organization" data transfers, then they likely end up with competition issues related to tracking users across their own contexts but not independently owned contexts. Better from a practical compliance POV to stick with contexts.

(There are some other examples of difficulties of going by organizations or contexts on the First-Party Sets/ Related Website Sets project, and they ended up going with contexts for most sets. Organizations are hard.)