Expose partitionedness

[annevk]

Exposing whether an environment is partitioned, mainly through an HTTP request header, came up in the last cookie discussion privacycg/meetings#19 (again). There's a couple different ideas floating around addressing various use cases around security and developer ergonomics.

• Sec-Fetch-Ancestors? w3c/webappsec-fetch-metadata#56
• Fetch-Metadata to indicate when the browser is in a partitioned context w3c/webappsec-fetch-metadata#80
• User agents should indicate to servers whether a request is cross-site CHIPS#2
• Expose the first party to a partitioned third party #14 (although at this point nobody seems to seriously suggest exposing the full site anymore so maybe that can be closed?)

#31 and #25 also relate to this in that for cookies people have suggested a different keying setup, which really drives home the point that we have to be very careful with what we end up doing in this space.

---

I think having an equivalent to Sec-Fetch-Site that tells you something about your ancestor documents (none, same-origin, same-site, or cross-site) still makes a lot of sense. However, in a A1 -> B -> A2 scenario this header would signal cross-site for A2, which might not make it clear enough it can still set SameSite=None cookies (depending on how #31 gets decided). It would indicate that CHIPS cookies would work however so maybe that is good enough. (The main alternative I can think of is that we'd expose a separate "what is my site relation with the top-level" header, but I'm not convinced that carries its weight.)

[arichiv]

If ancestor chain bit gets implemented for CHIPS, SameSite=None cookies would no longer be available in ABA contexts right? @johannhof

[johannhof]

Ancestor chain bit just means it's partitioned by a different key, no? And of course they become available once storage access is granted. :)

[arichiv]

Ah, I'm conflating two things. Makes sense

[cfredric]

Exposing whether an environment is partitioned,

I think there are two main questions (each with a follow-up) that web developers may ask here:

• Does this request include partitioned cookies (and have the ability to set new ones)?
  • If so, what is the partition key?
• Does this request include unpartitioned cookies (and have the ability to set new ones)?
  • If not, would access be trivially granted via the Storage Access API (because the storage-access permission is either unnecessary or already granted)?

With that in mind, I think most of these would be satisfied by supporting two new sets of headers:

• Sec-Fetch-Ancestors? w3c/webappsec-fetch-metadata#56
  • Conveys some info re: partitioned cookies available to the request, by conveying the partitioned-ness of the request. (Does not indicate what the cookie partition key is, though.)
• https://github.com/cfredric/storage-access-headers
  • Conveys info re: the set of unpartitioned cookies available to the request. Also allows the server to opt into using an existing storage-access permission, if the user already granted it.

I think this neatly separates the question on partitioned cookies from the concern around A1 > B > A2 cookies mentioned above (and handles that concern gracefully, allowing server-side opt in if needed). I'd like to discuss supporting the combination of these headers, to see if others agree and support this work.