Trade-offs of FPS vs. requiring sites to unify on a single parent domain

[krgovind]

On the PrivacyCG Work Item proposal discussion (privacycg/proposals/issues/17), feedback from Mozilla indicated that the page URL is the simplest/clearest definition of "first party" to users. I am creating this issue for further discussion on that topic.

@englehardt said:

The definition of “first party” should be clear and understandable to users, web developers, and publishers. The simplest, most natural approach is to enforce a strict one-to-one mapping between first party and registrable domain (i.e., eTLD+1) or a narrower selector (e.g., origin). Using information from the top-level URL is the ideal way to indicate first party because this is already familiar to most users, it is based on a unique identifier for the website owner, it is consistent across web browsers, it is visible in the address bar, and is even visible in a URL to a page that has not yet been visited.

In addition, @annevk said this about the prospect of multi-domain first-parties being forced to move to sub-domains of a common parent domain:

If they indeed did that it seems like it would make it much more transparent to users who they have a relationship with. How is that not a win?

[krgovind]

It might be useful to keep in mind some of the multi-domain first-party situations we know of:

• Brands/apps owned by the same organization. Businesses would prefer to keep these on separate domains for branding reasons and acquisitions/sales. (e.g. sony.com and playstation.com)
• Commerical ccTLD domain variants (e.g. amazon.com and amazon.co.uk)
• .gov.$ccTLD domains (many of these have been placed on the PSL for good reason, but it also has the effect that hundreds of agencies of the same government are treated as separate registrable domains and can't share user data, disabling useful functionality such as shared consent)
• Domains separated for security reasons - e.g. Google's googleusercontent.com and CodePen's cdpn.io. A couple of the security issues that we know of that require this separation (there might be others):
  • Content-sniffing XSS attacks
  • HTTP cookies' default security model being aligned to the registrable domain

[gffletch]

I don't think it's beyond customer's knowledge or understanding that Disney also owns ESPN and ABC. Do we really want to force such organizations to change domains to espn.disneyholding.com?

I'd prefer to see effort put into how browsers can expose the details of the site's privacy policy to users in a user understandable way. This would give the user a better understanding of who they are interacting with and what that site is going to do with their data. This could also expose the "parent" company from the privacy policy. Making that data easy for the user to digest would be super valuable to users as they navigate the web.

[samuelweiler]

I don't think it's beyond customer's knowledge or understanding that Disney also owns ESPN and ABC.

It is within understanding if it is actively called out.

It's not reasonable to assume a priori knowledge of who-owns-what-this-year. (e.g. I didn't know about Disney and ABC until I read this. I still tend to forget that Comcast owns Universal. And if I gave you a list of consumer brands, could you pick out - reliably - which are Proctor and Gamble v. which are Kraft v. which are Kellogg's? I surely couldn't.)

[gffletch]

So in this context, what is considered... "actively called out"? Something on the page that says "A Proctor and Gamble company"?

I will note that with edge proxies it is not that hard to put all brands on a single domain... I just wonder if that is what we really want for the web? I don't know how many consumers really look at the domain. Are there any research studies that show how much users rely on the domain in the URL bar?

For instance... if I enter www.espn.com into the URL bar and then the edge system does a 301 to www.espn.disney.com will the user even notice?

[annevk]

@gffletch say that users don't notice, why would we go through the trouble of FPS? And if they do notice, it seems like it would be a useful deterrent.

[stpeter]

As we (Mozilla) mentioned in the Privacy CG meeting on 2020-08-27, in our view it's not the role of the W3C to "require sites to unify on a single parent domain"; whether that makes sense for any particular organization is not a technical decision but a business decision.

With that said, Internet users have been trained for the past 25+ years to use a registrable domain (i.e., eTLD+1) or a narrower selector (e.g., origin) as the basis for making decisions about who the first party is. We think that broadening the definition of first party now will violate the principle of least user astonishment, with potentially serious implications for user privacy and security.

Although it's true that large consumer-oriented corporations sometimes have multiple brands (and it makes sense for each of those brands to be hosted on its own domain), the point at issue is what is clear to the consumers of those brands.

A few examples:

• a subscriber to Architectural Digest might not expect that a casual reading of an article at GQ or Wired might result in sharing data across those sites (all owned by Condé Nast)
• a person who views a YouTube video might not expect that activity to be linked to their Gmail identity or their Google Searches (all owned by Google)
• a person who posts to IMDb might not expect those posts to be linked to their purchases at Whole Foods or Zappos (all owned by Amazon)

As discussed on the call, there are many wrinkles here, including:

• joint ownership (e.g., what if the corporation controlling a domain is 50/50 owned by two different organizations? what about minority owners in a joint venture? etc.)
• changes of ownership (e.g., large consumer-oriented corporations often divest themselves of brands and it's unrealistic to expect people to track such ownership changes; also what happens to data that was shared under the previous ownership?)
• trademarks and established brands in particular countries (e.g., Mr. Clean products are called Flash in the UK and Ireland because another company called Mr. Clean exists there)

These and other issues could be sources of significant confusion to users and even to the organizations involved. Our view is that it's best not to open this large can of worms.

[tmccombs]

Consider how we use domains at Lucid Software, Inc.

We have a set of domains associated with two web apps (Lucidchart and Lucidspark):

• lucidchart.com -- marketing site for Lucidchart
• lucidspark.com -- marketing site for Lucidspark
• lucid.co -- marketing site for the combined "suite"
• lucid.app -- site that hosts the actual apps

This set of domains is desirable for multiple reasons, including security reasons, SEO and discoverability, branding, etc. And even if using a single domain for all of these were a viable option, migrating to a single domain from our existing setup would require significant effort and coordination, and would likely cause confusion and disruption for existing customers, especially since migrating domains would cause them to lose cookies and local storage on the existing domains (thus losing settings, login tokens, etc.)

We currently rely on third party cookies for several user-facing features, including:

• Indicating if they are logged in on lucid.app on the marketing pages by showing their username in a header
• Redirecting to lucid.app from the root path on lucidchart.com and lucidspark.com if they are already logged in
• Using the user's history of browsing the marketing pages to give recommendations on templates they may wish to use when creating a new document
• Ensuring that users are assigned A/B tests consistently across our multiple domains (as well as being able to correlate behaviors across A/B test cohorts).

The storage access api would technically work for this. However, prompting the user for lucid.app to be able to access storage on lucidchart.com (and vice versa) would not be a great experience for the user.

I understand the reasons for wanting to remove third-party cookies, and the concerns with the First Party Sets proposal. However, if third party cookies go away without something like a FPS, it is unclear to me how to maintain our current feature set without compromising the user's experience.

[johannhof]

I think in this issue we've established some use cases for entities operating separate domains, which helped inspire the subset-based approach to FPS, e.g. the "service" domains that enable separation of content for security reasons, among other things. In our new proposal we've also acknowledged some of the concerns around common ownership as the primary criterion for set membership that were brought up here and in other places, and rely primarily on technical checks and assertions instead.

It seems appropriate to close this now.

[annevk]

Let me just say that I very much doubt the claim that FPS is for security. If security was the concern I'm sure there would be plenty of support to address the scoping issues around cookies.

[cleonombre]

• [ ]

[Maitevt1]

En la discusión de la propuesta de elemento de trabajo de PrivacyCG ( privacycg/proposals/issues/17 ), los comentarios de Mozilla indicaron que la URL de la página es la definición más simple y clara de "propio" para los usuarios. Estoy creando este número para una mayor discusión sobre ese tema.

@englehardt dicho :

La definición de "propio" debe ser clara y comprensible para los usuarios, desarrolladores web y editores. El enfoque más simple y natural es imponer una estricta restricción uno a uno entre el dominio propio y el dominio registrable (es decir, eTLD+1) o un selector más restringido (por ejemplo, origen). El uso de información de la URL de nivel superior es la forma ideal de indicar el origen porque esto ya es familiar para la mayoría de los usuarios, se basa en un identificador único para el propietario del sitio web, es consistente en todos los navegadores web. , es visible en la dirección barra, e incluso es visible en una URL a una página que aún no ha sido visitada.

Además,@annevk dijo esto sobre la perspectiva de que los propietarios de múltiples dominios se ven obligados a pasar a subdominios de un dominio principal común:

Si realmente hicieran eso, parece que sería mucho más transparente para los usuarios con quienes tienen una relación. ¿Cómo es que eso no es una victoria?