Exploring the potential for abuse

[johnwilander]

Thanks for writing this up, Mike!

Apple WebKit has some thoughts on the potential for abuse.

Affiliations Unclear to Users

While some affiliated domain names may be publicly known as owned by the same organization, there are plenty of cases where most users have no idea about who owns what.

Incentives to Form Sets

We believe a feature like First Party Sets will cause new consortiums to be formed for the sole purpose of cross-site data sharing since third-party data restrictions are relaxed within the set. Combine that with affiliations being unclear to users and you have a situation where users are effectively tracked across sites/contexts that they think are distinct.

Personalized Sets

With the current proposal, servers could serve personalized sets to enable specific tracking. Say ad-tech1.example, ad-tech2.example, and ad-tech3.example compete for the right to track the user across three news websites. They could bid for those rights and then the winner makes sure that the user's browser gets a First Party Set with them inside. In addition, ad-tech2.example could be a custom domain registered for this particular bidding and be synced with huge-ad-tech.example.

It may even be possible to personalize sets in a way to make them cross-site tracking identities themselves.

We need to make sure that all users get served the same First Party Set for a particular website.

Some Ideas for Mitigations

Things to consider:

• Would this still be useful if reduced to only address the country-specific eTLD issue?
• Would more of a static list work, similar to the Public Suffix List?
• Would some kind of opt-in model work where a single sign-on domain asks the user for permission to relax third-party data restrictions under a set of sites? The right to ask for such permission could be backed by all parties publishing their affiliation like in the proposal.

[colinclerk]

@johnwilander what if all domains in the first party set could Set-Cookie on any domain in the first party set?

Relax the restriction in Set-Cookie's Domain directive that it must be the current host or its parents, and update it to first party set or their parents.

Would this make it unviable for advertisers to form sets? I think it would make it so every participant can manage the cookies of other participants.

[johnwilander]

@johnwilander what if all domains in the first party set could Set-Cookie on any domain in the first party set?

Relax the restriction in Set-Cookie's Domain directive that it must be the current host or its parents, and update it to first party set or their parents.

Would this make it unviable for advertisers to form sets? I think it would make it so every participant can manage the cookies of other participants.

I don't understand this suggestion. It sounds worse to me, letting servers set cookies cross-site. Can you explain with an example how this would resolve or mitigate the three issues I brought up – affiliations unclear to users, incentives to form sets, and personalized sets? Thanks!

[colinclerk]

Here's a try, but let me know if more clarity would be helpful.

My high level thinking is that it might be possible to relax data-restrictions so much within the first party set (FPS), that it would pose a significant security risk for adtech to form sets.

The particular relaxation I'm recommending is that a server should be able to Set-Cookie for any origin listed in the FPS, by passing it to the Domain directive.

To be clear, this does nothing to resolve unclear affiliations to users.

The goal, though, is that it removes the incentive to form sets. Note Mike's restriction that the FPS must match across each origin included in the FPS. That means if an advertiser forms a set with multiple unaffiliated parties, those unaffiliated parties would be able to set cookies for each other:

adtech.example
FPS: participant1.example, participant2.example, adtech.example

participant1.example
FPS: participant1.example, participant2.example, adtech.example

participant2.example
FPS: participant1.example, participant2.example, adtech.example

In this scenario, participant1.example, participant2.example, and adtech.example would all be able to set cookies for each other, which sounds like a security nightmare. Using the functionality is only viable with coordinated trusted parties:

youtube.com
FPS: youtube.com, google.com

google.com
FPS: youtube.com, google.com

In this scenario, it's easier than ever to synchronize logins across all services.

Regarding personalized sets: I believe this concern is also resolved by removing the incentive to form sets? I might not understand this point completely, given other efforts that would limit the ability for ad-tech2.example to synchronize with huge-ad-tech.example. Specifically, I think this is the same problem as huge-ad-tech.example hosting a subdomain within the first party.

Additional notes:
I believe this approach would require FPS origins to be public suffix+1.

It might be compelling to create a FPS-Cookie header that makes it possible to send all cookies in the FPS set to a particular server. This should make it even easier to coordinate across multiple first-party domains, and further disincentivize adding an unaffiliated parties to the set.

Ultimately, I think allowing Set-Cookie on FPS origins would feel similar to Set-Cookie being allowed on parent domains.

[johnwilander]

Here's a try, but let me know if more clarity would be helpful.

My high level thinking is that it might be possible to relax data-restrictions so much within the first party set (FPS), that it would pose a significant security risk for adtech to form sets.

In my experience, tracker domains aren't that concerned over security. Fraud, yes, but they do a bunch of cookie syncing, telling each other data and IDs.

So I assume what you're saying is that the legitimate parties/domains will not want to risk Ad Tech getting access to their cookies.

The particular relaxation I'm recommending is that a server should be able to Set-Cookie for any origin listed in the FPS, by passing it to the Domain directive.

Just setting cookies is bad of course (session fixation, cookie overwrites) but it is already done through third-party tracker JavaScript setting first-party cookies through document.cookie. It's the reading of cross-site cookies that I think the participating parties would be most worried about.

To be clear, this does nothing to resolve unclear affiliations to users.

The goal, though, is that it removes the incentive to form sets. Note Mike's restriction that the FPS must match across each origin included in the FPS. That means if an advertiser forms a set with multiple unaffiliated parties, those unaffiliated parties would be able to set cookies for each other:

adtech.example
FPS: participant1.example, participant2.example, adtech.example

participant1.example
FPS: participant1.example, participant2.example, adtech.example

participant2.example
FPS: participant1.example, participant2.example, adtech.example

In this scenario, participant1.example, participant2.example, and adtech.example would all be able to set cookies for each other, which sounds like a security nightmare. Using the functionality is only viable with coordinated trusted parties:

youtube.com
FPS: youtube.com, google.com

google.com
FPS: youtube.com, google.com

In this scenario, it's easier than ever to synchronize logins across all services.

Regarding personalized sets: I believe this concern is also resolved by removing the incentive to form sets? I might not understand this point completely, given other efforts that would limit the ability for ad-tech2.example to synchronize with huge-ad-tech.example. Specifically, I think this is the same problem as huge-ad-tech.example hosting a subdomain within the first party.

Additional notes:
I believe this approach would require FPS origins to be public suffix+1.

It might be compelling to create a FPS-Cookie header that makes it possible to send all cookies in the FPS set to a particular server. This should make it even easier to coordinate across multiple first-party domains, and further disincentivize adding an unaffiliated parties to the set.

Ultimately, I think allowing Set-Cookie on FPS origins would feel similar to Set-Cookie being allowed on parent domains.

[krgovind]

@johnwilander - Thanks for reviewing Mike's original proposal! FYI, we now have a revised version of the explainer which should address some of your concerns.

Affiliations Unclear to Users

We are currently working with UX researchers and experts to come up with potential UI treatment ideas. We will loop back on this issue when we have some ideas.

Incentives to Form Sets

We now have some ideas for technical mitigations.

Personalized Sets

See the discussion here.

Some Ideas for Mitigations
Things to consider:

• Would this still be useful if reduced to only address the country-specific eTLD issue?

The use cases that we are currently considering extend beyond country-specific variants, so we’d like to find a reasonable solution that works for them too.

• Would more of a static list work, similar to the Public Suffix List?

Please see the section Using a Static List.

• Would some kind of opt-in model work where a single sign-on domain asks the user for permission to relax third-party data restrictions under a set of sites? The right to ask for such permission could be backed by all parties publishing their affiliation like in the proposal.

Is the single sign-on domain in this case truly “first-party” to the set of sites, or is it a federated login provider? Note that we do not intend for this proposal to be used as a solution for federated login. If the single sign-on domain is indeed first-party to the set of sites, then this proposal would apply, but we envision its application to go beyond seamless login. Regarding use of a permission prompt, it’s not clear that a permissions-driven model would actually result in users making informed choices. Our experiences teach us that permission prompts should make sense to the user in the context of what they’re trying to do (e.g. requesting access to location when loading a Maps application, requesting access to Files for email attachments); but showing a First-Party Set prompt on page load does not fall in that category. Ideally, we would like to find a solution where the browser can enforce against abuse to a large extent and allow users to rely on their safety and privacy being preserved by default. Additionally, UI treatment could act as an informational surface for the discerning user.

[krgovind]

@johnwilander FYI, I've now added a section about UI treatment.

[johnwilander]

Thanks for your reply and sorry for my delay in following up.

@johnwilander - Thanks for reviewing Mike's original proposal! FYI, we now have a revised version of the explainer which should address some of your concerns.

Affiliations Unclear to Users

We are currently working with UX researchers and experts to come up with potential UI treatment ideas. We will loop back on this issue when we have some ideas.

Thanks.

Incentives to Form Sets

We now have some ideas for technical mitigations.

From that section: "Thus these technical measures are only a first-pass filter on unacceptable sets. The browser still must apply interventions to unacceptable sets. This may be done by detecting and maintaining a list of blocked first-party owners, as in Google Safe Browsing."

The essence of this is changing from my (vague) proposal of a list of good entries to a list of after-the-fact bad entries.

Will this scale? Will Google take on the responsibility such as with Google Safe Browsing?

Will it be global? If so, how do we find an entity to take care of regions where Google doesn't operate?

In my experience, Safe Browsing covers malicious endpoints that are purely malicious, not sites that are partially, temporarily, or intermittently malicious, for instance cases of malvertising or defacing.

Say we come across a first-party set which includes the two unaffiliated adtech.example and major-publisher.example, perhaps only in a specific region or for specific users such as logged in users, not logged in users, users with tracking prevention enabled, etc. Will both those domains be blocked from participating in any first-party sets or only in this specific first-party set? For how long? If major-publisher.example claims they were tricked into the set, will someone investigate whether they were actually in on the scam or not?

If we are going to maintain lists, I still think a before-the-fact list of good entries is safer and involves fewer hard decisions down the road.

Personalized Sets

See the discussion here.

Some Ideas for Mitigations
Things to consider:

• Would this still be useful if reduced to only address the country-specific eTLD issue?

The use cases that we are currently considering extend beyond country-specific variants, so we’d like to find a reasonable solution that works for them too.

Would it be possible to make it optional to support sets wider than country-specific eTLDs? That way, the format can be explicit about it and browsers can decide what to support.

• Would more of a static list work, similar to the Public Suffix List?

Please see the section Using a Static List.

Could a combination work? A static list for common, major players would yield:

• Transparency for some of the most prevalent domains out there,
• Performance gains since nothing needs to be loaded and checked at runtime for these major players, and
• The opportunity for browsers to implement different behavior for static and dynamic entries, such as extra validation for the dynamic ones.

• Would some kind of opt-in model work where a single sign-on domain asks the user for permission to relax third-party data restrictions under a set of sites? The right to ask for such permission could be backed by all parties publishing their affiliation like in the proposal.

Is the single sign-on domain in this case truly “first-party” to the set of sites, or is it a federated login provider? Note that we do not intend for this proposal to be used as a solution for federated login. If the single sign-on domain is indeed first-party to the set of sites, then this proposal would apply, but we envision its application to go beyond seamless login. Regarding use of a permission prompt, it’s not clear that a permissions-driven model would actually result in users making informed choices. Our experiences teach us that permission prompts should make sense to the user in the context of what they’re trying to do (e.g. requesting access to location when loading a Maps application, requesting access to Files for email attachments); but showing a First-Party Set prompt on page load does not fall in that category. Ideally, we would like to find a solution where the browser can enforce against abuse to a large extent and allow users to rely on their safety and privacy being preserved by default. Additionally, UI treatment could act as an informational surface for the discerning user.

I was thinking of the single sign-on case and actually the kind of in-context prompt you refer to. Right when the user logs in, the current website would be able to ask for the permission to make use of its first-party set. That would allow single sign-on across a first-party set but only after a login and an explicit user opt in.

[krgovind]

@johnwilander Apologies for the long overdue response. Based on feedback from you and @ehsan; and further studying the limits of our anti-abuse enforcement in the previous version of the design, we have significantly re-designed this proposal to use "signed assertions" which require prior examination and approval of a First-Party Set, which a site owner may then host at the designated .well-known location. In addition, we now also allow for UAs to use static lists if they prefer.

Note that this proposal only defines the technical framework for First-Party Sets, which we hope will be standardized across browsers. There is a separate "policy" component that we have left up to the UAs to define and enforce before signing/accepting a set.

[deshpa]

Hi,

Thanks for the proposal and the update. I'm looking for clarification on some aspects of the proposal:

1. There is a comment in the explainer: "We must ensure this state does not introduce a cross-site tracking vector for two sites not in the same first-party set."
   Can a tracker site be included in first party sets for sites that are owned by its parent company? e.g. Consider a hypothetical case where a parent company (MyCompany, Inc) owns myCompanySiteA.com, myCompanySiteA.in, myCompanySiteB.co.uk, and myCompanyTracker.com.
   a. MyCompany would like to share data between myCompanySiteA.com, myCompanySiteA.in, myCompanySiteB.co.uk, and myCompanyTracker.com for tracking/measurement purposes. Will it be possible to declare these four sites / domains in the same First party set?
   b. Will AnotherCompany, Inc, which runs anothercompany.com, owned by a completely different entity, with no corporate relation to MyCompany, Inc. be permitted to declare myCompanyTracker.com in its first party set?

2. The explainer talks about extensions to SameSite=Lax (SameSite=FirstPartySetStrict and SameSite=FirstPartySetLax) - is this in the plan for Chrome, and for other browsers too?

3. Is there a limit on number of entries in a First Party Set?

Also, please let me know if it is better to open this as a new issue rather than as a followup to this one.

Thank you.
Ketan

[krgovind]

Hi Ketan,

Question#1 probes into what we term "UA policy" in the explainer. At this point, we are confident about the technical framework for First-Party Sets (FPS), but expect that the answer to what constitutes acceptable sets will need to evolve with inputs from experts and the community. However, I can try and answer the question based on my interpretation of Chrome's proposed privacy model. [Disclaimer: IANAL, but a humble engineer]

Can a tracker site be included in first party sets for sites that are owned by its parent company? e.g. Consider a hypothetical case where a parent company (MyCompany, Inc) owns myCompanySiteA.com, myCompanySiteA.in, myCompanySiteB.co.uk, and myCompanyTracker.com.
a. MyCompany would like to share data between myCompanySiteA.com, myCompanySiteA.in, myCompanySiteB.co.uk, and myCompanyTracker.com for tracking/measurement purposes. Will it be possible to declare these four sites / domains in the same First party set?

Yes. Since myCompanyTracker.com is owned by the same company as the other sites, I think it's reasonable to declare these four sites in the same FPS.

b. Will AnotherCompany, Inc, which runs anothercompany.com, owned by a completely different entity, with no corporate relation to MyCompany, Inc. be permitted to declare myCompanyTracker.com in its first party set?

No. Unrelated sites cannot be in the same FPS. Also, not allowing the same site, myCompanyTracker.com, to appear in more than one FPS may be a reasonable clause to include in the UA policy.

2. The explainer talks about extensions to SameSite=Lax (SameSite=FirstPartySetStrict and SameSite=FirstPartySetLax) - is this in the plan for Chrome, and for other browsers too?

We are currently working out the exact shape and semantics of the cookie attribute, but yes, it is on Chrome's plan to ship a FPS-related attribute for cookies. We have not yet received positive signals from other browsers on the First-Party Sets proposal, but hope to re-engage.

3. Is there a limit on number of entries in a First Party Set?

We did propose a size limit in a previous iteration as mitigation for abuse. However, with the latest revision, we defer to the UA policy on imposing reasonable limits.

[krgovind]

Thank you for providing feedback. We believe this is now captured in the explainer as indicated in my previous responses. Please feel free to reopen if there are any outstanding concerns.