Address concerns in changes in 3rd Party Cookie handling in Chrome

[rbaillargeon]

Google Chrome is changing to 3rd party cookie handling to address pressures on them with ad trackers and other privacy/security concerns.

This matters to OSLC since critical operations require the usage of 3rd party cookies. Most notably, they are the delegated dialogs and rich previews that utilize iFrames.

We faced a similar issue in 2021 when browsers changed the default of same site (Lax instead of None) settings for cookies. For OSLC nodes that were of different domains (e.g. myoslcserver.com & myoslcserver.de) this resulted in embedded iframes becoming non-function since the session cookie (usually JSESSIONID) was no longer being sent and prompting a user to login instead of the expected content. Resolutions to this problem often were server-based header rewrites to set these cookies to samesite=none explicitly. It required IT intervention and security reviews but was acceptable to most organizations.

The new changes coming in Google Chrome (https://developers.google.com/privacy-sandbox/3pcd) will make the current solution non-functional. They address the concerns of tracking cookies but will disable many of our usages of third parties to show embedded content. There is a phase-in approach and a temporary user override, but we expect that these are not long-term solutions. The OSLC community should review the changes and address whether there is a recommended action that all OSLC repositories should converge on.

Note that this will not affect applications that remain all in the same domain. While we prefer deployments in the same domain, we understand that this is an unrealistic IT constraint.

[rbaillargeon]

For example, when using OSLC services from an OSLC Connect for Jira instance to an IBM ELM instance, we will see warnings like the following about the impending cookie change when doing a rich hover.

[berezovskyi]

In case you feel like setting things on fire (recommend installing Chrome Dev edition next to the regular stable Chrome):

The link you provided lists 4 possible solutions, only option 2 https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API#browser_compatibility is supported by all browser vendors.

[rbaillargeon]

Running in Test mode today gives some interesting behaviors. Some heuristics allow some of the cookies to be assumed to be authentication tokens (driven by login pop-ups and such). But indeed, there is a bigger issue of how to have long-term stability in the solution and a friendly and consistent way to deploy it in enterprise IT environments. This is why we need to discuss and evaluate the impact and recommendation of the standards for consistent and well supported solutions.

[rbaillargeon]

In the Test mode, you will get things like the following, which imply it is currently working with no long-term guarantees.

The result is a single Chrome update to remove the heuristic could break many OSLC topologies.

[berezovskyi]

Oh, I didn't know about the phaseout heuristics. Are you on Chrome Dev v125?

I guess ;Partitioned could be added to cookies as a low-hanging fruit (well, as long as you have access to the codebase or are ready to do some response rewriting on the reverse proxy). The downside is that such approach will require a user to separately sign into the embedded OSLC tool iframe inside of every embedding tool. And other browsers like FF and Safari seem to be doing this already by default.

The Storage Access API does not seem to have this downside but it will require the user to do more clicking, which I think could be a bit better all things considered. Also, I expect the behaviour to be more consistent across Chrome/Edge/FF/Safari.

[berezovskyi]

I am not seeing any mention of heuristics with v125 and Polarion:

Naturally, the iframe integration is 0xDEADDEAD

[rbaillargeon]

I was running a non-Dev Chrome version in Test mode. There are some variances. But as you see Dead can happen quickly. And this is what we want to avoid. I'll do some more investigations in the later development releases as well.

[berezovskyi]

Normal Chrome is v123 now and Dev v125 is what stable Chrome users will see in ca. 5-10 weeks.

[rbaillargeon]

Note. We have a six month delay on this as Google recently re-timed this based on push back in the industry. We do still need a resolution, but at least it is not quite as urgent.

[jamsden]

See The Cookie Doesn’t Crumble: What to Know About Chrome’s Change of Plans for Third-Party Cookies: On July 22, 2024, Google Chrome announced that they are abandoning plans to deprecate third-party cookies in Chrome. Instead, they will take an updated approach that “elevates user choice.”

So perhaps this is no longer an issue.

[rbaillargeon]

We saw this a couple of weeks back (after we submitted some feedback to Google, but we are pretty sure we aren't the cause of this).

I think this particular issue is behind us, but I think the pattern of challenge will persist.

Browsers and security folks will continue to push back on iframes with remote content. We believe we should be exploring other patterns because even today our users are pushing back on some of the samesite needs for cross domain connections in iframes.

[berezovskyi]

We believe we should be exploring other patterns

WebComponents