Domain to Business Relationship

[jackfrankland]

I'm opening up an issue here to carry on a discussion from the proposal thread.

My initial post (please also see privacycg/proposals#11 for a related proposal):

Instead of defining a relationship between domains, I believe a better solution is to define the relationship between a domain and the business that owns it. A business may own multiple domains, and therefore relationships between domains can be inferred, potentially serving the same goals as first party sets. In just this regard I believe it has the following advantages:

• There is no need for a possibly arbitrary owner domain.
• It's not necessary to make requests to two domains to confirm the relationship.
• I believe there is value in knowing the business/entity that has access to the user's data for a domain, and that this relationship is a more easily defined thing that user agents can freely use to determine differing behaviour. This is in contrast to something that arguably has less meaning/value by itself when it depends on dynamic UA policy for its definition. In order for first party sets to be most successful, it may require consistency of behaviour between user agents, which could be difficult.

Latest reply from @krgovind:

Our specification of FPS as a domain-to-domains relationship is mostly an artifact of needing to find a domain to host the central/unified manifest file on. :) As I mentioned in my previous response, having a single source of truth makes verification and deployment easier. Do you envision a way that we can maintain a central manifest file using a domain-to-business relationship?

---

Firstly thanks for the reply :)

I don't believe that the user agent can treat the owner domain's manifest as a reliable single source of truth. At the time of verifying that two domains are within a First-Party Set, it should look up the manifests for both domains, and the owner domain if neither are the owner. If there is not consistency between the manifests, then it should be rejected, making this solution just as prone to periods of being out-of-sync as the domain to business relationship solution.

Do you envision a way that we can maintain a central manifest file using a domain-to-business relationship?

No I can't I'm afraid. I see it that both domain's business ownership would have to match at the time of verification, so it would not be possible to get the truth from a single source. Is there another benefit to having a central manifest that I'm not seeing?

[samuelweiler]

This seems to address a different problem without enabling the automated processing that FPS is trying to enable.

[jackfrankland]

My understanding of the main driver for this proposal is for the user agent to be able to choose not to impose certain privacy restrictions between two domains if they are considered the same party.

In order to do this, I imagine that the user agent will determine if two domains are part of the same first party set at the moment the domains interact with each other e.g. sub-resource request; top-level navigation from one domain to another.

I believe the user agent could perform the same logic by looking up the owning entity for each domain instead. If they match, it can decide not to impose privacy restrictions.

I see that this would not enable the automated discovery of a set of domains that should be considered same party, but I'm not aware of any other defined benefit to the user agent having access to that information directly. Perhaps I'm missing something here?

[johannhof]

@krgovind and I have been looking at this issue and think we should close it. I think your approach has some advantages as you outlined in your initial comment, but it's not really compatible with our current idea of FPS:

• A particular organization can form more than one FPS because of its product structure or for security reasons, so it is best not to assume that all domains owned by the same business are intended to be treated as one collection from a user privacy or security perspective.
• This proposal has moved away from a discovery/signed assertions based design to serving a static list instead. This also solves the problem of having to make two requests to confirm the relationship you mention.
• There's also Organisation name for the owner #40 which suggests adding business/organization information to the JSON, which would help with the "knowing the business/entity" part.