Site Groups / First Party Sets v2

[privacycg]

Site Groups / First Party Sets v2

[TanviHacks]

Hi @pbannist! We see that this proposal hasn't been touched in a while - is there anything more to discuss here or should we close this out?

[johnwilander]

Hi Paul!

The owner domain has access to read/write all data from across the site group

My understanding of this is that it would violate the same-origin policy. Is that accurate? Back when we (Apple WebKit) originally proposed this kind of feature we called it "Affiliated Domains" but later we unfortunately referred to it as "same-origin policy v2" to entice people (link to the email). That got people in W3C WebAppSec worried that we we're proposing a relaxation of the same-origin policy which we were not. Maybe things have changed since, but I'd be surprised if there was any appetite for such cross-site access to website data.

But it may be that you're saying the owner domain would have access to its website data unconditionally when embedded on a site from the site group. That would not violate the same-origin policy.

[pbannist]

Hi John,

Thanks for the feedback! I think I am not articulating myself correctly, so let me try again :) In the existing First Party Sets proposal, a primary application case is described as:

That is, if a.example and b.example are in the same first-party set, the same-origin policy should still prevent https://a.example from accessing https://b.example's IndexedDB databases. However, it may be reasonable to allow a https://b.example iframe within https://a.example to access the https://b.example databases.

From my understanding, that would not violate the same-origin policy. I'm proposing strengthening that, such that:

• If the owner of a given "site group" was a.example, with members b.example and c.example
• An a.example iframe embedded into b.example or c.example could read its IndexedDB database
• But a b.example or c.example iframe embedded into another domain in the site group could not read their IndexedDB data.

This is certainly where my knowledge of privacy/security concerns hits a limit. I think this is a more private/safer solution, since only one domain is given this special privilege. However, maybe there are reasons why this is a bad idea, and can totally remove this from my draft proposal if it's unworkable.

So yes - what you wrote at the bottom is what I mean, just trying to rewrite it so it's more clear.

[johnwilander]

Agreed that would not violate the same-origin policy, only relax third-party storage restrictions. In fact, that makes this particular part of your proposal very close to what we’ve expressed as our main interest in FPS, namely the ability to relax some restrictions for a dedicated single sign-on domain within a set. That relaxation could take many forms, such as wording in permission prompts or long term persistence of a granted permission instead of it being ephemeral or very limited in time.

[jackfrankland]

I'm not sure you can remove the concept of organizational ownership here, as a key aspect of a privacy policy is surely the entity that controls the users' data (the company, business, organization, or whatever you call it).

Is the aim of this proposal to make things more strict and to say, as well as being owned by the same entity, the group of secondary domains must also follow the same conditions of the privacy policy?

[jwrosewell]

A number of people are interested in discussing matters related to first and third party at TPAC. If the current accepted W3C definitions do not reflect people's higher fidelity requirements in practice then it may be better to address those definitions and the implications prior to working on technical changes.

[pbannist]

@jackfrankland thanks for your feedback! I don't think organizational ownership actually matters, and just acts as a construct to bias the proposal towards larger organizations. Two main reasons:

1. As I wrote about in WICG/first-party-sets#14 and WICG/first-party-sets#18, an "organization" is a very nebulous thing that has many different definitions in many places. Geico and Dairy Queen are part of the same organization, but clearly there is no data privacy relationship between the two. So making a shared privacy policy a feature of the proposal seems to help here, but the organizational ownership part doesn't seem additive to me at all.
2. On the reverse side, my company (CafeMedia) acts as an agent for a large number of smaller publishers. We manage their GDPR/CCPA consent and data sharing policies, we manage and enforce contracts with downstream companies that access user data, and we mandate shared privacy policies across sites. So in this case, we can enforce across a large number of domains (that we don't actually own), how all of the data is used and what the user can expect.

One of the reasons I think the "owner domain" within the site group should be the only domain with privileges across the site group, is because it addresses those two points in a way that (in my opinion) makes it easier to drop the organizational requirement. It enforces a singular entity (via one domain) as the "owner" of the group, which is the only entity that gets the special "privileges" of site groups. This can be the same organization as the member domains, or it can be a different organization, but it ensures that only one organization gets the special privileges. Then the shared privacy policy enforces that any domains in the group are acting with the same policies and practices.

[jackfrankland]

@pbannist Thanks a lot for the reply.

I completely agree that the concept of any organizational ownership of a company that operates a site is not additive. Perhaps it's the ambiguity of the term, and it's likely that I have misunderstood how it's been used so far.

I believe what is relevant is the entity that acts as the data controller for the domain a user visits. For dairyqueen.com this seems to be American Dairy Queen Corporation, and for Geico it seems to be Geico Corporation, as listed in their separate privacy policies.

I'm not sure if it's exactly what you're suggesting, but I wanted to raise the point that I don't believe two domains can share the same privacy policy if the data controller for each is different. They may share the same behaviour in regards to how they treat the user's data, but the contract is not the same. Therefore, if two domains are part of the same set/group, they must also be owned/controlled by the same entity.

[gffletch]

From an Identity perspective, what is the expectation for an identity provider that operates as both the IDP for first party relying parties and 3rd party relying parties? The IDP can only be part of a single "group" but still operate as a federated identity provider for other sites but not as a member of other group?

[pbannist]

@gffletch That's a good question and maybe better asked on the main FPS proposal, as your issue would be the same there, and that has more eyes watching it. I do not know the answer.