| Tgr | |
| Feb 3 2025, 8:08 PM |
| F58477536: Screenshot 2025-02-24 at 14.53.08.png | |
| Feb 24 2025, 2:53 PM |
| F58477504: Screenshot 2025-02-24 at 14.49.04.png | |
| Feb 24 2025, 2:53 PM |
| F58477467: Screenshot 2025-02-24 at 14.39.12.png | |
| Feb 24 2025, 2:46 PM |
| F58477466: Screenshot 2025-02-24 at 14.40.32.png | |
| Feb 24 2025, 2:46 PM |
| F58477465: Screenshot 2025-02-24 at 14.39.02.png | |
| Feb 24 2025, 2:46 PM |
| F58477477: Screenshot 2025-02-24 at 14.43.45.png | |
| Feb 24 2025, 2:46 PM |
| F58477483: Screenshot 2025-02-24 at 14.45.52.png | |
| Feb 24 2025, 2:46 PM |
Seamless credential sharing (docs, blog) allows sharing Google Password Manager credentials between multiple websites, or a website and an Android app.
See also: T384844: Ensure auth.wikimedia.org is added to shared-credentials list in password managers
Each participating website needs to serve .well-known/assetlinks.json, with the primary site (in our case this would be auth.wikimedia.org) listing all the sites it shares passwords with, and the other sites listing the primary site. The format can be seen here: https://developers.google.com/identity/credential-sharing/example-multiple-websites
The docs don't link to it, but this now-archived repository seems to come the formal specification; it says that websites need to be listed in the form of fully qualified domains (so individual wikis, not wiki families). Since we have ~1000 wikis, that's a little unwieldy at best, and might hit some undocumented size limit on Chrome / Android. (We could try to reach out to Google and clarify.) There is some documentation about scaling but doesn't exactly clarify how far things can be scaled.
Btw the blog post says "When two websites are in the same-site relationship, Chrome will show autofill credentials for the other site if there's at least one credential saved on one site." (Same-site roughly means they share a parent domain.) So maybe if sites A and B use seamless credential sharing and sites B and C are same-site, Chrome will also show credentials for C when logging in on A? It doesn't really fit with how domain handling is documented in the spec, though.
Btw2 it also says "It may take a while for Googlebot to fetch the resource and recognize the association." so this whole thing might be too slow to be useful for the SUL3 migration.
Credentials sharing between the website and the official Android app is more interesting since it would remain useful even after the SUL3 migration has finished; but setting it up is doubly slow since the app manifest also needs to be changed and that change needs to be picked up by the users.
In terms of implementation difficulty, referring to the primary site, or to the app, is just a static .well-known file, trivial to write and deploy. The primary site referring back to the other sites means a list of all wikis would have to be maintained. But since the connection between websites is only really useful during the SUL3 migration, there is probably not much point in keeping it up-to-date, and it's also just a static file. So this would be quite easy to do, not sure how much it would help though.
Change #1119739 had a related patch set uploaded (by Krinkle; author: Krinkle):
[operations/mediawiki-config@master] docroot: Add experimental assetlinks.json from and to various domains
Change #1119739 merged by jenkins-bot:
[operations/mediawiki-config@master] docroot: Add experimental assetlinks.json from and to various domains
Mentioned in SAL (#wikimedia-operations) [2025-02-17T15:59:03Z] <krinkle@deploy2002> Started scap sync-world: Backport for [[gerrit:1119739|docroot: Add experimental assetlinks.json from and to various domains (T385520)]]
Mentioned in SAL (#wikimedia-operations) [2025-02-17T16:02:55Z] <krinkle@deploy2002> krinkle: Backport for [[gerrit:1119739|docroot: Add experimental assetlinks.json from and to various domains (T385520)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)
Mentioned in SAL (#wikimedia-operations) [2025-02-17T16:11:56Z] <krinkle@deploy2002> Finished scap sync-world: Backport for [[gerrit:1119739|docroot: Add experimental assetlinks.json from and to various domains (T385520)]] (duration: 12m 53s)
Change #1120216 had a related patch set uploaded (by Krinkle; author: Krinkle):
[operations/puppet@production] mediawiki: Add rewrite rule to fix serving of /.well-known static files
Change #1120216 merged by RLazarus:
[operations/puppet@production] mediawiki: Add rewrite rule to fix serving of /.well-known static files
Mentioned in SAL (#wikimedia-operations) [2025-02-20T17:10:57Z] <rzl@deploy2002> Started scap sync-world: T385520
Mentioned in SAL (#wikimedia-operations) [2025-02-20T17:12:26Z] <rzl@deploy2002> rzl: T385520 synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)
Mentioned in SAL (#wikimedia-operations) [2025-02-20T17:19:23Z] <rzl@deploy2002> Finished scap sync-world: T385520 (duration: 09m 01s)
Success! The autofill is now working in Chrome.
In terms of UI, Chrome adds a little caption indicating where the password was first saved.
When I save it on www.mediawiki.org:
When I save it on en.wiktionary.org instead:
I've also confirmed that, as we already suspected, Chrome does not automatically include subdomains under the same registrable domain (eTLD+1, public suffix). In the above experiment, I did not include de.wiktionary.org and there's indeed no autofill there.
And, perhaps more importantly, when you originally save your password on de.wiktionary.org, it does not get auto-filled on any of the other top-level domains like wikivoyage.org, auth.wikimedia.org, commons.wikimedia.org, or www.mediawiki.org.
One thing that Chrome does seem to offer by default, after one extra click, is auto-fill on sibling subdomains. This doesn't help us, but it is interesting to know. This means that even when there is no DAL associating or claiming the domain in either direction, Chrome will still suggest a password previously saved on de.wiktionary.org, when logging in on another *.wiktionary.org domain:
Change #1123810 had a related patch set uploaded (by Krinkle; author: Krinkle):
[operations/mediawiki-config@master] docroot: Enable Chrome credential sharing on all open SUL wikis
Change #1123810 merged by jenkins-bot:
[operations/mediawiki-config@master] docroot: Enable Chrome credential sharing on all open SUL wikis
Mentioned in SAL (#wikimedia-operations) [2025-03-04T21:04:09Z] <jforrester@deploy2002> Started scap sync-world: Backport for [[gerrit:1123810|docroot: Enable Chrome credential sharing on all open SUL wikis (T385520)]]
Mentioned in SAL (#wikimedia-operations) [2025-03-04T21:07:11Z] <jforrester@deploy2002> jforrester, krinkle: Backport for [[gerrit:1123810|docroot: Enable Chrome credential sharing on all open SUL wikis (T385520)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)
Mentioned in SAL (#wikimedia-operations) [2025-03-04T21:14:42Z] <jforrester@deploy2002> Finished scap sync-world: Backport for [[gerrit:1123810|docroot: Enable Chrome credential sharing on all open SUL wikis (T385520)]] (duration: 10m 33s)
We had some issues today, filed T388222: Remove(?) Office wiki from DAL as it's not an SUL wiki
We should add a Tech News entry about this. Suggestion:
The hints we give for password managers about reusing passwords across domains have recently been updates, so some password managers might now offer you login credentials that you saved for a different Wikimedia site. (Some password managers already did this, and are now doing it for more domains.) (1, 2)
Thanks for the draft! I propose this slightly adjusted version. Please let me know if this is un/suitable, or if any corrections are needed.
Editors who use password manager software at multiple wikis may notice changes in the future. The way that our wikis provide information to password managers about reusing passwords across domains has recently been updated, so some password managers might now offer you login credentials that you saved for a different Wikimedia site. Some password managers already did this, and are now doing it for more Wikimedia domains. This is part of the SUL3 project which aims to improve how our unified login works, and to keep it compatible with ongoing changes to the web-browsers we use. [1] [2]
Editors who use password manager software
This is true for some standalone password managers as well, but also built-in password managers in Chrome etc. Not sure if the wording conveys that? I would associate from "password manager software" to standalone desktop apps like 1Password, but it might just be me. Otherwise, looks good, thanks.
Thanks again! I've removed the word "software", and added the entry in https://meta.wikimedia.org/wiki/Tech/News/2025/11
Confirmed to work as expected in both directions, including for Wikipedia, with these test cases:
For all of the above, credentials are then auto-filled on de.wiktionary, nl.wiktionary, en.wikivoyage, mediawiki.org, en.wikipedia, commons.wikimedia, and SUL3 auth.wikimedia (e.g. via test.wikipedia). I wiped the password manager between test cases.
Change #1129922 had a related patch set uploaded (by Krinkle; author: Krinkle):
[operations/mediawiki-config@master] docroot: Enable Chrome credential sharing on foundation.wikimedia.org
Change #1129922 merged by jenkins-bot:
[operations/mediawiki-config@master] docroot: Enable Chrome credential sharing on foundation.wikimedia.org
Mentioned in SAL (#wikimedia-operations) [2025-03-21T22:31:57Z] <krinkle@deploy1003> Started scap sync-world: Backport for [[gerrit:1129922|docroot: Enable Chrome credential sharing on foundation.wikimedia.org (T385520)]]
Mentioned in SAL (#wikimedia-operations) [2025-03-21T22:36:52Z] <krinkle@deploy1003> krinkle: Backport for [[gerrit:1129922|docroot: Enable Chrome credential sharing on foundation.wikimedia.org (T385520)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)
Mentioned in SAL (#wikimedia-operations) [2025-03-21T22:58:11Z] <krinkle@deploy1003> Finished scap sync-world: Backport for [[gerrit:1129922|docroot: Enable Chrome credential sharing on foundation.wikimedia.org (T385520)]] (duration: 26m 14s)
The commit message for rOMWCc79785f742ec: docroot: Enable Chrome credential sharing on all open SUL wikis implies that we want to keep the DAL files forever, but do we really want to do that? Once we moved everything to the authentication domain, there's not much benefit to password sharing, and it would make phising via a hijacked non-MediaWiki wikimedia.org subdomain easier. If we remove the files after a year, users who haven't logged in during that time (and so don't continuously use the site, since logins expire in a year) would have to find the correct password manually, but that seems like a reasonable tradeoff.
Although I suppose if Chrome shares passwords between same-site subdomains anyway, that concern is moot.
I think I'm misunderstanding you. Allow me to stretch this to expose my misunderstanding, and then you can correct me. It sounds like you're saying that, so long as I smoothly log in once on SUL3 with the help of DAL files in Chrome, I'll stay logged in forever? Afaik our sessions last 7 days, "Remember me" 1 year. Maybe "Remember me" cookies could be prolonged while browsing logged-in. Browsers may still wipe all web cache and cookies after 2-3 weeks of not visiting a site, even if we ask for 1y, especially on mobile. People may switch browsers, buy new devices; they rely on their password manager to login.
Hmm...
Or... maybe you think password managers update their database after auto-fill from a new domain? In my testing, I did not see password managers do or offer that.
Yeah I assumed the password manager would add the new domain (or at least ask). Haven't actually checked though.