GDPR Sets proposal

[rblanck]

If I understand correctly, this proposal goes into this proposal's direction (#86), although it frames it differently.
Important: Naming is entirely free to choose. Alternative “associated sets extension” would also be acceptable.

First Party Sets GDPR Proposal

Problem statement:

The original proposal to structure first-party sets by entity ownership has been changed in the current draft for FPS. There are now different sub-sets. For publishers who have the same ownership (according to GDPR, also same controller) of several domains, there is now an associated set. These sets are limited to three. In contrast to the previous proposal, domains that do not have the same ownership (different controllers according to GDPR) can also be merged into one FPS in associated sets.

Example 1:
website-a.com (company A) website-b.com (company B) website-c.com (company C) is allowed under FPS.
Example 2:
website-a.com (company A) website-b.com (company A) website-c.com (company A) website-d.com (Company A) is NOT allowed under FPS - maximum three.

In example 2, it would be the same controller under GDPR. It's the same data under the same entity and the same legal framework (GDPR). So if the data collection with different domains but with the same controllership is a reliable consent of the specific controller regulated by GDPR law and authorities, it should not be regulated by the browser.
Interestingly, in the other three proposed subsets beside “associated subset”, there are also ownership requirements: top-level domain differences, domains on the public-suffix list, and service subsets with CDN domains. So here, ownership is also checked. But this ownership check is supposed to be based on a public submission process, domain access, and other processes that certainly do not stand up to a KYC check (Know your customer ). However, many reliable standard processes today in the industry are based on this idea.

In summary, subsets are proposed that do not take GDPR into account on the one hand (associated) and, at the same time, others that are based on ownership via processes that are easy to abuse and are not subject to audited control.

Idea: GDPR subsets

A new GDPR subset relies on reliable proof of ownership and, therefore, on the same controllership. But on the other hand, let authorities decide and enforce what reliable consent is to bind data from different domains altogether for the same data controller entity.
Use an independent European Trustee Org (like SSL Cert companies before) to make the proof of ownership process, which must certify in dedicated periods ownership. This process has to be paid for by the demanding parties (publishers) and should give the org a business case to be reliant and long-term steady. There should be trust in this Trustee Org, so it must be carefully built or pitched by the industry and balanced regarding control by browsers, publishers, and other industry stakeholders.

Known Critics:

There are known critics of the SSL Cert process.
In financial and other business industries, the whole process of KYC is built on proof processes of ownership. So perhaps an SSL Cert process is not the right technical idea. Still, with technology, there should be a way to make trusted industry processes inside a regulated environment like the EEA or EU. In case of abuse, there could be a penalty process to revoke proof of ownership by the Trustee Org as well.
In any case such a process has to continously be improved and developed, as abuse can't be ruled out in any case. Additionally - to mitigate eventual abuse - there can be strong enforcement be the Trustee (ownership abuse) or Authorities (consent abuse)

[krgovind]

Thanks for opening this issue, @rblanck. We are reviewing internally and evaluating the best way to provide feedback and insights on this suggestion. We also appreciate your acknowledging possible challenges and so we look forward to working with you on this.

[helenyc]

Hi @rblanck - thanks for your proposal. We’ve been in active discussion about this over the last several weeks across our Product, Engineering, Partnerships, and Legal teams. We appreciate your proposal submission, but we’d like to outline the reasons why we will not pursue this proposal in the current design of first-party sets.

We want to respond to the 3 areas that we think you are raising here - the issues around common ownership; the issues with the numeric limit; and the issues regarding enforcement. If we understood the feedback correctly, the proposal attempts to approach those three issues through the lens of GDPR.

The issues around common ownership:
As Chrome recently shared in a first-party sets blog post, we received feedback regarding the "common ownership" requirement that a definition of FPS which focused solely on corporate ownership would give larger companies a greater ability to pool data across a wide range of domains and user-facing services, compared to smaller companies. Since our goal is to build the Privacy Sandbox for the ecosystem as a whole, we took this feedback seriously and prioritized a solution that was more inclusive.

From our understanding of your feedback, you find that the combination of moving away from an ownership-based proposal and the addition of a numeric limit (we’ll discuss this further below) to “not take GDPR into account.”

Google takes seriously the Applicable Data Protection Legislation, in addition to other legal obligations it has entered into. However, the FPS proposal is not meant to be a reflection of or proxy for privacy regulation. Instead, the FPS proposal reflects how the browser may best act to reflect the privacy interests of its users. This may sometimes go beyond or be more restrictive than privacy regulation.

We acknowledge that GDPR, and its definition of “controllership”, may be more approachable and understood by those based in the European Union. From that perspective, a framework that takes into account GDPR-derived definitions could have merit. However, the Privacy Sandbox is a global initiative. Many countries operating in North America, LATAM, and APAC and many users based in those regions wouldn’t be familiar with this kind of framework. As we work to build at scale, we need to build for a global web ecosystem that supports users equally, regardless of where they are located.

If we go from here and acknowledge that working off a concept of common ownership is not workable for first-party sets, Chrome has to figure out how to create sets that find the right balance between privacy and utility, while also implementing technical controls that allow site primaries to create valid sets. This brings us to the numeric limit.

The issue around the numeric limit of 3:
Chrome has been actively seeking feedback regarding which use cases would be challenged by the numeric limit of 3. We have heard from dozens of stakeholders about both the preferred number they would like to have in the set as well as the use cases that they are trying to uphold. We recognize that there is a tradeoff between privacy and utility and we are trying to strike the right balance.

Our goal here is to continue to support use cases. For the "associated" subset, we proposed a numeric limit of three domains as an objective, technical mechanism to prevent widespread tracking abuse. Absent an impartial method of assessing user understanding, we felt that a numeric limit was most appropriate to uphold protections against potential widespread and passive tracking. For organizations that have multiple domains (beyond three) that could qualify for the “associated” subset, we encourage these organizations to identify specific use cases so Chrome can consider how to best minimize user-facing breakage post-third-party cookie deprecation.

The issue regarding enforcement:
With regard to “processes that are easy to abuse and are not subject to audited control,” we want to highlight that we’ve developed several abuse mitigation measures that help ensure the valid creation of first-party sets. This includes the well-known file check -- only an administrator of the domain may modify the well-known file, which means that only an authorized administrator of the domain could include the domain in a set or remove it from a set.

Our goal is to create a mechanism that is accessible to developers and transparent to users and the larger web ecosystem. Key to this goal is creating a scalable and objective system. This is why our proposal leans heavily into technical validation checks, which brings us back to why we proposed a numeric limit for the associated subset. Chrome’s goal is to mitigate widespread tracking abuse for its users. Using a numeric limit is objective and technically enforceable.

There are alternative enforcement mechanisms we explored. For example, we initially evaluated alternative designs like signed assertions and set discovery instead of static lists, using EV certificate information for dynamic verification of sets, and self-attestation and technical enforcement.

Additionally, while we had initially proposed that an independent enforcement entity take on the role of investigating and enforcing compliance with policy, in the current ecosystem, finding an independent enforcement entity with the appropriate expertise to carry out these responsibilities in an impartial manner was challenging. This would also apply to finding an enforcement entity for a GDPR based system that is able to get strong support on the web. Instead, we strived to pivot to a policy that could be technically enforced to ensure that implementation could be applied consistently and objectively.

We are hopeful that relying on a consistent and objective policy will help us with our goals of cross-browser adoption. Chrome is keen to promote interoperability with other browsers to maintain the health of the web platform. Since other browsers like Safari, Firefox, and Edge currently use the Storage Access API (SAA) to facilitate active cookie requests, we opted for leveraging SAA in Chrome not only to help address key feedback we received, but also to support web interoperability. (To provide more flexibility for developers and address known limitations of SAA, we have also proposed the requestStorageAccessForOrigin API.)

Thank you for bringing your proposal forward, and providing the opportunity for us to reflect on the updates we made to the FPS proposal. We hope our response provides clarity into our thoughts regarding the GDPR Sets proposal.

[jwrosewell]

Google have referenced this issue in the Q1 2023 report.

See GDPR Validated Sets PR for a similar proposal which Google responded to in the Q4 2022 report rather than on GitHub.

Would @rblanck, and/or others, be interested in arranging a meeting to discuss the two GDPR based proposals and where they might align and debating how Google's concerns can be overcome? As the issues are mainly non technical the Improving Web Advertising Business Group chaired by @dmarti might be a good forum.