1433679 - Firefox Sync should passively ask for the master password to be unlocked instead of forcing a modal dialog

Status: NEW

(Firefox :: Sync, defect, P3)

Description

[Peter Jenkins]

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0
Build ID: 20180125084229

Steps to reproduce:

Set up firefox sync


Actual results:

Sync causes the password manager to prompt.  The password dialog box pops up at the most inopportune moments.


Expected results:

I would prefer there be something similar to a drop down curtain or similar so you know there is something waiting to be actioned but doesn't scream at you that you have to do it right at this moment.

Comment 1

[Adrian Florinescu [:aflorinescu]]

Peter, could you elaborate a bit where/how the inopportune moments arise, preferably with steps in the section - Steps to reproduce?

Comment 2

[Peter Jenkins]

I have multiple tabs open and have firefox remember my last session.  When I open firefox, if there is a tab which requires a password, even though I haven't clicked on that tab, I will get the prompt to enter my password for sync.

There is no set time when the dialog pops up.  Its random depending on what firefox is doing.  If a page in a tab does require a password, shouldn't the sync dialog only show if I have clicked on the tab to load the page?

Also, does this feature need a dialog?  Could it be a discreet notification which will sit there until the user decides to do something with it?

Comment 3

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

I believe this has nothing to do with restored tabs and is just a side-effect of Sync - it always prompts for the master-password on the first sync as being unlocked is necessary for Sync to work.

However, I agree with your general point and we do already have enough of a framework in place for this.

Ryan, I'm thinking that when Sync tries to start, if it finds the master-password locked we change the hamburger menu to something like the "need to reauthenticate" state, but with the wording on the menu being, say "Unlock master password to sync", and when the user clicks on it, we prompt at that time. We could even introduce a new pref, say services.sync.forceMasterPassword that if set, just works like it does today.

WDYT?

Comment 4

[Ryan Feeley [:rfeeley]]

I'm hesitant to build anything on top of the existing master password as it's sorely needs to be replaced.

However what you have proposed sounds like an intelligent solution, but may involve more UI changes than just the hamburger menu.

Would this state also need to be reflected in other areas of the browser to be feature complete?

- Preferences
- Tools system menubar (currently says Sync Now)
- Synced Tabs menu
- Send to Device menus (incl. context menu)
- Synced Tabs sidebars

If it's true that there may be more involved than the hamburger menu change, is there a simpler solution?

Comment 5

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

(In reply to Ryan Feeley [:rfeeley] from comment #4)
> Would this state also need to be reflected in other areas of the browser to
> be feature complete?

That's a good point. In general, I think it would be fine for the UI to act as though we have yet to Sync for the first time in the hope that the menu is clear.

> - Preferences

I don't think this needs to change.

> - Tools system menubar (currently says Sync Now)

I think that "Sync Now" could still force the MP prompt - it's really just automatic Syncs where it shouldn't IMO.

> - Synced Tabs menu
> - Send to Device menus (incl. context menu)
> - Synced Tabs sidebars

The sidebar and menu are problematic as they both are blank before the first sync under the assumption that the sync will happen very soon - so we'd probably need a new state there and in "send to device"

> If it's true that there may be more involved than the hamburger menu change,
> is there a simpler solution?

Good question :) I can't think of one at the moment.

Also as a "meta" comment:

> I'm hesitant to build anything on top of the existing master password
> as it's sorely needs to be replaced.

I think everyone agrees but AFAIK no work has actually started on that, so I wouldn't be surprised to find we have to live with it for the next year or 2.

Further, any change to master password seems likely to still need an explicit "unlock" process - automatically unlocking would tend to defeat the purpose. So it's probably not wasted work to introduce the concept of a "locked" state even if the MP implementation changes.

Comment 6

[Andy McKay]

We'd need some feedback from the Lockbox team on where the master password is going long term.

Comment 7

[Devin Reams]

>We'd need some feedback from the Lockbox team on where the master password is going long term.

I think Mark's conclusions are right (don't build on top of it as-is, and don't assume it's changing soon).

Master Password is not something we plan to tackle in the short-to-mid term (current year). Based on unrelated discussions with other folks including :Dolske, "business needs" around other browser features may force MP to change sooner than we're prepared to help with or inform, too.

Comment 8

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

To clarify a little. I suspect that regardless of what lockbox does and/or regardless of what improvements are made to the existing master password implementation, there will always be a state which means "the credential store is locked and the user must take some action to unlock them".

Thus, I believe this is generally actionable now and needn't depend on (or be fundamentally broken by) these enhancements. However, it should also be noted that correctly describing this state in the UI isn't trivial.

Comment 10

[Wellington Torrejais da Silva]

I have the same problem, causing:

1580850394823	Sync.Service	DEBUG	Exception calling WrappedLock:
 Error: Login failed: service.master_password_locked(
resource://services-sync/service.js:1041:15)
 JS Stack trace: [e-mail]:1041:15
[e-mail]:452:15
[e-mail]:687:20
[e-mail]:931:10
[e-mail]:718:44
[e-mail]:181:38
[e-mail]:779:39
[e-mail]:454:19
[e-mail]:409:23
[e-mail]:479:26
[e-mail]:166:38
[e-mail]:373:41
1580850394824	Sync.Service	DEBUG	Not syncing: login returned false.

My service file: https://gist.github.com/wellington1993/8cf5c616258a48a682b5790388405a84

Many times...

Thanks!

Comment 11

[Wellington Torrejais da Silva]

Hi,

I read the previously messages.

My modest suggestion is:

First, schedule the Sync to another moment (15/30 seconds per example) aftert the browser start if password "storage" locked.
And notify the user. By menu or other ways.

For notify the necessity of the master password, I suggest:

• A non-block Notification with an icon(Like the sites notifications).
• When browser start with restored tabs, launch with a notification.

When clicked a non blocking modal is showed prompting a master password.
If not clicked, not problem, sync will be scheduled and a notification of schedule will should appear.

My point is:

• Should the Sync be more informative.
• The prompt need to be less blocker, allowing the user to use browser.
• Fix the "errors", expecting that situation in sync proccess.
• More notifications(not invasive).

If necessary, when user cancel the notifications use Mark Hammond [:markh] perfect idea, showing a icon in the hamburger menu.

And still about the non click:

• When sync schedule comes to run, lauch new notifications to ask the password.
• And the sync schedules should will be postponed incrementally.

What did you think?
Thanks!

Comment 12

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

(In reply to Wellington Torrejais da Silva from comment #10)

I have the same problem, causing:

1580850394823	Sync.Service	DEBUG	Exception calling WrappedLock:
 Error: Login failed: service.master_password_locked(

To be clear, you do have a master-password enabled and it does remain locked, right? ie, the log file isn't confused but is accurately reporting reality?

My service file: https://gist.github.com/wellington1993/8cf5c616258a48a682b5790388405a84

Is that different from what's in mozilla-central?

Comment 14

[cupantae]

Hi all,

I have this issue too, I think. Maybe I'm misunderstanding this, but I've seen this "modal dialog" (= pop-up text prompt window?) when I activated master password on my logins, not the sync password. Are we saying it happens when both are enabled?

I want to submit a bug or two. Maybe I can get feedback here or will I just create them?

1. The "master login password" and the "Firefox Accounts / sync password" should be one and the same. The user should have the option to create a local password only, and then it's like the master password, but once the syncing service is enabled, it should be using the same authentication. Does that sound possible? It could possibly fix this bug because you only have 1 password...
2. My preferred behaviour would be that I can fill logins without giving a master password, but that I need to unlock it only to show or copy passwords. I believe that's how chrome works. This is almost a dealbreaker for me. I think this would fix the bug because you're not getting asked for the master password just to allow passwords to flow, just if you want to actually view them.

also
3. Linux authentication still doesn't exist, but what I'd prefer is #1 above ^ and I hear it's broken on windows now too.

Thanks in advance.

Comment 16

[jpluess]

Attachment: Solution-1.png

A solution for a more passive masterpassword

Comment 17

[jpluess]

Attachment: Solution-2.png

A Notification idea if masterpassword is needed

Comment 18

[jpluess]

How is this making progress?

Comment 19

[jpluess]

Any News?

Comment 20

[jpluess]

Who is in charge of this issue? I needs more attention. Thanks

Comment 21

[Steve J]

Hello, this issue is starting to get annoying on Windows Home 64-bit. Most of the time the password prompt pops up several seconds (and sometimes minutes) after opening FF. If I'm not looking at the screen as I type I find the password prompt has stolen my focus. I have entered an incorrect password and have an incomplete fill in the address bar.

Is it possible to use something like SSH Keys on Windows? https://docs.microsoft.com/en-us/windows-server/administration/openssh/openssh_keymanagement

I confess that I haven't researched this in any detail.

Comment 22

[miguel.nuno.ribeiro]

Created an account just to bump this. Modal focus stealing dialogs are the worse, and FF really doesn't deserve this ...

Comment 23

[jpluess]

Is there some News?
If I open FF, and go immediately to show Passwords. to view or copy a password, I get prompted 3 times to enter my Password.
expected result: If I unlock FF I do not want to be asked within a given time. let’s say 3 minutes. within this time, I want full access to manage my passwords. or give me the chance to have a different password to edit passwords. and one to log in to Firefox to just use it for browsing.

Comment 24

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 3 duplicates.
:skhamis, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 25

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Comment 26

[jpluess]

https://connect.mozilla.org/t5/discussions/password-input-needs-attention/m-p/36672#M13186

Comment 28

[Rob N]

Hi,
I have a comment which is from a perspective way back from the intracies of "why we can't do this, or that".

the essence is: IF a person wants to not have their browser actvity tracked and stored in cloud, at any time, they just need to click "sign out", irresepctive if there is a master password or not.

This is much more of a data privacy issue than it is a simple UX annoyance.

Making it, in any part, difficult to turn off sync is a contravention to Mozillas own user data privacy policy. Putting a password in front of the ability to sign out fundamentally makes signing out an undesirable action.

Please, get the simple process of 'signing out' to be easy, not a headache.
Let the user decide and don't obstruct that decision, instead, facilitate it.

Comment 29

[Simon Friedberger (:simonf)]

Hi Rob,

signing out of Firefox Sync is not related to signing you out of websites, deleting cookies or other anti-tracking measures.
Was this a misunderstanding or could you clarify what you mean?

Comment 30

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

I believe Rob is coming here via bug 1864116. Rob, please note that this bug is referring to the general operation of Sync and not about signing out. Let's keep the sign-out specific discussions in that bug.