You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
GPC actively pushes the Sec-GPC value to all sites via HTTP header
While GPC can be applied to send signals to all sites users visit, they can select only individual sites as well. Also, in addition to the header, GPC defines a DOM property that can be used to indicate GPC preferences as well.
I am also not 100% sure if the following is really a difference as described in the Centralized Consent API explainer
The Centralized Consent API avoids adding a global fingerprinting bit by making per-site and global preferences indistinguishable
There should be only minor changes to clarify the relationship a bit. I can open a PR accordingly, but if anyone wants to weigh in ... .
Just to follow up on what @SebastianZimmeck is saying, theres nothing in the GPC spec requiring an implementation to have the same setting for all origins (or even to all parties on the page, an implementor could send a different signal to the 1p than to each different 3p, etc).
My suggestion for the paragraph on the relationship between the Centralized Consent API and GPC would be:
Global Privacy Control (GPC) is a proposal to standardize 'Do Not Sell' and similar signals. This work has some overlap with our purpose, but differs in the following way.
GPC actively pushes the Sec-GPC value to a site via an HTTP header or a DOM property. It may be subject to legal enforcement under the CCPA, GDPR, and other laws. By contrast, the Centralized Consent API will rely on a site's incentive to create a better user experience and have more persistent storage for consent data. Though, just as GPC, it may use legal enforcement if applicable once a site obtains a user's preference.
The following could go under Make per-site and global preferences indistinguishable as I am not sure that there is a difference in terms of fingerprinting risks.
The Centralized Consent API avoids adding a global fingerprinting bit by making per-site and global preferences indistinguishable, and mitigates fingerprinting risks further by only revealing a user's preference in a first-party context with user interaction.
I am happy to discuss further or, given access, open a PR with the above changes.
Currently, the Centralized Consent API explainer reads:
While GPC can be applied to send signals to all sites users visit, they can select only individual sites as well. Also, in addition to the header, GPC defines a DOM property that can be used to indicate GPC preferences as well.
I am also not 100% sure if the following is really a difference as described in the Centralized Consent API explainer
There should be only minor changes to clarify the relationship a bit. I can open a PR accordingly, but if anyone wants to weigh in ... .
(cc'ing GPC draft spec fellow co-authors @darobin, @asoltani, @dharb, @pes10k)
The text was updated successfully, but these errors were encountered: