Intent to Ship: Cookies Having Independent Partitioned State (CHIPS)

[Dylan Cutler]

Contact emails:

dylan...@google.com, kaust...@google.com 

Proposal repository:

https://github.com/privacycg/CHIPS

Design doc:

https://docs.google.com/document/d/1wL2lCXpaVOi0cWOn_ehfLFIZQxT3t0SH-ANnZYPEB0I/edit?usp=sharing

Specification:

https://datatracker.ietf.org/doc/draft-cutler-httpbis-partitioned-cookies/

Summary:

Given that Chrome plans to deprecate unpartitioned third-party cookies, we want to give developers the ability to use cookies in cross-site contexts that are partitioned by top-level site to meet use cases that don't track users cross-site (e.g. SaaS embeds, headless CMS, sandbox domains, etc.). Chrome will introduce a mechanism to opt into having third-party cookies partitioned by top-level site using a new cookie attribute, Partitioned.

Since we announced our Intent to Experiment with CHIPS, there have been some changes to the API:

• The Partitioned attribute no longer requires the __Host- prefix or its required attributes. The Secure requirement remains.

• We are changing the per-partition-per-domain limit to be based on the total size (in bytes) of the cookies set by a domain in a particular partition in addition to the number of cookies. We intend to impose a limit of 10 KB per-embedded-site, per-top-level-site and increase the numeric limit from 10 to 180.

• For sites embedded in top-level domains that are in a First-Party Set, their cookies' partition key will no longer be the owner domain of that set. Rather, the partition key will always be the top-level domain that the cookie was created on.

Blink component:

Internals>Network>Cookies

TAG review:

https://github.com/w3ctag/design-reviews/issues/654 (Supportive early review)

https://github.com/w3ctag/design-reviews/issues/779 (Oct 19 specification review)

Risks

Interoperability and Compatibility

Firefox: Positive

WebKit: Supported incubation, Official position pending

Web developers: Developers have indicated that CHIPS does solve for many use cases that depend on access to cookies in cross-site contexts (1, 2, 3). Through incubation, and the Origin Trial, we received feedback to improve ease-of-use, particularly to allow for easier migration of existing systems to use CHIPS. We believe we have satisfactorily resolved these concerns (see changes made listed under Summary section).

Other signals:

Ergonomics

N/A

Activation

This feature introduces a new cookie attribute, Partitioned, which is opt-in only. Sites which do not set their cookies with Partitioned should not see any change in the browser's behavior when we ship.

Security

See S&P questionnaire for TAG

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

This feature does not deprecate or change behavior of existing APIs. This feature is behind a killswitch.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Is this feature covered by web platform tests?

Yes

Flag name

partitioned-cookies

Requires code in //chrome?

No

Tracking bug:

https://crbug.com/1225444

Non-OSS dependencies

Does the feature depend on any code or APIs outside the Chromium open source repository and its open-source dependencies to function?

Not anymore than cookies already do now.

Estimated milestones

OriginTrial desktop last	106
OriginTrial desktop first	100

OriginTrial Android last	106
OriginTrial Android first	100

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

List of open issues: https://github.com/privacycg/CHIPS/issues

Chrome Platform Status page:

https://chromestatus.com/feature/5179189105786880

Links to previous Intent discussions

Intent to Prototype:

https://groups.google.com/a/chromium.org/g/blink-dev/c/hvMJ33kqHRo/

Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/_dJFNJpf91U/m/YqP09XbbAgAJ

Intent to Extend Experiment:

https://groups.google.com/a/chromium.org/g/blink-dev/c/kZRtetS8jsY/m/ppK4kDbqAwAJ

https://groups.google.com/a/chromium.org/g/blink-dev/c/MKQODOL0Fso/m/nZXI2dqwAQAJ

[Dylan Cutler]

Estimated Milestone for Shipping:

109

Apologies, I included the OT milestones instead...

[Mike West]

Thanks for the work you've put in through security and privacy review on this feature. It's an important step towards our ability to remove third-party cookie access, and I'm looking forward to seeing it used more widely in the future as we continue down that path. That said, I have a few thoughts:

1.  I'd be happier if we'd been able to keep the `__Host-`-like restrictions on `Domain` and `Path` (even if not the prefix); that seems like a missed opportunity, given that we're going to need to support CHIPS into the indefinite future. The patch removing these requirements (https://github.com/privacycg/CHIPS/pull/46) references discussion on a PrivacyCG(?) call, but I wasn't able to find minutes. Could you help me understand the rationale?

2. There are a few issues open against the spec that seem like they ought to be resolved before shipping. https://github.com/privacycg/CHIPS/issues/58, https://github.com/privacycg/CHIPS/issues/40, and https://github.com/privacycg/CHIPS/issues/2 all seem like they would benefit from explicit resolution. Do you think those ought to be considered blockers?

-mike

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMCNMFScgacg%3D3ueyRyOtUz4QnoJiYA9BKTryeWp_%2B%3D1Mi6yRg%40mail.gmail.com.

[Rick Byers]

I'm excited to see this being close to shipping! Minor questions on the tests below:

I see there is one failing subtest on Chrome 108. Known issue that will be fixed prior to shipping?

Also the harness is failing on Safari and Firefox, is that just because the test has a dependency on the Cookie Store API (while CHIPS is orthogonal from the API)? If Firefox decided to implement CHIPS but not Cookie Store would we be able / willing to modify the tests to pass on Firefox?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3Dcyb4d07a8PO8LUsSCTR3W2qM_ur43mejN4D_6t2XGc9Q%40mail.gmail.com.

[Dylan Cutler]

Hey Mike,

Thanks for your comments, let me address your two points:

I'd be happier if we'd been able to keep the `__Host-`-like restrictions on `Domain` and `Path` (even if not the prefix); that seems like a missed opportunity, given that we're going to need to support CHIPS into the indefinite future. The patch removing these requirements (https://github.com/privacycg/CHIPS/pull/46) references discussion on a PrivacyCG(?) call, but I wasn't able to find minutes. Could you help me understand the rationale?

The PrivacyCG feedback is best summarized here but the notes are sparse. While it would be ideal to keep the Domain restriction, we came to the conclusion that requiring no-Domain will make adoption of partitioned cookies more difficult for websites based on partner feedback (example), since there is significant site re-architecting that may be needed to adapt to the requirement.

As for Path, restricting Path to only "/" seems not necessary after removing the Domain restriction. During a PrivacyCG call on the matter, we also heard from partners that third-party embeds have use cases for setting cookie paths. You can see notes on the call here.

We are still requiring that cookies set with Partitioned should be set with Secure, and have no plans to remove that requirement.

There are a few issues open against the spec that seem like they ought to be resolved before shipping. https://github.com/privacycg/CHIPS/issues/58, https://github.com/privacycg/CHIPS/issues/40, and https://github.com/privacycg/CHIPS/issues/2 all seem like they would benefit from explicit resolution. Do you think those ought to be considered blockers?

Let me address each issue you linked:

For issue 58, "Specify what happens when partitioned cookies collide with same-name unpartitioned cookies," we believe that the correct behavior is to save and send both cookies. There is precedent for saving/storing multiple cookies with the same name. The Storage Model section of RFC626bis already defines how to handle cookies with the same name by treating cookies as unique based on their {name, domain, path}. Our implementation adds the cookie's partition key to this tuple. We have added a PR to our draft spec which we are publishing to the IETF datatracker. The issue has been closed now.

Issue 40, "Keying of "CHIPS" cookies should align with other state," can be reworded as "Should the cookie partition key have a cross-site ancestor chain bit?". The primary difference between Chromium’s storage partition key and cookie partition key is that the storage key has an additional bit which indicates whether the frame has a cross-site ancestor. This was added in order to fix an existing limitation where SameSite cookie semantics are not accounted for in service workers. Our thinking is that this bit is not relevant for the cookie partition key, since site developers can restrict which cookies are available in embedded contexts using the SameSite attribute already.

Issue 2, "User agents should indicate to servers whether a request is cross-site," we have not come to a solution for this but we think that mechanism applies to state partitioning broadly (not just CHIPS), and probably doesn't affect the UA's treatment of cookies. So, our request is to not treat this as a blocker for the launch of CHIPS.

Given that we have closed #58, #40 has a proposed resolution, and #2 should not be a blocker for the launch of CHIPS, we think we are ready to ship.

—

Hey Rick,

Let me answer your question as well.

I see there is one failing subtest on Chrome 108. Known issue that will be fixed prior to shipping?

That failure is expected since partitioned cookies are not enabled in Chrome 108. Cookies set with the Partitioned attribute in that version will create unpartitioned third-party cookies. Once the feature is enabled in Chrome 109 then the test should pass.

Also the harness is failing on Safari and Firefox, is that just because the test has a dependency on the Cookie Store API (while CHIPS is orthogonal from the API)?

That is entirely possible. Good catch! I am fixing this and will have a CL up shortly.

If Firefox decided to implement CHIPS but not Cookie Store would we be able / willing to modify the tests to pass on Firefox?

I suppose any CookieStore-related test could be guarded on the existence of window.cookieStore, so that those tests are skipped if the browser does not support the API.

[Mike Taylor]

On Thursday, November 10, 2022 at 6:40:38 PM UTC-5 dylan...@google.com wrote:

Hey Rick,

Let me answer your question as well.

I see there is one failing subtest on Chrome 108. Known issue that will be fixed prior to shipping?

That failure is expected since partitioned cookies are not enabled in Chrome 108. Cookies set with the Partitioned attribute in that version will create unpartitioned third-party cookies. Once the feature is enabled in Chrome 109 then the test should pass.

Also the harness is failing on Safari and Firefox, is that just because the test has a dependency on the Cookie Store API (while CHIPS is orthogonal from the API)?

That is entirely possible. Good catch! I am fixing this and will have a CL up shortly.

If Firefox decided to implement CHIPS but not Cookie Store would we be able / willing to modify the tests to pass on Firefox?

I suppose any CookieStore-related test could be guarded on the existence of window.cookieStore, so that those tests are skipped if the browser does not support the API.

Unless we consider Cookie Store to be a normative requirement of CHIPS (and I don't think we do), that doesn't seem like a great outcome. Can I ask what WPT is missing to be able to write these tests in a cross-browser fashion? A better outcome would be to add the missing functionality to WPT itself.

[Mike Taylor]

On Friday, November 11, 2022 at 10:22:41 AM UTC-5 Mike Taylor wrote:

Unless we consider Cookie Store to be a normative requirement of CHIPS (and I don't think we do), that doesn't seem like a great outcome. Can I ask what WPT is missing to be able to write these tests in a cross-browser fashion? A better outcome would be to add the missing functionality to WPT itself.

After looking at the failing test in question, I see that you're testing that CookieStore can correctly handle a partitioned cookie. Maybe that test should live in the cookie-store directory as follow-up work, but a quick workaround to feature-detect like you described seems fine for now.

[Mike West]

LGTM1.

I think the loss of the domain restriction is quite unfortunate, but I understand why you landed on that as the simplest path for deployment. My feeling is that folks are going to have to rework things in any event, and this would be an opportune time to revisit same-site-but-cross-origin cookie access within partitions to make the eventual work to align cookies with the origin model easier in the future. At the same time, I recognize that that's a problem that's not made any worse by shipping this feature, and I'll defer to y'all on the short-term deployment tradeoffs.

On the issues, I'd appreciate y'all taking another pass through to make sure there aren't any decisions lurking in the tracker that will be hard to revisit once we ship. I'd also appreciate you finalizing the resolution to https://github.com/privacycg/CHIPS/issues/40, which looks like there's still some ongoing discussion. That's the only issue I saw in a very quick pass that looked like it clearly required resolution before shipping, but y'all are more familiar with the conversations on the topic than I am. :)

Thanks!

-mike

[Yoav Weiss]

On Thu, Oct 20, 2022 at 10:57 PM 'Dylan Cutler' via blink-dev <blin...@chromium.org> wrote:

Contact emails:

dylan...@google.com, kaust...@google.com 

Proposal repository:

https://github.com/privacycg/CHIPS

Design doc:

https://docs.google.com/document/d/1wL2lCXpaVOi0cWOn_ehfLFIZQxT3t0SH-ANnZYPEB0I/edit?usp=sharing

Specification:

https://datatracker.ietf.org/doc/draft-cutler-httpbis-partitioned-cookies/

Can you expand on the plans for this I-D? Have y'all talked to the HTTPWG?

 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMCNMFTt9hEnH1%2BBzB6c0qQijbBEJwvUKPKSO2gu7E-A%2BY_v8w%40mail.gmail.com.

[Johann Hofmann]

Hi Yoav,

On Wed, Nov 23, 2022 at 5:28 AM Yoav Weiss <yoav...@chromium.org> wrote:

On Thu, Oct 20, 2022 at 10:57 PM 'Dylan Cutler' via blink-dev <blin...@chromium.org> wrote:

Contact emails:

dylan...@google.com, kaust...@google.com 

Proposal repository:

https://github.com/privacycg/CHIPS

Design doc:

https://docs.google.com/document/d/1wL2lCXpaVOi0cWOn_ehfLFIZQxT3t0SH-ANnZYPEB0I/edit?usp=sharing

Specification:

https://datatracker.ietf.org/doc/draft-cutler-httpbis-partitioned-cookies/

Can you expand on the plans for this I-D? Have y'all talked to the HTTPWG? 

Yes, this is being discussed in HTTPWG. Dylan presented CHIPS at IETF 115, minutes are here: https://httpwg.org/wg-materials/ietf115/minutes.html#cookies 

One important thing to note is that the HTML/Fetch <-> Cookies spec interfaces aren't well defined at the moment, which also affects other specs that deal with cookie changes such as the Storage Access API. We're working on fixing this in a larger effort called "cookie layering", which is intended to give Fetch some more responsibility in providing the information that is used to select cookies from the cookie store. This way we can actually access concepts like "top-level site" at the right implementation layer. So, in the mid-term, parts of CHIPS will likely end up back in HTML and Fetch.

In the meantime, like for SameSite, the RFC will hand-wave some of the browser bits.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUDzq6pUpw_%2BGMBxzrsb23qtw5Vnv-QG6yZQ35G_j%2BZfQ%40mail.gmail.com.

[Chris Harrelson]

On Wed, Nov 23, 2022 at 10:34 AM 'Johann Hofmann' via blink-dev <blin...@chromium.org> wrote:

Hi Yoav,

On Wed, Nov 23, 2022 at 5:28 AM Yoav Weiss <yoav...@chromium.org> wrote:

On Thu, Oct 20, 2022 at 10:57 PM 'Dylan Cutler' via blink-dev <blin...@chromium.org> wrote:

Contact emails:

dylan...@google.com, kaust...@google.com 

Proposal repository:

https://github.com/privacycg/CHIPS

Design doc:

https://docs.google.com/document/d/1wL2lCXpaVOi0cWOn_ehfLFIZQxT3t0SH-ANnZYPEB0I/edit?usp=sharing

Specification:

https://datatracker.ietf.org/doc/draft-cutler-httpbis-partitioned-cookies/

Can you expand on the plans for this I-D? Have y'all talked to the HTTPWG? 

Yes, this is being discussed in HTTPWG. Dylan presented CHIPS at IETF 115, minutes are here: https://httpwg.org/wg-materials/ietf115/minutes.html#cookies 

Great. Were there any concerns raised there that might create a risk for CHIPS?

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAD_OO4gVfT1aAHE4%3D3Cs6KoCA54q14bGaPepuqofdTEKJVkkgw%40mail.gmail.com.

[Johann Hofmann]

On Wed, Nov 23, 2022 at 5:37 PM Chris Harrelson <chri...@chromium.org> wrote:

On Wed, Nov 23, 2022 at 10:34 AM 'Johann Hofmann' via blink-dev <blin...@chromium.org> wrote:

Hi Yoav,

On Wed, Nov 23, 2022 at 5:28 AM Yoav Weiss <yoav...@chromium.org> wrote:

On Thu, Oct 20, 2022 at 10:57 PM 'Dylan Cutler' via blink-dev <blin...@chromium.org> wrote:

Contact emails:

dylan...@google.com, kaust...@google.com 

Proposal repository:

https://github.com/privacycg/CHIPS

Design doc:

https://docs.google.com/document/d/1wL2lCXpaVOi0cWOn_ehfLFIZQxT3t0SH-ANnZYPEB0I/edit?usp=sharing

Specification:

https://datatracker.ietf.org/doc/draft-cutler-httpbis-partitioned-cookies/

Can you expand on the plans for this I-D? Have y'all talked to the HTTPWG? 

Yes, this is being discussed in HTTPWG. Dylan presented CHIPS at IETF 115, minutes are here: https://httpwg.org/wg-materials/ietf115/minutes.html#cookies 

Great. Were there any concerns raised there that might create a risk for CHIPS?

Not as far as I'm aware of. I couldn't attend the meeting in person, but revisited it with the team. From what I was told the main discussion point was whether we shouldn't just partition all 3P cookies by default instead of giving developers the ability to decide. It's a valid question, but one that has been extensively discussed between browser vendors in Privacy CG, and both Safari and Chrome have made it clear that they strongly prefer blocking 3P cookies by default (with Firefox not being opposed to that). We'll of course keep on engaging with these concerns and questions in HTTPWG, but it seems like a decision that ultimately browsers should have the most authority on.

In any case, I don't think that this discussion presents any compat risk for CHIPS, as the Partitioned attribute would be compatible with a hypothetical partition-by-default future (i.e. by being a no-op).

[Yoav Weiss]

LGTM2

On Thu, Nov 24, 2022 at 10:43 AM Johann Hofmann <joha...@google.com> wrote:

On Wed, Nov 23, 2022 at 5:37 PM Chris Harrelson <chri...@chromium.org> wrote:

On Wed, Nov 23, 2022 at 10:34 AM 'Johann Hofmann' via blink-dev <blin...@chromium.org> wrote:

Hi Yoav,

On Wed, Nov 23, 2022 at 5:28 AM Yoav Weiss <yoav...@chromium.org> wrote:

On Thu, Oct 20, 2022 at 10:57 PM 'Dylan Cutler' via blink-dev <blin...@chromium.org> wrote:

Contact emails:

dylan...@google.com, kaust...@google.com 

Proposal repository:

https://github.com/privacycg/CHIPS

Design doc:

https://docs.google.com/document/d/1wL2lCXpaVOi0cWOn_ehfLFIZQxT3t0SH-ANnZYPEB0I/edit?usp=sharing

Specification:

https://datatracker.ietf.org/doc/draft-cutler-httpbis-partitioned-cookies/

Can you expand on the plans for this I-D? Have y'all talked to the HTTPWG? 

Yes, this is being discussed in HTTPWG. Dylan presented CHIPS at IETF 115, minutes are here: https://httpwg.org/wg-materials/ietf115/minutes.html#cookies 

Great. Were there any concerns raised there that might create a risk for CHIPS?

Not as far as I'm aware of. I couldn't attend the meeting in person, but revisited it with the team. From what I was told the main discussion point was whether we shouldn't just partition all 3P cookies by default instead of giving developers the ability to decide. It's a valid question, but one that has been extensively discussed between browser vendors in Privacy CG, and both Safari and Chrome have made it clear that they strongly prefer blocking 3P cookies by default (with Firefox not being opposed to that). We'll of course keep on engaging with these concerns and questions in HTTPWG, but it seems like a decision that ultimately browsers should have the most authority on.

In any case, I don't think that this discussion presents any compat risk for CHIPS, as the Partitioned attribute would be compatible with a hypothetical partition-by-default future (i.e. by being a no-op).

Thanks for the details! :)

[Rick Byers]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXOZKtBQPewkukz85JZdT6OXSqLTz8%2BvUZQ6rBaY4hQ3g%40mail.gmail.com.

[Dylan Cutler]

Hey all, quick update.

We intend to roll out the feature in gradual increments starting January 10, 2023; and expect to reach 5% of Chrome instances on January 24, 2023 and stay there for a couple of weeks. Once we are satisfied that there is no regression in metrics/behavior, we will proceed with the rollout.

[Dylan Cutler]

Hey all,

Another quick update. Due to a partitioned cookies privacy bug that was discovered, we have to delay the launch of CHIPS to M110, which is the most recent release with the patch.

Since M110 has been released to beta, we have enabled the PartitionedCookies feature on 50% of dev/beta/canary. We will begin rolling out to 1% stable next week.

Thanks,

Dylan

[Dylan Cutler]

Hey all,

We have enabled the PartitionedCookies feature on 1% of stable. We will continue to keep the feature enabled on 50% of canary/dev/beta.

Thanks,

Dylan

[Dylan Cutler]

Hey all,

Another update for CHIPS, we will be rolling out to 5% stable starting tomorrow. Canary/beta/dev will remain enabled at 50%.

Thanks,

Dylan

[Dylan Cutler]

Hey all,

We were planning to ramp up CHIPS to 50% of stable this week, but upon doing metrics analysis we see some guardrail metrics have variations between our control/experiment groups. We are delaying the ramp-up a couple days to do additional analysis to make sure the variations are legitimate and/or are actually caused by partitioned cookies.

Thanks,

Dylan

[Dylan Cutler]

Hey all,

Another update. We decided to roll out CHIPS to 10% of stable instead of 50% to get a better picture on whether CHIPS is having impacts on any of our guiding metrics before rolling out to 50%. Our plan is to let the experiment gather data for 7 days at 10% before checking metrics again and rolling out to 50%.

Thanks,

Dylan

[Dylan Cutler]

Hey Alexandru,

Thanks for following up. We are still at 10% at the moment. We noticed some regressions in UMA metrics which we have contacted owners (just two teams) to see if they are a concern, and if they are worth blocking the release to 50%. Once I get the green light from them, I will begin the rollout to 50%.

Thanks,

Dylan

On Tue, Mar 21, 2023 at 8:57 AM Alexandru Mihai <a.m...@eyeo.com> wrote:

Hi @Dylan,

What's the current status of the rollout? Have you moved to 50%?

Best,
Alex M

[Alexandru Mihai]

Hi @Dylan,

What's the current status of the rollout? Have you moved to 50%?

Best,
Alex M

[Kaustubha Govind]

Hi Alex,

Apologies for the late response. The rollout is currently still at 10%; but we've been able to make progress on resolving metrics regressions; and intend to go to 100% either later this week, or early next week. We'll send an update here when that happens.

K

[Alexandru Mihai]

Awesome, thanks for letting me know 🙂

The rollout will cover all versions from 110 to current, not just the latest version right?

On Mar 30, 2023, at 03:49, Kaustubha Govind <kaust...@google.com> wrote:

Hi Alex,

[Kaustubha Govind]

On Thu, Mar 30, 2023 at 1:24 AM Alexandru Mihai <a.m...@eyeo.com> wrote:

Awesome, thanks for letting me know 🙂

The rollout will cover all versions from 110 to current, not just the latest version right?

Correct, all versions from Chrome 110 onwards are covered.

[Kaustubha Govind]

CHIPS is now enabled for 100% of Chrome 110+ users. The feature is also now enabled by default on the Chromium tip-of-tree, which corresponds to the Chrome 114 release.

[Eric Lawrence]

Should the change to "Enabled by default" appear for 114 on https://chromestatus.com/roadmap ?

[Dylan Cutler]

Good catch, Eric. I just updated the Chromestatus page for CHIPS to enabled by default on 114.

[Eric Lawrence]

There is not a Chrome Policy to control this feature (and no similar mechanism for an Enterprise to turn off chrome://flags/#partitioned-cookies), is there?

I ask because a major enterprise SaaS vendor today reached out to me to say that their product abruptly stopped working properly. 

Investigation revealed that their web App is dependent upon a SSO flow where there's a subframe in the main page that checks for an auth cookie, and failing to find one, the subframe spawns a new tab to the auth provider. That new tab sets the cookie and closes its tab. The main page then retries its operation, and (problematically) the subframe again reports that its cookie was not set, and the new popup repeats. This happens forever.

I looked at traces and confirmed that the problem is that the Auth provider is setting its cookie as "Partitioned" and this causes the cookie to never appear in the subframe of the app. Turning off support for Partitioned cookies causes the site to work correctly.

I built a reduced repro here:  https://debugtheweb.com/test/auth/app.html

Now, as far as I can tell, this is all expected as far as how things are supposed to work, but this SaaS vendor is concerned that they don't seem to have any sort of temporary escape hatch to give their customers until the Web App devs can fix their auth flow (either changing the auth provider to not use Partitioned, or changing the way the main site works such that it is not impacted in this way).

[Mircea Craciun]

hi all,

Eric explained already the issue that we are having .

We have more than 1500 customers impacted by this change with Millions of end-users  and no valid workaround on Corporate level.

Is there any way to set up a Chrome policy for  chrome://flags/#partitioned-cookies to disabled by default on Corporate level?Or on the next update at least to disable it by default and give us some time to fix our auth flow?

[Kaustubha Govind]

Eric: Thanks for identifying the issue so quickly, and flagging this.

Mircea: Since CHIPS is an opt-in feature; and isn't expected to impact legacy code, we do not have an enterprise policy in place. The most expedient fix here would be to identify the cookies that had the Partitioned attribute mistakenly added, and to remove the attribute. I believe Eric was able to pinpoint the exact cookie(s) in question; so I'm hoping that this fix can be implemented quickly. Happy to discuss over a call if helpful (we can make ourselves available over the weekend if needed).

[Kaustubha Govind]

Mircea: 

Since CHIPS is only enabled via Finch/ChromeVariations for versions Chrome 110-113. One other thing you could try is to set the ChromeVariations Policy value to "CriticalFixesOnly" (value 1) temporarily; restart the browser, and check if that disables CHIPS. Note that this will also disable any other Chrome features that are enabled via Finch/ChromeVariations as well. 

CHIPS is enabled by default in the binary starting in Chrome 114 (stable release date: May 30, 2023), so this mechanism will not be effective when your clients upgrade to Chrome 114.

[Kaustubha Govind]

Hi Mircea,

When I test your site; login works for me even regardless of whether PartitionedCookies is enabled/disabled. You can force enable/disable the feature by using the drop-down at chrome://flags#partitioned-cookies.

Happy to fork this discussion into a smaller/private thread, and report back here when we've come to a resolution.

K

On Sat, Apr 8, 2023 at 7:17 AM Craciun, Mircea <mircea....@sap.com> wrote:

And the screenshot :

And can we have a link from where we can download the 114 version before the release at least to test it ?Would be really nice for us to be able to check the Chrome releases before they go live so we can adapt if needed or at least to communicate with you what issues we might have

 

 

Best regards,

Mircea

 

From: Kaustubha Govind <kaust...@google.com>
Sent: Saturday, 8 April 2023 02:21
To: blink-dev <blin...@chromium.org>
Cc: Kaustubha Govind <kaust...@google.com>; Mircea Craciun <mircea.craciun%sap...@gtempaccount.com>; Eric Lawrence <eri...@microsoft.com>; dylan...@google.com <dylan...@google.com>; Alexandru Mihai <a.m...@eyeo.com>; Chris Harrelson <chri...@chromium.org>; joha...@google.com <joha...@google.com>; blink-dev <blin...@chromium.org>; rby...@chromium.org <rby...@chromium.org>; yoav...@chromium.org <yoav...@chromium.org>; Eric Lawrence <bay...@gmail.com>
Subject: Re: [blink-dev] Intent to Ship: Cookies Having Independent Partitioned State (CHIPS)

 

You don't often get email from kaust...@google.com. Learn why this is important

[Kaustubha Govind]

Circling back on the main thread. Setting the ChromeVariations policy to Value 1 did indeed disable CHIPS for the enterprise customer, and resolve the issue (as a reminder, this will only be effective through Chrome 113).

HUGE THANKS to Eric Lawrence for helping us figure out that Mircea's set up had chrome://flags#partitioned-cookies set to "Enabled", which was overriding the policy and keeping CHIPS enabled. Setting that back to "Default" was the solution.

[Craciun, Mircea]

Thank you Govind! I will try it and let you know!

Best regards,

Mircea

On 8. Apr 2023, at 02:20, Kaustubha Govind <kaust...@google.com> wrote:



You don't often get email from kaust...@google.com. Learn why this is important

[Craciun, Mircea]

Hi Govid,

Thank you for the help but is not working:

You can test here:

https://salesdemo.successfactors.eu/login?company=SFPART061393

mircea....@sap.com

Welcome1!

 

 

Best regards,

Mircea

 

From: Kaustubha Govind <kaust...@google.com>
Sent: Saturday, 8 April 2023 02:21
To: blink-dev <blin...@chromium.org>
Cc: Kaustubha Govind <kaust...@google.com>; Mircea Craciun <mircea.craciun%sap...@gtempaccount.com>; Eric Lawrence <eri...@microsoft.com>; dylan...@google.com <dylan...@google.com>; Alexandru Mihai <a.m...@eyeo.com>; Chris Harrelson <chri...@chromium.org>; joha...@google.com <joha...@google.com>; blink-dev <blin...@chromium.org>; rby...@chromium.org <rby...@chromium.org>; yoav...@chromium.org <yoav...@chromium.org>; Eric Lawrence <bay...@gmail.com>
Subject: Re: [blink-dev] Intent to Ship: Cookies Having Independent Partitioned State (CHIPS)

 

You don't often get email from kaust...@google.com. Learn why this is important

Mircea: 

[Craciun, Mircea]

And the screenshot :

And can we have a link from where we can download the 114 version before the release at least to test it ?Would be really nice for us to be able to check the Chrome releases before they go live so we can adapt if needed or at least to communicate with you what issues we might have

 

 

Best regards,

Mircea

 

From: Kaustubha Govind <kaust...@google.com>
Sent: Saturday, 8 April 2023 02:21
To: blink-dev <blin...@chromium.org>
Cc: Kaustubha Govind <kaust...@google.com>; Mircea Craciun <mircea.craciun%sap...@gtempaccount.com>; Eric Lawrence <eri...@microsoft.com>; dylan...@google.com <dylan...@google.com>; Alexandru Mihai <a.m...@eyeo.com>; Chris Harrelson <chri...@chromium.org>; joha...@google.com <joha...@google.com>; blink-dev <blin...@chromium.org>; rby...@chromium.org <rby...@chromium.org>; yoav...@chromium.org <yoav...@chromium.org>; Eric Lawrence <bay...@gmail.com>
Subject: Re: [blink-dev] Intent to Ship: Cookies Having Independent Partitioned State (CHIPS)

 

You don't often get email from kaust...@google.com. Learn why this is important

Mircea: 

[Craciun, Mircea]

THANK YOU ALL for the help especially Eric!

Best regards,

Mircea

On 8. Apr 2023, at 15:25, Kaustubha Govind <kaust...@google.com> wrote:



Circling back on the main thread. Setting the ChromeVariations policy to Value 1 did indeed disable CHIPS for the enterprise customer, and resolve the issue (as a reminder, this will only be effective through Chrome 113).

HUGE THANKS to Eric Lawrence for helping us figure out that Mircea's set up had chrome://flags#partitioned-cookies set to "Enabled", which was overriding the policy and keeping CHIPS enabled. Setting that back to "Default" was the solution.

On Sat, Apr 8, 2023, 7:35 AM Kaustubha Govind <kaust...@google.com> wrote:

Hi Mircea,

When I test your site; login works for me even regardless of whether PartitionedCookies is enabled/disabled. You can force enable/disable the feature by using the drop-down at chrome://flags#partitioned-cookies.

Happy to fork this discussion into a smaller/private thread, and report back here when we've come to a resolution.

K

On Sat, Apr 8, 2023 at 7:17 AM Craciun, Mircea <mircea....@sap.com> wrote:

And the screenshot :

<image001.png>