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:
When we investigate the response headers of one those GIFs:
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.
UniversalAuth.enabled()and check if it returns true?(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/312956UniversalAuth.enabled()->true(function () { $.cookie('uauth', 'true');UniversalAuth.performAuth();})(). The result is 2 identical warnings ofCookie “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 byundefined, followed by a POST request tohttps://superuser.com/users/login/universal/request, followed by... (continued)https://stackoverflow.com/users/login/universal.gif...(blocked by DevTools, and I am not sure why), followed by allowed GET requests tohttps://stackexchange.com/users/login/universal.gif...and several other SE domains.https://stackoverflow.com/users/login/universal.gif...but not the same requests on other SE domains?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.