Page MenuHomePhabricator

Login state not propagated across domains in Safari and in Firefox with strict mode
Open, MediumPublic

Description

[Update] As of Feb 2021, this is now reportedly a problem in Firefox, and will be soon in Chrome.

[Older notes]
As noted at Meta:Babel CentralAuth login state does not seem to propagate across domains in Safari.

Steps to reproduce:

Tested Safari 12.1.1 (14607.2.6.1.1) on macOS 10.14.5. Firefox 67.0.4 on the same machine using the same account retains login across domains just fine.

Is there maybe a cookie issue with Safari's anti-tracking/anti-cookie stuff? Or something that might strike randomly and only happens to be hitting Safari when we're testing it? Is this a known issue I should merge the report with?

SSO, cross domain, requestStorageAccess, hasStorageAccess

Event Timeline

1: yes this is ITP and related policies
2: Firefox has something similiar with Enhanced Tracking Protection (ETP) but this can be bypassed by the user, unlike Safari
3: google chrome will be following with blocking 3rd party cookies

Safari advises using
https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API

We can likely add firefox to this as their ETP becomes full state partitioning
https://hacks.mozilla.org/2021/02/introducing-state-partitioning/

We might be lucky and fall inside the heuristics, but reading that description... I doubt it.

Just noting that there's a thread about this on enwiki. I agree with the sentiment there; this should be triaged as high priority.

I can confirm that this is a problem on Firefox 84 (Debian testing) and Firefox 85 (Ubuntu Groovy)

That seems very wrong, CentralAuth expose my ip address when i try to use mw.ForeignApi in js to read some not user specific data from Wikidata project. I'm logged in at ruwiki.

Quiddity added subscribers: hoo, Quiddity.

Adding Platform team and Hoo_man. (I believe that's the correct tag to use - please fix as needed.)

Quiddity renamed this task from Login state not propagated across domains in Safari to Login state not propagated across domains in Safari and Firefox.Feb 27 2021, 4:12 AM
Quiddity updated the task description. (Show Details)

As far as expected impact @Wugapodes , you said you replicated on FF 84 and 85; was this with default options - or only after making a change such as enabling strict mode over their warning?

That seems very wrong, CentralAuth expose my ip address when i try to use mw.ForeignApi in js to read some not user specific data from Wikidata project. I'm logged in at ruwiki.

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?

The assert=user parameter exists for some requests so maybe edits should pass that cross wiki?

Found this nice resource on storage access technical details, if anyone ever needs to work with that: https://github.com/rchild-okta/itp#storage-access

daniel triaged this task as High priority.Mar 3 2021, 6:39 PM

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.

...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.

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.

tstarling lowered the priority of this task from High to Medium.Mar 5 2021, 4:37 AM
Aklapper renamed this task from Login state not propagated across domains in Safari and Firefox to Login state not propagated across domains in Safari and in Firefox with strict mode.Mar 7 2021, 6:02 PM