Standardizing Global Privacy Control (GPC)

[SebastianZimmeck]

Background

On January 1, 2020 the California Consumer Privacy Act (CCPA) went into effect and established new privacy rights for California consumers. Specifically, it covers the rights to:

1. Opt out from the sale of personal information (Do-Not-Sell),
2. Access personal information, and
3. Delete personal personal information.

A "sale" is understood broadly and likely covers, for example, a website making available or disclosing identifiers or location data to an ad network for purposes of monetization. The most recent regulations to the CCPA published by the California Attorney General specify that automatic signals communicating a user's decision to opt out must be respected. Here is the relevant language:

If a business collects personal information from consumers online, the business shall treat user-enabled global privacy controls, such as a browser plugin or privacy setting, device setting, or other mechanism, that communicate or signal the consumer’s choice to opt-out of the sale of their personal information as a valid request ... .

The CCPA appears to be a catalyst for implementing new privacy functionality in browsers and other clients. Other states beyond California are introducing similar privacy bills in their legislatures. Microsoft announced to honor the new CCPA privacy rights not only for California but for all other states as well. Similarly, Mozilla announced the option to delete telemetry data for its users anywhere.

In addition to the CCPA, the General Data Protection Regulation (GDPR) also mentions the option for clients to make privacy practices explicit via machine-readable icons:

The information to be provided to data subjects pursuant to Articles 13 and 14 may be provided in combination with standardised icons in order to give in an easily visible, intelligible and clearly legible manner a meaningful overview of the intended processing. Where the icons are presented electronically they shall be machine-readable.

Various efforts are underway to implement the new privacy rights. The Interactive Advertising Bureau has released the IAB CCPA Compliance Framework for Publishers & Technology Companies and the Digital Advertising Alliance CCPA tools. Efforts by W3C Working Groups include the Confinement with Origin Web Labels. There are also various approaches led by companies in this space, for example, the Data Transfer Project.

Some Initial Thoughts

At this point, it seems worthwhile to have a discussion of these developments with the goal of converging to a standard. In particular, a Do-Not-Sell signal could be implemented similar to the Do-Not-Track (DNT) signal via an HTTP header.

Previously, the Tracking Protection Working Group developed the Tracking Preference Expression (DNT). There are certainly lots of learnings that can be taken from that effort for the question here. Though, a big difference is that recipients of a DNT signal are not required to comply with it. Per the California Online Privacy Protection Act (CalOPPA) they only need to say whether they comply.

There are multiple dimensions to the implementation of privacy rights:

1. Which functionalities should be implemented? For example, a narrow implementation could just focus on a Do-Not-Sell signal, a simple binary signal. At the other end of the spectrum could be a full privacy communication channel that allows users not only the opt out from selling data, but also signal access requests and receive related data through the browser, for example.
2. Which types of clients or platforms should be covered? Especially, on mobile devices much of the user interaction happens through non-browser apps. Should operating system vendors get involved here to add or change existing APIs to accommodate for privacy signals and communication?
3. Which technologies should be used? The DNT effort relied on HTTP headers. Other choice mechanisms are reliant on HTTP cookies, many on third party cookies and some on first party cookies. With relevance for this context Google recently announced a plan to phase out support for third-party cookies in Chrome. Should Do-Not-Sell and similar functionalities even part of the browser and other clients or should there be a web platform (e.g., a Do-Not-Sell registry similar to the Do-Not-Call registry)?

Internet users, publishers, privacy organizations, and ad networks are some of the stakeholders in this question. Ultimately, there needs to be a consensus because the proposed task here is not only one of technology but also one of policy. The implementation of privacy rights such that they can be meaningfully exercised and the evolvement of the web ecosystem for all participants go hand-in-hand.

One concrete idea to move forward is the implementation of prototypes and testing them in usability studies. We already started this effort here at Wesleyan.

This issue is continuing a discussion of members of the Privacy Community Group on the mailing list.

Edit July 30, 2021: Below is a list of blog posts, public comments, and other responses on Global Privacy Control. I am updating the list on a regular basis. It is not comprehensive, but I am trying to cover all major developments.

[AramZS]

I do have a proposal to build out this process for the IAB system - https://github.com/AramZS/IAB-CCPA-Framework-Implementation-Notes/pull/2

[SebastianZimmeck]

This was a great call. In addition to @AramZS proposal, here are a few other related items (some of which we discussed in the call):

• W3C Workshop on Permissions and User Consent
• Microsoft Edge Auditing - Privacy on the Web
• The Chromium Projects - The Privacy Sandbox

Also, the California Attorney General released the Written Comments Received During 2nd 15-Day Comment Period (takes a while to load, I should add).

I would be interested in hearing what everyone thinks as to which functionalities should be implemented. Should the standardization focus on Do-Not-Sell or go beyond?

[jackfrankland]

Hi @SebastianZimmeck, just want to point you in the direction of a proposal I just made here: https://github.com/privacycg/proposals/issues/11. It would be interesting if this or something like this has already come up previously, and your general thoughts. Cheers.

[SebastianZimmeck]

@jackfrankland, I provided a few initial comments.

[SebastianZimmeck]

I do have a proposal to build out this process for the IAB system - AramZS/IAB-CCPA-Framework-Implementation-Notes#2

@AramZS, could you explain your proposal a bit more? Wouldn't it be possible to process the uspString via a browser or browser extension as is?

[AramZS]

@SebastianZimmeck This is specific to the current IAB CCPA process which is the most commonly adopted in the US among publishers and their legal understanding of how CCPA is handled, which most publishers are signed on in agreement with. The idea of the proposal is indeed to allow a browser or browser extention to set it. While, in theory, a browser could overwrite the window-level object to reset the output of the USP String, it isn't the expected behavior, and it would likely lead to the same sort of war of browser interactions that we see with ad blockers, one agent overwrites the object the other then watches for that and overwrites their object etc...

The specific concerns then are:

• The USP interface provided in the IAB specification should be changed to take external input
• That external input to alter any values notify the system processing the USP consent signal so that it can be processed. (This is a concern for any complex publisher that may want to then pass that consent change to other systems like newsletters that don't share the same execution space as their standard JS)
• That external input be able to certify that it is user-initiated and not an automated change to the consent state, as automated changes to the consent state are not allowed by the law. According to the IAB's interpretation, all consent changes must occur with an active per-site action from the user.
• That the USP interface can then process the request and signal if the change is accepted or rejected (the USP signal might be rejected, for instance, if the user is not actively in the CA area)

So my proposal aims to address all those concerns and leave a space for further extension, for example the additionalData object could be extended to allow plugins to attest that they have verified the users' CA residency or something like that, which is a larger discussion. Does that make sense?

[LALeVasseur]

Have there been any proposals or discussions around the idea that Do Not Track and Do Not Sell should be default settings, and that the individual not bear the burden to opt out?

[dmarti]

@LALeVasseur Yes, at the early stages of discussion of the initiative that became the CCPA there were some proposals to make it more of a direct clone of Europe's GDPR, which (at least on paper) requires consent first. However the people who drafted the CCPA decided that an opt out based system would be more likely to hold up in court in the USA. The law here is set up for tracking and sales as the default and likely will be for quite a while.

Good news is that right now the regulations say that "user-enabled privacy controls" that signal your "choice to opt out of the sale of [your] personal information" have to be treated as a valid request to opt out. Which is huge if the privacy tool developer can make a credible claim that your setting was flipped on purpose by you and not set as a default or by some other software. That imho makes the proposal from @AramZS a good one..it complies with the law but requires not much action from the user, or from sites that already implement the IAB's CCPA spec.

[SebastianZimmeck]

The idea of the proposal is indeed to allow a browser or browser extention to set it.

@AramZS, that is great!

Does that make sense?

Very much so.

@LALeVasseur, in addition to what @dmarti said, the Do Not Track signal is based on the California Online Privacy Protection Act, which requires operators of online services only to describe how they respond to Do Not Track signals (i.e., say whether they are honoring it or not). The current regulations to the CCPA on the other hand are requiring businesses receiving a Do Not Sell signal to honor such.

There is quite a bit of a discussion on this topic and what the default setting should be for the Do Not Sell signal (opt-in vs opt-out) in the Written Comments Received During 15-Day Comment Period and the Written Comments Received During 2nd 15-Day Comment Period. In a nutshell, on one side, sending a Do Not Sell signal should be an active decision by the user, but on the other side a user should not be disadvantaged from using a browser (or other user agent) that adheres to privacy by design and has privacy-preserving default settings.

I would expect that the California Attorney General will publish the next (and final?) iteration of regulations within the next days or weeks. At that time, I would suggest to have a call with everyone who is interested on how to concretely implement the Do Not Sell signal in browsers.

[LALeVasseur]

Thanks @dmarti and @SebastianZimmeck! I get the alignment to the regulation, but regulation doesn't always reflect a higher, aspirational set of human rights. Don mentioned the important differences between GDPR and CCPA on opting in/out--is there a reason, in a global SDO, to favor one regulation vs the other?

@SebastianZimmeck can you say more about how someone is disadvantaged from using a PBD enabled browser? Thanks for the links--I'll take a look.

From a human and humane perspective, Do Not Track and Do Not Sell should be default settings.

Finally, what is the order of precedence of the DNT/DNS signals and other preferences that may be set when the individual is logged in?

[SebastianZimmeck]

is there a reason, in a global SDO, to favor one regulation vs the other?

Ideally, the standard would account for these differences in the law. The applicable laws of different countries or geographies govern what is allowed and what is not allowed. The standard is a technical implementation of and must adhere to these laws (which are themselves are intended to effectuate human and constitutional rights). So, there could be different default settings (for example, opt in as the default for users in the EU and opt out for the users in the US).

@SebastianZimmeck can you say more about how someone is disadvantaged from using a PBD enabled browser?

The disadvantage could be that simple use of PBD enabled browser might not be seen as an active choice to convey a Do Not Sell signal as opposed to using a standard browser and enabling a Do Not Sell setting. In the first case an argument can be made that the Do Not Sell signal was not actively selected and can be disregarded. In the second case the user made an active selection, where such argument is more difficult to make.

Finally, what is the order of precedence of the DNT/DNS signals and other preferences that may be set when the individual is logged in?

That is a point that probably warrants further discussion. I do not think the discussion has converged to a clear answer. It may also depend a lot on the concrete situation. This question is also discussed quite a bit in the comments to the regulations mentioned above.

[SebastianZimmeck]

@TanviHacks, in light of the finalized Regs, would it be possible to add a few minutes for discussion on this to the agenda of next call?

[hober]

@TanviHacks, in light of the finalized Regs, would it be possible to add a few minutes for discussion on this to the agenda of next call?

If you'd like to discuss this issue on a cal, add the 'agenda+' label to it.

[michael-oneill]

The CCPA AG final regulations https://oag.ca.gov/sites/all/files/agweb/pdfs/privacy/oal-sub-final-text-of-regs.pdf

The section § 999.315. Requests to Opt-Out requires that relevant businesses offer at lease 2 designated methods for submitting requests to opt-out, one via a site UI e.g.a link, and one of a list of others including email or snailmail. Other than the site UI, which can identify the user via a locally managed mechanism e.g. a first-party low-entropy session cookie, most of these are unsuitable for the web because there is no way to copy all the the possible user identification mechanisms that may be present which could be any of first or third party cookie, other web storage, fingerprinting etc. The only other method available is: "user-enabled global privacy controls, such as a browser plug-in or privacy setting, device setting, or other mechanism, that communicate or signal the consumer’s choice to opt-out of the sale of their personal information". This requirement is reinforced by the current draft of the CPRA. Leaving aside browser extensions which would be unwieldy to scale-up, we are left with a browser HTTP signal the simplest of which being a low-entropy value in a request header. There is already a header that could suffice for this, DNT, which was also recognised as such by the drafters of the GDPR (in A21.5) and the ePrivacy Regulation draft (A10) passed by the EU parliament.

The Tracking Preference Expression document exists and would not be hard to revamp, why not revisit it?

[asoltani]

@michael-oneill The CA AG's FSOR (Final Statement of Reasons) didn't seem to accept 'Do Not Track' as a global privacy mechanism because "the majority of businesses disclose that they do not comply with those signals" and the AG concluded "that businesses will very likely similarly ignore or reject a global privacy control if the regulation permits discretionary compliance". Later in one of the appendix they says that "If a business chooses to treat a “do not track” signal as a useful proxy for communicating a consumer’s privacy choices to businesses and third parties, the regulations do not prohibit this mechanism" -- but thats different than relying on DNT/TPE as the de-facto standard (snippet below).

CalOPPA), the OAG has reviewed numerous privacy policies for compliance with CalOPPA, which requires the operator of an online service to disclose, among other things, how it responds to “Do Not Track” signals or other mechanisms that provide consumers the ability to exercise choice regarding the collection of personally identifiable information about their online activities over time and across third- party websites or online services. (Bus. & Prof. Code, § 22757, subd. (b)(5).) The majority of businesses disclose that they do not comply with those signals, meaning that they do not respond to any mechanism that provides consumers with the ability to exercise choice over how their information is collected. Accordingly, the OAG has concluded that businesses will very likely similarly ignore or reject a global privacy control if the regulation permits discretionary compliance. The regulation is thus necessary to prevent businesses from subverting or ignoring consumer tools related to their CCPA rights and, specifically, the exercise of the consumer’s right to opt-out of the sale of personal information.

That said, I believe a mechanism that works similarly to DNT may be sufficient if it it designed with the express purpose of permitting consumers to communicate their privacy rights. @SebastianZimmeck and I have been thinking about this and hope to discuss in this weeks CG.

[SebastianZimmeck]

Indeed, as @asoltani said, we have made lots of progress and would like to continue the discussion in the group.

[michael-oneill]

If a site needs to implement 2 designated methods, i.e. a Do Not Sell link (and all the necessary ability to communicate the user request to third-parties) and another method e.g. email, then they would need to identify the user (e.g. associate their email address with the tracking cookies), and perhaps share that association with third-parties. If we have a designated device level signal which has an unambiguous meaning, then all that would be unnecessary, and sites might then be encouraged to support the signal. AB370 would mean they have to declare it. I look forward to hearing your ideas next meeting on this important topic.

[dmarti]

Global Privacy Control (GPC) unofficial draft specification

"This document defines a signal, transmitted over HTTP and through the DOM, that conveys a user's request to websites and services to not sell or share their personal information with third parties. This standard is intended to work with existing and upcoming legal frameworks that render such requests enforceable."

(for discussion at privacycg meeting 8 Oct 2020)

[SebastianZimmeck]

Landing page:

• Global Privacy Control

Specification:

• Global Privacy Control specification

Reference implementation:

• Global Privacy Control reference implementation

Press releases:

• Global Privacy Control press release

Twitter account:

• globalprivctrl

Public comments:

• Xavier Becerra, California Attorney General
• Xavier Becerra, California Attorney General
• Alexander McD White, Privacy Commissioner, Bermuda
• Ron Wyden, US Senator from Oregon
• NZ Privacy Commissioner, New privacy standard launched for the whole internet
• Rob Bonta, California Attorney General, Attorney General Bonta Provides Update on CCPA Enforcement Efforts
• Rob Bonta, California Attorney General, CCPA Enforcement Case Examples
• Washington State Rep. Shelley Kloba
• Richard Blumenthal, US Senator from Connecticut (and other senators)

Blog posts, articles, videos, and podcasts:

• Gilad Edelman - Wired: 'Do Not Track’ Is Back, and This Time It Might Work
• Natasha Lomas - TechCrunch: Tech-publisher coalition backs new push for browser-level privacy controls
• Wendy Davis - MediaPost: Privacy Advocates Unveil CCPA Do-Not-Sell Tool
• Paul Hill - Neowin: Global Privacy Control is a new initiative to help people enforce their rights
• Dennis Fisher - Duo: Global Privacy Control Protocol Aims to Pick up where Do Not Track Left Off
• Thomas Claburn - The Register: Global Privacy Control emerges as latest attempt to let netizens choose whether they want to be tracked online
• Steven Melendez - Fast Company: DuckDuckGo, EFF, and others just launched privacy settings for the whole internet
• Lauren Rubenstein - News@Wesleyan: Zimmeck Spearheads Launch of Important Online Privacy Tool
• Dan Goodin - arsTechnica: Now you can enforce your privacy rights with a single browser tick
• Privacy Beat - Wesleyan computer scientist building “Do Not Sell” browser application in bid to follow CCPA; plans W3C and industry discussions and UX testing
• heise online - "Global Privacy Control" - Browser-Signal gegen Datenhandel
• Security Now podcast (73:21 min mark)
• Shubham Agarwal - digitaltrends: The digital switch that blocks all websites from selling your personal data
• Laura Hautala - c|net: Why you're hounded by pop-ups about cookies, and how they could go away
• lola odelola - Samsung Internet Developers (Medium): What’s Global Privacy Control?
• Shira Ovide - The New York Times: How to Make Data Privacy Real
• Russell Brandom - The Verge: Global Privacy Control Wants to Succeed Where Do Not Track Failed
• Kate Kaye - Digiday: Why a tweet from California's AG about a global privacy tool has companies scrambling
• Darren Abernethy and Gretchen A. Ramos - National Law Review: Global Privacy Control Endorsed by California AG – Next Steps
• Issie Lapowsky - protocol: Concern trolls and power grabs: Inside Big Tech’s angry, geeky, often petty war for your privacy
• Kate Kaye - Digiday: California’s attorney general backs call for Global Privacy Control adoption with fresh enforcement letters to companies
• Julie O'Neill, Mary Race - Morrison Foerster: How Can We Opt-Out? Let Me Count the Ways: Businesses Must Honor the Global Privacy Control as a Valid CCPA Opt-Out of Sale Request
• Robin Berjon - GPC under the GDPR
• Harshvardhan J. Pandit - GPC + GDPR: will it work?
• Eddie Holman, Tracy Shapiro - Wilson Sonsini: California Attorney General Mandates CCPA-Covered Businesses Honor the Global Privacy Control and Announces Update on CCPA Enforcement Activity
• Gilad Edelman - Wired: The Privacy Battle That Apple Isn’t Fighting
• Gilad Edelman - Ars Technica: The Privacy Battle Apple Isn’t Fighting
• Jon Healey - Los Angeles Times: Those annoying website pop-ups about cookies — what should you do about them?
• Natasha Lomas - TechCrunch: After years of inaction against adtech, UK’s ICO calls for browser-level controls to fix ‘cookie fatigue’
• Tatum Hunter - Washington Post: Your browser can tell websites how to treat your data. But companies didn’t have to listen — until now
• Mozilla: Implementing Global Privacy Control
• Jake Holland - Bloomberg Law: Global Privacy Control Popularity Grows as Legal Status Up in Air
• Steve Gibson and Leo Laporte - Security Now, Episode 869

Research:

• Maximilian Hils, Daniel W. Woods, and Rainer Böhme - PoPETS: Privacy Preference Signals: Past, Present and Future

[LALeVasseur]

I must have missed the opportunity to participate in the development of the draft spec--was there an invitation somewhere that I overlooked?

[SebastianZimmeck]

@LALeVasseur, we did not have an explicit call to participate. Though, you are very much welcome to do so. We are always looking forward to discuss.

[SebastianZimmeck]

@TanviHacks, it would be great to continue the discussion in the next Privacy CG meeting. So, I am leaving the agenda+ label on. After that meeting we would then schedule an ad hoc meeting for a more detailed discussion.

[jwrosewell]

This is a Pandora’s box. If the W3C debates a technical standard for one particular regulator’s requirement, why not others? How is the list decided upon? What would commenters think if the W3C settled on a mixture of China (1/4 of our host organisations), Iraq and India’s regulations for a standard? Should web browsers really become implementation mechanisms of specific government regulation? If so which ones? Do they pick and choose?

These important questions need to be resolved before this subject is discussed further. I would welcome reopening the proposal for a Technical Policy Interest Group with a mandate to determine what base line policy W3C operates to. In 2016 there appeared to be no appetite to get involved in these subjects. Perhaps the time is now right to come back to the question?

If others disagree and the debate continues at this time then it’s important to recognise the distinction between directly-identifiable information (to which CCPA applies) and de-identified/pseudonymous IDs which are exempted.

[LALeVasseur]

So, is this spec being developed completely outside the W3C in the Global Privacy Control organization? Not sure, then, what the role of this issue thread (and the W3C) is wrt to this spec.

[SebastianZimmeck]

@jwrosewell, @GoodTechWiki, and @LALeVasseur, we intend the spec to be developed inside the W3C. Everyone can be part of this discussion. We would like to continue in the next PrivacyCG call and then in a W3C ad hoc meeting.

[michael-oneill]

I agree a W3C standard should be internationally applicable, but the TPWG DNT experience showed how this could be done. If it had been allowed to become a recommendation we would now have a user controlled opt-in and/or opt-out signal which would have met the user consent requirements of most if not all existing and emerging online privacy laws. The rising mistrust for the web technology industry, driven to a large extent by privacy concerns, commands a lightweight and transparent worldwide standard for signalling consent and the W3C is the best place to do that. I support the current proposal, with the rider that it be enhanced to support an opt-in mode. I also have some technical improvement suggestions.

[michael-oneill]

I pressed the close button by mistake

[jwrosewell]

If this proposal is to progress as proposed, the next step is to engage regulators and understand their requirements for such a feature. In the UK as a minimum this involves the Competition and Market Authority (CMA) who have suggested a common user identifier as one of several remedies to competition issues in the digital market and the Information Commissioners Office (ICO). In the case of Europe the commission are rethinking their approach to privacy and GDPR.

Progressing this proposal sets a precedent for the W3C which I find uncomfortable. Consulting the Advisor Committee (AC) seems like a logical next step given the feedback received in 2016 on these matters.

[michael-oneill]

In fact it is the European Council that has yet to finish its deliberations on the ePrivacy Regulation (which is meant to replace the existing ePrivacy Directive). The European Commission created the first draft which amended and agreed by the European Parliament back in in 2016 and published 2017. The legitimate interest exemption was recently inserted into the Council draft under lobbyist pressure but has now been deleted. For the sake of transparency here is the current draft under the German Presidency: http://downloads2.dodsmonitoring.com/downloads/EU_Monitoring/2020-09-24_Projet_e-privacy_Allemagne.pdf

[jwrosewell]

Thank you for the updated document. When does the ePrivacy Regulation become european law? How will it align with the UK CMA's position on common user ids? What about Australia, Brazil, China, India or 100s of other countries regulations? What process is then used to achieve global alignment? These all of 100s of questions that need to be answered.

I hope we can agree it is not the role of a technical standads body or a forum like this to answer such questions.

[michael-oneill]

The ePrivacy Directive, which requires user consent for access to browser storage, has been law since 2009, enacted in almost all member states (Germany had its own pre-existing Telemedia Act). The ePrivacy Regulation was supposed to update it, e.g. bringing fines to the same level as the GDPR, but the Council sat on it. The recent moves under the German Presidency should change that. But in any case the opt-in requirement has long been current law, last year even confirmed by CJEU ruling.

[lknik]

Hello,

Slight comment.

Previously, the Tracking Protection Working Group developed the Tracking Preference Expression (DNT). There are certainly lots of learnings that can be taken from that effort for the question here. Though, a big difference is that recipients of a DNT signal are not required to comply with it.

Indeed, recipients of DNT/TPE do not need to comply but this is not a shortcoming of the standard (nor any difference, because with what), but the regulatory landscape (which is still in fluid).

It seems to me that the DNSell spec would be aligned towards California only?

[SebastianZimmeck]

It seems to me that the DNSell spec would be aligned towards California only?

Initially, the CCPA is a major application. Though, we envision that the GPC signal can apply more broadly. Depending on where the sender and recipient are located (and possibly other factors), it may have effects in other legal regimes.

[michael-oneill]

Indeed, nobody is compelled to comply with any W3C Recommendation. The TPE described a protocol to signal a users agreement or not for being tracked. Privacy laws imply its reception in various circumstances would have to be taken into account. If it had made it as a Recommendation the DPAs, EDPS, EDPB would have surely published more specific rules, just as the CA AG has done for the CCPA.

[SebastianZimmeck]

These are really good observations. We are a now at a point where both privacy laws and technical specifications are converging. Bridging the gap between the two is where our discussion can make a difference. Often, people in the legal and regulatory community do not know what is possible from a technical standpoint or they intentionally leave it to us for the blanks to be filled. That is where we have an opportunity to implement the laws on a practical level.

[rvaneijk]

I welcome the GPC spec.

What stands out for me are when it comes to a application in the European context: (1) both consent and the right to object under GDPR are bound to the purpose of the processing, which requires additional metadata to be specific and granular. (2) opt-in requires IMHO a different protocol design in comparison to opt-out, e.g. synchronous instead of asynchronous.

I recommend to focus on the design for a CCPA expression by the browser with verifiable server claims, and not on GDPR and/or ePR signals at this stage.

[LALeVasseur]

Then we had best get some legal expertise involved.

[SebastianZimmeck]

Then we had best get some legal expertise involved.

We do! Quite a number of people in our group are lawyers with expertise in privacy law and admissions to European and US bar associations (myself included, though, currently on inactive status).

[lknik]

I recommend to focus on the design for a CCPA expression by the browser with verifiable server claims, and not on GDPR and/or ePR signals at this stage.

Good thinking! It would be best to strip the GDPR/etc aspects (though I understand the PR needs ;-)) for the time being Some of the granularity was offered by TPE, but since this one did not look promising enough for W3C, maybe better not to link to it via GPC.

Then we had best get some legal expertise involved.

I've got an impression that many people with knowledge of EU regulatory framework are already involved (myself, kind of also included, even more so for @rvaneijk!).

[jwrosewell]

At this point, it seems worthwhile to have a discussion of these developments with the goal of converging to a standard.

It would be understandable for an outside observer to conclude the member organisations represented in this group are seeking to implement specific legislation within browser standards. I'm not sure that is the case.

Before this issue continues as is Privacy CG chairs should ask the Advisory Committee (AC) if there is an appetite among W3C members to establish a standard based on specific jurisdiction's laws, and if so should such a standard limit individual entities who may not be browser vendors from making a choice concerning compliance with said standard and laws.

Alternatively the scope could be limited explictly to a discussion about these laws, and the issue re-submitted without any reference to standards.

[darobin]

@rvaneijk Consent needs to be specific (evidently) but not its withdrawal. Likewise for objections — at least that is my understanding. As a data subject, when you are processing my data, I see no reason why I could not withdraw my consent from your sharing it with other controllers (ditto objection for LI). If that requires you to stop more processing than just that, that's a problem of your technical set up. At the very least for LI Art21 is clear that it can be done through automated means.

GPC does not involve opt in, so thankfully we're spared these issues (here).

GDPR isn't included for "PR" purposes, it's included because even though it's a currently unused GDPR angle, there seems to be no reason not to. The BM Privacy Commissioner has indicated that under PIPA, which is a GDPR-style regime, GPC would be applicable.

We probably need to tighten up the text in GPC, taking additional expert input into account (we went broad on purpose initially), but this is meant to work wherever people have rights.

[hlauinfo]

The California AG's office has concluded that when privacy preference signals can be ignored by websites without legal consequence, they will be. That, in short, can be the simple obit for DNT. CCPA allows for the creation of this very signal and provides legal standing/enforcement behind it. I'm surprised that discussion around this topic has not moved more quickly in light of the game-changing opportunities that it affords to the average consumer.

I am not as well-versed on recent GDPR updates. How much legal teeth are behind such a signal in Europe right now as the law currently stands? If there is not explicit legal standing, as there is in the CCPA, then perhaps we can just focus our efforts on the California-specific Do Not Sell standard for now before tackling GDPR.

I also wanted to stress - as I discussed with @johnwilander and others before, that this setting must be exposed to the consumer in order for it to have legal standing, as it is an explicit opt-out. Privacy by default is great but has even more legal teeth with this preference chosen explicitly.

[JulesPolonetsky]

@rvaneijk Consent needs to be specific (evidently) but not its withdrawal. Likewise for objections — at least that is my understanding. As a data subject, when you are processing my data, I see no reason why I could not withdraw my consent from your sharing it with other controllers (ditto objection for LI). If that requires you to stop more processing than just that, that's a problem of your technical set up. At the very least for LI Art21 is clear that it can be done through automated means.

GPC does not involve opt in, so thankfully we're spared these issues (here).

GDPR isn't included for "PR" purposes, it's included because even though it's a currently unused GDPR angle, there seems to be no reason not to. The BM Privacy Commissioner has indicated that under PIPA, which is a GDPR-style regime, GPC would be applicable.

We probably need to tighten up the text in GPC, taking additional expert input into account (we went broad on purpose initially), but this is meant to work wherever people have rights.

@darobin I understood Rob's "ePR signals" as referencing the ePrivacy Regulation (not "PR" public relations). In any event, looking forward to discussing.

[michael-oneill]

Agreed it will be tricky to graft on the European style consent requirements onto an opt-out standard, as it was for the TPE. The problems are easily soluble technically, but not when it comes to getting consensus amongst differing philosophies or interests. Not impossible though, as the DNT experience showed.

[michael-oneill]

Its also not only GDPR/ePR that requires a consent mode. See Proposition 24 (bringing in the CPRA) page 43 the amendment 19 (v) to 1798.18 covering requirements for AG regulations.

provide a mechanism for the consumer to selectively consent to a business's sale of the consumer's personal Information, or the use or disclosure of the consumer's sensitive personal Information, without affecting their preferences with respect to other businesses or disabling the opt-out preference signal globally.

https://www.oag.ca.gov/system/files/initiatives/pdfs/19-0021A1%20%28Consumer%20Privacy%20-%20Version%203%29_1.pdf

[JulesPolonetsky]

Thoughts on indicating jurisdiction? Every state may define global opt-outs or sale differently. Some orgs may respect a signal in some manner in every jurisdiction, some may only in certain jurisdictions. Complications of course when a site has differing geo details about an individual, but the signal also may be passed on to parties that do not have geo information.

[michael-oneill]

Sites should declare how they respond to any client that presents a signal. If they want to differentiate based on IP source address then that's up to them. They could declare in a dynamically generated GPC support resource. But in my view privacy is a human right, so signals from anywhere need respecting the same way.

[LALeVasseur]

But in my view privacy is a human right, so signals from anywhere need respecting the same way.

If privacy were a human right, the default behavior would be no selling/sharing of information, and people would opt in to allow it.

[michael-oneill]

Of course the default should be opted-out, but in CA sites do not have to support that. They should however have the ability to support it if they want to, and there should be a protocol for that.

[rvaneijk]

To what extent is there impementer's interest? Or still too early? Apologies if this is clear for everyone here and has been discussed on a call already. Catching up..