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.

[bvandersloot-mozilla]

Is there a particular reason you reached for Sec-Fetch-Ancestors rather than the Sec-Fetch-Partitioned proposal that answers partitionedness more directly?

[cfredric]

I haven't read through all of w3c/webappsec-fetch-metadata#80, but from what I've seen, I prefer Sec-Fetch-Ancestors because I think it provides more useful information. (I think it's also a bit ambiguous what "partitionedness" means, depending on who's asking. I.e., are they concerned about privacy, or security, or neither?)

IIUC, Sec-Fetch-Partitioned: ?1 would be the equivalent of something like (e.g.) Sec-Fetch-Top-Level-Document: ?0. (I'd argue that every iframe should be considered a "partitioned" context, since they can all set Partitioned cookies using some non-empty partition key.) I'm not aware of an existing Sec-Fetch- header that says whether the request came from a top-level document or not, so maybe it'd be useful.

However, I think that knowing the cross-site/same-site/same-origin-ness of the request context is more useful for web developers, since that gives a way to assess the security/privacy context that the request came from. I expect that to be what web developers are most commonly trying to assess, when asking whether the request is partitioned.

[bvandersloot-mozilla]

More detail seems like it could be worthwhile, in order to match the definition of Sec-Fetch-Site. But I'm not sure how much we want to add more headers versus adding enums. Data on the wire for every request seems expensive to me intuitively.

I expect that to be what web developers are most commonly trying to assess, when asking whether the request is partitioned.

I think so, but also the question "can I set unpartitioned cookies" seems like a common reasonable one that should have a simple answer. There is the javascript solution, but making it available on HTTP handling has been an open request IIRC.

[cfredric]

but also the question "can I set unpartitioned cookies" seems like a common reasonable one that should have a simple answer.

Agreed, but neither Sec-Fetch-Partitioned nor Sec-Fetch-Ancestors really answer that question. Storage Access Headers is aiming to answer that via Sec-Fetch-Storage-Access.

(Incidentally, that's a good example of why I think "is this partitioned" is sometimes ambiguous. It's possible for a context to be partitioned and also have access to unpartitioned cookies, so we need to be careful not to conflate "is partitioned" with "cannot access unpartitioned cookies".)

[bvandersloot-mozilla]

Sec-Fetch-Ancestors is probably the best then. It is weird that Sec-Fetch-Site has a semantic mismatch with the SameSite attribute, but it may be too hard to change it to SameSite's more strict definition.

It would be nice to get @annevk's latest take on it though!