User agents should indicate to servers whether a request is cross-site

[DCtheTall]

Consider the example of embed.maps.com, the locator service that example.com embeds on their site which sets a cookie to remember a user's preferred store location.

The server at maps.com may set a same-site cookie when a browser's top-level context is maps.com which is used for billing so they do not want it sent in any cross-site requests. In a top-level context, maps.com might want to include the Set-Cookie header:

Set-Cookie: SID=34e76fa; SameSite=Lax; Secure; HttpOnly; Domain=.maps.com;

However, in cross-site requests maps.com is only interested in setting a Partitioned cookie in their Set-Cookie header for the embed's use case:

Set-Cookie: __Host-example_locationid=187; SameSite=None; Secure; HttpOnly; Partitioned;

This distinction becomes more important to map.com's server when unpartitioned third-party cookies are no longer available, and the server must include the Partitioned attribute for their cookie to be sent in cross-site requests (ideally without having to wait to do it in for a JS execution context).

We may want to consider having user agents indicate whether in some request header whether a server needs to set a Partitioned cookie in order to have the browser accept the cookie.

This is discussed some in this PrivacyCG storare partitioning issue.

One difference is that for this cookie use case, exposing the entire top-level context (or partition key) is not necessary. maps.com only needs to know a single bit of information: whether a request is cross-site or same-site according to the user agent (and therefore only a Partitioned cookie can be set).

Perhaps browsers can send that bit in the Cookie header? A new request header?

[rowan-m]

I may be misunderstanding the use case, but from the title I think the Sec-Fetch headers cover this.

• https://web.dev/fetch-metadata/
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-Site

[krgovind]

I may be misunderstanding the use case, but from the title I think the Sec-Fetch headers cover this.

My understanding that that the Fetch headers would speak to the immediate parent context; and not the top-level site, correct? i.e. in case of nested frames, such as where site A embeds site B, which in turns embeds site A; the fetch headers would indicate cross-site, but the current CHIPS proposal might treat the inner A, as being first-party/same-site to the top-level A.

[annevk]

w3c/webappsec-fetch-metadata#56

[krgovind]

w3c/webappsec-fetch-metadata#56

Thanks for the reference, @annevk . However, it seems this feature is meant to "send the relationship between the initiator and all its ancestors and the target"; but since the partition key only uses current frame site and top frame site, intermediate ancestors are not relevant for state partitioning.

For example, if site A embeds site B, which in turn embeds site A; we are considering allowing site A to access it's unpartitioned state (I don't think this is how Chrome's "Block third-party cookies" behaves currently though). In this scenario, it seems Sec-Fetch-Ancestors would say cross-site when we really want to say "unpartitioned".

[annevk]

That feature isn't done yet and perhaps we could come up with values that address both scenarios. I'd rather not have a whole bunch of request headers with slightly different values all related to your embedders.

[DCtheTall]

Although we have not yet come up with a solution for this, this particular issue applies to state partitioning more broadly than just CHIPS. Given that, we do not think that this being unresolved should block shipping the partitioned cookies feature.