Make the architecture support other privacy laws

[privacycg]

Make the architecture support other privacy laws

[bvandersloot-mozilla]

If we are changing the syntax of the header (e.g. because of #6), I'm much more open to the idea of allowing other rights to be expressed via this header.

[bvandersloot-mozilla]

Making this infinitely extensible is a bad idea IMO. Part of the strength of GPC is that it is a single choice for a user that represents a "more private" experience that reflects a very sane boundary.

By changing the semantics, we may be throwing away California's progress in enforcement by changing the meaning out from under them.

If there are more compelling use cases we could add another header or two in this spec. Sec-*: 1 should compress well. I understand the concern of not wanting to have multiple headers for very similar semantics, however I don't think the set of things the user can reasonably be asked to opt out of with every request is that big. Maybe just a couple more? Even ADPC only provides a single value for the object option.

[jyasskin]

+1 that it shouldn't be infinitely extensible (unlike parts of ADPC): adding values should require a change to the standard. The GPC spec mentions 3 plausible values so far: sale, direct-marketing, and (unnecessary) local storage. I don't think there's a need to include all 3 in the first version, but this issue is about ensuring that there's semantic space for them. If that's just a described naming pattern for future extensions to follow, I think that'd be ok.

Sec-*: 1 doesn't compress that well under HPACK, which allows re-using field names or (name,value) pairs, but doesn't re-use parts of names. That said, the size isn't likely to be a big problem here.

[bvandersloot-mozilla]

If that's just a described naming pattern for future extensions to follow, I think that'd be ok.

That would be reasonable. Having a naming pattern called out and understanding that future variations can land here.

I think we agree that using the cookie namespace for the variations is non-ideal and we would be closer to ADPC syntax if we had no adoption yet.

Sec-*: 1 doesn't compress that well under HPACK, which allows re-using field names or (name,value) pairs, but doesn't re-use parts of names.

You caught me, I forgot that header compression was tricky :)

[jyasskin]

we would be closer to ADPC syntax if we had no adoption yet.

It seems like you're saying that because someone shipped and there's some adoption, the standards process can't change any of the names anymore. While lots of Chrome teams would be happy with that policy, it's not usually the policy we follow for the web platform, especially for features that shipped before getting any feedback from other browsers.

[arichiv]

There is some adoption on the user agent side and web side, but multiple localities have automated opt-out clauses that only go into effect in 2024. Don’t we still have time to revisit the format of the header? The ADPC pattern may be relevant for opt-outs limited to targeted advertising, sale of personal data, or both. We should anticipate more, distinct opt out requirements in the future and don’t want to end up with Sec-GPC2, Sec-GPC3, etc. fields in the not-too-distant future.

[npdoty]

If that's just a described naming pattern for future extensions to follow, I think that'd be ok.

That would be reasonable. Having a naming pattern called out and understanding that future variations can land here.

A naming pattern could help; I wouldn't expect it to be in the normative spec itself (though I don't care strongly where it ends up).

I think more helpful would be advice from implemented experience on sending opt-out signals and their usage.

Different opt-outs (though I don't anticipate many of these will see strong legal support or wide interest for some time) will have potentially quite different semantics, how they're explained to users, how they're interpreted by websites, even which parties or with which data they're communicated in the browser. Guidance and lessons learned on how to write and deploy such a mechanism seems more helpful than anticipatory architectural design to use the same header for other rights or controls.

[bvandersloot-mozilla]

Don’t we still have time to revisit the format of the header?

I think this is a good question for the editors and those that did outreach in California where GPC already constitutes a binding opt-out.

[HeinzBaumann]

I believe there's potential in broadening the current single-bit encoding to a more comprehensive 6-bit system. This enhancement would accommodate the varying privacy laws across different regions, such as the United States, Europe, and beyond. In Europe, for instance, a single bit doesn't suffice due to the requirement for more detailed consent, exemplified by the 11 purposes outlined in the TCF (Transparency and Consent Framework). By incorporating such granularity into the header encoding, browsers could assume the role of gatekeepers, thereby obviating the need for numerous intrusive consent managers.

While I acknowledge that the implementation may be more intricate than this simplified explanation, I believe it aligns with the broader goal of designing the GPC (Global Privacy Control) signal with scalability in mind. This direction holds promise for facilitating smoother compliance with evolving privacy regulations.

[bvandersloot-mozilla]

A complication has come up in the draft text of the APRA that is not elaborated on here. A single privacy law would have two different global opt outs that could (and maybe should) function independently. This is more support that we should expand the definition to >1 bit.