1340949 - The Sync "Manage Account" link doesn't work properly with First-Party Isolation

Status: RESOLVED FIXED

(Firefox :: Firefox Accounts, defect, P3)

Description

[Ryan Kelly [:rfkelly]]

See related discussion in Bug #1323853, where we had similar issues with Private Browsing mode.

STR:

1. Sign in to Sync in your browser
2. Open Preferences -> Sync, and click on "Manage Account"
3. Observe that you're taken to the FxA settings page on the web
4. Open about:config and toggle `privacy.firstparty.isolate` to `true`
5. Return to Preferences -> Sync, and click on "Manage Account" again
6. Observe that you're prompted to sign in, because the web content on accounts.firefox.com "doesn't know" that you're signed in to the browser itself

I assume this has to do with changes to the behaviour of localStorage, of the same sort that cause Bug 1308038.  We currently use localStorage on accounts.firefox.com to share login state between the browser and web content.

ISTM that "manage account" should Just Work regardless of the first-party isolation pref, but it's not clear to me yet exactly what we need to do to fix it.  It's possible that just adding a webchannel handshake between accounts.firefox.com and the browser (as in Bug 1308038 Comment 18) will do the right thing here.

You can observe another implication of the current approach by doing the following:

0. Reset `privacy.firstparty.isolate` to `false`
1. Sign in to Sync in your browser
2. Navigate to https://addons.mozilla.org and click on "log in"
3. Observe that you can login without re-entering your password, because we know you're already signed in in the browser
4. Open about:config and toggle `privacy.firstparty.isolate` to `true`
5. Navigate to https://addons.mozilla.org in this private window and click on "log in"
6. Observe that you're prompted to sign in again, because the web content on accounts.firefox.com "doesn't know" that you're signed in to the browser

I don't know enough about the intended semantics of first-party isolation, to know whether this is appropriate behaviour.  Tom, Ehsan recommended I ask you about first-party isolation stuff, could you please weigh in on whether the above STR seem like the right behaviour when this pref is enabled?

Comment 1

[Tom Ritter [:tjr]]

I'm switching the NI to Georg because I think he'll have a better answer than me. FWIW, I don't think Tor Browser really supports using Firefox Sync or Firefox Accounts in Tor Browser, although it does kind of work.

As far as my opinion goes; however - this is appropriate behavior. One signs into the browser itself for two purposes (AFAIK):
1. To auto-login to Mozilla related services
2. To sync data between Firefox instances (tabs, passwords, etc)

The point of First Party Isolation is (technically speaking) to scope data by the URL bar domain. But conceptually, it's to make it so a user's browsing is isolated per 'logical entity'. If I visit a.com and b.com and each has a Facebook widget, Facebook can't correlate me between the two visits using any history, cookies, cached HSTS trickery, or whatever.  

Extending that to this situation - for users whose primary intention is to do (2) they automatically get (1) by accident and that breaks First Party Isolation if you consider 'The User's Browser' and 'Mozilla Services' as separate 'logical entities'. And I think we should. FPI can be a signal saying "I don't want my history or logged in status following me around the web" and I think Mozilla should respect that.

Comment 2

[Ryan Kelly [:rfkelly]]

FWIW this seems reasonable to me; we might consider adding some explicit tests to ensure we don't regress this behaviour with any future changes we make to the FxA integration in the browser.

Comment 3

[Georg Koppen]

(In reply to Tom Ritter [:tjr] from comment #1)
> I'm switching the NI to Georg because I think he'll have a better answer
> than me. FWIW, I don't think Tor Browser really supports using Firefox Sync
> or Firefox Accounts in Tor Browser, although it does kind of work.

That's actually a pretty good answer you gave. :) Just to the sync support point: we have not reviewed and audited Sync yet (https://trac.torproject.org/projects/tor/ticket/10368). So, while not disabling it we hide it from users removing the obvious hints for it in the UI. Looking at older Tor Browser bugs it seems it should work but users need to jump through some hoops before getting there.

Comment 4

[Ryan Kelly [:rfkelly]]

I believe this bug is now fixed; we added a special WebChannel handshake for you visit the "Manage Account" link from preferences, which means that we get your login state directly from the browser rather than from first-party-isolated localStorage.  This handshake *doesn't* kick in when accessing OAuth reliers.

I'm going to close this, but please re-open if the current behaviour doesn't seem to be what we want, as described in Comment 1.