This site will have limited functionality while we undergo maintenance to improve your experience. If an article doesn't solve your issue and you want to ask a question, we have our support community waiting to help you at @FirefoxSupport on Twitter and/r/firefox on Reddit.

Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

Cookies being written and automatically deleted

  • 7 replies
  • 0 have this problem
  • 1 view
  • Last reply by amleek

more options

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?

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?

All Replies (7)

more options

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.

more options

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:

https://mozilla.github.io/mozregression/

more options

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?

more options

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...)

more options

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.

more options

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.)

more options

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.