Make spec consistent about same contexts rather than same sites #127
Conversation
|
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. |
|
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. |
|
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. |
jyasskin
left a comment
There was a problem hiding this comment.
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.)
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