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

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?

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

@jackfrankland, I provided a few initial comments.

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?

@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?

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?

@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.

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.

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?

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.

@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?

@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.

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?

@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.

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

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.

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)

We've scheduled an ad-hoc meeting on Thursday Dec 10th to discuss this further (right after the regular PrivacyCG teleconference). More details can be found here.

For reference, a draft proposal is available on github and we've put together a website, press release and FAQ for those that want more background.

We look forward to hearing everyone's feedback and questions.

A fascinating discussion at the meeting yesterday. My takeaway is that there are two ways forward concerning this proposal.

1. Involve multiple external lawyers from different jurisdictions, with different briefs to fully understand the legal ramifications. The output from this activity will benefit the proposal and ensure it is robust prior to deployment.

2. Turn the proposal into a technical standard and remove all references to laws and specific signal use cases. Focus on the single use case of minimising repetitious preference entry.

In general, I remain concerned about the W3C being complicit in the implementation of a standard to support a specific law without agreement from the membership on the rules associated with doing so.

Can we revisit this as part of the agenda this week? The outgoing attorney general has already expressed support for GPC.

Can we revisit this as part of the agenda this week? The outgoing attorney general has already expressed support for GPC.

@SebastianZimmeck @asoltani - Do you want to lead a discussion in the Privacy CG call tomorrow on this?

Thanks! I've added this to the agenda.

I realize how closely related this standard is to the CCPA/CPRA regulation, and I have to raise once more (last time, promise) that a global standard should transcend one jurisdiction's specific regulation. This standard, in particular, should uphold the principle of Privacy by Default. A global privacy signal called "Do Not Sell" without a default setting of "enabled" does not do that. I continue to advocate for a default setting "Do Not Sell" as enabled to uphold the principle of Privacy by Default.

@LeVasseur-Me2B indeed. Unfortunately it's hard to dictate through a standard what a particular legal regime should do.

That said, as I mentioned on the call, the California CCPA, in their Final Statement of Reasons - Appendix E #73 does specify, in response to questions about whether such a mechanism can be on by default, "The consumer exercises their choice by affirmatively choosing the privacy control […] including when utilizing privacy-by-design products or services")

I'm happy to provide an update on GPC adoption and the various US state privacy proposals that include language for a 'Global Privacy Control' if it would be helpful (and theres room on the agenda). @TanviHacks

I added both labels agenda+ and agenda+F2F for an update depending on which meeting has time available.

I've just checked the agenda here and don't see GPC included. Does anyone know the time the discussion is scheduled for?

@rvaneijk great question. I would be surprised if there were any interest in a web browser vendor implementing, or their representatives even being involved in discussing implementing, specific jurisdiction's laws when there is no legal requirement for them to do so.

Note that major browsers are actually going above and beyond existing privacy laws, which is a great thing for user privacy. Allowing these privacy improvements to move forward is in users' best interest, which is what standards bodies exist for.

I think thats a bit of a stretch, the law in Europe has required specific, informed and freely given prior consent for tracking since 2009 (ePrivacy), and as easy to withdraw consent as to give it since 2016 (GDPR)
But I agree its great that browsers are finally catching up (more some than others of course).

In light of the upcoming GPC discussion, here is the spec as it stands.

Is there any information on how to implement something similar for mobile apps? This refers to @SebastianZimmeck's point on "Which types of clients or platforms should be covered?".

At the initiative of Luis Alberto Montezuma, we had a lengthy discussion on this topic recently on Twitter.

There was also some discussion as to whether an implementation on Android would even be possible, so I now created a small proof of concept for Android: https://github.com/kasnder/gpc_android

I'm sure there are many flaws with my piece of code, but an implementation on Android seems possible to me?

Nice work, @kasnder! I opened an issue in your repo to discuss a bit more over there.

We have moved this to the CG as a work item. Closing this.