tl;dr CentralAuth autologin (the ability to log in on one wiki and be also logged in everywhere else without having to enter credentials again on every site) has been significantly degraded to a non-trivial fraction of our users due to browsers' anti-tracking measures, and will probably be degraded for everyone by 2024 summer.
Problem description
See T345245: Mitigate phase-out of third-party cookies across MediaWiki in production for context and links to relevant documentation.
CentralAuth uses two session mechanism: cookies set on the shared domain of the wiki family (e.g. on wikipedia.org in the case of en.wikipedia.org) and cookies set on a designated central domain (login.wikimedia.org). The first mechanism is considered as a first-party cookie, and not affected. The second mechanism is considered as a third-party cookie, and is at risk of breaking.
There used to be three workflows using the central domain:
- After login, the user is redirected to the central domain and back, to invisibly set a session cookie on the central domain.
- After login, a set of images is included in the page, one for each shared domain other than the current one (e.g. if you log in on en.wikipedia.org, the landing page will embed an image from meta.wikimedia.org, en.wikisource.org, en.wiktionary.org etc.), and each one will go through a redirect cycle of several steps which establishes the user's identity by going to the central domain, then returns to the initial domain and sets session cookies there, essentially logging in the user on all those domains in the background. (This is referred to as "edge login".)
- If you arrive to a wiki where you are not logged in (either because it's too insignificant to be included in edge login, such as outreach.wikimedia.org, or because edge login didn't work, expired etc), a similar redirect chain happens via a <script> tag; after a successful login it might reload the page, or suggest the user via a notice to reload, or just kind-of simulate a reload by replacing the user menu.
- A fourth mechanism was added by T326281: Attempt top-level central autologin when visiting the login page (to allow autologin when the browser blocks third-party cookies): when you are not logged in and visit the login page, the same redirect chain is attempted at the top level.
The first and fourth flow are what browsers call "bounce tracking" or "redirect tracking"; it's mostly allowed today, although definitely within the sight of browser vendors. (It might cause issues in Safari, which does sometimes drastically reduce cookie lifetimes when it detects bounce tracking.) The other two are probably failing in Safari and Firefox, and will fail in Chrome (which is the majority of our traffic) starting mid-2024. (Although they have pushed back the deadline by multiple years already, so there is always the chance of that happening again.)
User impact
Users will have to log in once per "domain family" (wikipedia.org etc), instead of just once. For most users this will probably mean three separate logins: Wikipedia, Commons and Wikidata. (This can be sometimes mitigated by the centralauthtoken API, although it's cumbersome to use.) With a Wikimedia login with the "remember me" option checked lasting for a year, this is a small annoyance for most normal users. Temp users would be cut off from other projects entirely, though - autologin is the only login mechanism for them.
Mitigation options
- Accept the UX degradation and don't do anything.
- Accept the UX degradation and don't do anything in general, but improve the most problematic special cases.
- Turn the centralauthtoken API into something more flexible (e.g. token reusable in multiple requests, less strict time limits).
- Provide an explicit login mechanism for temp users, maybe something like Facebook's "tap the notification in another device where you are logged in" feature. (With third-party cookie restrictions, there would be no way to detect whether the user is logging in from same device, so this would also mean temp users could be logged in in multiple devices - not sure if that's a good thing or a bad thing.)
- T335851: Investigate the Federated Credential Management browser API
- T345589: Investigate the First-Party Sets / Related Website Sets browser API
- Use popups instead of embedded resources, with requestStorageAccess() which on some browsers (Firefox, at least) have more lax heuristics.
- Replace the current cross-domain authentication flows with something that involves user interaction with the central domain (i.e. users would have to click on the login link, and then maybe click through an interstitial, but wouldn't have to enter their credentials again). Possibly do all that in a popup. There are a number of unrelated reason why we might want to do this. We could use a more standard indentity provider protocol, such as OpenID Connect.
