During the review of the JS rewrite of password manager, this issue of the autocomplete=off attribute came up. [It was originally desired by some sites (notably financial institutions) to prevent users from saving their passwords in the password manager.] Mike Connor said he was open to the idea of revisiting the issue, and possibly ignoring the attribute when a master password was being used. I think this makes sense to do now, for a few reasons: * When a master password is used, logins are securely encrypted on disk with 3DES. Someone accessing the computer while you're away would not be read your password. * Our "do you want to save this password?" prompting is better than it was is the old days. It's easier to understand, and the default action is to NOT save a password. This makes it less likely that a user will accidently save a login on a shared computer (eg, at a library). * When a master password is used, when you do opt to save a password, you must have entered the master password to save it (if you're not not yet entered it, you'll be prompted for it). This makes it less likely that someone else will accidently save their login on your computer. * Overall greater security by using a strong password (hard to remember) protected by a master password, compared to a weak password (easy to remember) because the site won't let Firefox save it. * Some anti-phishing benefits. Firefox's password manager checks the site's URL and form submit URL to the saved values before filling anything in. Thus, it won't provide your password on a phishing site. Users are terrible at determining if they're on a phishing site, but if they're expecting Firefox to fill in their hard-to-remember password, there's a better chance they'll notice something is not quite right.

For historical reference see also bug 245333 (dupe-catching flame-fest leading to WONTFIX) and spin-off suggestions bug 318667 and bug 333080. I fully support implementing this, I only mention the wontfixed bug so people don't have to re-argue everything already covered. Note that bug 245333 was asking for a weaker form of this, namely that we merely implement a hidden pref to do it that interested people could turn on.

I think tying autocomplete=off overriding to a specific, questionable "local security" measure is a bad idea. If we encourage users to use any form of "local security", it should be an OS feature, not the Firefox master password feature. I could get behind simply having a pref to ignore autocomplete="off" for passwords, though :)

Clarifying summary; this bug is mostly interesting in the context of *saving* form passwords. I think with the resolution of bug 362576 we're going to continue allowing *using* existing logins when filling a page, so having a master password for that doesn't really matter.

Just re-discovered this bug and bug 425145 in the process of checking for duplicates before filing one myself. Any status on this bug? It seems to have had support from at least one person @mozilla.com . With Firefox Sync now available, I'd like to use Firefox's secure password storage as a means of remembering and backing up my secure passwords rather than having to manually store them in a GPG-encrypted file and copy/paste them.

Justin, this patch is working for me. Is that what you were expecting?

Oh dear. I should look at my feedback-requested queue more often. :( :( I'm marking this WONTFIX. My thinking has changed from when I filed this 4.5 years ago. But not so much from bug 425145 16/21, which is the future for this kind of thing. Reasoning: There are actually entirely legitimate cases where autocomplete=off preventing filling/saving a password. The canonical example is an admin page for setting/changing a user's password... The admin won't want the admin password placed in the field for the user's password, nor the user's password to be saved in the admin's browser. There are other examples as well. I'll update bug 425145 with more details.

(In reply to Justin Dolske [:Dolske] from comment #6) > Oh dear. I should look at my feedback-requested queue more often. :( :( > > I'm marking this WONTFIX. My thinking has changed from when I filed this 4.5 > years ago. But not so much from bug 425145 16/21, which is the future for > this kind of thing. > > Reasoning: There are actually entirely legitimate cases where > autocomplete=off preventing filling/saving a password. The canonical example > is an admin page for setting/changing a user's password... The admin won't > want the admin password placed in the field for the user's password, nor the > user's password to be saved in the admin's browser. There are other examples > as well. So just have the admin click "no" when asked to save the password. Or make "no" the default answer, but provide a means to say "yes, do it anyway".

Dolske, could you explain why you WONTFIX'd this?

(In reply to Mounir Lamouri (:volkmar) (:mounir) from comment #8) > Dolske, could you explain why you WONTFIX'd this? Oups, I didn't see your explanations in comment 6. I tend to agree with comment 7: it already happen quite often to be asked to save a password when changing a password. We could probably improve our heuristic to not show the doorhanger in that situation. Anyhow, I prefer to keep this bug open until something happens.

(In reply to Justin Dolske [:Dolske] from comment #6) > Reasoning: There are actually entirely legitimate cases where > autocomplete=off preventing filling/saving a password. The canonical example > is an admin page for setting/changing a user's password... The admin won't > want the admin password placed in the field for the user's password, nor the > user's password to be saved in the admin's browser. There are other examples > as well. There might be such cases. But please let the user decide, not the Web author. I thought that what the philosophy of Firefox, putting the user in control.

"Let the user decide" is what bug 425145 is now about. We're not going to fix this bug as summarized, so there's no use tracking this issue in two different places.