1864116 - Sync should let you sign out (or at least deactivate) if you have a Primary Password and you cancel out of the Primary Password prompt

Status: NEW

(Firefox :: Sync, defect, P3)

Description

[Daniel Holbert [:dholbert]]

[note: credit to Rob N. for reporting this over in bug 1833050. I filed a fresh bug & duped that bug here to have a clear/concise starting point, since that original bug report took a little bit of a long diagnostic walk before we identified what was actually happening.]

STR:

1. Add a Primary Password (aka Master Password) in Firefox Preferences.
2. Sign in to Firefox Sync.
3. Quit Firefox.

From this point on in the STR, whenever you're prompted for your Primary Password, always cancel out of the dialog. Pretend your primary password is annoying or inconvenient to enter (e.g. it's stored on a USB key in a file cabinet, and you don't expect to have to use it that often, because it's just protecting your passwords for a few sites that don't tend to force you to reauthenticate).

4. Start Firefox. Notice that you now automatically get prompted for your master password. (Cancel out of it.)
5. After realizing that this startup prompt was due to Firefox Sync: try to sign out of Firefox Sync, either at about:preferences#sync or by using the sync toolbar icon "Sign Out" menu-entry.

ACTUAL RESULTS:
If you attempt to sign out of sync (whether via preferences or the toolbar icon), Firefox presents you with another Primary Password prompt. If you cancel out of that one, then sync silently remains signed-in, even though you clicked a Sign Out button. And it will continue to nudge Firefox to prompt you for your Primary Password on every startup.

EXPECTED RESULTS:
We should allow the user to sign out of Sync even if they haven't authenticated with their master password. I'm guessing it's slightly complicated since we want to delete their saved sync credentials; but presumably we could set a simple "user has signed out of sync but we haven't managed to update their password DB" flag somewhere, which we take action on opportunistically the next time the user authenticates with their Primary Password? And if that flag is set, then we could simply behave as if sync is signed out (aside from the fact that we still have now-"stale-and-pending-deletion" credentials saved & protected by the primary password)

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: screencast of final step in STR and "actual results" from comment 0 (sync silently declining to sign out)

Here's a screencast showing how Sync sign-out silently-fails (i.e. you remain signed in), if you decline to enter your primary password when prompted.

(And as a result, you'll continue to be prompted at startup for your primary password, and there's no way to get out of this situation (i.e. no way to remove Sync to stop the Firefox-startup-nag) without relenting and entering your Primary Password in order to let Sync proceed with its sign-out.)

This caused one user much frustration in bug 1833050, though it took a little while to get to the bottom of exactly what was going on (which I've distilled into the STR in comment 0 here).

tl;dr: the Sync-generated instant-Primary-Password-Nag on startup is undeniably a bit annoying; and for users who are annoyed by it, it's even-more-annoying that there's literally no way to get rid of it without relenting and entering your primary password.

Comment 3

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #0)

presumably we could set a simple "user has signed out of sync but we haven't managed to update their password DB" flag somewhere, which we take action on opportunistically the next time the user authenticates with their Primary Password? And if that flag is set, then we could simply behave as if sync is signed out (aside from the fact that we still have now-"stale-and-pending-deletion" credentials saved & protected by the primary password)

I imagine there's also some server-side action we need to take here (which we can only do once we've got the Sync credential unlocked), e.g. removing the device from the "Connected Services" list at https://accounts.firefox.com/settings .

Maybe that server-side action could be handled in some sort of pending/delayed operation as well? Worst-case (and/or perhaps as a first-pass), we could conceivably just leave the entry there indefinitely, just as we do if your Firefox profile gets wiped for whatever reason.

Comment 4

[Rob N]

+1
Yup! That screen cast in comment 0 sums up the issue precisely, and the bug report itself is entirely accurate and concise.
Thank you for un-mincing it all.
Rob

Comment 5

[Mark Hammond [:markh] [:mhammond]]

Note you can't sign in without your master password either and I doubt we are ever going to support that.

The report as written makes it sound like the biggest problem is the user might think they were signed out when they were not. Would an alternative be to simply report to the user that we were unable to sign out?

Comment 6

[Daniel Holbert [:dholbert]]

(In reply to Mark Hammond [:markh] [:mhammond] from comment #5)

The report as written makes it sound like the biggest problem is the user might think they were signed out when they were not. Would an alternative be to simply report to the user that we were unable to sign out?

That would be an incremental clarity improvement -- particularly if we acknowledge that there was a primary-password prompt and explain why we need the user to enter their primary password.[1]

I don't think that's really the biggest problem here, though. The biggest problem is the one-two-punch UX annoyance of new-and-unexpected-nag-prompts (issue #1: the sudden password nags at startup after you sign in to sync. issue #2: the fact that you have to complete a password nag to stop this nagging.)

I believe issue #1 has come up in other bug reports (I recall experiencing/discussing it in the early days of Sync when I used a primary password), and I recall it being architecturally difficult to address while still keeping your sync credentials protected (because users expect Sync to do its job, and it needs access to your sync credentials in order to do that, and those are protected by the primary password).
But issue #2 seems potentially-tractable (and harder to justify as being just-the-way-it-has-to-be), since it's just a user asking Firefox to stop doing something, and it's not obvious why the user must unlock their password store in order for Firefox to stop doing something.

Comment 7

[Mark Hammond [:markh] [:mhammond]]

Issue 1 is largely being tracked as https://bugzilla.mozilla.org/show_bug.cgi?id=1433679

Comment 8

[Rob N]

For my purpose/point of view, signing out of cloud 'anything' should be the easiest thing in the world. One button click and done.
Opting out of sync temporarily should also be as easy as clicking "Pause sync".
It is true, that the only way to achieve this is not to use Sync at all? Or am i getting the wrong idea?
Thanks for looking into this. I realise it's not going to be as easy, but it should still be possible, right?

Comment 9

[Rob N]

(In reply to Mark Hammond [:markh] [:mhammond] from comment #5)

Note you can't sign in without your master password either

Hi Mark.
This is not an issue. The issue is signing out . Without obstruction or hinderence or delay.

Tell us not why it cannot be achieved, instead, tell us what will be done to MAKE IT ACHIEVABLE.

Thank you :)

Comment 10

[Daniel Holbert [:dholbert]]

(In reply to Rob N from comment #9)

tell us what will be done to MAKE IT ACHIEVABLE.

(Just a reminder, see the "no obligation" section on https://bugzilla.mozilla.org/page.cgi?id=etiquette.html -- we're a relatively small team, juggling many priorities, and may not get to any particular bug right away. And in many cases, finding out what can be done to make something achievable is most-of-the-work in fixing the bug.)

Good news, markh and I had a chat about this bug and it looks like this is indeed achievable.

In particular, it looks like Sync-sign-out only uses the primary password for the benefit of the "Delete data from this device" checkbox (which, in order to function thoroughly, requires access to your password vault). This functionality was added in bug 1657463, and from code-inspection, it doesn't look like Sync-sign-out required access to the Primary Password before that point.

So: the fix here will likely be an incremental patch on top of the code added in bug 1657463, to move that prompt closer to when we need it (e.g. when we're preparing to respond to the "delete data" checkbox if it was checked). And we need to warn the user that some data wasn't deleted, if they do check the box and we're unable to access the password database due to the primary password being locked.