Host-only cookie retrieval

[will-bartlett]

FedCM has some additional privacy complexities that are motivated by the current cookie retrieval algorithm. In particular, FedCM retrieves metadata from the registrable domain rather than the origin (like most specifications) because cookies are scoped to registrable domains and not origins. See FedCM section 5.3.1 Manifest Fingerprinting for motivation and w3c-fedid/FedCM#809 and w3c-fedid/FedCM#821 for the problems this causes and an attempt to resolve them.

Some participants observed that only retrieving host-only cookies would resolve this issue cleanly. FedCM could switch to metadata on the origin (like most specifications) if cookies were origin scoped.

Proposal: The retrieve cookie algorithm from draft-ietf-httpbis-layered-cookies takes five inputs ("To Retrieve Cookies given a boolean isSecure, host host, URL path path, boolean httpOnlyAllowed, and string sameSite"). Add a sixth input boolean originScoped and update the retrieval algorithm such that, when originScoped is true, cookies are only retrieved if the host-only flag is true or if host exact-matches cookie's host.

Once in the cookie specification, fetch can consume it as a new credential mode, and FedCM consume it through fetch.

[annevk]

How does that make it origin-only? What about the port for instance?

[will-bartlett]

How does that make it origin-only? What about the port for instance?

I will rename the issue - host-only is the right name for this, not origin-only. My goal is to expose the existing host-only semantics available as a storage algorithm additionally as a retrieval algorithm for fetch (and thereby for FedCM), not to define new semantics.

[samuelgoto]

Some participants observed that only retrieving host-only cookies would resolve this issue cleanly.

Can you expand on this a bit more? How it is that constraining the cookies to be host-only / origin-only help resolve the issue of fingerprinting?

[will-bartlett]

Some participants observed that only retrieving host-only cookies would resolve this issue cleanly.

Can you expand on this a bit more? How it is that constraining the cookies to be host-only / origin-only help resolve the issue of fingerprinting?

Fingerprinting in FedCM happens when foo.example uses foo-example.login.idp.example and bar.example uses bar-example.login.idp.example and foo-example.login.idp.example and bar-example.login.idp.example share cookies. Here, login.idp.example receives both the relying party identity and the shared user cookie in a single request pre-consent.

Constraining cookies to be host-only reduces fingerprinting by preventing shared cookies between subdomains. It doesn't resolve the issue fully - but it makes the domain where a singleton endpoint is required to prevent fingerprinting be the host (login.idp.example) instead the registrable domain (idp.example).

[annevk]

cc @bvandersloot @sysrqb

[samuelgoto]

foo-example.login.idp.example and bar-example.login.idp.example share cookies

What's special about login.idp.example? Wouldn't an attacker be able to use foo-example.idp.example and bar-example.idp.example equally well and still meet the following attack "receives both the relying party identity and the shared user cookie in a single request pre-consent."?

Or, are you working under the assumption that we'd still have some sort of well-known file somewhere that guarantees that there is only 1 login.idp.example per registrable domain?

[will-bartlett]

foo-example.login.idp.example and bar-example.login.idp.example share cookies

What's special about login.idp.example? Wouldn't an attacker be able to use foo-example.idp.example and bar-example.idp.example equally well and still meet the following attack "receives both the relying party identity and the shared user cookie in a single request pre-consent."?

Or, are you working under the assumption that we'd still have some sort of well-known file somewhere that guarantees that there is only 1 login.idp.example per registrable domain?

Not per registrable domain.

Today, FedCM prevents manifest fingerprinting in both host and path by using a well known file at the registrable domain. If we could specify FedCM to only use host-only cookies, FedCM would only need to prevent manifest fingerprinting in the path but not the host, because there would be no shared data between hosts. Then, we could host the well known file in the same host as the config file instead of using the registrable domain.

PS - this issue is in http-extensions github, not FedCM, so we may way to take the conversation to FedCM github or slack. We already have a conversation in FedCM slack. Just not sure how interested these folks are in details of FedCM.

[will-bartlett]

Maybe another way of looking at this protocol://subdomain.registrabledomain/path.

FedCM today prevents manifest fingerprinting in the "subdomain" portion and the "path" portion, but not the "registrabledomain" portion (no shared data) nor the "protocol://" portion (fixed to https by spec).

I am suggesting FedCM could prevent fingerprinting only in the "/path" portion by removing the shared data in the "subdomain" portion. My understanding is that cookies are the only type of shared data in that portion and that limiting cookie retrieval to host-only would make the subdomain and registrabledomain portions equivalent, from a privacy perspective. Keep in mind that it is already approximately free to obtain infinite registrabledomains through the use of PSL.

[npm1]

Today, FedCM prevents manifest fingerprinting in both host and path by using a well known file at the registrable domain. If we could specify FedCM to only use host-only cookies, FedCM would only need to prevent manifest fingerprinting in the path but not the host, because there would be no shared data between hosts. Then, we could host the well known file in the same host as the config file instead of using the registrable domain.

I think this does not actually prevent fingerprinting. Even if FedCM fetches are restricted to origin-scoped cookies, there is nothing preventing IDP1 from later writing those origin-scoped cookie contents into domain-scoped cookies, IDP2 doing the same, and the IDP domain then cross-referencing those cookies to get all of the information.

PS - this issue is in http-extensions github, not FedCM, so we may way to take the conversation to FedCM github or slack. We already have a conversation in FedCM slack. Just not sure how interested these folks are in details of FedCM.

Isn't FedCM the motivation of this issue? It is not in the title but it is the only use case mentioned in the issue description.

[will-bartlett]

I think this does not actually prevent fingerprinting. Even if FedCM fetches are restricted to origin-scoped cookies, there is nothing preventing IDP1 from later writing those origin-scoped cookie contents into domain-scoped cookies, IDP2 doing the same, and the IDP domain then cross-referencing those cookies to get all of the information.

Interesting. I was thinking host-only was equivalent to PSL, but it isn't, because browser bounce tracking operates at the level of the registrable domain. That is, the browser will keep idp.foo.example, idp2.foo.example, and foo.example storage around if the user only interacts with idp.foo.example, unless foo.example is on the PSL, and then it requires interaction with the specific subdomains and parent domain separately to keep the storage around.

That's probably kills this idea for FedCM then.

I was thinking this idea was generally useful - folks have been talking about making cookies origin only for decades to reduce the inclusion of unnecessary data. But FedCM was the case I was primarily interested in, of course.