Open DCtheTall opened 3 years ago
I may be misunderstanding the use case, but from the title I think the Sec-Fetch
headers cover this.
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.
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".
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.
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.
Consider the example of
embed.maps.com
, the locator service thatexample.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 ismaps.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 theSet-Cookie
header:However, in cross-site requests
maps.com
is only interested in setting aPartitioned
cookie in theirSet-Cookie
header for the embed's use case:This distinction becomes more important to
map.com
's server when unpartitioned third-party cookies are no longer available, and the server must include thePartitioned
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 aPartitioned
cookie can be set).Perhaps browsers can send that bit in the
Cookie
header? A new request header?