Re: [w3ctag/design-reviews] First-Party Sets (#342)

Thanks for the feedback @rhiaro !

> * Can you tell us more about the use cases for a single party with multiple domains placing those domains into different sets?

We don't have specific use-cases in mind; but this is something we have been recommending to organizations that own a very large portfolio of domains, many of which maybe be unrelated from the user's perspective (e.g. one set of domains that's related to fast food services, and another set related to insurance products). Our [recommendation](https://github.com/privacycg/first-party-sets/blob/main/ua_policy_proposal.md#responsibilities-of-the-site-author) is that entities "strive to create sets consistent with user understanding and expectations."; and in some cases that may lead to an entity splitting up their domains into multiple disjoint sets.

> * We agree it's useful to mandate a particular UI surface to make sure web users are aware of all parties in common in a set as this gives sites less opportunity to potentially mislead people. What are your expectations around normative language regarding the UI? What are your thoughts about how it would be possible to mandate and test for in the specification?

Could you clarify whether this is referring to the user agent's [UI Treatment](https://github.com/privacycg/first-party-sets#ui-treatment); or the [recommendation](https://github.com/privacycg/first-party-sets/blob/main/ua_policy_proposal.md#responsibilities-of-independent-enforcement-entity) (footnote 2) in the UA Policy document that site authors surface group identity to users via some UI surface in the content area?

If the former; since the UI surface does not affect how developers write code around this feature, it's not clear to me that it needs to be specified.  If the TAG's feedback is to include normative language around browser UI, we can consider either (a) using SHOULD to indicate the goals for the UI (e.g. "User agents SHOULD surface First-Party Sets information to users on an appropriate UI surface in order to aid their understanding of how their browsing data may be joined across domains"); or (b) using MAY to recommend possible surfaces (e.g. "User agents MAY surface a website's FPS information on UI surfaces related to site identity or information. Examples of such surfaces are the Origin Info Bubble, and Settings page in the Chrome browser."). 

> * We are concerned about the international applicability and future-proof-ness of language like "parent company" with respect to the owner/controller of sites/domains. Have you thought about how this would work in the face of different corporate structures?

The phrase "parent company" is referenced in footnote#2 in [this section](https://github.com/privacycg/first-party-sets/blob/main/ua_policy_proposal.md#responsibilities-of-independent-enforcement-entity). It is used in a bulleted list of items indicating that "it is the site author's responsibility to ensure that at least one of the following is true". We list many possible scenarios that could achieve the high-level objective of surfacing either common group identity, or indicate same-party affiliation to users. As we encounter additional scenarios, we are able to expand this list, as long as it is consistent with the high-level objective.

>   "Random spot checks" by the enforcement entity may not be sufficient when there is the potential for huge amounts of data leakage which it would not be possible to claw back if it was shared erroneously (data leaks by other means happen all the time, but it doesn't mean we want to add tools that let the UA facilitate them). 

The intention for the random spot checks vs. manual checking of every single submission was to balance preventing abuse and scalability. As footnote #1 in [this section](https://github.com/privacycg/first-party-sets/blob/main/ua_policy_proposal.md#responsibilities-of-independent-enforcement-entity) calls out _"...an organization would need to publicly declare that they own and control the sites listed in their proposed set. ... Organizations could be held responsible for fraud or misrepresentation either in direct legal action from users or by regulators that enforce either privacy or consumer protection laws on behalf of users."_

>   * Related is the worry about web users actually recognising the names of the controlling entities, or with sibling entities, when in practice they are only used to interacting with one or two particular subsidiary brands. It may be that presenting this information to a person visiting the site is functionally meaningless - they aren't really giving informed consent to data being shared within the set.

One way to address this could be to highlight/bubble up the domains/brands that the user has previously interacted with.

> There is some language about pop-ups as a potential solution, which we think would be an unfortunate direction to go in.

I believe this is a reference to footnote#2 [here](https://github.com/privacycg/first-party-sets/blob/main/ua_policy_proposal.md#responsibilities-of-independent-enforcement-entity) which lists possible UX patterns that a site could use to denote group identity/affiliation to the user in its content area; but not a specific recommendation to use pop-ups. For example, if a website would like to list several sibling domains, it may provide provide a UI affordance that opens a pop-up menu listing all the sibling domains. 

Perhaps the concern here was around pop-up windows? (Our intention was to say "pop-up menu")

> In general, we remain concerned about the dependencies on things that don't fit as part of a web standard.

I think this is referring to the fact that the proposal depends on a UA Policy? I believe there is precedence for this in other parts of the web platform. A couple of examples that come to mind:
* The definition of site / registrable domain (which cookies, and other parts of the web platform use extensively) depends on the Public Suffix List which has an [acceptance process](https://github.com/publicsuffix/list/wiki/Guidelines), and alludes to the role that user agents play (_"Browsers do what browsers do..."_).
*  Browsers perform TLS certificate validation before connecting to https:// URLs, which relies on the the Web PKI infrastructure that is governed by a complex set of rules developed by the [CA/Browser Forum](https://cabforum.org/).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/342#issuecomment-973309373