In T226797#6878150, @TheDJ wrote:

That is correct, you are crossing a domain line and are thus not logged in (because of this ticket). ForeignApi retrieves the user information from Wikidata and Wikidata tells foreignapi that you are a non-authenticated user on Wikidata, and thus your username is your ip (as on all wikis). The api response in itself is not a CentralAuth problem. With this bug it is expected and it is a result of CentralAuth no longer being able to fulfil its purpose due to changes in the browser landscape. There is no security problem or something, something that I think had you concerned if I read your words?

Theoretically a bad actor with IA flag can add simple js code, and gain ip addresses of the users affected of this bug.

@SerDIDG A bad actor that can execute client side scripts could already do that other ways.

This task and T202028 is about site isolation as state partitioning was not in effect when the tasks were created. State partitioning has the same effect, but the mechanism is different.

The fix is to let the server talk to CentralAuth directly, without going through the browser. And use WebAuthn, not the homegrown weed.

@Xaosflux, yes, but using of ForeignApi makes the code looks more legit, can last longer and go unnoticed. But, if you say so.

On the upstream bug I asked for architecture advice, since I don't see a way to make our SUL system work with state partitioning. I'm also asking for temporary whitelisting since a full rearchitecture of sign-on (we might call it SUL3) is going to take months. Tim Huang, a relevant developer and co-author of the "Introducing State Partitioning" article on the Mozilla blog, is the "triage owner" of my bug, but it's unclear whether that means he has been notified. The next step for progressing the upstream bug is to make sure Tim Huang is aware of it.

In T226797#6881107, @tstarling wrote:

...since a full rearchitecture of sign-on (we might call it SUL3) is going to take months.

It would be good to incorporate T248339: Decide how to deal with WebAuthn login/registration flow on Wikimedia wikis in future in any SUL3 plans as well, as another auth problem caused by having multiple login domains.

I see this is getting some heat. I think we need a power-user workaround, involving editing about:config.

@tstarling I didn't see a response to my query above about when this causes an actual problem on Firefox. I'm not personally seeing it on FF86, is this only a FF problem for users that specifically change to the non-default browser setting that warns that it may be breaking? (Which also links to how to put in your own bypass per https://support.mozilla.org/en-US/kb/enhanced-tracking-protection-firefox-desktop?as=u&utm_source=inproduct#w_what-to-do-if-a-site-seems-broken)

I'm not personally seeing it on FF86, is this only a FF problem for users that specifically change to the non-default browser setting that warns that it may be breaking?

Seems like it's broken for anyone who has privacy set to the "strict" profile.

In T226797#6884690, @daniel wrote:

I'm not personally seeing it on FF86, is this only a FF problem for users that specifically change to the non-default browser setting that warns that it may be breaking?

Seems like it's broken for anyone who has privacy set to the "strict" profile.

OK with that being the non-default, opt-in with a warning message setting- that also seems to have a per-site workaround (at least on FF) this shouldn't be a problem for most users

Indeed, in a default installation it still appears to work. I was able to reproduce the problem in a new Firefox profile by enabling "strict" enhanced tracking protection. And I was able to permit cross-site login by disabling tracking protection for en.wikipedia.org via the shield icon.

See also: T257853: CentralAuth edge login broken on desktop (coinciding with SameSite rollout)

We've also had issues at Miraheze now ETP is rolled out. I opened https://bugzilla.mozilla.org/show_bug.cgi?id=1774861 last night for Miraheze.

In T226797#8013018, @Legoktm wrote:

Can we start sketching out what SUL3 would look like? In my head I currently have an idea that the login link will send you to login.wikimedia.org with ?uselang and original URL preserved, then you log in, including 2FA, it redirects you back to where you came from with an OAuth style handshake. Then on another wiki family, you have to click login, but once you hit login.wikimedia.org it immediately redirects you back and you're now logged in. I'm not sure if there's a way to transparently do the wiki logins without redirecting back and forth...

Take into consideration how this interacts with CheckUser.

See also T321181: Constantly getting logged out and T319279: Increased session loss since 20221001 (although the timeline doesn't quite match; according to Wikipedia's release notes log, Total Cookie Protection was made default on July 26 on desktop and November 15 on Android).

In T226797#8013018, @Legoktm wrote:

Can we start sketching out what SUL3 would look like? In my head I currently have an idea that the login link will send you to login.wikimedia.org with ?uselang and original URL preserved, then you log in, including 2FA, it redirects you back to where you came from with an OAuth style handshake. Then on another wiki family, you have to click login, but once you hit login.wikimedia.org it immediately redirects you back and you're now logged in.

I think the minimum-effort temporary fix would be to send the user to Special:CentralAutoLogin/checkLoggedIn when they visit the login page and the CentralAuthAnon localStorage / cookie key is not set (ext.centralauth.centralautologin.js does that already, but via AJAX so it gets subjected to TCP state partitioning while a top-level redirect would not) and make Special:CentralAutoLogin add an extra query parameter on an unsuccessful return to avoid an infinite redirect cycle. That's just a few lines of code changes and enough to unbreak privacy sandbox type issues which limit cookie access on embedded navigation but not top-level navigation, and the change should be mostly invisible to the user, I think (other than the login page loading a little slower when they are not logged in centrally + if something breaks in CentralAuth they might end up on an error page on loginwiki which is confusing but hopefully very rare).

The next step would be to disable local login entirely on every wiki that is not the central login wiki. We could either keep triggering the central autologin logic from SpecialUserLogin, or make CentralAuthPrimaryAuthenticationProvider return a REDIRECT reponse instead of trying to do password-based authentication (AuthManager already knows to automatically redirect instead of showing the login page if there is only one primary auth provider and it redirects), and manipulate the last leg of autologin so that it redirects back into the normal login process. Still seems fairly easy to do, but all clients which provide their own login UI (e.g. the WMF apps) would have to update their code, and loginwiki would have to be prepared to a user-facing wiki.

I think the end goal should be for loginwiki to be an OIDC provider (standards are nice, makes it easier to understand and test, makes it easier to replace CentralAuth with something else), which it sort of already is via the OAuth extension (T254063: OAuth extension should support OpenID Connect) but we'd probably want CentralAuth to hook into OAuth and suppress the authorization dialog. The login page would then just perform an OIDC handshake and CentralAuthSessionProvider would probably store the OIDC bearer token in a cookie, instead of the current set of cookies.

I'm not sure if there's a way to transparently do the wiki logins without redirecting back and forth...

You need to redirect back and forth to be able to set a cookie, so not really (short of a hidden popup window maybe). I think we'll have to give up on edge login, at least until first party sets or some other cross-origin-collaboration oriented new browser API makes it into the wild.

In T226797#8013090, @Izno wrote:

In T226797#8013018, @Legoktm wrote:

Can we start sketching out what SUL3 would look like? In my head I currently have an idea that the login link will send you to login.wikimedia.org with ?uselang and original URL preserved, then you log in, including 2FA, it redirects you back to where you came from with an OAuth style handshake. Then on another wiki family, you have to click login, but once you hit login.wikimedia.org it immediately redirects you back and you're now logged in. I'm not sure if there's a way to transparently do the wiki logins without redirecting back and forth...

Take into consideration how this interacts with CheckUser.

Legoktm already told me on IRC the proposed solution here wouldn't start logging logins on loginwiki, but worth pointing out in case anyone thought there should be a CU impact: loginwiki was intentionally excluded from the implementation of tracking logins in the CU table when we made that change a few years ago because it would effectively create global CU. While this has been a steward wishlist item for a while, it doesn't have global consensus and is controversial/would probably need a global RfC to expand the steward mandate. For those unaware, loginwiki currently only tracks account creations in CU, and it was intentionally left that way when other wikis started to track logins.

Anyway, know that hasn't been a main focus here, but since CU was mentioned and CU and loginwiki have been points of contention before on technical implementation, it was worth mentioning.

Filed T326281: Attempt top-level central autologin when visiting the login page (to allow autologin when the browser blocks third-party cookies) so it's easier to keep track of changes to the login flow, separate from user reports about login issues (of which we have many).

Is a recently created task T328397: API:Clientlogin send wrong cookie headers on mobile domains related to this?

In T226797#8628080, @I wrote:

Is a recently created task T328397: API:Clientlogin send wrong cookie headers on mobile domains related to this?

No. The clientlogin API is not used internally.

As of https://blog.mozilla.org/en/mozilla/firefox-rolls-out-total-cookie-protection-by-default-to-all-users-worldwide/, the opt-in strict mode that started in 2021 is now enabled by default in Firefox.

This seems to be affecting Google Chrome (and other Chromium derivatives like Microsoft Edge) as well (probably due to implementation of the client-side storage partitioning feature since M-115). Maybe we could opt-in to the deprecation trial for the same as a temporary solution ?

In T226797#9104644, @Soda wrote:

This seems to be affecting Google Chrome (and other Chromium derivatives like Microsoft Edge) as well (probably due to implementation of the client-side storage partitioning feature since M-115). Maybe we could opt-in to the deprecation trial for the same as a temporary solution ?

Their explainer says they are not partitioning cookies for now. I can confirm that central autologin still (sometimes) works on M-115.

In T226797#9113329, @Tgr wrote:

In T226797#9104644, @Soda wrote:

This seems to be affecting Google Chrome (and other Chromium derivatives like Microsoft Edge) as well (probably due to implementation of the client-side storage partitioning feature since M-115). Maybe we could opt-in to the deprecation trial for the same as a temporary solution ?

Their explainer says they are not partitioning cookies for now. I can confirm that central autologin still (sometimes) works on M-115.

Ah shoot, it appears I have enabled the option to remove third-party cookies at chrome://settings/cookies due to some privacy sandbox configurations :( Sorry for the false alarm :(

It also says, sadly,

We also considered using the First-Party Sets (FPS) of the top-level document instead. It has been suggested, however, that FPS should not be used as a security boundary. This was discussed in the context of http cache, but the same security concerns exist in quota managed storage and service workers. Therefore we have chosen not to partition by FPS for now.

I was hoping we could use first-party sets to prolong CentralAuth's life but none of the major browser vendors seem to be supportive of that kind of usage.

I'll close this to reduce the number of CentralAuth cookie blocking related tasks. The issue was somewhat mitigated in T326281: Attempt top-level central autologin when visiting the login page (to allow autologin when the browser blocks third-party cookies), although I wouldn't call it fixed; but the issue is already covered in detail in T345249: Mitigate phase-out of third-party cookies in CentralAuth. I have copied over the comments with relevant information.