Keying of "CHIPS" cookies should align with other state

[annevk]

I think the current model just adds the top-level site as an additional key.

However, this is inconsistent with plans for state elsewhere: privacycg/storage-partitioning#25. I think it would be good if there was alignment there. Otherwise we end up with a world where what is considered "partitioned" for some state is not considered "partitioned" for other state, which I suspect will lead to a lot of confusion and subtle application bugs.

[DCtheTall]

Hey @annevk, thank you for staying on top of this and making sure cookies and storage are consistent.

Personally, I do not think cookie partitioning should include the ancestor chain bit. My thinking is that the only situation in which the ancestor chain bit on the storage key would be false are the same contexts that SameSite=Lax cookies are available and SameSite=None cookies would not be. So therefore, we did not think it was necessary to include this bit in the cookie partition key.

My understanding was that the ancestor chain bit was to make storage more like cookies, and that we need it to do things like making sure partitioned service workers have the correct site for cookies (i.e. null when they are registered in a frame that would otherwise be unable to access SameSite cookies).

What's more, we actually have a use case for Partitioned in first-party contexts as a less-restrictive form of SameSite (see First-party CHIPS). IIRC Microsoft Teams is interested in using Partitioned cookies in this way on embeds on their own top-level site which have a cross-site ancestor. @erik-anderson can you confirm this is the case?

[annevk]

Did you mean SameSite=None cookies are available and SameSite=Lax are not?

I think the problem with using different keys here is that we don't end up with a unified partitioning story. That's going to make it a lot harder to explain to web developers. It's also going to make it harder for auxiliary features, such as a request header or API that exposes whether you are in a partitioned context.

[DCtheTall]

Did you mean SameSite=None cookies are available and SameSite=Lax are not?

Yes, exactly. The ancestor chain bit was added to the partitioned storage key to enforce SameSite semantics in service workers and to prevent click jacking. That attack model is not a threat to partitioned cookies (since SameSite already exists), so we do not believe adding the ancestor chain bit is necessary.

In addition, we've also received feedback from partners that there are use cases where they would like the top-level document and a same-site embed with cross-site ancestors to share partitioned cookies.

[bvandersloot-mozilla]

I think the problem with using different keys here is that we don't end up with a unified partitioning story.

Ditto to this point.

In addition, we've also received feedback from partners that there are use cases where they would like the top-level document and a same-site embed with cross-site ancestors to share partitioned cookies.

Is this predicated on #51 resolving with first-party Partitioned cookies being different than regular first-party cookies?

[johannhof]

We discussed the "unified partitioning" concern at TPAC and elsewhere already, with the conclusion that the existence of SameSite fundamentally changes the threat consideration for cookies vs. storage and it's desirable to enable developers to opt-in to sharing cookies across cross-site ancestors.

[DCtheTall]

Closing this issue, since there is a consensus on @johannhof's last comment.

[annevk]

I thought @arturjanc still had reservations about this as website developers would likely forget about the subtleties once cross-site cookies are disabled in all browsers and think they are safe when they are not.

[arturjanc]

I still have these reservations, particularly if we were to apply this behavior to SameSite=None cookies (if this applies only to CHIPS/Partitioned cookies then it's a bit better, but IMHO remains a footgun). The reason is that any scenario where a given site has a cross-site iframe will allow that iframe to make credentialed requests to other endpoints within the top-level site, re-enabling a number of attacks that are prevented by default in a post-third-party cookie world.

In my view, we haven't heard of compelling enough use cases to ignore the cross-site ancestor chain bit for cookies that couldn't be addressed in other ways (e.g. by using new platform primitives such as FedCM, or by implementing application-specific functionality to pass data between the top-level document and a same-site-iframe-with-a-cross-site-ancestor context).

[annevk]

Thanks, let's reopen this based on that.

[johannhof]

@arturjanc This discussion is specifically about Partitioned cookies. But we're planning to discuss the overall idea of restricting cookies at the SameSite=None boundary in PrivacyCG and I agree that we should look at the existing use cases and developer concerns to decide on that. It's important to note that allowing for SameSite=None+Partitioned cookies may be a compromise for A > B > A scenarios that would make developers happy to some degree while providing a high amount of security through the opt-in nature of both (and the fact that both in combination are unsuitable for any other use case than A > B > A sharing).

The other possibility could be inventing a new cookie attribute or another kind of opt-in API that makes it more clear to developers (e.g. by name) that they're opting into an A > B > A scenario, and possibly provide customization options for that. It's not entirely clear to me that this effort (for both implementers and developers) is justified when weighing with the threat and the already available solution through CHIPS.

[arturjanc]

It's important to note that allowing for SameSite=None+Partitioned cookies may be a compromise for A > B > A scenarios that would make developers happy to some degree while providing a high amount of security through the opt-in nature of both

My main concern with this view is that, in practice, setting a cookie attribute (either SameSite=None or Partitioned) doesn't have the granularity we'd want from an opt-in into being loaded with credentials by a third party.

Authentication cookies are commonly set for the whole origin -- and sometimes, the whole site / eTLD+1 -- and developers need to set the least restrictive cookie attributes in order for their site to work. The presence of a single endpoint which depends on authentication/state in a third-party context (either SameSite=None or CHIPS) will likely require developers to set the appropriate attribute on their application's authn cookie. This, in turn, will expose all other endpoints in their origin/site to cross-site attacks (as long as there exists a document with a cross-site iframe, such as an ad, anywhere within the top-level site); for example, a cross-site iframe would be able to iframe a credentialed page from the top-level site and exploit clickjacking.

I think that rather than just ignoring the cross-site bit in the key for CHIPS to enable the A > B > A scenario, we'd want to have an opt-in that is more tightly scoped; for example:

• A per-iframe opt-in via Permissions Policy, e.g. <iframe allow="authenticated-cross-site-embeds example.org">, granting the iframe the ability to load resources same-site with the top-level document with credentials.
• An opt-in for the embedded endpoint to allow it to be loaded with credentials even with a cross-site ancestor (FWIW this one would probably be too much of a burden for developers in practice).

Something like this should still allow the use cases we care about with relatively modest application-level work.

(FWIW I think this doesn't really address @annevk's original concern about partitioning consistency between different mechanisms because it allows two different behaviors depending on the presence of the opt-in...)

[johannhof]

developers need to set the least restrictive cookie attributes in order for their site to work. The presence of a single endpoint which depends on authentication/state in a third-party context (either SameSite=None or CHIPS) will likely require developers to set the appropriate attribute on their application's authn cookie.

Right, but the special thing about Partitioned + SameSite=None is that it only works for A > B > A, i.e. there's no other use case for developers to combine these attributes in a top-level context otherwise. I don't see why a developer would need to set these attributes on a cookie for some other functionality.

I think that rather than just ignoring the cross-site bit in the key for CHIPS

I think "ignoring" is a bit strong given that it still incorporates site for cookies through honoring SameSite rules (and again, in a way that would not be accidentally enabled to support other functionality).

A per-iframe opt-in via Permissions Policy, e.g. <iframe allow="authenticated-cross-site-embeds example.org">, granting the iframe the ability to load resources same-site with the top-level document with credentials.

Hmm, how would that change the security considerations? That iframe can still load all endpoints of example.org. I think it would actually be much worse because now you get the effect that you described where all SameSite=None cookies are attached to the cross-site request from that iframe, not just the ones marked as Partitioned by the top-level context. I suppose this could be utilized in cases where the top-level context embeds several third parties and only trusts one to make these kinds of requests, though. But I don't think it works without something like Partitioned+SameSite.

An opt-in for the embedded endpoint to allow it to be loaded with credentials even with a cross-site ancestor (FWIW this one would probably be too much of a burden for developers in practice).

I feel like this capability already exists on the web in various forms, i.e. CORS, XFO, CSP.

[arturjanc]

Right, but the special thing about Partitioned + SameSite=None is that it only works for A > B > A, i.e. there's no other use case for developers to combine these attributes in a top-level context otherwise. I don't see why a developer would need to set these attributes on a cookie for some other functionality.

Wouldn't several of the core use cases for CHIPS require a cookie to be set as Partitioned + SameSite=None? Specifically, which cookie attributes should a site use for its authentication cookie if it:

1. Has an embeddable widget that it wants to access 1P state in 3P contexts (e.g. using Storage Access API).
2. Has an embeddable widget that needs to maintain state in 3P contexts without authentication.
3. Has an endpoint that wants to maintain state across different embedders all of which are in the same FPS.
4. Has 3 different endpoints, each subject to one of the requirements above.

While IIUC for 1 and 2 you could have a cookie that's either SameSite=None or Partitioned respectively, if you want to support all of these use cases, you'd need both SameSite=None + Partitioned, even without an A > B > A scenario.

Also, it seems that all of the examples of using Partitioned cookies at https://github.com/privacycg/CHIPS also set SameSite=None so it seems fairly likely that many sites will want to use Partitioned + SameSite=None cookies.

A per-iframe opt-in via Permissions Policy, e.g. <iframe allow="authenticated-cross-site-embeds example.org">, granting the iframe the ability to load resources same-site with the top-level document with credentials.

I think it would actually be much worse because now you get the effect that you described where all SameSite=None cookies are attached to the cross-site request from that iframe, not just the ones marked as Partitioned by the top-level context. I suppose this could be utilized in cases where the top-level context embeds several third parties and only trusts one to make these kinds of requests, though. But I don't think it works without something like Partitioned+SameSite.

I meant that we need both: we'd only send Partitioned + SameSite=None cookies and we'd require permission delegation to the cross-site iframe which we want to give permission to preserve 1P credentials across a cross-site ancestor chain. This is a way to ensure that an unrelated cross-site iframe doesn't get the ability to make credentialed requests to the embedding site (assuming the site needs to set a SameSite=None + Partitioned cookie as mentioned above).

An opt-in for the embedded endpoint to allow it to be loaded with credentials even with a cross-site ancestor (FWIW this one would probably be too much of a burden for developers in practice).

I feel like this capability already exists on the web in various forms, i.e. CORS, XFO, CSP.

Unfortunately it doesn't because neither of these features is enabled by default, and we'd need this to be safe by default, where a given endpoint would have to actively opt into receiving credentialed cross-site requests.

For example in an A1 > B > A2 scenario we wouldn't want B to be able to embed arbitrary endpoints within A with credentials by default and we'd require A2 to opt into this interaction. We could certainly consider using one of these features as a way to convey this opt in (e.g. require the presence of CSP with frame-ancestors on the response), but in this model we'd still need to enforce the opt-in, i.e. fail if A2 responds without the appropriate header.

[bvandersloot-mozilla]

How many use cases of Partitioned cookies without SameSite=None are there?

The README.md says the following.

User agents may only accept Partitioned cookies if their SameSite attribute is None.

If that is an RFC 2119 "MAY", then it is shaky, implementation-dependent ground. If that is a "MUST" in sheep's clothing, then they can't exist.

The complication of this conversation since Jan 17 gives more credit to Anne's point in the initial comment on this issue:

Otherwise we end up with a world where what is considered "partitioned" for some state is not considered "partitioned" for other state, which I suspect will lead to a lot of confusion and subtle application bugs.

[bvandersloot-mozilla]

A per-iframe opt-in via Permissions Policy, e.g. <iframe allow="authenticated-cross-site-embeds example.org">, granting the iframe the ability to load resources same-site with the top-level document with credentials.

I think it would actually be much worse because now you get the effect that you described where all SameSite=None cookies are attached to the cross-site request from that iframe, not just the ones marked as Partitioned by the top-level context. I suppose this could be utilized in cases where the top-level context embeds several third parties and only trusts one to make these kinds of requests, though. But I don't think it works without something like Partitioned+SameSite.

I meant that we need both: we'd only send Partitioned + SameSite=None cookies and we'd require permission delegation to the cross-site iframe which we want to give permission to preserve 1P credentials across a cross-site ancestor chain. This is a way to ensure that an unrelated cross-site iframe doesn't get the ability to make credentialed requests to the embedding site (assuming the site needs to set a SameSite=None + Partitioned cookie as mentioned above).

I think that controlling access to the storage-access permission is one avenue to controlling 1P credentials outside of top-level contexts. One starting point could be changing the storage-access policy-controlled feature to be self by default and including the cross-site ancestry bit in determining if a storage access request should succeed without requesting or checking the permission.

[johannhof]

Right, but the special thing about Partitioned + SameSite=None is that it only works for A > B > A, i.e. there's no other use case for developers to combine these attributes in a top-level context otherwise. I don't see why a developer would need to set these attributes on a cookie for some other functionality.

Wouldn't several of the core use cases for CHIPS require a cookie to be set as Partitioned + SameSite=None? Specifically, which cookie attributes should a site use for its authentication cookie if it:

1. Has an embeddable widget that it wants to access 1P state in 3P contexts (e.g. using Storage Access API).

SameSite=None. Partitioned wouldn't be accessible here.

2. Has an embeddable widget that needs to maintain state in 3P contexts without authentication.

SameSite=None and Partitioned, but this wouldn't bleed into its top-level/1P state

3. Has an endpoint that wants to maintain state across different embedders all of which are in the same FPS.

This isn't supported right now (we removed CHIPS+FPS support when we updated the FPS proposal to use SAA), but I agree that if we were to change CHIPS keying for top-levels based on FPS this is something to consider.

4. Has 3 different endpoints, each subject to one of the requirements above.

While IIUC for 1 and 2 you could have a cookie that's either SameSite=None or Partitioned respectively, if you want to support all of these use cases, you'd need both SameSite=None + Partitioned, even without an A > B > A scenario.

Also, it seems that all of the examples of using Partitioned cookies at https://github.com/privacycg/CHIPS also set SameSite=None so it seems fairly likely that many sites will want to use Partitioned + SameSite=None cookies.

Those wouldn't affect each other, which is what I was trying to say. If you attach a "Partitioned" attribute to any SameSite=None cookies they can not be used in any other top-level contexts. So, it would not be possible for a developer to attach "Partitioned" to a cookie they want to use in a 3P context, unless it's for the A > B > A case (or A > B > C > A or something like that). Partitioned cookies are bound to the top-level they were set in.

As mentioned above, this becomes a different consideration when you take into account shared partitioning via FPS or similar mechanisms, for which we've already seen some use cases. I'll try to think about this more :)

Unfortunately it doesn't because neither of these features is enabled by default, and we'd need this to be safe by default, where a given endpoint would have to actively opt into receiving credentialed cross-site requests.

I guess that some of these aren't enabled by default because of compat considerations that still apply to the 3PCD effort, though.

Independent of that question, you're right that an affected top-level site A wouldn't be able to restrict which endpoints B is allowed to make (partitioned) credentialed requests to, or whether an embedded C could also make credentialed requests. So, I can see the overall concern here, which we have to balance against developer usability.

To add to @bvandersloot-mozilla's suggestion, @annevk and I recently explored the idea of requiring an (automatically granted) SAA call for an embedded A > B > A frame to be able to use non-partitioned SameSite=None cookies (as if it were a regular third-party). This would allow us to exactly specify the A > B > A case for SAA, give developers back a lot of flexibility with IMO reasonable security protection, and still simplify the rules around cookie blocking (= block at the SameSite boundary).

It's not entirely clear whether ecosystem usage would allow us to change the PP default to self (this previously failed because of concerns that some 3P couldn't ask all their embedding parents to update the iframe code), but overall I'm a fan of the idea.

[arturjanc]

If you attach a "Partitioned" attribute to any SameSite=None cookies they can not be used in any other top-level contexts.

I think we might either be missing each other's point, or I'm somehow misunderstanding a key aspect of how CHIPS works. Let me clarify the four salient points here, just for the sake of syncing our mental models:

1. Some developers will want to set their cookies as SameSite=None; Partitioned. For example, a service might need them because is provides widgets embeddable in 3P contexts, and those widgets might want to maintain state.

2. Cookies set as SameSite=None; Partitioned work like regular cookies in a purely 1P scenario. Assume that there is no 3P embedding at all, but an application set its auth cookie as Partitioned: this cookie will be sent as expected when the user interacts with the application in a 1P context.

   • Under the specific proposal we're discussing, the cookie would also be sent if there is a cross-site ancestor, in an A > B > A scenario.

3. Many applications use session IDs, usually implemented as a cookie with a random value, created when a user without an existing session interacts with their application. When the user logs in, the cookie is often overwritten with a new session ID value.

4. Developers often use a single session cookie throughout their entire application, i.e. they don't create individual auth cookies for different endpoints within their site.

Because of all of the above, my claim is that it is reasonable to expect some developers to create their application's main authentication/session cookie as Partitioned: this will make the application work normally in a 1P context, but will also allow any embeddable widgets to maintain (partitioned) state in 3P contexts. IOW the behavior of SameSite=None; Partitioned cookies is the closest to how cookies work(ed) before third-party cookie deprecation.

However, if we relax the logic to share A's cookie in an A > B > A scenario, sites which set their auth cookies as Partitioned will expose themselves to the attacks mentioned above in #40 (comment) if they have any cross-site iframes.

@johannhof do any of the claims above sound incorrect to you?

To add to @bvandersloot-mozilla's suggestion, @annevk and I recently explored the idea of requiring an (automatically granted) SAA call for an embedded A > B > A frame to be able to use non-partitioned SameSite=None cookies (as if it were a regular third-party). This would allow us to exactly specify the A > B > A case for SAA, give developers back a lot of flexibility with IMO reasonable security protection, and still simplify the rules around cookie blocking (= block at the SameSite boundary).

At first glance this sounds quite appealing to me as well. It would allow us to build on the reasonable security model we landed on for SAA, i.e. prevent cross-site iframes from embedding arbitrary endpoints of the top-level site with credentials. IIUC only those endpoints which call SAA would get credentials, which could serve the role of the explicit opt-in we talked about above.

The developer ergonomics of auto-granting also sound quite nice, so I'd be all for exploring this direction.

[johannhof]

@johannhof do any of the claims above sound incorrect to you?

If we assume that developers will set top-level cookies as SameSite=None; Partitioned e.g. to be able to re-use the same code between embedded widgets and top-levels then I can see your point. As you know, this cookie wouldn't be shared across sites and so keeping both these attributes really only makes sense for a developer that has both a top-level site version as well as an embedded version of something, and also logs users into both (Google Maps?). Depending on how the ancestor chain bit works they might also be susceptible to attacks in an A > B > C > B scenario, if users log into the embedded B.

It's great that you're interested in the SAA idea, and we'll also talk more about that going forward. For CHIPS, I could personally still see us compromising on accepting the security risk from that edge case if there's enough developer need. But I get your concerns and they should be considered going forward.

[arturjanc]

Thanks a lot for the discussion @johannhof, it was very useful -- I think that if the SAA integration works here, this might be a good compromise approach.

As to whether CHIPS specifically could relax the model to retain state across cross-site ancestors, my one remaining thought is that the effect of relaxing the security properties of CHIPS compared to other cookies has consequences that might hinder its adoption. For example, if security guidance for developers discourages the use of CHIPS to avoid making applications susceptible to cross-site attacks (or suggests CHIPS specifically for cookies that are used for embeddable widgets, i.e. splitting session management across multiple cookies), I'd expect it to add some friction in the efforts to roll them out. My guess is that if we can avoid this and land on a model where CHIPS is just as safe as regular post-3PCD cookies (e.g. if the ABA case is served by auto-granting SAA) it will make it easier to encourage developers to more broadly enable CHIPS.

[johannhof]

Thanks Artur, I see your point there. We'd like to discuss cookie blocking and ABA cases more holistically in PrivacyCG soon and I expect us to align on the CHIPS behavior as part of that, i.e. we might find out that SAA is all we need to support. You certainly make a strong case.

[aselya]

We are leaning towards using the ancestor bit to handle A->B->A situations; this matches the behavior of regular SameSite=None cookies discussed in the Standardizing Security Semantics of Cross-Site Cookies proposal. While it will be a backwards incompatible approach for Chrome, it will more closely align the implementation of partition keys with the existing storage key used for partitioned storage.

Since CHIPS is already rolled out in Chrome, we are going to be careful about how we roll this change out.

• We are going to add metrics to measure existing usage of CHIPS inside ABA embeds. Our expectation is that this is relatively low, given that CHIPS is a new feature.

• For CHIPS existing in Chrome’s cookie jar, we will automatically migrate the partition key and set the cross-site ancestor. 

  • With existing partitioned cookies created on their own top-level site will set the ancestor-chain bit to false. 
  • While, Cookies set by third-party domains will set the ancestor-chain bit to true.

• For any existing developer use-cases that need to have the same cookie available on top-level “A” and embedded “ABA” contexts, we recommend not using CHIPS, but just SameSite=None cookies (without the Partitioned attribute). In a post-third-party-cookie world, the cookie can be made available to the inner ABA frame by invoking the Storage Access API

[aselya]

This topic was discussed as part of the community group meeting last week. Based on the feedback received from the group, we will continue moving forward with exploring adding an ancestor bit to handle A->B->A situations.

If you are interested what was presented and the discussion, feel free to review these meeting notes.

Additionally the first metric we will be using to track the potential impact has been committed.

[bmayd]

@aselya The link you added for meeting notes:

If you are interested what was presented and the discussion, feel free to review these meeting notes.

points to a doc that is reused for each meeting. I assume the notes you intended to link to are for the first discussion in the 2023-10-12 Privacy CG meeting here. Please correct me if I got that wrong.

[aselya]

points to a doc that is reused for each meeting. I assume the notes you intended to link to are for the first discussion in the 2023-10-12 Privacy CG meeting here. Please correct me if I got that wrong.

@bmayd, thank you for noticing. I've updated the original comment with the correct link.

[aselya]

We have completed gathering metrics and are moving forward with adding the cross-site ancestor chain bit to the partition key for CHIPS.

As discussed above, the addition of this key serves two purposes. The primary reason is to unify the partition key of CHIPS with the already existing partition key for storage. This unification will make it easier to explain partitioning to developers since the partition keys will have the same parameters. It will also allow developers to leverage the similarities between the keys when developing APIs to determine if something is in a partitioned context.

The second reason is, if the top frame's partitioned cookies are available in embedded subresource requests, this creates a potential vector for clickjacking attacks. For developers that require access to cookies in an A->B->A context, there will no longer be a way to join the outer and inner A partitions. The Storage Access API can provide access to unpartitioned cookies as well as opting into CORS protections.

[aselya]

The initial implementation of the ancestor chain bit is available to be enabled in Chrome Canary through the use of the command line flag "--enable-features=AncestorChainBitEnabledInPartitionedCookies"

Still working on updating devtools to reflect the bit but hopeful that implementation will land soon.

[HeikoTheissen]

After testing with

"<Chrome for testing>\win64-126.0.6478.61\chrome-win64\chrome.exe"
--enable-features=AncestorChainBitEnabledInPartitionedCookies
--flag-switches-begin
--test-third-party-cookie-phaseout
--disable-features=TpcdHeuristicsGrants,
  TpcdMetadataGrants,
  TopLevelTpcdSupportSettings,
  TpcdSupportSettings
--flag-switches-end

I was surprised to find that if a cross-site page is loaded in an iframe, an ancestor bit is or is not included in the partition key, depending on whether the request was caused by an HTTP redirect or a Javascript redirect.

Consider a web page (https://embedding.page) containing an iframe that

• loads a cross-site app (https://embedded.app/start) that sets a partitioned cookie (think of a SAML relay state cookie, SAML Binding spec, section 3.4.3)
• triggers an outbound navigation (think of a logon flow to an IdP https://idp.embedding.page/sso on the same eTLD+1 as the embedding page)
• is navigated back to the embedded app (https://embedded.app/welcome, after successful authentication with the IdP).

Is the partitioned (relay state) cookie sent with this last request? Or does the partition key differ because of the ancestor bit? The answer depends on whether the outbound and back navigation are triggered by an HTTP redirect or not.

Scenario	Outbound navigation via HTTP redirect	Back navigation via HTTP redirect	Cookie sent?
1	No	No	Yes
2	No	Yes	No
3	Yes	No	Yes
4	Yes	Yes	Yes

In scenario 1 two iframes appear in the DevTools (if "Group by frame" is active):

• embedded.app
  • start
  • sso
    idp.embedding.page
• embedded.app
  • welcome

In scenario 2 only one iframe appears:

• embedded.app
  • start
  • sso
    idp.embedding.page
  • welcome

The fact that https://idp.embedding.page/sso appears in the same iframe as https://embedded.app/welcome probably causes the ancestor bit to set for the latter request.

(In scenarios 3 and 4 the appearance of iframes in the DevTools is unstable, it looks different after a page refresh.)

If the embedded app contains a "Logon with IdP" button, a logon flow with SAML HTTP Redirect Binding (SAML Binding spec, section 3.4) would correspond to scenario 1 and would fail (the relay state cookie would be blocked because of the ancestor bit), but a logon flow with SAML HTTP POST Binding (section 3.5) would correspond to scenario 2 (it makes a Javascript-based redirect) and would succeed.

[aselya]

@HeikoTheissen, Thank you for the feedback. I'm working on a CL to update chromium that hopefully will address the behavior you observed.

[aselya]

@HeikoTheissen, the CL has landed and is now available in the current version of Chrome Canary (Version 128.0.6551.0). The ancestor chain bit is not yet turned on by default in Canary, so you will need to pass this argument "--enable-features=AncestorChainBitEnabledInPartitionedCookies" to facilitate testing.

[HeikoTheissen]

With that CL, the partitioned cookie is sent in all cases.

[aselya]

Thanks for confirming the behavior @HeikoTheissen.

[bvandersloot-mozilla]

Sorry, redirects affect whether or not the partition key includes the ancestor bit?

[aselya]

@bvandersloot-mozilla, This was a bug specific to the chromium implementation and how chromium handles redirects.

Technical details on the fix:
Prior to the fix mentioned above, the ancestor chain bit would be calculated by comparing the site_for_cookies to the request site. If the site_for_cookies was null or wasn't first party with the request site, the ACB would be resolve to be cross-site.

For url requests, chromium creates a vector of urls and then iterates through them, using the site at the back of the chain as the request site for the ACB. For navigations the vector remains at a size of 1 so there request site is correct but with redirects, the vector has multiple entries making it hard to determine what site should be used for the request site. This caused the ACB to be calculated as cross-site when the site the redirect resolves to is same-site.

The fix was to use the site that the redirect resolved to instead of the back of the vector as the request site. This ensured that the ACB would be correctly calculated in redirect scenarios, since the site for cookies in cross-site situations would be null.