Expose the first party to a partitioned third party

[annevk]

During the CG meeting there was a question whether the first party location should be exposed to third parties (both via HTTP and JavaScript). And some agreement that it might make sense, modulo referrer policy.

[michaelkleber]

There are two plausible places to consider exposing this:

1. In an HTTP header associated with cookies:  If we're sending the server some partitioned cookies, then it would be good to make clear (a) that the cookies are partitioned, and (b) the top-level domain/eTLD+1/whatever that is the partitioning key.

2. In a JS API associated with partitioned storage: For example, when document.hasStorageAccess() resolves, "could have additional info in the resolved promise say whether the storage is partitioned or not and potentially what the partition origin/registrable domain is" (quoting @johnwilander from the notes).

If the top page has a referrer policy that indicates it doesn't want to reveal its domain to subresources, then we could still indicate that storage is partitioned, but report explicitly that the partitioning key is unavailable.

[annevk]

@hober I wonder if this should be part of the storage access standard in some way? (And eventually HTML I suppose?)

[annevk]

There was some further discussion during the F2F both on the call and on Slack:

1. Firefox currently doesn't leak the embedder through location.ancestorOrigins (and equivalent service workers API) and is concerned about starting to leak the top-level authority to third parties.
   1. In a scenario where A embeds B, A is usually leaked to B through the referrer and leaking it might be okay when the referrer would leak it as well, but note that this does not apply to A embedding B and B then navigating to C. C might learn about B, but not A.
   2. A embedding B and B embedding C. B might learn about A and C might learn about B, but C doesn't necessarily learn about A.
   3. It would be preferable to not increase the number of cases where A is leaked. Otherwise a tracker (a B or C) that is embedded on a large part of the web can learn a lot about a user by learning about the sites (the As) the user frequents.
2. Should this share the top-level authority even if the third party is not partitioned? That is, are we sharing the key or the top-level authority? It seems this was primarily about the key, though sharing the authority might make sense as various permissions will be handled by it. That it sometimes serves as the key is just one of the various roles it has.

[michaelkleber]

Re. (1)(iii), I would prefer to attack the threat by focusing on recognizing the user across sites, of course! Removing 3p cookies isn't the end of the story, obviously, but the point of doing so is to relax the need for this kind of privacy protection.

Since this is a threat only when there's a widely-embedded party that is transitively but not directly embedded — i.e. it's often a C but rarely a B — perhaps the kind of targeted anti-circumvention scrutiny mentioned in https://wiki.mozilla.org/Security/Anti_tracking_policy#Policy_circumvention is a useful tool.

[annevk]

I agree that being able to identify the user to some approximation is the root cause problem, but tackling that is involved and only Tor currently has taken significant steps toward that, which don't really seem feasible to adopt for other browsers.

Why not flip it and only leak A to B, unless A set a referrer policy that would prohibit that?

[michaelkleber]

Why not flip it and only leak A to B, unless A set a referrer policy that would prohibit that?

I agree that's a feasible option as well. Whether or not we should by-default reveal A to C has to do with a judgement call about the utility of the use cases it would support:

• We're discussing partitioned cookies and storage, and the top-level site is the partition key, even for nested iframes. It makes sense for a user of partitioned storage to know what partition they're in, to avoid some of the breakage problems Safari ran into with silent cookie partitioning.

• Less on-topic for the discussion so far, but I'll note that the frame-ancestors CSP directive already acknowledges an embedded party's interest in controlling what environment they can be embedded in — not just their direct parent, but their higher-level ancestors as well. I have a lot of sympathy for the "brand safety" considerations enabled by that sort of control. Of course C can enforce e.g. "I won't allow my video to be embedded in site A" by implementing "...in site A or any unknown embedder", but the more unknown embedders in the world, the harder this becomes.

[annevk]

There's also a significant risk with giving the server the partition key, in that it makes it easier for the server to tie seemingly unrelated sessions together.

I'd like a much clearer understanding of what problems Safari ran into (or what problems you foresee) as conceptually it would seem that servers would have to see these as completely distinct sessions.

(I think it's correct that there are legitimate reasons to have this information, but to me they do not outweigh the potential harm toward end users.)

[michaelkleber]

Sorry, wait, I don't understand that. If we're talking about a third party which has partitioned cookies or storage available, then they could certainly tie together all the different requests that come from the same partition — it suffices to store a random number. What am I missing?

[annevk]

Ah, I meant across partitions. It was basically restating the concern from the perspective of the third-party server.

[michaelkleber]

Got it. I totally agree, if we're talking about third parties that are colluding with the first parties they are embedded in! But this A->B->C scenario is for third parties that don't have that cooperation from the first party. At that point, how does identifying the first-party site help the third party track across partitions?

[annevk]

By being a pretty significant data point about user activity and behavior.