Change Details

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} 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 are 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 will be added by {T326281}: 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 will probably fail 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 mitigated by the [[https://www.mediawiki.org/wiki/Extension:CentralAuth/API#centralauthtoken|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 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} * {T345589} * 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.

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} 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}: 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 [[https://www.mediawiki.org/wiki/Extension:CentralAuth/API#centralauthtoken|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} * {T345589} * 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.

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} 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 areused 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 will bewas added by {T326281}: 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 willare 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 [[https://www.mediawiki.org/wiki/Extension:CentralAuth/API#centralauthtoken|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} * {T345589} * 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.