Cookies being written and automatically deleted
Hello,
I work for Microsoft, and one of our sites offers users a way to opt out of personalized advertising on some Microsoft domains by setting a cookie. The site: https://account.microsoft.com/privacy/ad-settings/signedout
When the user clicks the toggle to Off, we cycle through four domains via an iframe and write a TOptOut cookie on each one. If everything is working properly, the user should then be able to go to www.bing.com and see a TOptOut cookie on Bing that will prevent personalized advertising on that domain.
The problem is, this stopped working in Firefox. We have verified that it still works* in 115.7.0, but in 122.0.1 and 123.0, the cookie is written and then deleted on refresh. If the user doesn't already have Bing open in another tab, they'll never see the cookie at all. I have verified this behavior in Bing several times, on my work machine (Firefox 122.0.1 on Windows 10) and my personal machine (Firefox 122.0 snap on Xubuntu 23.10).
- It still works on our corporate VPN in 115.7.0, but not on my coworker's non-VPN machine. Same version. I'm really not sure what's up with that one.
This is a large concern for us. Because the cookies can still be written, it doesn't trip our test for third-party cookies being disabled. Because the cookie for microsoft.com is written, the toggle will show up as Off even after a refresh. This is misleading to our users.
I have gone over the Firefox docs on Enhanced Tracking Protection and Total Cookie Protection, but neither seem to handle this case. Firefox does not block any trackers on account.microsoft.com or on www.bing.com. It's fine if the cookies are in separate jars, we just want them to be written to the proper domains and not deleted. Can anyone tell me what changed in Firefox recently? Is this expected behavior, or a bug? If it's expected behavior, what can we do to allow users to opt out of personalized advertising?
Alla svar (7)
That is likely a problem with Total Cookie Protection that isolates third-party cookies, so those cookies are only exposed on that settings page and not on other pages.
You can check for issues with Total Cookie Protection.
The requests are redirected (302 = Temporary Redirect). I don't know whether that is a factor.
First redirect:
Referer = account.microsoft.com Host = api.choice.microsoft.com Cookie set on: .microsoft.com Effect: success
Second redirect:
Referer = account.microsoft.com Host = api.choice.msn.com [cross-site from referer] Cookie set on: .msn.com Effect: failure
Third redirect:
Referer = account.microsoft.com Host = api.choice.bing.com [cross-site from referer] Cookie set on: .bing.com Effect: failure
Fourth redirect:
Referer = account.microsoft.com Host = api.choice.live.com [cross-site from referer] Cookie set on: .live.com Effect: failure
I can't help thinking that it's the cross-site nature of the request that causes the problem. Even though you have samesite=none in the Set-Cookie header.
Could you install the MozRegression tool and see which build caused it to stop working? Your security software may balk at some unsigned development builds, but you may be able to at least figure out the major version in which it stopped working, even if you can't run the development builds. More info:
We've always done the redirect, and it worked a few years ago. I tried the regression tool, and narrowed the range down to sometime in mid 2020 (2020-08-06 bad, 2020-03-15 good), but ran into a bunch of weird crashes around May/June that made testing hard. I'll keep working with it when I have the time.
Can you think of something that changed in that timeframe?
Hmm, it's kind of puzzling to get a regression range in 2020 if Firefox 115 ESR is working. Unless there was a change that was made, discovered to cause problems, and then later backed out. ??
(As for my memory of that time, I had some other things on my mind...)
My coworker reported it working on the corporate network in 115, but I'm unable to reproduce this behavior with the regression tool. Whenever I test with the tool, the failures start mid-2020. I verified this on my work machine and on a personal laptop. Unfortunately, also in mid-2020 FF just starts crashing constantly, so I can't track it down further than that. This also occurs on my work machine and personal laptop. The best I can get is "somewhere between March and September".
I'm trying to get my coworker to also test, but he has other things to do and because of market share, this isn't a super high priority. I care, but it's hard to get other people on board.
Thank you for testing as far as you could. I wonder whether your coworker has a modified setting that allows it to work in their installation. If they want to compare vanilla settings -- assuming Group Policy doesn't reinject a modification -- they could run a quick comparison using the following steps.
New Profile Test
Inside Firefox, type or paste about:profiles in the address bar and press Enter/Return to load it.
Take a quick glance at the page and make a mental note of which Profile has this notation: This is the profile in use and it cannot be deleted. That is your current default profile.
Click the "Create a New Profile" button, then click Next. Assign a name like Test2024, ignore the option to relocate the profile folder, and click the Finish button.
Firefox will switch your default profile to the new one, so click the Set as Default Profile button for your regular one to avoid an unwanted surprise at your next startup.
Scroll down to Test2024 and click its Launch profile in new browser button.
Firefox should open a new window that looks like a brand new, uncustomized installation. (Your existing Firefox window(s) should not be affected.) Please ignore any tabs enticing you to connect to a Sync account or to activate extensions found on your system to get a clean test.
Do the cookies get set (and persist) in the new profile?
When you are done with the experiment, you can close the extra window without affecting your regular Firefox profile. (Test2024 will remain available for future testing.)
I asked my coworker, and he confirms it doesn't work if he makes a new profile. So it looks like he did something to the original profile and it is broken in 115.