What does "fail" mean? Is it outputting error messages? Or just failing to log you in?

Fail to log in. I've double checked in Firefox and there are no error messages in the browser. I would have been very surprised if there were any error messages, as that would imply a path between the isolated instances.

In Firefox it seems like subdomains are not isolated, only domains. That is central auth logs me in on enwiki if I log in at nowiki, but it does not log me in at meta.

I'm not sure there's anything we can do here. The whole point of these features is to prevent setting/accessing cookies for other domains from JS or images, and that's exactly what CentralAuth needs to do. Anything we do to work around it seems likely to be blocked eventually.

The one thing that might not be blocked would be to have ext.centralauth.centralautologin.js try a CORS request to login.wikimedia.org to see if the user is logged in there, and if so either redirect the whole browser window or provide a link to do the same.

A CORS request to login.wikimedia.org would work, and it could provide necessary login info. There are several other methods too. One is to open an iframe and to use postMessage()to transfer login information. Another is to add a one time token to the url, and then check if someone else is logged in from the same IP-address, and then if one of those accept the one time token.

Still note that Cross-Origin Read Blocking (CORB) prevents the renderer process from receiving a cross-origin data resource unless CORS explicitly allow access to the resource. I have not checked but my guess is that login.wikimedia.org just add cookies to an image request, and does not use CORS properly. Fix CORS and I guess login works as-is.

In T202028#4509914, @jeblad wrote:

A CORS request to login.wikimedia.org would work, and it could provide necessary login info.

Note one request would be insufficient. The current redirect-based process (via either <img> or <script>) uses five steps, implemented by SpecialCentralAutoLogin:

1. A cacheable hit to the local wiki to begin the process. (/start)
2. An anon-cacheable check to loginwiki that the user is actually logged in there, to an SUL account. (/checkLoggedIn)
3. A hit to the local wiki to set up the local session. (/createSession)
4. A hit to the loginwiki to validate the data. (/validateSession)
5. A hit to the local wiki to set the cookies. (/setCookies)

Note caching in steps 1 and 2 is important to avoid overloading the app servers, see T56195 for details.

Other than potentially omitting step 1 entirely, I'd be wary of trying to reduce the number of steps without a full security re-review. I don't remember the details from 5 years ago, but reviewing some old notes it looks like the extra back-and-forth is intended to defend against attacks where an attacker does the first few steps and then gets the victim to complete the process resulting in the victim being logged in to an account controlled by the attacker.

One is to open an iframe and to use postMessage()to transfer login information.

Are you talking about having Special:UserLogin use a bunch of JS to post to every site? That would be a lot to do from an extension. And if iframes can so easily get around these "isolation" things, it seems reasonably likely the bad ad networks will jump on that and the browsers will have to block it.

Another is to add a one time token to the url, and then check if someone else is logged in from the same IP-address, and then if one of those accept the one time token.

That doesn't seem workable. At minimum it would mean starting to track who's logged in from each IP address and would break for various kinds of proxies. It's also not clear what URL you're talking about adding a token to or how it would prevent various attacks.

I have not checked but my guess is that login.wikimedia.org just add cookies to an image request, and does not use CORS properly. Fix CORS and I guess login works as-is.

The drawback with all of that is that it requires the user has JavaScript enabled, while the existing <img>-based mechanism doesn't. We'll likely wind up keeping the image-based mechanism for the cases where it works, and potentially update ext.centralauth.centralautologin.js with CORS requests (rather than using a <script> tag as it does now) once someone has time to test and write code for it.

1. or 2. is probably the reason why unified login already fails a lot, but this task isn't about that.
2. and 4. would probably fail without CORS, so CORS must be enabled already (using script-tags, that seems like a bad idea)
3. fails because of CORB, check why, perhaps it is al that remains to make this work again

Site isolation isn't about blocking ads, it is about leaking information between instances. The call postMessage() is part of webmessaging. If you want to discuss JS, then sorry, I'm not into flamewars over languages.

If you don't believe one time tokens are workable, then that is your decission. Identification of sessions by one time tokens are although quite common.

Then fix whatever works or can be made to work in the future, because the present solution already fails.

I just tried it out (while looking into T231887) and this is weirdly asymmetric.

Assuming I have strict site isolation active on Chromium:

1. If I only login on de.wikipedia.org, then I'm still not logged in on www.wikidata.org (as expected)
2. If I only login on www.wikidata.org, then I'm automagically logged in on de.wikipedia.org!?

Shouldn't 1. and 2. be the same?

o.O

On T202028#5516175; Wikidata has a slightly different CORS setup if I remember correct.

Still fails.

Potentially superseded by T252236 and T257802 etc?

Still fails.

Chrome's site isolation feature is about ensuring that resources belonging to different domains render in different CPU processes, to mitigate Spectre / Meltdown type side channel attacks. It has nothing to do with login cookies whatsoever. Also, Chrome with default settings doesn't limit login cookies today (and cross-domain login with Chrome still mostly works) while site isolation has been the default for a while; so I suspect the people who tested this with Chrome misidentified some unrelated login bug as having to do with this task.

(First-party isolation in Firefox is indeed related to cross-domain cookie access so that part of the report is likely correct. That feature has become default since then in Firefox.)

In T202028#9138119, @Tgr wrote:

(First-party isolation in Firefox is indeed related to cross-domain cookie access so that part of the report is likely correct. That feature has become default since then in Firefox.)

...but that's already covered by T226797: CentralAuth login session and auto-login no longer work across wikis in Safari and Firefox. So I'm inclined to close this.