Cross-domain communication broken in latest Chrome (115+)

[gerneio]

This is mostly a thread to share my experiences with the issues with my cross-domain setup using sysend.js, which stopped working several months ago, but I only now was able to dig in to it and figure out what was happening.

When I tested your built-in cross-domain demo (https://jcubic.pl/sysend-demo/) it still worked, so at first, I thought the issue was due to something with my setup (I only load one iframe since that seemed to be enough for me to get full functionality, see #29 & #37). So I first updated to the latest version of sysend, and when I still had issues, next changed my setup to be configured with dual iframes, but ultimately had the same issues. Lastly, I tried toggling the enforcement of using the localStorage feature via sysend.useLocalStorage(), but no differences.

Switching to evaluating the roots of the problem, broadcastChannel.postMessage would never propagate from an iframe window to a tab with the same domain when that iframe was rendered under a page with a different domain. The same holds true for any localStorage events (all of the localStorage data was completely different and isolated, even though the tab and iframe were from the same origin).

In my case my two sites are different domain origins entirely (a.subdomain1.com vs b.subdomain2.com), where as your cross-domain demo are both under the same domain, just one is a subdomain (jcubic.pl vs terminal.jcubic.pl) which is why I suspect the demo still works, although I couldn't find any documentation anywhere for that exception. I did try the setup for my domains with different subdomains but under same main domain, and it did work, but unfortunately I can't make that change in production since it'll break a lot of users access (on both sites) to various resources (too many hardcoded URL's in emails).

Ultimately, the issue is due to a new feature coming down the pipe in browsers, storage/state propagation. I investigated Chrome specifically since that's what we work with internally, so the situation for Firefox or Edge could be different. For Chrome, this feature started in Chrome Beta 113, but was officially available in the production release of Chrome 115 (I'm on 117 atm), which was released back in July '23 I think, which kind of lines up with when I suspect this issue started to occur for me. FYI, I believe that they are rolling out this feature to users slowly, so not all users on latest Chrome version may be affected by it.

For Chrome, there is a way to register in an Origin Trial and submit a form which essentially will generate you a code that you then embed in your site (as a meta tag, or a http header in some cases). You have to provide it your top-level site domain and specify some other settings (i.e. subdomain wildcard, third-party script injection, usage count, etc). Ultimately, this allowed me to restore this functionality to my site in the latest chrome browser version without needing all users to disable a chrome feature flag or anything like that, HOWEVER, this code/trial will expire (supposedly) by Sept 2024 (link), which if anything, at least gives me a year to figure out an alternative (or actually migrate to using same domain origin). I'm hoping that they enable some sort of way to enable a whitelist of allowed domains to have unpartioned cross-origin access to these resources before the trial expiration date.

If anyone has any other suggestions or knows more about this, I'm all ears. But until then, I hope this helps someone else.

Other useful links:

https://developer.chrome.com/en/docs/web-platform/origin-trials/#take-part-in-an-origin-trial
https://developer.chrome.com/docs/web-platform/origin-trial-troubleshooting/
https://developer.chrome.com/docs/web-platform/third-party-origin-trials/
https://chromeenterprise.google/policies/atomic-groups/#ThirdPartyStoragePartitioningSettings

Credit to @yangon99's comment which was my first hint of the source of the issue being related to the new storage partitioning feature.

[jcubic]

Thanks for bringing this to my attention. I need to read more about Storage Partitioning and decide what to do. Maybe I will just update the docs (README) with a warning about this security feature.

[jcubic]

I've asked the question where you are supposed to give feedback about the API.

[slemus29]

Any updates about this issue, im having same problem with the latest version of chrome

[jcubic]

You can follow the updates here privacycg/storage-access#102

[jcubic]

I think you should look into issues with the title "Extending Storage Access API (SAA) to non-cookie storage". It looks promising but we need to wait for it to be implemented in browsers.

[gerneio]

Looks like something is happening per this new comment.

Would be waiting on Chrome 121 Stable mid Jan '24 release which should have support for the broadcast channel "fix", which is what we need, but we can probably test in beta a bit sooner.

So far the origin trial has been working fine for me, but that'll expire Sept '24.

[jcubic]

Yes, I will test with Beta and see how it will work.

[jcubic]

I was able to make it work with localStorage. BroadcastChannel doesn't work yet even in Beta 121.

In order to use the code you need to register for the Origin Trail: StorageAccessAPIBeyondCookies.

But the library just works:

You can test it at:
https://jcubic.pl/sysend.php?_=local
https://just.net.pl/sysend.php?_=local

[jcubic]

I was too fast, there is still an issue with sending messages.

[jcubic]

It's working now, I've used the wrong token, I though that it was the same token for both domains.

[jcubic]

There were some issues with the library when localStorage was used, the sysend.ist() was not returning proper values on init (in the update track event) and when refreshing the page sometimes the demo didn't have the other window in the select. This is fixed in 1.17.1.

Now everything in the demo should work.

Also, the API may change but they added BroadcastChannel as a function, not a constructor. They said it would be odd to have new in front of the method.

[jcubic]

One more update for the code and the tracking events. Note that this works properly only in Chrome 121 (I'm not sure why the code doesn't work properly - only tracking - in Chrome 120).

Also few updates:

• in Firefox the library throws an error when calling document.requestStorageAccess without user interaction.
• In Chrome when the user blocks third-party cookies in settings it will give permission errors

For both cases the user needs to make an interaction with the iframe and requestStorageAccess needs to be triggered in an event that is triggered by the user.