Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Standardizing Global Privacy Control (GPC) #10

Closed
SebastianZimmeck opened this issue Apr 6, 2020 · 74 comments
Closed

Standardizing Global Privacy Control (GPC) #10

SebastianZimmeck opened this issue Apr 6, 2020 · 74 comments
Assignees

Comments

@SebastianZimmeck
Copy link
Member

SebastianZimmeck commented Apr 6, 2020

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.

@TanviHacks TanviHacks added the agenda+ Request to add this issue to the agenda of our next telcon or F2F label Apr 6, 2020
@AramZS
Copy link

AramZS commented Apr 9, 2020

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

@SebastianZimmeck
Copy link
Member Author

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):

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
Copy link

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.

@SebastianZimmeck
Copy link
Member Author

@jackfrankland, I provided a few initial comments.

@SebastianZimmeck
Copy link
Member Author

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?

@TanviHacks TanviHacks removed the agenda+ Request to add this issue to the agenda of our next telcon or F2F label Apr 21, 2020
@AramZS
Copy link

AramZS commented May 8, 2020

@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
Copy link

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
Copy link
Member

dmarti commented May 13, 2020

@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
Copy link
Member Author

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
Copy link

LALeVasseur commented May 14, 2020

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
Copy link
Member Author

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
Copy link
Member Author

@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
Copy link
Member

hober commented Jun 6, 2020

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

@SebastianZimmeck SebastianZimmeck self-assigned this Jun 8, 2020
@SebastianZimmeck SebastianZimmeck added agenda+ Request to add this issue to the agenda of our next telcon or F2F and removed agenda+ Request to add this issue to the agenda of our next telcon or F2F labels Jun 8, 2020
@SebastianZimmeck SebastianZimmeck removed the agenda+ Request to add this issue to the agenda of our next telcon or F2F label Jun 25, 2020
@SebastianZimmeck SebastianZimmeck changed the title Implementing privacy rights Jun 29, 2020
@SebastianZimmeck SebastianZimmeck changed the title Implementing the CCPA Do Not Sell opt out Jul 1, 2020
@SebastianZimmeck SebastianZimmeck changed the title Standardizing the CCPA Do Not Sell opt out Jul 1, 2020
@michael-oneill
Copy link

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
Copy link

asoltani commented Oct 5, 2020

@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 SebastianZimmeck added the agenda+ Request to add this issue to the agenda of our next telcon or F2F label Oct 5, 2020
@SebastianZimmeck
Copy link
Member Author

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

@michael-oneill
Copy link

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
Copy link
Member

dmarti commented Oct 7, 2020

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)

@asoltani
Copy link

asoltani commented Dec 3, 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.

@jwrosewell
Copy link

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.

@SebastianZimmeck SebastianZimmeck changed the title Standardizing Do Not Sell Jan 14, 2021
@hlauinfo
Copy link

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

@TanviHacks
Copy link
Member

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?

@asoltani
Copy link

asoltani commented Feb 10, 2021 via email

@TanviHacks TanviHacks added the agenda+ Request to add this issue to the agenda of our next telcon or F2F label Feb 11, 2021
@TanviHacks
Copy link
Member

Thanks! I've added this to the agenda.

@LeVasseur-Me2B
Copy link

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.

@asoltani
Copy link

@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")

@SebastianZimmeck SebastianZimmeck removed the agenda+ Request to add this issue to the agenda of our next telcon or F2F label Feb 16, 2021
@asoltani
Copy link

asoltani commented May 13, 2021

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

@SebastianZimmeck SebastianZimmeck added agenda+ Request to add this issue to the agenda of our next telcon or F2F agenda+F2F Request to add this issue or PR to the agenda for our upcoming F2F. labels May 13, 2021
@SebastianZimmeck
Copy link
Member Author

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

@jwrosewell
Copy link

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

@SebastianZimmeck SebastianZimmeck removed agenda+ Request to add this issue to the agenda of our next telcon or F2F agenda+F2F Request to add this issue or PR to the agenda for our upcoming F2F. labels May 19, 2021
@chelseakomlo
Copy link

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

@michael-oneill
Copy link

michael-oneill commented Jul 13, 2021

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

@SebastianZimmeck SebastianZimmeck added the agenda+ Request to add this issue to the agenda of our next telcon or F2F label Oct 13, 2022
@SebastianZimmeck
Copy link
Member Author

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

@kasnder
Copy link

kasnder commented Oct 25, 2022

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?

@SebastianZimmeck
Copy link
Member Author

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

@SebastianZimmeck SebastianZimmeck removed the agenda+ Request to add this issue to the agenda of our next telcon or F2F label Oct 28, 2022
@SebastianZimmeck SebastianZimmeck added the agenda+ Request to add this issue to the agenda of our next telcon or F2F label Jan 19, 2023
@martinthomson
Copy link

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

@martinthomson martinthomson removed the agenda+ Request to add this issue to the agenda of our next telcon or F2F label Jan 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet