I have my web browser set to block all third-party cookies. The only place where this is an issue is on Stack Exchange sites, where it prevents a log in action on one site from successfully logging in to other Stack Exchange sites that happen to have different domain names. As such, I created exceptions to allow third-party cookies for stackexchange.com, superuser.com, askubuntu.com, mathoverflow.net, stackoverflow.com, et. al.

For years, this has worked as expected.

Recently (approximately 3-14 days ago), however, this stopped working. Now when I log into Software Recommendations Stack Exchange at https://softwarerecs.stackexchange.com, I have to log in separately to all other Stack Exchange sites that do not share the stackexchange.com domain name (e.g. https://superuser.com).

Did something change on Stack Exchange's end, and if so, how does one work around the changes?

  • 1
    Have you checked your cookie settings to confirm that the exceptions are still there?
    – Catija
    Commented Feb 16, 2022 at 15:00
  • @Catija Yes. Cookies are for all SE sites are set to be allowed per session. Commented Feb 16, 2022 at 15:44
  • 4
    Maybe I'm just misunderstanding. I've never been able to have logins carry over between SE and the sites that are on custom domains due to third party cookie blocking. If you've done something special to allow this, what I'm asking is whether your special settings you've changed are still active. We do not generally allow this.
    – Catija
    Commented Feb 16, 2022 at 15:47
  • @Catija Years ago, I created exceptions to allow 3rd-party cookies for all SE domains. I have not changed those settings. For years, those settings allowed me to log into into softwarerecs.stackexchange.com and then access any SE site with my account (without having to go through the login process again). Suddenly, towards the end of 2021, that useful functionality ceased to work. I did not change anything possibly relevant on my end except, of course, I do keep my web browser up to date. Commented Feb 16, 2022 at 15:54
  • which browser and for sake of completeness what OS are you using? If you use firefox, please indicate if it is an ESR version.
    – rene
    Commented Feb 16, 2022 at 17:19
  • Can you run on any SE in the console UniversalAuth.enabled() and check if it returns true?
    – rene
    Commented Feb 16, 2022 at 17:30
  • 1
    Can you try running on the developer console of your browser (function () { $.cookie('uauth', 'true');UniversalAuth.performAuth();})(). That should give in the network tab requests for universal.gif for each SE toplevel domain and in the response headers you should get cookies. Now, in Chrome I see a warning that the set-cookie is blocked by Chrome due to a missing SameSite attribute. It is suggested that SameSite is set to None. Based my suggestion of my answer here: meta.stackexchange.com/a/312956
    – rene
    Commented Feb 16, 2022 at 17:48
  • @rene I use Firefox on multiple operating systems (Linux and Windows primarily). I use the current stable release (currently 97.0.0) and not ESR. Regarding your other requests, I'll write back soon. Commented Feb 16, 2022 at 18:04
  • @rene UniversalAuth.enabled() -> true Commented Feb 16, 2022 at 18:05
  • @rene I ran (function () { $.cookie('uauth', 'true');UniversalAuth.performAuth();})(). The result is 2 identical warnings of Cookie “uauth” will be soon rejected because it has the “SameSite” attribute set to “None” or an invalid value, without the “secure” attribute. To know more about the “SameSite“ attribute, read https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite, followed by undefined, followed by a POST request to https://superuser.com/users/login/universal/request, followed by... (continued) Commented Feb 16, 2022 at 18:16
  • ...followed by a BLOCKED GET request to https://stackoverflow.com/users/login/universal.gif... (blocked by DevTools, and I am not sure why), followed by allowed GET requests to https://stackexchange.com/users/login/universal.gif... and several other SE domains. Commented Feb 16, 2022 at 18:19
  • and if you inspect the header responses: any warnings that set-cookie is blocked for missing the samesite attribute?
    – rene
    Commented Feb 16, 2022 at 18:21
  • @rene I'll check right now. Any idea why DevTools is blocking the request to https://stackoverflow.com/users/login/universal.gif... but not the same requests on other SE domains? Commented Feb 16, 2022 at 18:22
  • 2
    This might be a firefox feature as it is supreme for protecting its users from security issues. The way SE uses cookies here is by today standards problematic as it is the same how Google, facebook, et al track us. That I see warnings in Chrome for those cookies is a red-flag.
    – rene
    Commented Feb 16, 2022 at 18:34
  • 1
    @rene Yes, for a long time, I've thought that SE would benefit from offering all their content from a single second-level domain (in addition to the unique legacy domains like mathoverflow.net). For example, MathOverflow would also be available at mathoverflow.stackexchange.com. This will eliminate all the problematic cross-domain cookie shenanigans currently used by StackExchange sites. Commented Feb 16, 2022 at 18:42

2 Answers 2


Yes, something did change. The browsers we all use got a bit more picky about which cookies they accept.

In my answer on How does one Stack Exchange site know that I'm logged in to the other? I explain how Universal Login works under the hood. It basically is a trick where images are loaded for all Stack Exchange domains once you login. The images carry the needed cookies as a response. Those cookies make you are being logged in on the other sites.

Cookies have a bunch of security implications, due to their features, how browsers implement them and how audience targeting businesses run away with our privacy. Legislation like GDPR in the EU restrict the broad use of cookies and users that become more conscientious about how their whereabouts across the net are tracked make that rich features that we are used to need a different implementation as relying on cookie behavior is no longer feasiable

You can try for yourself in your browser developer console to see how Universal Login works. The code for the performAuth function is found on the dev cdn.

Run the following code (I use Chrome):

(function () { $.cookie('uauth', 'true');UniversalAuth.performAuth();})()

and observe the Network tab:

enter image description here

When we investigate the response headers of one those GIFs:

enter image description here

That warning says:

This Set-Cookie header didn't specify a "SameSite" attribute and was defaulted to "SameSite=Lax' and was blocked because it came from a cross-site response which was not the response to a top-level naviagtion. The Set-Cookie had to have been set with "SameSite=None" to enable cross-site usage.

You can find the info also in this Stack Overflow Q/A: This Set-Cookie didn't specify a "SameSite" attribute and was default to "SameSite=Lax" - Localhost

Maybe it might be enough to have SE mark the cookies as SameSite=None as hinted on in this article and on MDN but without access to the codebase I can't foresee any side-effects. You probably want to test this properly and screwing up user authentication will do more harm then having to login in a couple of times extra.

There are other options to solve this but that might take serious development work. If the SameSite setting can work then we're back in the login business within 6 to 8 weeks.

  • 1
    Yep, I remember seeing warnings in the console a while back that cross-site cookies will soon stop working unless they're sent with that header. Commented Feb 16, 2022 at 22:28

I can confirm that nothing changed on our end in this area. And I can endorse rene's answer:

Yes, something did change. The browsers we all use got a bit more picky about which cookies they accept.

We can't think of things we can do to alleviate this short of completely changing the way that we handle cross-domain auth (and only if we can find a way to do so that will not run into the same browser issues that we are running into now).

  • Thanks. SE might find it worthwhile to find a good solution. I can only speak for myself, but I noticed my use of, and contributions to, the SE/SO sites that require a separate login are down by at least 85% as a result of this issue. Commented May 18, 2022 at 16:07
  • 2
    Sometimes I hate it when I'm right .... :/
    – rene
    Commented May 18, 2022 at 17:03
  • 2
    Can't you just send SameSite=None in the cookie attributes so that it works, as stated in the rest of the answer? Or is there more that has to be changed in the system to send that? Commented Sep 1, 2022 at 21:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .