702925 - "Forget About This Site" shouldn't delete saved passwords (without a prompt?)

Status: RESOLVED FIXED

(Toolkit :: Data Sanitization, defect, P3)

Description

[ydsujffx]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20100101 Firefox/8.0
Build ID: 20111104165243

Steps to reproduce:

I used the "Forget About This Site" option in the history item of a site for which I had saved a username and password.


Actual results:

The password for this site was deleted without a warning!


Expected results:

Firefox should have warned that I have a saved password for this site and should have asked if I want to delete the password for this site.

In my opinion this is a severe data loss. "Forget About This Site" doesn't delete bookmarks without a warning. And since saved passwords are more important (since if you loose them you may not be able to find them again) than bookmarks it shouldn't delete saved password either without a warning.

Comment 1

[Parashar]

Since "Forget About This Site" feature is accessible from various places, "History" and "about:permissions" are the two that I know of (there might be more !?), it might not be clear to the user that using this feature will delete the site specific data from various places (eg: Cookies, Passwords, Bookmarks, History).

Especially, the first time users of this feature (like me) might not expect that it would remove the bookmarks as well. The user might be shown a warning/form to select which items to clear like the way we get for "Tools > Clear Recent History...".

Comment 2

[Necmettin Begiter]

Kubuntu 12.04 x64 Firefox 14.0.1, same behavior. 

Here is the behavior I would expect:
When I click on "forget about this site" in History, it should either delete only history entries or ask me what else I want removed about this site. It deleted my passwords for that site, but I was only trying to find a site in History.

Comment 3

[Bob Clary [:bc] (inactive)]

This bit me this evening and it was a pita. Confirming and Nominating for Firefox 29 if not sooner.

Comment 4

[Benjamin Kerensa [:bkerensa]]

Given this is such an old bug were not going to track this for release but CC'ing Gavin to see what the plan is for this bug.

Comment 5

[Marco Mucci [:MarcoM]]

Removed from Backlog and marked as 'Wontfix' based on team feedback from the point estimation meeting.

Comment 6

[Matthew N. [:MattN]]

Since we don't remove bookmarks I think we should revisit this. A solution that addresses both sides would be to show a dialog to ask whether to delete or keep the saved logins if we detect there are some.

Comment 9

[watchman]

I filed a report which has been closed as a duplicate of this. Reference https://bugzilla.mozilla.org/show_bug.cgi?id=1656646

My point was different. I pressed the cancel button when I had entered about one-third of my master password. My legitimate expectation was that would end the process but the process continued as though I had entered the master password. I have not tested other situations where the master password is sought.

In my case, fortunately, no saved password was deleted but my log-in to the site was cancelled which presumably means that cookies were deleted. It seems to me that we would be better off 1 without the option "forget this site", 2 if 'cancel' meant cancel and 3 if the master password was actually required when it is requested.

Comment 11

[vasileios.revelas]

I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1727267 because of this issue. I had all passwords for multiple subdomains on an entire internal domain deleted when I was using the right click "forget about this site" in my history pane thinking it just cleared history and cookies.

Comment 14

[hjp]

I filed #1735532 today. That was rejected as WONTFIX. Not entirely happy about that but I agree that not deleting passwords would at least minimize the damage.

Comment 16

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

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

For more information, please visit auto_nag documentation.

Comment 17

[Emma Zühlcke [:emz]]

S3 seems appropriate. While the mechanism isn't ideal, we have added a warning / confirmation prompt.

Comment 18

[Tony Davis]

Is it known yet when this added warning change will be available to users? e.g. FF100+ and Nightly?

Actually this would be a good opportunity to make this function really good and user friendly, by adding setting tick-boxes, like FF does with the clear cache. For example, separate options for history, cookies, bookmarks, AND of course the password(s).

This will show up-front WHAT the scope of this "Forget Site" function is, as not even tech users are fully aware, and give users more control.

Of course, still keep the confirmation prompt, even with the tick box off for passwords (if implemented), as these are important (as with any good password manager, as the Firefox one undoubtedly is).

Comment 19

[Tony Davis]

Apologies for the typo in my comment above, the last line should have read:
"even with the tick box ON for passwords (if implemented)."

Comment 20

[Emma Zühlcke [:emz]]

Bug 1711759 added the warning, since Firefox 93. As for allowing users to decide if passwords or bookmarks are also cleared, I think it's a good idea, but there is no timeline for it yet. It's also quite hard to get right. For example: What should be the default for these checkboxes, checked or unchecked?

Comment 23

[Alexander Balagurov]

Word "Site" != "domain" !!!
Clearing data for SITE sitename1.domain.tld clears EVERYTHING about domain.tld including other subdomains. It's very unintuitive because site and domain is different mentions and they shouldn't be messed up even with popup - why are other subdomains is affected - they are different sites!

Comment 24

[Emma Zühlcke [:emz]]

I'm afraid site doesn't have the same meaning universally - I can see how this is confusing.
Spec-wise a site does actually contain the base domain / registrable domain, see https://html.spec.whatwg.org/#obtain-a-site

I think we want to remove password clearing and improve our language a bit so it's more clearer to users that we include subdomains when clearing data.

Comment 25

[Alexander Balagurov]

(In reply to Paul Zühlcke [:pbz] from comment #24)

I'm afraid site doesn't have the same meaning universally - I can see how this is confusing.
Spec-wise a site does actually contain the base domain / registrable domain, see https://html.spec.whatwg.org/#obtain-a-site

I think we want to remove password clearing and improve our language a bit so it's more clearer to users that we include subdomains when clearing data.

Why just not threat site as it is - as a single application with given address. Domain, subdomain, whatever. Of course it's cheapest approach to remove all the data with given domain, but parent and other subdomains might not be related to particular site pretty frequently

Comment 26

[Alexander Balagurov]

I mean "treat" of course, sorry for typo

Comment 27

[gwarser]

The whole point of this option is to delete the whole data for domain, I would not like it working in different/more specific way.

But.

I understand passwords more like "web browser data", not page/domain data. Passwords should not be deleted.

Comment 28

[Alexander Balagurov]

(In reply to gwarser from comment #27)

The whole point of this option is to delete the whole data for domain, I would not like it working in different/more specific way.

But.

I understand passwords more like "web browser data", not page/domain data. Passwords should not be deleted.

In my case, there was a slow script on one of the pages on the dev subdomain that was slowing down the whole browser and I couldn't even open the developer tools, so I decided to clear its data. I copied the password, but I couldn't assume that I would lose the data of 100+ other dev sites on the same domain

Comment 29

[Tony Davis]

I noted that gwarser stated "The whole point of this option is to delete the whole data for domain". Is this really the correct intended design for this option? DEV sites could have many sub-domains, and even developers are finding that this can remove a whole bunch of passwords unexpectedly. This is really leaving "banana skins" on the floor of the excellent Password Manager in Firefox, and may cause a negative perception of its robustness, and usability, and end up tarnishing its reputation. I know it is NOT the fault of the password manager, but non-techie users might not see it that way! Can someone on the internals of this, please revisit the design specs, and see if 1) it IS designed correctly 2) does NOT cause any interference or conflicts (or unexpected behaviours) in other areas, e.g. Password Manager. Thanks.

Comment 30

[Alexander Balagurov]

(In reply to Tony Davis from comment #29)

DEV sites could have many sub-domains, and even developers are finding that this can remove a whole bunch of passwords unexpectedly.

We saw this earlier in password suggestions where you have a bunch of user/passwords suggestions from entire domain, which is luckylly can be disabled because it's useless. Even the saving password prompt still mentioning parent domain while saving user/password pair for subdomain. IMO firefox for now doesn't make the difference between domains and subdomains even in strings definitions

Comment 31

[Ben Dean-Kawamura [:bdk]]

This definitely seems inconsistent to me, but it seems to be that the solution is unclear because the use case for the button is unclear. For users who have gotten bit by this bug, what was your intended use for the button? Free up disk space? Improve your awesomebar results? Bulk-delete cookies?

Comment 32

[vasileios.revelas]

My use case was clearing cookies for a specific misbehaving site. Pressing ctrl-h, sorting by most recently visited, and choosing "forget about this site" felt a lot quicker than going in to settings, clicking around until I find the cookie-clearing functionality under "privacy and security", and then clicking "clear data", realize that the wrong button because it wants to delete everything, cancel, then try "manage data" which actually does what I want.

Also, it's important to note that in the history sidebar if you click the "view" dropdown, one of the options is "by date and site". So this part of the UI already has an opinion on what a "site" is, and it looks like the full subdomain.domain.com. So right clicking on one of those "sites" and choosing "forget about this site" violates the UIs own definition of site, because it displays subdomain.domain.com, then deletes everything under domain.com.

Comment 33

[Sergey Galich [:serg]]

Attachment: image.png

What do you think if we open "Clear all history" dialog with all checks set and time range set to "Everything"?
We might add "Passwords" checkbox there and do it for specific site only.

Comment 34

[Alexander Balagurov]

(In reply to Ben Dean-Kawamura [:bdk] from comment #31)

This definitely seems inconsistent to me, but it seems to be that the solution is unclear because the use case for the button is unclear. For users who have gotten bit by this bug, what was your intended use for the button? Free up disk space? Improve your awesomebar results? Bulk-delete cookies?

Last time i've used it when script on the page was too slow and collapsed the entire browser. It wasn't possible for me to load the page without cache bc i was unable to open devtools. I didn't want to completely clear all the cache, and i even copied password for this site. But lost the others :) I knew that the password will be erased too but not for the domain and other subs. It's pretty useful function for public computers even with password deletion too

Comment 35

[Tony Davis]

(In reply to Sergey Galich [:serg] from comment #33)

Created attachment 9306755 [details]
image.png

What do you think if we open "Clear all history" dialog with all checks set and time range set to "Everything"?
We might add "Passwords" checkbox there and do it for specific site only.

Looks good - but if you DO add the Passwords option in the UI, I would suggest it is UNTICKED - as busy users/DEV's might miss it, and it is best to let the users tick it ON themselves as a deliberately chosen option if that IS what they want. Put out a warning as well if chosen, that the password(s) for the site(s) will be removed, and maybe indicate if/what sub-domain passwords are being removed if possible. Thanks.

Comment 36

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

(In reply to Sergey Galich [:serg] from comment #33)

Created attachment 9306755 [details]
image.png

What do you think if we open "Clear all history" dialog with all checks set and time range set to "Everything"?
We might add "Passwords" checkbox there and do it for specific site only.

If you were going that far, you probably want "bookmarks" too?

TBH though, I haven't really heard anyone say they would expect the saved password to be deleted (much in the same way I'm not aware of bug reports that this feature did not delete bookmarks) - is there a good reason to not just change the existing behavior without additional ui?

Comment 37

[Sergey Galich [:serg]]

Tony, yeah, it should be unchecked. I'd rather have users suffer to check it manually each time than having them lost their data by accident. Accidents happen.

Mark brings us back to reality though. There is harm in deleting passwords. Not so many people, in this or a few linked bugs, actually expect passwords to be deleted when they use "Forget site" command. And making a better dialog will take much more time than just removing password deletion.

Comment 38

[Sergey Galich [:serg]]

Attachment: Bug 702925 - stop deleting saved passwords when user runs History > Forget this site command r=hpeuckmann

Comment 39

[Ben Dean-Kawamura [:bdk]]

The behavior change seems good, but I'm slightly worried that the text is misleading users. To me "Forget this site" indicates it's a privacy feature that removes the evidence that you've visited the site. The dialog text "This action will remove all data related to [site] ..." seems to confirm that.

I think the ideal solution would be that dialog, which makes things very clear. In the meantime, what about changing the menu item to something like "clear site data" and the the dialog text to "This action will remove site data for [site] including as ..., but not ...".

Comment 40

[Meridel [:meridel]]

Hi Sergey, we don't have a content designer dedicated to logins at this time so this would fall into our triage bucket — meaning, we will have to work on it when we can/as bandwidth frees up for a team member. Do you have a PM and a deadline for this workstream?

Comment 41

[Sergey Galich [:serg]]

Hi Meridel, let me connect you with PM offline.

Comment 42

[Meridel [:meridel]]

Brian, can you please take a look? Thank you. I understand there is not time sensitivity. If it's something we could wrap by end of year that would be great.

Comment 43

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/46569ff3dd33
stop deleting saved passwords when user runs History > Forget this site command r=fluent-reviewers,flod

Comment 44

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/46569ff3dd33