Apple Safari security update messes up cookies

Apple has updated Safari browser and added into privacy preferences a default checked to on "Website tracking: Prevent cross-site tracking". It is impossible to load the designer without going into preferences and unchecking this option. The cookie POOPup thing just keeps appearing. Anything we can do about this?

Ouch, this is a tough question.
You have the designer loaded into frames, but you are serving RTD as HTTPS, right?
I mean, I assume this issue is happening only when you use the popup.

However, the security thing in past was to have this behavior allowed when both sites are served in SSL.
If this update messes this thing up, I'm not really sure there's much we could do.
The RTD cookies are not really "tracking" anything, as they're used exclusively within the RTD itself.
If the only way to avoid it is to serve everything from a single domain, then it looks like a frame integration becomes impossible...

I tried to search online a little, but I only found evidences about what's above.
I'm afraid that the only way out for this would be not to use the frame integration any longer.

The best I can think at, eventually, is to allow you to decide if you want to reload the RTD on top-level in case a multiple iteration of the RTD cookie popup happens. Which in this case would mean to force Safari to not use frames anymore.

Sorry if this does sound like a bad news, but at present stage I cannot really think at anything else. Thoughts?

Oh me oh my. Lots to consider in the grand scheme of my current chewing

Yeah, it definitely looks like a frame issue because I tried my site (and my future setup I am working on) and I wasn't having any issues at all. Hope you guys can figure it out. That's a lot to move around if you are using frames. Best of luck!

Still that sounds like a strange move.
I understand about preventing from reading cookies cross-site, but technically this is not what RTD does.
It uses its cookies only within the RTD itself, it is not trying to read "from" your website.
However I cannot really test as I do not have Safari here. But I wanted to check something else.

1st, as also Chrome has the "do not track" option, I ried to enable it there and then I tried to browse your website.
No problems at all, everything worked fine and the RTD popped up normally.
This makes me think that Safari version is not really the same as the "do not track", which is actually not preventing anything but just sending that request to websites (which might even ignore it). I found about this here:
https://support.google.com/chrome/answer/2790761?co=GENIE.Platform%3DDesktop&hl=en

2nd, I THINK that it allows cookies only if the fram page is serverd from the same domain, not sure about 3rd-level domains.
But what avout scripted things from 3rd party? Specifically I am thinking at services like live chats which are normally hosted on 3rd-party domains, and I think are using cookies to know about an active session. Just for curiosity, any chance someone can test it and see what happens?

Finally, about the dirty way out just in case.
There's a function in the RTD named rtd_cookie_fix: it's the one invoked by the user when clicking the TRY TO FIX COOKIE ISSUE AUTOMATICALLY button of the popup. It normally solved the issue as it requires user action, which solved the block realted to sites setting cookies without user knowledge.
That function really just opens, on user request, a dummy page from the RTD domain (which is there toplevel and so can set the cookie) and then just reloads the opener (the frame, in your case). As it realods there's no way to let the parent know if that's the 1st time the cookie popup appeared, but a dirty solution could be to just alter that function's behavior. This means that the cookie fix will no longer work as a cookie fix, but could be used to force a top-level reload if the cookie is not found.

To do something like that, In the FOOTER code for designer something like this can be added on top:

rtd_cookie_fix = (function() {
var cached_function = rtd_cookie_fix;
return function() {
	window.top.location=window.location;
};
}());

What this block does is simply to override the rtd_cookie_fix function and, if it is invoked, load the current RTD URL on top instead of keeping it in the frame. Not optimal for sure, and you would need to test it to see if it actually works.
As I said, unfortunately I don't have any Safari to test this on my own.

It's not a "do not track" thing. That's what Apple was using and now removed. In it's place they've added "Intelligent Tracking Prevention". Other browser may follow suit also. Who knows. Apple removing Do Not Track and adding Intelligent Tracking Prevention

Well, good to know it's intelligent

Yep, I read about Safari being the only one for now. But I'm in doubt about everyone embracing this, honestly.
I can understand about allowing CORS only when websites were bot hSSL, I can understand the same domain policy when I'm trying to READ the other website's cookies. But prevent setting cookies in other scenario basically means to make impossible any embeddable service that requires a session. That's why I was curious about services live chats

Thanks for your time exploring this Alex. I can't get the fix to help. I think my LAST resort will be to apply a warning on our site that detects Safari and asks users to turn the option off first or use another browser. At least until we can change our entire rtd without frames.

I did find this https://www.tinywebgallery.com/blog/advanced-iframe/advanced-iframe-pro-demo/3rd-party-cookie-in-iframe-workaround

I am having a similar problem with iframes with RTD in Chrome.
no matter what I do it gives me the error

COOKIE PROBLEM DETECTION
Our Online Designer requires cookies to work, but we were unable to set it now.
As it may be related to your browser, please click the button below to try fixing the issue automatically.
If this is not the first time you see this message, or it will appear again even after clicking the button,
please consider trying again by using a different browser.

I've set RTD to be approved no matter what on chrome but I still can't get the cookies to work.

any suggestions for Chrome? it just started a few weeks ago where I couldn't fix it.
thanks
tamara

You're not alone...

Unfortunately, this is because of recent "security" updates of browsers, which are described in these issues:
https://stackoverflow.com/questions/61123108/this-set-cookie-was-not-stored-due-to-user-preference
https://venturebeat.com/2020/05/19/google-chrome-83/

The point is this: with these new addition, who will be controlling the security settings will be the browser itself (like that fact that incognito mode will just not allow third party cookies no matter what), and in short this means that popups in iframes are to be considered... bad.
In short, the only solution is to open the RTD links in top or new windows instead of the popup.

If you're using an integration like the Woocommerce plugin, you need to edit it.
In the js_functions.php file. In there there's a function named LaunchRTD.
Close to the end of it there should be this conditional line:

if (forcenew==1 || 'ontouchstart' in window) {

You need to change it to force it always, so like this:

if (1==1 || forcenew==1 || 'ontouchstart' in window) {

This change will force links that used to be loaded in the popup/iframe in a new window.

I know this will be less "pleasant" for customers, but if it's something now forbidden by browsers policy there's not much esle that can be done.

Hope this helps