https://office.wikimedia.org/.well-known/assetlinks.json links to auth.wikimedia.org but https://auth.wikimedia.org/enwiki/.well-known/assetlinks.json does not link to office.wikimedia.org. It was simpler to do it this way - the DAL files are static Apache files, Apache understands some wiki categories (project families mostly) but not cross-cutting categories like "wikis that use CentralAuth", so if we only to link to auth.wikimedia.org on SUL wikis, we'd have to make assetlinks.json a PHP file which is a significantly bigger maintenance burden. It should be fine - credential sharing only happens when both sites link to each other, one direction is not enough.

But Chrome automatically shares credentials between subdomains of the same parent domain, so I suspect what happens is that previously (e.g.) office.wikimedia.org and en.wikipedia.org didn't share passwords, but now en.wikipedia.org and auth.wikimedia.org share passwords because we explicitly ask for it, and auth.wikimedia.org and office.wikimedia.org share passwords because they have the same parent domain, and password sharing is transitive. If so, I don't think we can do much about it.

For Chrome to autofill a password, it needs to be acknowledged in both directions. It is safe to rely on this, because otherwise Google Chrome would permit third-party sites to steal passwords.

The list that "matters" is https://auth.wikimedia.org/.well-known/assetlinks.json which only includes public open SUL wikis. It does not include office.wikimedia.org or other private/non-SUL wikimedia.org wikis.

The reason officewiki/.well-known indeed responds (as unused static file) is that we share a single docroot for static files.

I have confirmed in my test setup that passwords saved from Wikipedia or Wiktionary in Chrome are not suggested or auto-filled on officewiki.

@JTweed-WMF Can you share a screenshot of these two screens?

1. Log out from officewiki, open https://office.wikimedia.org/wiki/Special:UserLogin, and focus the password field.
2. If it suggests non-officewiki credentials, click Manage passwords. If not, go to Chrome Settings > Autofill passwords > Google Password Manager. Once there, search for these two accounts to determine their associated domain (i.e. where you first saved it) for your officewiki and SUL accounts.

For me:

My theory is that this behaviour is not related to DAL files. I suspect perhaps you (or Chrome, on your behalf) may have, on a recent SUL3 testing activity, re-saved your SUL credentials while logging in via auth.wikimedia.org. And Chrome has (separate from DAL files) a feature of suggesting passwords under the same top-level domain (i.e. *.wikimedia.org).

What DAL files enable is sharing across separate domains, with each relation being tied to a specific subdomain. It does not support wildcards. If this was powered by DAL files, I'd expect it to happen consistently.

I noticed that the old foundationwiki has a separate docroot, which means our unused static files don't mount there by default:

https://foundation.wikimedia.org/.well-known/assetlinks.json (404 Not Found)

This allows for a natural experiment: Try logging in at https://foundation.wikimedia.org/ and see what it does or doesn't suggest.

I did a bit more testing.

In T385520#10615985, @Krinkle wrote:

1. Log in and save on de.wiktionary.org, then log-out.
2. Log in and save on en.wikipedia.org, then log-out.
3. Log in and save on SUL3 auth.wikimedia via test.wikipedia, then log-out.

For all of the above, credentials are auto-filled on de.wiktionary, nl.wiktionary, en.wikivoyage, mediawiki.org, en.wikipedia, commons.wikimedia, and SUL3 auth.wikimedia (e.g. via test.wikipedia). […]

For scenario 1 and 2, I confirmed that credentials are correctly not auto-filled on office.wikimedia.org. In scenario 3, it does. This supports (but not confirms) the theory that this is orthogonal to DAL files.

I tested a fourth scenario:

4. Log in and save on foundation.wikimedia.org, then log-out. (This website lacks a DAL file. Oversight on my part. I'll fix this next week. But makes for a useful test right now!)

The credentials were correctly not auto-filled on any of de.wiktionary, nl.wiktionary, en.wikivoyage, mediawiki.org, or en.wikipedia. However, they did get included on office.wikimedia.org.

I believe this confirms the hypothesis that this is a pre-existing Chrome feature.Indeed, if you save your password on commons.wikimedia.org or meta.wikimedia.org (rather than a language project like en.wikipedia), this is suggested on private wikis, too.

Summary

Audience 1: Chrome users who saved their Wikimedia global account password (and are not a member of a private wiki).

• Previously: Chrome only auto-filled your password on language editions of the project where you first logged-in and clicked "Save". It did not auto-fill on sister projects. You may have entered and saved duplicate copies of your credentials for some projects.
• Today: Thanks to T385520, Chrome now auto-fills credentials from and on any public Wikimedia wiki. For example, if you saved your password on Wikipedia, it is now also auto-filled on Wiktionary, Wikidata, and Commons.

Audience 2: Chrome users who saved their Wikimedia global account password and are member of a private wiki.

• If you're a member of a private wikimedia.org wiki and saved your password there, then Chrome also included these in the suggestions when logging in on Commons, Meta-Wiki, or another public .wikimedia.org wiki. This remains unchanged. They also remain not suggested on Wikipedia and sister projects.
• If you saved your SUL password from a public .wikimedia.org wiki (rather than from Wikipedia, or another project with its own domain), then these were also included in the suggestions on private wikimedia.org wikis. This also remains unchanged.

Audience 3: Chrome users who have not saved their Wikimedia global account password, and are member of a private wiki, but who adopt Chrome's password manager in the future.

• SUL3 will move the login screen to auth.wikimedia.org. If you already saved your password pre-SUL3, then this is auto-filled on auth.wikimedia.org, too. However, since it wasn't saved from here, it remains un-associated with wikimedia.org, and thus is not and remains not suggested on private wikimedia.org wikis.
• If you haven't saved your password so far, but click Save" in the future when logging in with your Wikimedia global account on auth.wikimedia.org, this will be included in the suggestions on a private wikimedia.org wiki.

The number of people who are member of a private WMF wiki, and use Chrome, and don't use its password manager today, but will do so in the future, is probably quite small. However, it does apply to future hires to WMF staff and future elected community members, which makes it likely we'll hear about it.

Chrome's UI does indicate the source of such a suggestion, however: