1600416 - It's surprising that autogenerating a password in a private window saved the password

Status: RESOLVED WORKSFORME

(Toolkit :: Password Manager, defect, P1)

Description

[(no longer active)]

When we autogenerate a password in a private window, we currently show the blue UI that says the password has been saved, and save it in the login manager. This leaks the fact that the user has been visiting that website. We should stop doing this automatically to fix this privacy bug. We should also think about the usability aspects of this scenario probably outside the scope of this bug.

STR:

1. In a new profile on Nightly, open a private window.
2. Go to a page like https://github.com/join and right click on the password field and select "Use a Securely Generated Password".
3. In a new tab go to about:logins.
4. Search for github.com. There will be an entry there.

[Tracking Requested - why for this release]:
This is a violation of private browsing mode. I haven't tested the older versions and I'm not sure exactly what the affected versions are...

Comment 1

[(no longer active)]

Sorry, I filed the bug with the wrong summary, since initially I misunderstood what's happening...

Comment 2

[Julien Cristau [:jcristau]]

Is the summary now missing a "not"?

Comment 3

[Matthew N. [:MattN]]

I'm also confused about this bug but I think it's a dupe of bug 1598717. We just added support for private browsing by informing the user that the generated password will be saved (in most cases).

Comment 4

[(no longer active)]

Yes, I was missing a "not", sorry about that.

This bug is about ensuring that we don't store passwords in the login manager when using a generated password in a private window. I just tested to ensure the STR from comment 0 is valid in the latest Nightly.

Based on my reading of bug 1566536, this bug is still valid after that bug.

Please note that the semantics of private browsing are such that we allow saving of data which the user explicitly asks Firefox to save, based on the assumption that the user wouldn't find it surprising that Firefox saved something they asked it to save. Examples include bookmarks and downloads. Data that will be saved as a result of implicit actions (such as the password in this case) should not be saved automatically in private browsing mode in a way that reveals the user's browsing history.

Comment 5

[Matthew N. [:MattN]]

(In reply to :ehsan akhgari from comment #4)

Please note that the semantics of private browsing are such that we allow saving of data which the user explicitly asks Firefox to save, based on the assumption that the user wouldn't find it surprising that Firefox saved something they asked it to save. Examples include bookmarks and downloads.

That's exactly why we just changed the UI to make this case "explicit" before enabling the feature in private windows.

Data that will be saved as a result of implicit actions (such as the password in this case) should not be saved automatically in private browsing mode in a way that reveals the user's browsing history.

The user must click on the row that says "{brandShorterName} will save this password for this website.". Why is that not sufficient?

P.S. I thought about confirming this new behaviour with you but decided against it since it seemed clear to me that this would align with bookmarks, also because my understanding is that nobody properly owns PB now.

Comment 6

[(no longer active)]

I filed this bug originally because I myself got caught by surprise and did not notice that this prompt says "Firefox will save this password for this website." The second time when looking at the screenshot posted in bug 1566536 I also did not notice this text. It wasn't until the third time I looked at the screenshot this time looking for the details of the UI that I noticed the text. Perhaps this is an anecdote but I filed the bug anyway.

Do you believe the current UI is noticeable enough to turn this into an explicit action?

Comment 7

[Timea Cernea [:tbabos][inactive]]

QA would like to inquire if there are any plans to accommodate this fix into Fx72 timeline since it would most likely affect user flows. Please note that if a decision to accommodate this fix for Fx72 timeline is reached, QA would need to update the user flows and also probably delay the preliminary testing, which is due next EOW.

Comment 8

[Julien Cristau [:jcristau]]

updating status flags since 70 and 71 don't generate passwords in private windows.

Comment 9

[Matthew N. [:MattN]]

(In reply to :ehsan akhgari from comment #6)

I filed this bug originally because I myself got caught by surprise and did not notice that this prompt says "Firefox will save this password for this website." The second time when looking at the screenshot posted in bug 1566536 I also did not notice this text. It wasn't until the third time I looked at the screenshot this time looking for the details of the UI that I noticed the text. Perhaps this is an anecdote but I filed the bug anyway.

Did you not notice the blue toast by the key icon in the address bar saying "Password saved!" either?

Do you believe the current UI is noticeable enough to turn this into an explicit action?

Yes, with a combination of factors:
a) The text on the autocomplete row itself is clear.
b) The user will also see a blue "Password Saved!" toast making it clear that it was saved if they didn't notice the text
c) Users who have already used the password generation feature in non-private windows would have learned by now that it auto-saves the password.

Do you have any suggestions to make this more clear? In theory we could add a separate preference for this but I don't think that's a good idea as users would have no reason to seek it out so it would never get used. I did suggest to UX that perhaps the key icon in autocomplete could be improved to indicate that it's different than the other rows, perhaps with some kind of icon implying it saves though I'm not sure there are great ideas there.

(In reply to Timea Cernea [:tbabos] from comment #7)

QA would like to inquire if there are any plans to accommodate this fix into Fx72 timeline since it would most likely affect user flows. Please note that if a decision to accommodate this fix for Fx72 timeline is reached, QA would need to update the user flows and also probably delay the preliminary testing, which is due next EOW.

This bug effectively says to backout bug 1566536 and I don't think we're at that point yet.

Comment 10

[(no longer active)]

Attachment: Safari screenshot

(In reply to Matthew N. [:MattN] (PM me if requests are blocking you) from comment #9)

(In reply to :ehsan akhgari from comment #6)

I filed this bug originally because I myself got caught by surprise and did not notice that this prompt says "Firefox will save this password for this website." The second time when looking at the screenshot posted in bug 1566536 I also did not notice this text. It wasn't until the third time I looked at the screenshot this time looking for the details of the UI that I noticed the text. Perhaps this is an anecdote but I filed the bug anyway.

Did you not notice the blue toast by the key icon in the address bar saying "Password saved!" either?

I did notice that, and at first my eyes just ignored it. After a few minutes, something went off in my mind saying "wait a minute, was I not in a private window? why did Firefox save the password?!"... which resulted in trying to reproduce the issue (where I again didn't see the notice on the in-content drop-down) and filing this bug.

Do you believe the current UI is noticeable enough to turn this into an explicit action?

Yes, with a combination of factors:
a) The text on the autocomplete row itself is clear.

FWIW this, at least for me, was not an issue of the clarity of the text. But rather an issue of the visibility of the text. Perhaps a matter of low contrast against the background, or being at the bottom of much higher contrast text?

Previously when I said I didn't notice the text I meant I quite literally did not see it.

b) The user will also see a blue "Password Saved!" toast making it clear that it was saved if they didn't notice the text

By which time it will be too late to do anything about it, unless if the user understands how to clean up after the fact in about:logins.

c) Users who have already used the password generation feature in non-private windows would have learned by now that it auto-saves the password.

Do you have any suggestions to make this more clear? In theory we could add a separate preference for this but I don't think that's a good idea as users would have no reason to seek it out so it would never get used. I did suggest to UX that perhaps the key icon in autocomplete could be improved to indicate that it's different than the other rows, perhaps with some kind of icon implying it saves though I'm not sure there are great ideas there.

This is a tricky problem... I admit that I don't have any great ideas here.

Is it possible to change the way that the interaction works in private windows more substantially compared to how it is in non-private windows? For example, would it be possible to switch to saving the password after the fact if the user is in a private window, just like what would have happened if they had typed in a password manually? I suppose doing that would require somehow warning the user about the fact that taking no action would mean losing this generated password, and probably making their account unusable.

Another thing to look into is how well other people would notice the text in the drop-down UI that tells the user that their password is being saved. After all we shouldn't decide to change the UI just based on my experience. :-)

BTW, I was also curious to see how Safari handles this. They show the same UI in private and non-private windows alike, though I find the design of their UI makes it a little bit harder to ignore the text, but on the other hand it has a longer piece of text which the user may just tune out and not read.

Comment 11

[Matthew N. [:MattN]]

Re-summarizing this to reflect the current issue.

Comment 12

[Matthew N. [:MattN]]

OK, after many discussions with UX we have a proposed solution to this problem but it requires a significant change to the password generation flow in both PB/non-PB modes so it's not something we would uplift. Instead we will backout this new ability from beta once I confirm with product that they are okay with this.

Comment 13

[Matthew N. [:MattN]]

I just wanted to reply to one piece:

(In reply to :ehsan akhgari from comment #10)

b) The user will also see a blue "Password Saved!" toast making it clear that it was saved if they didn't notice the text

By which time it will be too late to do anything about it, unless if the user understands how to clean up after the fact in about:logins.

I think it would be a failure (to address) if users are saving passwords and not knowing how to manage them since we have made them much more discoverable in the last year and we have seen a significant increase (5x from Fx67 alone) in the number of users who have accessed the saved logins UI as a result.

Comment 14

[Matthew N. [:MattN]]

We've spent many hours discussing and designing potential solutions but it sounds like we are leaning towards shipping this as-is because we feel like the chance of a user auto-saving a password and not noticing or being able to delete it is low. Users also have the option to disable the whole password generation feature if they want.

One idea I had that isn't exactly addressing the specific problem you mentioned: we could choose to not offer the generation option for autocomplete="new-password" in private windows and therefore require the context menu to be used, thus reducing accidental usage.

Comment 15

[(no longer active)]

(In reply to Matthew N. [:MattN] (PM me if requests are blocking you) from comment #14)

One idea I had that isn't exactly addressing the specific problem you mentioned: we could choose to not offer the generation option for autocomplete="new-password" in private windows and therefore require the context menu to be used, thus reducing accidental usage.

Hmm, that seems not all that much different to me than disabling the generation option altogether, given how non-discoverable context menu item additions are... I tend to think that if we have come to the decision to keep the feature working as it is we should let users use it. Building the feature and hiding it in a way that most users won't find it seems like the worst available option!

Comment 16

[Matthew N. [:MattN]]

(In reply to :ehsan akhgari from comment #15)

(In reply to Matthew N. [:MattN] (PM me if requests are blocking you) from comment #14)

One idea I had that isn't exactly addressing the specific problem you mentioned: we could choose to not offer the generation option for autocomplete="new-password" in private windows and therefore require the context menu to be used, thus reducing accidental usage.

Hmm, that seems not all that much different to me than disabling the generation option altogether, given how non-discoverable context menu item additions are... I tend to think that if we have come to the decision to keep the feature working as it is we should let users use it. Building the feature and hiding it in a way that most users won't find it seems like the worst available option!

The ideas was to address a user accidentally triggering that option in a private window e.g. a mis-click of the mouse or bump of the keyboard… it's much harder to accidentally open the context menu and choose the generation option. As long as the generation in autocomplete UI is limited to sites using autocomplete="new-password" this won't make it that much less discoverable since it's already rarely seen. We are hoping to implement bug 1595244 soon though which should make the autocomplete option much more common.

I guess I'll close this for now then since it sounds like we don't want to change the behaviour specifically for PB.