Skip to content

Make spec consistent about same contexts rather than same sites#127

Open
darobin wants to merge 2 commits intow3c:mainfrom
darobin:coherent-context-site
Open

Make spec consistent about same contexts rather than same sites#127
darobin wants to merge 2 commits intow3c:mainfrom
darobin:coherent-context-site

Conversation

@darobin
Copy link
Member

@darobin darobin commented Dec 22, 2025

This is a small change (aside from trailing spaces it's just editing one sentence) to make the spec consistently about contexts rather than sites. We can of course talk informally about websites and when technical limits force us into site-based distinctions, but it's important that the semantics of the GPC signal itself remain grounded in the notion of context.

Using sites instead of contexts would put GPC at odds with both the privacy architecture detailed in the Privacy Principles and the Vision for W3C's provisions on avoiding centralisation.


Preview | Diff

@michaelkleber
Copy link

As I said in #108 (comment), I disagree with this PR.

GPC was originally about triggering the privacy rules in California's CCPA / CPRA, which discusses websites. It has been taken up by a variety of other state privacy laws, all of which discuss websites.

I think it is a bad idea to both claim that its intent is to trigger these laws, and that its intent is about a boundary relating to contexts not websites.

@darobin
Copy link
Member Author

darobin commented Dec 22, 2025

If you want to discuss what GPC was originally about, it might be best to ask the people who originally worked on it. I can assure you with absolute certainty that making it easier for a tech monopoly than for other businesses to merge behaviour across contexts is not an idea that excited anyone.

It is fully to be expected that applications of GPC — both in how the GPC signal may be captured in law and in how it may be technically implementable — can have some degree of mismatch with the semantics of the signal. Reality is messy that way. Nevertheless the best approach we can take is to provide a signal with clear semantics that are grounded in the web's privacy architecture, as detailed in the Privacy Principles, and offer a consistent meaning to the signal that others can make a best effort at applying in practice.

Picking an interpretation that aligns neither with the original intent of the signal nor with the web's privacy architecture would be a highly objectionable choice that I see no clear benefit to, except in increased revenue and competitive advantage for large conglomerates.

@michaelkleber
Copy link

So GPC does X per various laws, and you want to change the spec from "GPC was designed to do X" to "GPC was designed to do Y".

I guess you're right that a "was designed to" kind of sentence is a non-normative artifact about historical intent. I just hope you don't expect browsers to represent that unachieved historical intent to the user.

Copy link
Member

@jyasskin jyasskin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The WG has been pretty clear that it doesn't want this to restrict same-site sharing (https://github.com/w3c/privacywg/blob/main/minutes/privacywg-20250807.md#edit-to-spec-to-clarify-scope and #94 (comment)). As such, the right fix is probably to clarify the other uses of "context" rather than to undo that WG consensus.

It probably makes sense to check this consensus in a meeting given Robin's additional argument, but it's not the case that the Privacy Principles constrain all future W3C specs to create intra-site boundaries. At the limit, we can check that in a formal-objection council, and I don't think the conclusion of that council is a foregone conclusion. (Full disclosure: Google has an opinion on this, but I'll be careful not to be the only reason there's disagreement on the council.)

@darobin
Copy link
Member Author

darobin commented Jan 15, 2026

@jyasskin The minutes discuss the difference between cross-org and cross-context, but they do not manifest a discussion or decision regarding cross-context and cross-site. In fact, quite the contrary: there are multiple statements indicating that cross-context is preferable, well defined, and in line with what the CCPA wanted. The discussion includes the fact that GPC isn't meant to prevent same-context ad targeting, and that's entirely true — if we consider contexts. As far as I can tell from the minutes, this here PR is a better implementation of the group's consensus than the existing text.

@michaelkleber You keep saying things like "GPC was originally for" or wanting to change GPC from X to Y. I'm sorry man, that's just not how things happened. The source of truth for GPC globally isn't California, it's here. GPC was designed before the CCPA came into effect, certainly before the CCPA regulations that made it binding. It was intended to be multi-jurisdictional from the get-go and that has important implications for how the spec itself must be written.

It was also deliberately intended to be context-based; that was key to getting publisher support behind it. You invoked POSIWID; if we make GPC about sites rather than contexts, then the POSIWID implication is that: "The purpose of the W3C is to create economic benefits to tech monopolies to the detriment of other actors." Some may find this to be an unfortunate purpose.

More generally, the strategy for multi-jurisdictional, co-regulatory standards is relatively straightforward. We know that technical concepts will translate inaccurately within different regulatory systems that all have to contend with different constraints based on their specificities. Some have to talk about "businesses" and others about "internet society services", in other cases some things can be forbidden but others have be tolerated because of rules on federal trade or treaty constraints. That's just the messy real world. A notion like "site" or "domain" won't map better than contexts (in some cases it will, in others it won't — whether you can express it in code or not is irrelevant here, it's the legal bindings that matter). What we can do to help is to pick the notion that is the most coherent, that best matches the web's architecture, that has the best privacy properties, that supports the better economic outcomes, that best meets the expectations of human beings, and then to convey that clearly. Legal bindings will differ and will be less perfect than the semantics we choose, but by picking the option that best matches the interests of our constituencies we can drive alignment on something better rather than on something worse.

@j-br0 j-br0 added the agenda+ Request to add this issue to the agenda of our next telcon or F2F label Feb 3, 2026
@SebastianZimmeck SebastianZimmeck removed the agenda+ Request to add this issue to the agenda of our next telcon or F2F label Feb 5, 2026
@SebastianZimmeck
Copy link
Member

In today's W3C Privacy Working Group meeting we broadly reached consensus that "context" is preferable over "site."

@jyasskin jyasskin dismissed their stale review February 5, 2026 21:59

The WG had consensus against my statement here, so it shouldn't block merging.

@anderagakura
Copy link

Sorry for jumping in late, but I’m curious about this PR shifting GPC from site to context (or it was already the case and I missed it?) :

  • Which law explicitly refers to contexts rather than sites?
  • How are contexts clearly defined within a site (by page category, by country or something else)?
  • What about UX? (many pop up per site)
    Thanks for the understanding

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants