Expand Set Eligibility Beyond a Single Organization

[brodrigu]

In Proposed Work Item: First-Party Sets @kgrovind discussed the following concern regarding a possible security risk if first parties decide to leverage a shared domain as a result of 3rd party cookie elimination and the resulting side-effects of moving a site between eTLD+1s:

Essentially, forcing all sites to move to subdomains of their parent/owner domains would have, in my example, manifested as flickr.com moving to flickr.yahoo.com, then flickr.verizon.com and subsequently to flickr.smugmug.com. This would train users to stop paying attention to the registrable domain, and focus only on the subdomain. Thus, it would make them susceptible to entering their credentials on mybank.evil.com, because mybank is in the subdomain, and lead the user to think “perhaps mybank was recently acquired by evil.com”?

First party sets provides a good solution to this concern by allowing first parties who might be leveraging some cross-domain functionality to continue to do so without migrating to a shared eTLD+1 domain.

However, the initial proposal seems to suggest shared ownership is a prerequisite for joining a first party set.

First parties who do not share a common owner are equally, if not more incentivized to join together onto a shared eTLD+1 once 3rd party cookies are removed. This has been referred to as the publisher co-op model. Other examples of this might be bankofamerica.com migrating to bankofamerica.zelle.com when managing bank transfers or wapo.com redirecting to wapo.medium.com for access to differentiated monetization.

If we wish to truly offer a workable alternative to eTLD+1 consolidation, and prevent user domain apathy, taking a more pragmatic approach and relaxing the shared owner requirement is needed.

Even with an expanded set of qualified first parties, First Party Sets still provide elevated accountability for websites and their partners, as well as a mechanism for user agents to disqualify sets that don’t meet the standard for conduct within a set.

[othermaciej]

Allowing sites the are unrelated and independently operated to be part of the same First Party Set essentially creates a cross-site super cookie and negates the advantage of dropping third party cookies. eTLD+1 consolidation at least has the advantage of being clear and obvious to the user.

[johannhof]

(running some triage on old issues on behalf of @krgovind)

First-Party Sets is intended as a mechanism for browsers to use in the design of privacy protections and Web APIs in a way that reduces breakage for entities with a common owner/data controller (#56) that are spread across multiple eTLD+1s. It does not aim to solve the risk of eTLD+1 consolidation in its entirety, as it's not a panacea for all side effects from blocking 3rd party cookies. Not having a common owner and/or data controller would significantly complicate both the technical as well as the policy aspects of this proposal and increase the risk of attacks as outlined by Maciej above.

Without having looked into the technical details of the use cases described above, you may find that other API proposals such as CHIPS or FedCM help solve them without consolidating onto a shared eTLD+1.

[npdoty]

Did the answer to this issue change? In February it was closed as not in line with the goals of the proposal, but as of July it seems that domains operated by different companies are now allowed to belong to the same set and have the browser combine data between their domains. Is that correct?

As Maciej pointed out above (February 2021), that would create a cross-site super cookie and negate the advantage of dropping third party cookies.

[johannhof]

I guess the answer is that the proposal got a lot more complicated, as mentioned above, though I hope that we're actually decreasing the risk of attack vs. the previous proposal.

For most proposed subsets, common ownership is still required as a baseline policy. The associated subset is where it's currently not listed as a requirement, but which instead has new strict requirements that in my personal opinion go beyond common ownership in protecting user agency as they do not ask users to know about corporate ownership and instead require clear association signals, in addition to a hard limit on how many sites can be in the subset. This is based on feedback from Privacy CG and others.

We've additionally worked on ensuring that browsers don't have to support the associated subset (or any other subset), they may prompt users or apply heuristics (as some already do) to ensure compatibility instead.

[npdoty]

The previous proposal was common owner and common controller and common group identity easily observable and a common privacy policy visible to users and numeric limits, so I'm not sure how removing requirements (no longer limited to a single organization, or a common privacy policy, or a common data controller, and observability could just be on an about page somewhere) goes further in protecting user agency. What are the new strict requirements?

[johannhof]

@npdoty the previous proposal did not enforce numeric limits, there were discussions (#29) but there was also clear feedback that through things like ccTLDs, CDNs, etc. it was difficult to arrive on any reasonable number. Subsets allows us to enact a low numeric limit for "associated" and other strict requirements for the remaining subsets (as listed in the README).