Closed Bug 956906 Opened 10 years ago Closed 10 years ago

ignore autocomplete="off" when offering to save passwords via the password manager

Categories

(Toolkit :: Password Manager, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla30
Tracking Status
relnote-firefox --- 30+

People

(Reporter: Gavin, Assigned: adw)

References

Details

(Keywords: dev-doc-complete, Whiteboard: p=5 s=it-30c-29a-28b.3 [qa!][Please see comment 100])

Attachments

(2 files, 1 obsolete file)

autocomplete="off" does two things:
a) prevents us from automatically filling in already-saved data for forms/fields that have the attribute
b) prevents us from saving new data for forms/fields that have the attribute

This behavior is a concession to sites that think password managers are harmful and thus want to prevent them from being effective. In aggregate, I think those sites are generally wrong, and shouldn't have that much control over our behavior.

I think we should investigate removing support for autocomplete="off" entirely, or at least the portion of it that prevents us from saving passwords.
Apparently, Safari now has an option to ignore the attribute: http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/1028.html

Our bug 425145 got us a pref for that, and bug 951981 covers exposing it.

IE11 seems to have gone further, and have stopped supporting the attribute entirely: http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0015.html. I'm not clear from that message on whether it affects both a) and b) cases, or whether there's some difference between having the attribute on the form vs. the password input - testing/research needed.
Blocks: 897536
(That thread also has other comments from Chrome engineers looking to make similar changes.)
> I think those sites are generally wrong, and shouldn't have that much control over our behavior.

I agree.

Nonethless, Robert in comment 3 has a strong point. In France, banks even use mouse-clickable number images to enter an access code. (Totally accessible-hostile, and impossible to automate, which is their goal.)
Blocks: useragent
No longer blocks: useragent
Just to get an idea of the security side of the issue; I've asked a question here: http://security.stackexchange.com/q/49326/7497
I also filed bug 963913 based on Justin's comment on bug 425145 comment 53 to provide a compromise that may reduce opposition to enabling this feature by default.
I think some people out there somewhere might think regular form autocomplete is the risk they're trying to avoid with 'autocomplete="off"'. That's theoretically a valid concern, but password fields should already not be covered by regular form autocomplete in any sane browser. This flag exists to prevent autocomplete from remembering SSNs, credit card numbers, encryption/login keys, and other sensitive information that would otherwise be automatically remembered. It doesn't appear to have been created to give pages the ability to override an *opt-in* feature of the user's browser.

There's really no reason to consider the password manager to be "autocomplete" in this respect. It is an opt-in feature that won't be automatically completing anything unless the user explicitly asks it to do so for the specific site. The spec [1] doesn't actually recommend the password manager be overridden here. It's all about the form field autocomplete features, including different types of fields, what data they have and should be remembered and auto-filled for them. If form autocomplete and the password manager are considered two separate features, then there's no reason for the password manager to be affected by this flag at all.

[1] http://www.w3.org/TR/html5/forms.html#autofilling-form-controls:-the-autocomplete-attribute
Summary: ignore autocomplete="off" for the purposes of filling in saved passwords → ignore autocomplete="off" for the purposes of filling in saved passwords via the password manager
Whiteboard: p=0
Assignee: nobody → adw
Status: NEW → ASSIGNED
Whiteboard: p=0 → p=5 s=it-30c-29a-28b.2
Could we get a review on the end-user security impact of this?
Flags: sec-review?(curtisk)
Flags: sec-review?(curtisk) → sec-review?
Whiteboard: p=5 s=it-30c-29a-28b.2 → p=5 s=it-30c-29a-28b.2 [qa+]
Security team is fine with this proposed change.
Flags: sec-review? → sec-review+
I think this is a great change, for the reasons explained in
http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/1028.html
because requiring manual password typing leads to weak passwords.

To avoid that websites work around this by making obfuscated or non-automatable forms, we should actively reach out and explain our rationale why this is safer. The minimum is a dedicated page on MDN explaining it all and the implications and link to it from the dev notes.
Keywords: dev-doc-needed
Any ideas for where on MDN (read: page title, nesting) we should keep it?

Or should we add it to one/all of these pages:

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Input
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/form
https://developer.mozilla.org/en-US/docs/Mozilla/How_to_Turn_Off_Form_Autocompletion

"One can override this behavior using the signon.autocompleteOverride" about:config option"

and later

"The ability to use this attribute has been disabled by default because <reasons>"
I'd suggest a new article called
https://developer.mozilla.org/en-US/docs/Mozilla/Password_manager_and_password_strength
(title drives point home, but is not in itself controversial) and linking it on all of the above pages and dev notes. I'd also massively revise https://developer.mozilla.org/en-US/docs/Mozilla/How_to_Turn_Off_Form_Autocompletion .
Alright, that makes sense. I'll see if I can write something by the end of this week, or we'll work on it together.

The page on turning off autocompletion *is* disorganized.
(In reply to Manish Goregaokar [:manishearth] from comment #11)
> "One can override this behavior using the signon.autocompleteOverride"
> about:config option"

In order to make things more clear as to what's being overridden, in what direction, it might make sense to rename it and invert its meaning to "signon.allowSitesToDisablePasswordManager" or something.
(In reply to Dave Garrett from comment #14)
> In order to make things more clear as to what's being overridden, in what
> direction, it might make sense to rename it and invert its meaning to
> "signon.allowSitesToDisablePasswordManager" or something.

Could you file a separate bug for that? Pretty easy fix, and it makes sense, but best to track it elsewhere.
Blocks: 974742
No longer blocks: 974742
Depends on: 974742
QA Contact: andrei.vaida
I've been looking at this since I'm assigned to it.

Comments 0 and 1 are a little confusing, so just to be clear, echoing what Dave said in comment 7, we're only talking about <input type=password> here, not all form fields.

The thread that Gavin linked to in comment 1 is enlightening.  Even if we decide to dismiss reasons for using autocomplete=off on password fields, that thread raises a security concern that's not addressed by only flipping signon.overrideAutocomplete to true.

Joel from Chromium says:

> Additionally, we have taken precautions against password
> harvesting via XSS. We do not autofill into the DOM until the
> user has made a gesture (click, keypress, etc.) within the
> page, and we never autofill into iframe forms (we wait for a
> user to explicitly select their username from a dropdown).

Maciej from Apple:

> Safari has similar behavior available as a non-default user
> preference: "Allow AutoFill even for websites that request
> passwords not be saved." Even with this setting enabled, some
> user interaction is required both to save and to fill.

(I played around with Safari, and I'm not sure what user interaction he's referring to.  It autofilled without my ever having to do anything.  Maybe it's that good.)

Right now in Firefox, using autocomplete=off on a password field lets sites protect themselves from XSS like Joel mentions.  If we ignore it, we'd need to take precautions similar to his.

Going back to the question of whether we should ignore it at all, I'll quote Maciej again.  He lists three reasons sites told him they use it:

> (1) "Public computer" scenarios. Accidentally saving a password
> on a shared or public computer may endanger the user's account.
>
> (2) Casual walk-up attacks, for example temporary access to a
> friend's or relative's computer. AKA "friendly fraud".
>
> (3) At least some sites believe that consumer finance
> regulations require them to use autocomplete=off. They believe
> their requirement to protect the user's authentication
> information and prevent it from being accessed by third parties
> extends to preventing passwords from being automatically stored
> on the user's computer.

And he gives two reasons why ignoring it is opt-in, not -out, in Safari:

> (A) They could blacklist browsers that ignore autocomplete=off
> - this has been explicitly threatened in the past. It's also
> been claimed that, even if the sites did not want to do this,
> regulatory bodies would require them to do so because of point
> #3 above.
>
> (B) They could reimplement password input from scratch (using
> script and not using a real password field) in a way that
> evades browser autocomplete heuristics. This would be bad
> because it would prevent even off-by-default autocomplete=off
> bypass from working.

Interestingly, Safari pops up a little message when you focus an <input type=password autocomplete=off> that says the site prevents it from saving the password.

So, IE 11 is apparently the only browser that always ignores autocomplete=off on password fields.  According to NetMarketShare, IE 11 has 11.51% market share [1].  Safari is opt-in, and Chrome will be opt-in soon via a flag.  At this point I'd be more comfortable with an opt-in in the UI, too.  We can always reevaluate and flip it on.

[1] http://www.netmarketshare.com/browser-market-share.aspx?qprid=2&qpcustomd=0
See Also: → 951981
I find it hard to believe that any site would really go as far as described in comment 16 to force a lack of password completion. (not that I think it's impossible) It also seems to be based on beliefs of others' interpretations of regulations. It really would be nice if an actual lawyer could take a look at the specific laws and/or regulations that are supposedly being cited and see whether or not they actually do require what they say. It would not amaze me to hear that some law/regulation is just vague/confused on the topic.

One concession that might make sense to make would be to detect the 'autocomplete="off"' flag and add some language to the password manager doorhanger saying that the site would rather you not remember this password. Still let them; just make it clear that the site would rather you didn't. I think this would be notably better than a global opt-in for ignoring this flag, as you would have to opt-in to ignoring each site's warning each time.
(In reply to Dave Garrett from comment #17)
> I find it hard to believe that any site would really go as far as described
> in comment 16 to force a lack of password completion. (not that I think it's
> impossible) It also seems to be based on beliefs of others' interpretations
> of regulations. 

Well, there seem to be links all over the Web with workarounds[1] to the IE 11 removal of the attribute for password fields. There seem to be some people who want it, at any rate. Something to do with HIPAA, apparently, but it looks like a misinterpretation.

As for doorhangers, there's bug 963913.

I also found this[2] answer to be a tad enlightening:

> When the browser doesn't offer to autocomplete a password, the user assumes that the browser is broken. They then either use another browser which ignores the attribute, or install a password manager plugin that ignores the attribute.



 [1]: http://www.nerdbox.it/ie-11-autocomplete-ignore-workaround/
 [2]: http://stackoverflow.com/a/18242266/1198729
Using a password manager that encrypts its database must be considered more secure than easily remembered passwords, passwords saved by users in plain-text files, or passwords written on physical sticky notes.  Perhaps the Password Manager should mandate that users have master passwords, which would improve security over the current option to not use a master password.  

For the situation in which a user might forget the master password, there could be a button to force the Password Manager to forget all existing stored passwords; this should require a confirmation dialogue.  Implementation might also provide a measure of the "strength" of the master password, possibly similar to the way the PGP application has a bar (similar to a progress bar) that gradually changes color.
(In reply to Manish Goregaokar [:manishearth] from comment #18)
> I also found this[2] answer to be a tad enlightening:
> 
> > When the browser doesn't offer to autocomplete a password, the user assumes that the browser is broken. They then either use another browser which ignores the attribute, or install a password manager plugin that ignores the attribute.


Well, I as a browser-literate user assume that the website is broken and the browser buggy enough not to be able to deal with that. And then I chose a password that is as simple as possible so I can easily remember it (like I did for the Austrian Federal Railways or the Persona fallback) - while on sites that work nicely with password manager, I chose more complicated and hard to crack passwords. So, which one was it that website creators thought would help security? :p
(In reply to David E. Ross from comment #19)
> Perhaps
> the Password Manager should mandate that users have master passwords, which
> would improve security over the current option to not use a master password.

I disagree. When I use full-disk encryption, a secure OS and don't share the computer, having a master password is more a nuisance than a real help, esp. with our pretty weak encryption that isn't too hard to crack. But that doesn't belong in this bug. This bug is about autocomplete=off. Creating a mechanism like you describe, or improving our master password system or whatever all belong into different bugs.
(In reply to Dave Garrett from comment #17)
> I find it hard to believe that any site would really go as far as described
> in comment 16 to force a lack of password completion. (not that I think it's
> impossible) It also seems to be based on beliefs of others' interpretations
> of regulations. It really would be nice if an actual lawyer could...

I'll quote from that thread again, this time Jonas:

> Whether it benefits users or not is unfortunately less relevant
> than whether websites thinks that it benefits users. Since if
> they don't think it does, we'll end up in an escalating war of
> browsers and websites working around each other.

Same reasoning applies to whether sites think they are compelled to do it, for security, for regulation compliance, whatever.

(In reply to Dave Garrett from comment #17)
> One concession that might make sense to make would be to detect the
> 'autocomplete="off"' flag and add some language to the password manager
> doorhanger saying that the site would rather you not remember this password.

If some big sites told us they'll block us unless we do that, then I guess so, but otherwise I'm against that.  What's the user supposed to do with that information?  It's a concession to sites, not to users.  (Maybe that's what you mean?)

> I think this would be notably better than a global opt-in for ignoring this
> flag, as you would have to opt-in to ignoring each site's warning each time.

I'm not sure I understand you, but no.  You're prompted, as you are prompted today, to let Firefox save your password.  (No warning about the site not wanting you to save it.)  On autofill, you aren't prompted, with a caveat being the security concern I mentioned.  In other words, once you opt-in -- and the opt-in would apply to all sites -- the UX would pretty much be what it is today for autocomplete=on login forms.
Dave, I did misunderstand.  "as you would have to opt-in to ignoring each site's warning each time" applies to your suggestion of showing a warning in the usual prompt, not to my suggestion of a global opt-in.  Whoops.  The idea of showing a warning makes more sense to me now.
(In reply to Drew Willcoxon :adw from comment #22)
> (In reply to Dave Garrett from comment #17)
> > One concession that might make sense to make would be to detect the
> > 'autocomplete="off"' flag and add some language to the password manager
> > doorhanger saying that the site would rather you not remember this password.
> 
> If some big sites told us they'll block us unless we do that, then I guess
> so, but otherwise I'm against that.  What's the user supposed to do with
> that information?  It's a concession to sites, not to users.  (Maybe that's
> what you mean?)

Yes, it's a suggested concession to website developers and those who don't want to do things just because somebody might try and work around it. Threats of website developers trying to break the password manager through other means seem to make people hesitant to implement this. I would argue that such things not be given too much weight, but if there's a way to do things in a way that would have less opposition, that might make sense.

(In reply to Drew Willcoxon :adw from comment #23)
> Dave, I did misunderstand.  [...]  The
> idea of showing a warning makes more sense to me now.

Sorry, I may have not been clear. To restate: we currently show a doorhanger asking permission to remember a password each time a new one is detected. My suggestion was to detect the 'autocomplete="off"' flag and add a warning to this doorhanger for these sites saying something to the effect of:

"This site recommends taking extra precautions with your login information. Don't store this password on any computer that you do not trust. We recommend choosing a strong password and having Firefox remember it with a master password."

(or something shorter & better worded)

The idea is not to actually change anything functional in the UX, but rather to make it clear that the user not only has to make the choice to allow Firefox to remember the password, but also acknowledge that the site would rather you don't. (though, with no extra clicks) Thus, instead of one option somewhere to opt-in/out to overriding this for all sites, the user would be opting-in each time by clicking past this warning. This would also be more flexible; a user could choose to remember passwords for some of these sites whilst still being given the option to heed the warning of new sites they log into each time.

All that being said, my preferred route would be to just have the password manager ignore this flag entirely without any option to do otherwise. In practice, this stupid flag allows my junk Hotmail account to demand that I not use my password manager, but Gmail is just fine with it. I'm not a particular fan of letting sites declare their own importance.
Daniel, you sec-review+'ed this bug earlier, but could you please comment on the security concern since raised in comment 16?  Should there be some hurdle before Firefox autofills autocomplete=off passwords?
Flags: needinfo?(dveditz)
ha ha ha ha ha <snort>.

IMO (well recorded in other bugs) we should never auto-fill passwords, ever, into any form, without the user doing something that shows intent to fill in the password. Basically what Joel and Maciej say in comment 16. Our current behavior allows the harvesting of passwords on any site that has an XSS -- and the victim doesn't have to visit that site! 
 1. user stumbles on malicious content
 2. malicious content uses various timing attacks or <img onload/onerror>
    tricks to figure out which sites the user visits or is logged into.
 3. attacker loads frames for the intersection of sites the user has visited
    and sites the attacker has XSS for (or skip #2 and load all of them)
 4. harvest any replayed passwords.
 5. Profit!!!

The best my efforts have gotten so far is the misleadingly named pref signon.autofillForms which when set to false triggers the "multiple username" flow. This does still autofill passwords, but only after popping up a username select rather than at page onload. Something like what Joel described for chrome in comment 16, but the UX of the flow kind of sucks in practice because our version of it is a hack and it doesn't get better because no one uses it except me.

I fully endorse the concerns in comment 16 I'm just not sure autocomplete=off passwords make it significantly worse (though it is worse). To be honest when I looked this over originally I thought this was the "... when there's a master password" version of this feature request (wontfixed a long time ago) and I considered it a no-brainer under that assumption. It'd be awfully nice to solve a lot of these PwdMgr problems at the same time if you're up for it, though that's a big increase in scope from "ignore an attribute". Are you up for that?

(In reply to Dave Garrett from comment #17)
> I find it hard to believe that any site would really go as far as described
> in comment 16 to force a lack of password completion. (not that I think it's
> impossible)

Believe it. One trick I've seen is to put the username and password in different (adjacent) forms, and then on onsubmit copy the data into a different hidden form with no type=password input and submit that.

We worried in the past about Maciej's concern "A)" in comment 16, but not so much these days since there isn't a plausible risk of "you must use IE" with so much browser (and mobile) diversity. His concern "B)" is valid and we've seen some of it. But if that's going to happen it'll happen if any of the major browsers start ignoring autocomplete=off (by default) and it sounds like we're already there no matter what Firefox does.
Flags: sec-review?(dveditz)
Flags: sec-review+
Flags: needinfo?(dveditz)
dveditz, my biggest problem with the non-automatic fill is that I cannot see (by looking superficially at the site for 0.2 seconds, before I react) that Firefox can fill out this form. This currently happens e.g. when I have 2 usernames for a site and Firefox knows them.

A thing that would help a lot in this situation is to give a clear and evident visual clue that we can fill out passwords. It would still be annoying, because I'd have to click once more, but it would be better. If I had a gesture to do fill and submit with 1 click, that would be even better.

E.g. the fields could have green backgrounds. Or they could show the username in dark grey, but inputfield.value returns "". Or there could be an icon to the left or right of the text fields.
Then, if I click on the icon, the password is not only filled in, but submit is triggered as well.
Likewise, we could show a dropdown menu on the submit button. Or make a middle click on the submit button fill out the first username/password and submit it, with the same click.

These are just ideas, but they would address your XSS.
It would also not be "autocomplete" anymore, because it's a direct and clear user action that fills in the password. Thus, it's easy to argue that we ignore the attribute.

If you prefer, we can discuss the UI ideas elsewhere. But I think dveditz is right that this is an important factor here.
If Firefox required an additional click to fill in passwords, this would have the side-benefit of being able to not prompt for the master password until the user makes a choice to use the password manager. As it stands right now, the master password prompt shows immediately upon opening the first page that has a password remembered (even if the site requires a click to show the field, e.g. Bugzilla). I personally find it quite annoying to prompt before I even have decided to log in or not. This would be a nice UX improvement in addition to the security benefits of not autofilling right away.
This is what Gavin and I decided to do: By default, ignore autocomplete=off, but leave the signon.overrideAutocomplete pref (which means flipping its default boolean value).  Don't warn the user about autocomplete=off when offering to save passwords.  Instead of filling on page load, to avoid exploits that the site may be trying to protect itself against by setting autocomplete=off, require the user to select the login name from the autocomplete dropdown, even if there's only one login for the site.

So that's what this patch does.

There were a couple of possible bad UX points around the master password, if you have one set.  First, I made it so that if you have a master password, you're prompted for it when you interact with the login name field instead of on page load, because if we don't fill on page load, it's dumb to ask for the master password on page load.  Second, by "interact" I mean focusing the login name field.  So the master password prompt is triggered when you focus the login name field.  I had to modify nsFormFillController to make this work.  I think it's worth it, because without any changes, nsFormFillController ended up triggering the prompt when it fills in its autocomplete popup, which it does when you trigger the popup, since that became the first site that accesses the password manager's storage.  So the UX was: You trigger the popup to select a login; before the popup appears, the master password dialog pops up; when you're done with that the popup briefly appears then disappears; and then to get the popup to appear again, you have to blur the login name field, focus it again, and try again.

Tangentially, I noticed that when signon.autofillForms is false, you're still prompted for your master password on page load, which as I explained I wanted to avoid here.  I think LoginManagerContent._fillForm can be modified further so that doesn't happen, but I don't want that to block this bug.  If this gets a quick r+ then I might try to post a new patch here.
Attachment #8382794 - Flags: review?(dolske)
(In reply to Daniel Veditz [:dveditz] from comment #26)
> It'd be awfully nice to solve a lot of these PwdMgr problems at the same
> time if you're up for it, though that's a big increase in scope from
> "ignore an attribute". Are you up for that?

Sure.  File bugs and mark them blocking the desktop backlog bug 950073, or do the same for existing bugs, and if the powers that be decide to prioritize them, I'll be happy to work on them.

(In reply to Ben Bucksch (:BenB) from comment #27)
> dveditz, my biggest problem with the non-automatic fill is that I cannot see
> (by looking superficially at the site for 0.2 seconds, before I react) that
> Firefox can fill out this form.

I agree.  Please file bugs and mark them blocking bug 950073.
(In reply to Drew Willcoxon :adw from comment #29)
> Instead of filling on page load, to avoid
> exploits that the site may be trying to protect itself against by setting
> autocomplete=off, require the user to select the login name from the
> autocomplete dropdown, even if there's only one login for the site.

Please reconsider this after reading my suggestion in bug 759860 comment 2. IMO, it is bad to treat a field with autocomplete=off any differently than autocomplete=on, full stop, because it is confusing to users that don't "view source" (i.e. everybody). I think that the solution I suggested in bug 759860 comment 2 is probably more complex to implement but I also think it is worthwhile to shift the complexity from users onto ourselves.

Also, I don't think that we need to take special precautions for websites that are trying to use autocomplete=off to foil attackers. That is what TLS and CSP and other security technologies are for. autocomplete=off is a security anti-feature. Therefore, I would support completely ignoring autocomplete=off for password fields even if we didn't do the thing I suggested in bug 759860 comment 2 first. In other words, we don't need to do extra work now.
> my suggestion in bug 759860 comment 2

Yeah, that's pretty much the same as (one of) my suggestion from comment 27 here.
Please stop the action and make a whole-picture design first.
(In reply to Drew Willcoxon :adw from comment #29)

> [...]  Don't warn the user about autocomplete=off when
> offering to save passwords.  Instead of filling on page load, to avoid
> exploits that the site may be trying to protect itself against by setting
> autocomplete=off, require the user to select the login name from the
> autocomplete dropdown, even if there's only one login for the site.
> 
> So that's what this patch does.

Err, don't we already do half of this today? Even with autocomplete=off, you can still select a username from from dropdown, and we'll then fillin the password. The only change here really relevant to the handling of autocomplete=off is to allow saving such passwords.

> There were a couple of possible bad UX points around the master password, if
> you have one set. [...]

I think this part should be spun off to another bug, and probably just WONTFIX'd. The Master Password UX is already fundamentally broken/awful, and I'd rather not try to optimize it further. (Unless you count "remove" as "optimize"). I'm kind of dubious about the value of this particular fix, since many pages will focus the username field upon pageload anyway.
(In reply to Brian Smith (:briansmith, was :bsmith; NEEDINFO? for response) from comment #31)

> IMO, it is bad to treat a field with autocomplete=off any differently than
> autocomplete=on, full stop, because it is confusing to users that don't
> "view source" (i.e. everybody).

I think I mostly agree. There are few cases where autocomplete=off has legitimate usecases, but they seem to be so rare in comparison to sites just being bad that I think it doesn't matter.

Dveditz has some good points, but if we're going to do something to make driveby XSS more difficult, we really need to handle the common (autocomplete=on) case (which makes autocomplete=off not so interesting again). I don't feel strongly either way about the need to have that fix first before completely ignoring autocomplete=off.

I'd like to think that such a solution might also be useful for the increasingly-common cases where a site breaks password manager through other means.
(In reply to Brian Smith (:briansmith, was :bsmith; NEEDINFO? for response) from comment #31)
> IMO, it is bad to treat a field with autocomplete=off any differently than
> autocomplete=on, full stop, because it is confusing to users that don't
> "view source" (i.e. everybody).

The result with Drew's patch is much less confusing than the current state, where autocomplete="off" effectively breaks the password manager entirely for those non-view-source users.

We're reducing confusion here, not increasing it.

It's fine to think we're not going far enough, but until we have better XSS protection (something like your proposal), I think ignoring autocomplete=off entirely goes a bit too far. That's harder than Drew's patch, though, and shouldn't block us taking a step in the right direction.
Comment on attachment 8382794 [details] [diff] [review]
ignore autocomplete=off by default, make user select login from dropdown

This patch seems to have more in it than I'm expecting.

I think the master password improvements should be split off into their own bug (but I definitely see the value).

The pref renaming seems unnecessary - slightly clearer, I guess. I don't feel strongly.

I think ideally this patch would just have two parts:
- flip the pref value (and optionally rename it)
- make the check in the autofill case always check for autocomplete=off, regardless of the pref value

Does that make sense?
Attachment #8382794 - Flags: review?(dolske) → feedback+
> I'd like to think that such a solution might also be useful for the increasingly-common cases
> where a site breaks password manager through other means.

Yes, that's what I worry about: Once we ignore autocomplete=off, sites will take counter-measures by completely breaking forms.
If we - *at the same time* - make a change that autofills only on explicit user request, without reducing usability (visibility/discoverability, number of clicks) for end users, I think that would go a long way in making this change here more justified and more acceptable to the concerned parties. And there are many who think security = passwords and crypto, so there's a lot of fear in this general area. It would help a lot to make these people feel secure.
Attached patch patch v2Splinter Review
OK, this ignores the master password UX entirely.  So what remains from the previous patch is flipping the pref value and renaming it; storing passwords for autocomplete=off fields when the pref has its default value of true; and ignoring the pref entirely in the autofill case.

(In reply to Justin Dolske [:Dolske] from comment #33)
> Err, don't we already do half of this today?

Yeah, I'm just stating the plans given all the options discussed here and elsewhere.

(In reply to :Gavin Sharp (email gavin@gavinsharp.com) from comment #36)
> The pref renaming seems unnecessary - slightly clearer, I guess.

Clearer is what I was going for.  It used to be that the pref was consulted in the autofill case, but it's not with this patch, which makes "overrideAutocomplete" not really accurate.
Attachment #8382794 - Attachment is obsolete: true
Attachment #8385068 - Flags: review?(dolske)
(In reply to :Gavin Sharp (email gavin@gavinsharp.com) from comment #35)
> (In reply to Brian Smith (:briansmith, was :bsmith; NEEDINFO? for response)
> from comment #31)
> > IMO, it is bad to treat a field with autocomplete=off any differently than
> > autocomplete=on, full stop, because it is confusing to users that don't
> > "view source" (i.e. everybody).
> 
> The result with Drew's patch is much less confusing than the current state,
> where autocomplete="off" effectively breaks the password manager entirely
> for those non-view-source users.
> 
> We're reducing confusion here, not increasing it.
> 
> It's fine to think we're not going far enough, but until we have better XSS
> protection (something like your proposal), I think ignoring autocomplete=off
> entirely goes a bit too far. That's harder than Drew's patch, though, and
> shouldn't block us taking a step in the right direction.

I think you misunderstand what I was saying.

I'm saying that, in this bug, we should simply make it so we ignore autocomplete=off for password fields. Full stop. Then, in another bug, we can add improved XSS/MitM/etc. mitigations for all password fields, regardless of autocomplete=off. That's something we'll have to do anyway.
Carry over to Iteration it-30c-29a-28b.3
Whiteboard: p=5 s=it-30c-29a-28b.2 [qa+] → p=5 s=it-30c-29a-28b.3 [qa+]
(In reply to Brian Smith (:briansmith, was :bsmith; NEEDINFO? for response) from comment #39)
> I think you misunderstand what I was saying.
> 
> I'm saying that, in this bug, we should simply make it so we ignore
> autocomplete=off for password fields. Full stop. Then, in another bug, we
> can add improved XSS/MitM/etc. mitigations for all password fields,
> regardless of autocomplete=off. That's something we'll have to do anyway.

I understand that. The problem with that approach is that between the time that we start ignoring autocomplete=off completely and the time that we implement XSS/MitM defenses, sites lose the ability to protect themselves from these kinds of attacks, which makes them more likely to revolt/block Firefox/get upset. I don't think the benefit of doing that outweighs those costs. I want to pair "always autofill" with "ensure there's some user interaction".
(In reply to :Gavin Sharp (email gavin@gavinsharp.com) from comment #41)
> (In reply to Brian Smith (:briansmith, was :bsmith; NEEDINFO? for response)
> from comment #39)
> > I think you misunderstand what I was saying.
> > 
> > I'm saying that, in this bug, we should simply make it so we ignore
> > autocomplete=off for password fields. Full stop. Then, in another bug, we
> > can add improved XSS/MitM/etc. mitigations for all password fields,
> > regardless of autocomplete=off. That's something we'll have to do anyway.
> 
> I understand that. The problem with that approach is that between the time
> that we start ignoring autocomplete=off completely and the time that we
> implement XSS/MitM defenses, sites lose the ability to protect themselves
> from these kinds of attacks

AFAICT, it doesn't make sense to do anything special for the autocomplete=off case because an attacker that inserts a form will insert one without autocomplete=off, both in the XSS and MitM cases.
Yes, you're right. I'm conflating my password manager security issues. Ignoring autocomplete=off completely would also remove some protection against click-jacking attacks (e.g. bug 610997, bug 786276).
OK, this simply flips the pref and updates a test, which means we ignore autocomplete=off by default when saving and filling.  Dolske or Gavin, please review this one or the previous one, whichever you want to go with.  (Or neither!)
Attachment #8385700 - Flags: review?(dolske)
Shouldn't we be renaming the pref too, since we moved work here from bug 974742?
I think overrideAutocomplete is fine.
Comment on attachment 8385700 [details] [diff] [review]
simply flip pref, ignoring autocomplete=off when saving and filling

Not a fan of this one, per comment 43.
Attachment #8385700 - Flags: feedback-
Comment on attachment 8385068 [details] [diff] [review]
patch v2

This looks good to me, but I'll let dolske weigh in here as well.
Attachment #8385068 - Flags: feedback+
Attachment #8385068 - Flags: review?(dolske) → review+
Attachment #8385700 - Flags: review?(dolske)
Comment on attachment 8385068 [details] [diff] [review]
patch v2

Review of attachment 8385068 [details] [diff] [review]:
-----------------------------------------------------------------

::: modules/libpref/src/init/all.js
@@ +3718,5 @@
>  // Login Manager prefs
>  pref("signon.rememberSignons",              true);
>  pref("signon.autofillForms",                true);
>  pref("signon.autologin.proxy",              false);
> +pref("signon.storeWhenAutocompleteOff",     true);

Come to think of it... Is there any reason to even keep this as a pref?

The only case I can think of where a user might want the old behavior is if a site they use happens to be one of the legitimate use cases for autocomplete=off. (EG, they're an admin on some site, and use it to disable password manager for a "change another user's password" page.) But we already allow saying "never for this site", which seems like an acceptable per-site workaround.

r+ either way. :)
(In reply to Justin Dolske [:Dolske] from comment #49)
> Come to think of it... Is there any reason to even keep this as a pref?

(In reply to Manish Goregaokar [:manishearth] from bug 974742 comment #5)
> People running Fx on shared systems may want to use it to provide their
> users with some additional security.

This makes sense, but just disabling the password manager entirely would make more sense for this situation.

Just removing this pref entirely would be simpler. It's kind of dubious to justify keeping it, but arguments can be made. Some people want one, but thus far no one has been willing to make a decision to just axe it.
https://tbpl.mozilla.org/?tree=Try&rev=f4e0e562c3c3
https://hg.mozilla.org/integration/fx-team/rev/27061dc242e4

Gavin and I talked about it, and we decided to leave it, but neither of us felt strongly about it.  If we had started from scratch, there wouldn't be a pref, but it's already there.  So.
Summary: ignore autocomplete="off" for the purposes of filling in saved passwords via the password manager → ignore autocomplete="off" when offering to save passwords via the password manager
https://hg.mozilla.org/mozilla-central/rev/27061dc242e4
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
I was able to confirm the fix for this issue on the latest Nightly (Build ID: 20140309030204) using:
- Windows 7 64-bit [1]
- Ubuntu 13.10 64-bit [2]
- Mac OS X 10.9.1 [3] 

1. Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:30.0) Gecko/20100101 Firefox/30.0
2. Mozilla/5.0 (X11; Linux x86_64; rv:30.0) Gecko/20100101 Firefox/30.0
3. Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:30.0) Gecko/20100101 Firefox/30.0
Status: RESOLVED → VERIFIED
Whiteboard: p=5 s=it-30c-29a-28b.3 [qa+] → p=5 s=it-30c-29a-28b.3 [qa!]
Some feedback by a "normal" user.  I was surprised when Fx offered to save my bank passwords.  I eventually remembered that there was an exception mechanism.

I suggest you change the save popup to offer the exception directly, rather than on a click through you need to know exists.
No longer blocks: fxdesktopbacklog
Flags: firefox-backlog+
Sorry, Rory McCune, not Scott Pack.
Maybe I'm missing something, but here are a few cases you may not have considered:

1) Not all "password" boxes are used to store passwords.  The behavior of using asterisks (or similar) to visually mask data and prevent over-the-shoulder eavesdropping is useful (or required) in a whole lot more contexts than for a login password box.


2) PCI Compliance.  As given above, CC input may be done with plain text or password boxes.  I have seen both.  Are you aware that you really should not store credit card data in any system?  If the browser stores credit card data this is protected card information and is in scope for PA-DSS.  Unless the storage is fully compliant and passes PA-DSS review, it is a big problem.  A website could prior to this change help you out with something you obviously couldn't have known (IE this box is for credit cards don't store the data), but not anymore.  I don't care if the stored data is encrypted or whatever, strong encryption or other methods can have a future vulnerability.  Just don't store it and it isn't a problem.  Users expect to type in the Credit card every time and I really don't think Firefox should ever store it.  The decision to store data like that should be the onus of the website, not the browser.  And at this point any web form that has an input box for CC data is going to end up remembering that CC data in the firefox field value history, and the site designer has no control or input on the matter.  That should greatly concern you and I think it is going to greatly concern the PCI board, think about it.  The PCI website for software is here: https://www.pcisecuritystandards.org/hardware_software/


3) In many cases, a password field is used for a form that has nothing to do with a login, and storing the data does not always make sense.  For example, consider a web application that has a user management page.  You may edit one of 100 users and you may need to alter data such as password or social security number information (or any other amount of sensitive data).  There is absolutely no reason to remember the passwords and social security numbers and offer to reuse them on the next edit of a completely different user.  This is a case where there is potential for actual harm in remembering and suggesting the data - no good purpose is served and bad results are encouraged (and the web designer can no longer stop it).  I am not saying these sites would be built to send the sensitive data (sensitive enough that an asterisk mask was desired) back to a page for edit.  Most that I have seen use some approach to send a hash or mask to the client and then detect on post back if the data has changed, so the system-stored data is never sent to the client after it is initially entered.  But again... the browser really is NOT being helpful and is being rather annoying to the end user to think that it should be offering to remember this data.  I realize the user can click "no" or "never" but this can be a speedbump that is confusing.  Would not a web application developer, perhaps, know a few cases like this where remembering data is really NOT what the users want?  The users DO tend to tell us what they want, and ask for it, and it is really nice if we can give it to them and stop the phone calls.

I understand that the change was made with the best of intentions.  The argument about password boxes and strength of remembered login passwords makes some sense but it seems like a very narrow-minded view of the potential use cases for a generic form input control.  Not all data is password data and even if it was, not all use cases make sense to IMPOSE the behavior with absolutely no developer control to stop it (and stop the support calls that will follow asking if the annoying behavior can be stopped).  In a quest to stop web sites from controlling users I guess the solution is to disallow websites from appeasing or helping THEIR users?  That is not exactly logical IMO.  If it is such a user problem then maybe let it run the natural course and let the website fall from favor with users.  Or maybe now it will follow the unnatural course: users will complain and the site developer will just be stuck with it and lose them as a customer because the interface is clunky and unfriendly.  If using autocomplete=off is bad security advice for login forms, let the security community hash that out and let the recommendations change.

IMO this "bug fix" should be reverted.  The feature to allow site developers (who surprisingly may know some context data the browser developers don't, on a case-by-case basis) to control autocomplete on the input level and on the form level should be restored.

The same changes should be made for Chrome and IE, not that this is the right place to mention that.  It is just that consensus may appear to offer weight toward correctness, but in this case I don't feel it does so it is worth mentioning.

It would be semantically nice if the "password" input type were not the only easy way to get good asterisk masking functionality.  But there is no other easy way.  It is not a huge issue until people put a narrow focus on something like this and don't consider a sufficient breadth of use cases before making decisions.

I'm not sure how to highlight this for further review but I'll try to figure something out.

Thanks for reading and considering the feedback.
Flags: needinfo?(adw)
Remember, if the box is a *password* box, it will prompt to save the password. Which is okay, because the user can click no. autocomplete=off is required because autocomplete is, well, automatic, and doesn't ask for confirmation before saving.

So giving websites the ability to block password field saving is redundant. The user already has full control over whether or not he wants to save the password. This is not the case for text boxes, hence autocomplete=off.
To be clear, the change was not made because it's a password-containing box. Hey, passwords are sensitive too. The change was made because password-saving already prompts the user (always).


As for PCI, the website has lost control over the password saving, but the user still has control.
(In reply to JC from comment #61)
You're going to have a hard time arguing that this should be kept to be used for reasons even further removed form its original intention. Password fields should contain passwords, and nothing else. You shouldn't hack it to do something else and then get annoyed that such a thing isn't viable forever. The autocomplete="off" is explicitly for credit card numbers and the like. If you want to have forms where it also isn't fully showed on screen as it is entered you should implement that feature on the proper element, not re-purpose a password field. You have a very good argument that we need a new standardized field that behaves like a password visually but not labeled a password for login purposes. In the meantime, you might be able to use a regular form element with a CSS override to change its appearance to a password element.
@Manish Goregaokar

I understand your stance.  There are two issues here, I consider them open issues.

1) The user does not always 'want' control over something.  It is not user-friendly to have to control everything, manually, thyat should be automatic.  The site basically ends up 'stupidly' not being able to prevent the user from having to deal with something obvious.

2) Concerning PCI:  Yes, you are right.  Now, the website has no control over the PCI question at all.  The only people that have control is Firefox (the application that would be involved in PA-DSS scrutiny here) and the user... to be clear -- the "everyday joe" user who maybe does not know about nor understand PCI, and probably assumes (if anything) that a URL with a padlock in it is "secure" so don't worry about anything else.  This is the user that trusts YOU the browser vendor and US the site vendors to keep them safe.  But, from this side, I can't help, sorry.  I really think that this is not going to work and will be reversed sooner or later.  I am pretty sure they are not thinking about the fact that their credit card is now stored somewhere.  Again, I would wonder what the PCI board would think about that.

Lastly, of course it is not only password boxes, the issue also applies to text boxes.  There are times when the data shouldn't be stored and the site designer knows that, whether it is for security (don't store this credit card data) or for convenience (don't offer to me John's SSN when I am editing Edith).

I fully understand that there is consensus that not storing passwords may lead to lower security due to poorly chosen passwords (don't want to remember a hard one) across the board.  This "fix" for the likely bad historical security recommendation problem however affects a lot more cases than that, and removes any case-by-case control in those other cases. It just seems heavy-handed and narrow to take that approach to fix the specific problem that raised concerns.
@Dave Garrett

Two comments:

1) We don't have an SSN or sensitive data field.  Given that, we have to pick from available fields we do have.  Which field matches the best?  Plain text?  No.  Password:  Yes that is closer.  It is not "repurposing" the field to some crazy new intention.  It is using the most logical existing field for a purpose nearest to what is desired.

2) Yes, the problem actually applies to (most) any type of form field.  I am not clear on if this fix affects only password fields or others.  But often a plain text field is used for CC entry in my experience using web sites.  In that case also autocomplete=off should work to tell the browser that the field is special and not like most plain text fields.  I am unclear on the status of this functionality but I'm under the impression that it no longer works and the field will be remembered anyway, even for text fields.
(In reply to JC from comment #65)
> @Manish Goregaokar
> 
> I understand your stance.  There are two issues here, I consider them open
> issues.
> 
> 1) The user does not always 'want' control over something.  It is not
> user-friendly to have to control everything, manually, thyat should be
> automatic.  The site basically ends up 'stupidly' not being able to prevent
> the user from having to deal with something obvious.

It's a password save box. This is something the user already has control over, we're just redefining boundaries here.

Also, note that the following case is very rare:

 - The site is an average-joe site
 - with sensitive input fields
 - the input field is a password box
 - there is no password box preceding this input field (it takes precedence)

over the rather common case where autocomplete=off is blindly applied everywhere, annoying users.

Also, the average joe user is smart enough to not save passwords on a public computer (doesn't matter much what they do at home). And if they aren't, well, that is a MUCH bigger security risk since credit card details can be found eventually if you have access to their other logins.


> 2) Concerning PCI:  Yes, you are right.  Now, the website has no control
> over the PCI question at all.  The only people that have control is Firefox
> (the application that would be involved in PA-DSS scrutiny here) and the
> user... to be clear -- the "everyday joe" user who maybe does not know about
> nor understand PCI, and probably assumes (if anything) that a URL with a
> padlock in it is "secure" so don't worry about anything else.  This is the
> user that trusts YOU the browser vendor and US the site vendors to keep them
> safe.  But, from this side, I can't help, sorry.  I really think that this
> is not going to work and will be reversed sooner or later.  I am pretty sure
> they are not thinking about the fact that their credit card is now stored
> somewhere.  Again, I would wonder what the PCI board would think about that.

I guess you'd have to ask the PCI people. Could you point out where PCI asks for autocomplete=off on password fields?



> Lastly, of course it is not only password boxes, the issue also applies to
> text boxes.  There are times when the data shouldn't be stored and the site
> designer knows that, whether it is for security (don't store this credit
> card data) or for convenience (don't offer to me John's SSN when I am
> editing Edith).


This patch *only* works on password/username fields. It is a change in the password manager, that is all. Not a change to the autocomplete code.

Also, there are many, many times when the designer does this for passwords, too (Yahoo did it). This is simply annoying.


> I fully understand that there is consensus that not storing passwords may
> lead to lower security due to poorly chosen passwords (don't want to
> remember a hard one) across the board.  This "fix" for the likely bad
> historical security recommendation problem however affects a lot more cases
> than that, and removes any case-by-case control in those other cases. It
> just seems heavy-handed and narrow to take that approach to fix the specific
> problem that raised concerns.

There is no such consensus ..?
Also note that in non-password fields, we don't store credit cards numbers that match the Luhn algorithm (bug 188285) so that deals with a some of the remaining PCI compliance issues you may have.

Perhaps you should propose a new value for @inputmode[1] or another attribute in HTML to have a field masked even when it's not type=password.

[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#input-modalities:-the-inputmode-attribute
Flags: needinfo?(adw)
Like most developers, I just want what is "best" for the users and for the application.  It is not always clear what is best, of course.  Discussion is good though.

My understanding was that the change was made based on the use case involving password fields.  But if it is based on the HTML autocomplete tag interpretation, then it pulls in all use cases involving the autocomplete tag functionality, which is how it gets to be a lot bigger issue than passwords.  I have given cases both involving and not involving passwords, so you can focus either on only just passwords and those cases if you like or you can focus on the other cases as well.  I think all the cases are important, including cases where input type=text are involved with the autocomplete attribute.  But if this change doesn't affect those in firefox then I don't mean to confuse.

My particular problem case for today is that I have a screen that is for modifying settings for integration with a 3rd party application.  This screen will accept a password (which users expect to be a STAR-BOX to put it in their terms) for the 3rd party, which it will store the result encrypted and will never regurgitate it upon edit.  The same settings screen allows editing settings for a lot of other integrations, some of which may or may not involve passwords.  In no case does it really make sense to remember and offer past data back.  The popup asking if I want to save the password is not something I want to see or respond to.  It would be great if I could pass this knowledge along, but apparently no current browser wants to hear it.  This will be annoying to users who are configuring integrations, and I can't help them.  This is just today's example.  It is quite common to run into this.  I am just one guy and I have had several cases in the past where users have complained that the "helpful suggestion" data was not really helpful and have been able to turn that off so it isn't in their way.  But no more.  It is not a deal killer just an annoyance.

Regarding:
> There is no such consensus ..?

Recently, IE, Chrome and Firefox all changed to act differently than in the past regarding the autocomplete=off html tag (which ironically was finally fully included in HTML5, as I understand it).  When searching the web for WHY that happened, it seems to be because of the COMMON case that you point out:  In the case of a regular password box being used for login (not a password box being used to store password or other data in a place that is not a "help me login" use case) there was argument (that much is clear) about the security best-practice about this.  And evidently (since many common browsers recently changed functionality) consensus has been arrived at.  I understand the problem case and I understand that it is common.  I think there are a lot of other cases which are reasonable, and are not relatively uncommon collectively.

I am just giving some thoughts to consider, because to me it is not cut and dried.  As a USER and as a developer, there are annoyances and security issues to consider but it is not just one simple case.

With regards to this:
> I guess you'd have to ask the PCI people. Could you point out where PCI asks for autocomplete=off on password fields?

First, of course you must know that websites, and therefore browsers, are involved in collecting credit card data from users.  I don't believe that is debatable.

What the PCI people want is for the credit card data to remain secure.  There are a lot of things to consider, such as the SSL channel, the server side code and storage functionality, and the client code.  I believe the fact that CC data will be stored in a browser data cache and can't be excluded would be a problem.  If there is not a way from the website designer side to suggest the CC data out of that cache, then it is solely the browser that you can refer to.  Anyway, since the site designer can't ever really control what happens on the client side it is probably not going to cause a train wreck on the server PA-DSS evaluation.  That is not to say that there is not some reliance on existing defacto standards for client side behavior; it is implicit.  But rather than me being argumentative, I'm trying to be constructive and I hope it comes across that way.  Just ask:  Is it not a problem to store CC data?  How can a site designer help out the browser to hint that it would be unwise to cache something?  It is not possible at this point, right?  So all that data WILL be stored by the browser.  Given that we know that that data WILL contain CC data, it is probably falling into trouble with PA-DSS scope requirements.  If that is true, I don't need to find what you asked for.  If they figure it out they will find you :)

I doubt that asking the user if they want to store it can keep firefox out of PA-DSS scope.  If they say yes then you are going to store it, and so the storage will be under scope.  It is not a maybe here, unless everyone stops using credit cards on the web.

Matthew N. mentioned in a separate post about the "Luhn algorithm".  I was not at all aware of that and it could cancel the PCI concerns.  It would be a different way to address those if it prevents storage in the relevant cases.

If the browser no longer supports autocomplete=off for input (and password) controls and will cache any input no matter what it is, and offer it back later in what is believed to be the same context...  It just isn't very flexible and in many cases isn't very friendly for the user.

You assert that the one case is extremely common and the other cases are uncommon enough to be negligible.  You did a study to show these numbers?  Can you present the study material?  How did you obtain the numbers and how many sites did you study?  What limits were placed on the source of sites?  I'm not really asking for this, just want it to be considered if the assumptions are really tested.  I have seen this a lot, but in the past I had a solution for it.  I can't be alone.

I don't want to become annoying I just wanted to present some solid feedback with use cases to justify the question and concern.  I will leave it to you to consider and decide if you are sure about your solution or not.  It is good to have a place to give feedback in hopes that it will be considered.  If there is anything more I could provide that would be helpful, let me know, otherwise I'll knock off.  I have given as much as I think I can contribute to this point.

Thanks again for listening and discussion.
(In reply to JC from comment #69)
> If the browser no longer supports autocomplete=off for input (and password)
> controls and will cache any input no matter what it is, and offer it back
> later in what is believed to be the same context...  It just isn't very
> flexible and in many cases isn't very friendly for the user.

THIS IS NOT TRUE.

To reiterate, this bug is not about form autocomplete AT ALL. This bug is about the password manager ONLY.

There are two things which can remember things entered into forms:
1) Generic form autocomplete
2) Password manager

The 'autocompete="off"' flag was designed for #1. The specific use case of credit cards is what this flag has always been for. Set 'autocompete="off"' on a form input field for a credit card and it will not be remembered by autocomplete. This has always and will continue to be the case.

What this bug is addressing is only #2. Previously, the password manager also honored this flag, however this was not really what it was for and is commonly abused. This change here simply makes the password manager's login & password autocomplete not check the flag. The generic form autocomplete is not affected by this at all. The things the generic form autocomplete would not autocomplete will STILL not be autocompleted by it. A short list of things the generic autocomplete ignores:
a) passwords
b) anything marked 'autocompete="off"' (that's what this flag is supposed to be for)
c) standard credit card numbers via the Luhn algorithm
(In reply to JC from comment #69)
> It is not a deal killer just an annoyance.

So was the state before this. See comments on  bug 425145

> Regarding:
> > There is no such consensus ..?
> 
> Recently, IE, Chrome and Firefox all changed to act differently than in the
> past regarding the autocomplete=off html tag (which ironically was finally
> fully included in HTML5, as I understand it).

As far as I can tell, the spec talks about *autofill*. This change does not affect autofill, it ONLY affects the password manager.
  When searching the web for


> If the browser no longer supports autocomplete=off for input (and password)
> controls and will cache any input no matter what it is, and offer it back
> later in what is believed to be the same context...  It just isn't very
> flexible and in many cases isn't very friendly for the user.


Once again, you seem to be under the delusion that this applies to all autofill. It isn't. It only applies to data stored by the password manager. Autofill on other input elements still works perfectly.


> You assert that the one case is extremely common and the other cases are
> uncommon enough to be negligible.  You did a study to show these numbers? 

Look at the comments on the bug I linked to, and search the web for workarounds to the issue -- you get tons of results. It was a *major* annoyance, especially since it blocked the password manager from being used, with *no* easy/obvious workaround. That's a loss of functionality, not just annoying.

The case here is annoying only -- there is no loss of functionality. You have an annoying doorhanger "do you want to save the password", which can be dismissed.

And if you really want to revert to the original state, just go to about:config and turn `signon.overrideAutocomplete` off.

Of course, we can only be sure of the numbers here if we wait a whle and see how much dissent this feature causes.


Note that fundamentally, using autocomplete=off on password fields to block the password manager is a misuse of the attribute. The attribute is supposed to turn off autofill, not the password manager (specs: http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#attr-fe-autocomplete). It just happened to get implemented that way, and was misused along the way. (Though using autoomplete=off on password-type CC fields is correct.)
@Dave Garret

> The specific use case of credit cards is what this flag has always been for. Set 'autocompete="off"' on a form input field for a credit card and it will not be remembered by autocomplete. This has always and will continue to be the case.

Well, that is a relief.  I did misunderstand (I guess I was delusional as Manish would put it).  The scope of the concern is much smaller than I thought.  So it only applies to password boxes.

I have seen password boxes used for only two main cases, passwords (sometimes for login, sometimes in other places) and SSN.  I can't think of any other big cases here.  The main things to worry about is HIPPA and PCI as far as I know.  Those require some care with sensitive or personal data.  SSN security has come up in multiple software scenarios and the password box has met that need perfectly, and it was really GOOD when it obeyed the autocomplete tag, though apparently to some this is a gross and absurd bastardization of the control.

I admit it seems arbitrary to say that the field should apply to text input controls but not password text input controls.  Other than the * mask, they are pretty similar.  I bet under the hood the code is the same for most of the implementation.  To me, it is a text field that has stars.  That is what it looks like and acts like.  But anyway, what really matters is what was intended by the spec and what was specified by the spec.  What I think has little relevance in this discussion.  But to me it doesn't seem like an abuse.  It seems like it naturally should apply and is useful when it does apply.  For my case today and for the SSN case which I have seen in the past once or twice, the desired functionality is that the field should act just like a textbox except the content is not displayed.  The field should obey the autocomplete tag however I set it (usually to false for this type of scenario).  Before now, it did what it should do, IMO.  For the login scenario I would have set autocomplete=on.

I know that there were annoyances in some cases before the change, I get that.  Before the change however there were options.  Now there are not.  Options are usually better.  For me they are!  I like options!  Options options options!  Hurray options!  Ok NOW I am delusional.  ;)

There are other solutions (ugly but functional) to the SSN problem as long as you can use javascript in the related work.  I don't think there is a simple CSS solution but I will look harder.

Have a great night everybody.  I have said my bit and I hope it was helpful and thoughtful.
Great to see that we have come to an understanding :)

Note: There *is* an option. about:config --> set signon.overrideAutocomplete to false. You get the old behavior back :)
@Manish 

I wouldn't call it an understanding... but I agree to shut up :)

Yes, I understand the about:config option. If I was the end user that would satisfy me.  I am the developer and you can't really pass this type of thing on to the users.  They:
* won't want to do it
* won't understand how to do it
* won't like it in any other cases besides this case and will be mad you told them to change it

As the developer I need ways to set things the way users want it en-masse, but for particular cases not blanket ones.  It is good for the users that they have an option though.

I personally never allow a browser to remember much about me, certainly not my bank passwords.  But I am not joe everyday user.  I don't want it tracking my data; I don't need the help and don't consider it helpful.  So the original annoyance did not impact me, just the new one, and only as the developer, not as the user.  Hey it is a big world out there I FULLY understand how hard it is to please everyone.
bug 951981 was filed about adding the pref for this to the UI, but users can already bookmark the following URLs to quickly toggle the options:

about:config?filter=signon.overrideAutocomplete
to toggle the previous behaviour, and

about:config?filter=signon.rememberSignons
to toggle prompting for passwords
I do not know about Firefox.  With SeaMonkey, however, I can go to [Edit > Preferences] on the menu bar.  On the left side of the resulting Preferences window, I select [Privacy & Security > Passwords].  On the Passwords pane, there is a checkbox labeled "Remember passwords".  I assume that, if this checkbox is NOT checked, NOTHING will be saved even after implementing the changes for this bug report.  If this assumption is not correct, please note here.
Your assumption is correct. When the box is not checked, nothing is saved. Autofill will still be saved on form fields without autocomplete=off. Password fields will not be saved.

With the box checked, the behavior changes for password fields only: you get a prompt before passwords are saved.
(In reply to JC from comment #65)
> 1) The user does not always 'want' control over something.

Sorry, this is a non-argument here as Mozilla is all about enabling user control over their online lives.
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #78)
> (In reply to JC from comment #65)
> > 1) The user does not always 'want' control over something.
> 
> Sorry, this is a non-argument here as Mozilla is all about enabling user
> control over their online lives.

Yes, understood and acknowledged, how noble an intent.  Therefore how sad the conundrum that the end-user has asked for something, and mozilla has denied it.  Me being on the same page as you, wanting to give the user that control, I can't help either.  And yes, that IS sad as I agree the users should have the control, I couldn't agree more.  The realm of web applications however extends the onus of this important criteria to bounds that you are apparently unaware.  Just forget it as the situation is complicated and the players are not complicit.  More discussion is not necessary nor warranted.
Having looked up "complicit" I retract my uninformed use of the word.  I meant to say players are not working together.
Ignoring autocomplete="off" might be a good idea,
but filling user credentials in any form that looks remotely like a login form is a mistake.

See for example https://code.google.com/p/chromium/issues/detail?id=352347 where I reported 

To summarize, ok to store passwords aggressively, it makes sense.
But filling any form with them is a security issue on admin web interfaces.

I do not feel I have control over my forms if I need to verify before each submit that my admin credentials hva not been filled without my consent.

Look for example at Opera, that will not fill forms without explicit request from the user.
They highlight fields that could be filled on request, but do not fill them.

I wanted to be sure that this was taken into account before ignoring completely the autocomplete attribute.
Firefox *always* asks before saving passwords. (You can disable the saving/prompting for new passwords as well)


And websites should not have control over the password manager of a browser. That is up to the user, and Firefox supplies sufficient security there as well as confirmation.
(In reply to Manish Goregaokar [:manishearth] from comment #82)
> Firefox *always* asks before saving passwords. (You can disable the
> saving/prompting for new passwords as well)
Yes, and it is a good thing
> 
> 
> And websites should not have control over the password manager of a browser.
Agreed
> That is up to the user, and Firefox supplies sufficient security there
Yup, agreed too
> as well as confirmation.
Nop. Firefox fills information from the password manager directly into the forms, wthout any kind of confirmation/notification.
This is a disaster on large admin forms, because admin credentials might be filled somewhere into the form without theadmin noticing.

I will create a new ticket blocking this one, except if firefox still honours the autocomplete="off" when filling forms with passwords. But in that case, what is the point of remembering a password that has been entered in a autcomplete="off" input field ?
(In reply to layus.on from comment #81)
> Ignoring autocomplete="off" might be a good idea,
> but filling user credentials in any form that looks remotely like a login
> form is a mistake.

You can set signon.autoFillForms to false using about:config to disable password manager auto-filling. Bug 534541/bug 610997 (and bug 653132) cover other risks associated with auto-filling.
(In reply to layus.on from comment #83)
> Nop. Firefox fills information from the password manager directly into the
> forms, wthout any kind of confirmation/notification.
> This is a disaster on large admin forms, because admin credentials might be
> filled somewhere into the form without theadmin noticing.


But the password is only saved if the user says so.


> I will create a new ticket blocking this one, except if firefox still
> honours the autocomplete="off" when filling forms with passwords. But in
> that case, what is the point of remembering a password that has been entered
> in a autcomplete="off" input field ?

The point is that autocomplete=off was never meant for passwords in the first place. Websites misused it, and now it's being removed from all major browsers. Autocomplete is a device that *automatically* saves form data (without confirmation) and brings it up at a later time. The password manager always prompts when saving data, so there is no need for a website to mark a password field as confidential -- the user can determine if s/he wants that field to be saved when the prompt pops up.
Manish, as Gavin points out with the bugs linked in comment #84, there is a valid concern with the auto-filling that we do for password when only one password is remembered for a site (we do not prefill when multiple passwords are saved or for form autocomplete) and we need to think about a mechanism to either require user interaction for autofilling or making the values non-accessible to JS (which I think will be complicated as having form values be JS-accessible is a feature that sites use legitimately).

All that said, this belongs in different bugs, like the ones Gavin cited.
Oh, I see. My bad.
Ok, after a complete investigation of the problem, I am convinced that this decision is good.
I must apologize for the fuss I made here. It come from the fact that my test case was broken.

To summarize, this patch allows the password manager to (ask to) remember credentials from login forms even when autocomplete is set to off. This is a really good thing.

I was worried about forefox also filling such forms without warning.
This appears to be wrong, as firefox still honors autocomplete="off" when filling forms.

In this particular case, when there is only one password in memory, firefox waits for the user to select his login name in the dropdown list before filling the according password field, which is acceptable (but not perfect, for example on huge forms, or on 'enter new password twice' forms).

Thanks for the carefully crafted implementation and instructive discussion.
There is a lot of misunderstanding and tension over this, my apologies again for adding to the fuss.


PS: This worry comes from Chrome, where they simply dismissed any autocomplete tag that was not in the 'form' element. See for example https://code.google.com/p/chromium/issues/detail?id=352347
While common sense is the enemy of most of Mozilla I'll still say this for the record.

While it is true that some sites are overzealous about preventing passwords from being saved there are certainly legitimate cases where I do not want passwords being saved.

Outright removing support for the autocomplete attribute is irrationally reactionary and lacks any common sense or desire for balance.

An appropriate response would to either add an option in or around the password manager in the options GUI to ignore or acknowledge autocomplete or to create an extension (since every time Mozilla breaks Firefox we have to keep adding extensions to restore NORMAL functionality).
- We are the third browser (iirc) to remove support for autocomplete=off on password fields
- This *only* works for password/username fields. Autocomplete=off behaves normally otherwise
- The spec never intended this to be for password[1]
- One is still prompted about saving the password. Passwords are never saved automatically -- the user has full control over that.
- This change can be reverted by flipping signon.storeWhenAutocompleteOff preference from about:config.
- As far as I can tell, the number of overzealous sites far outweigh the legitimate uses. And, again, the user still has full control over the saving of the password. Just that the website does not, anymore.

 [1]: http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#the-form-element
(In reply to John A. Bilicki III from comment #89)
> Outright removing support for the autocomplete attribute is irrationally
> reactionary and lacks any common sense or desire for balance.

(In reply to Manish Goregaokar [:manishearth] from comment #90)
> - We are the third browser (iirc) to remove support for autocomplete=off on
> password fields
> - This *only* works for password/username fields. Autocomplete=off behaves
> normally otherwise
> - One is still prompted about saving the password. Passwords are never saved
> automatically -- the user has full control over that.

This is inaccurate. Firefox does NOT ignore autocomplete="off".
It simply always ask if it can store detected credentials.

As far as I understand, the only change in behavior will be that the Password Manager "Do-you-want-to-remember-these-credentials" prompt will be displayed without taking into account the autocomplete tag.

In particular, the algorithm that decides whether to fill or not a form with credentials or not does not change. This means that if you fill a login form that has the autocomplete=off attribute, firefox will prompt you for remembering the password.
Let's make the assumption that you accept to save it.
On next login, firefox will not fill the form with your credentials, as has always been the case when the form has the autocomplete=off attribute.
BUT, if you type your login, a dropdown will be proposed with your remembered login. If you select it, then the saved password will be filled in the password field.

With this fix, firefox does NOT _ignore autocomplete_, but it does _remember your passwords_.
(In reply to John A. Bilicki III from comment #89)
> While it is true that some sites are overzealous about preventing passwords
> from being saved there are certainly legitimate cases where I do not want
> passwords being saved.

In my very personal opinion (which is independent of my employer), it's never legitimate for a website to block the user from saving their password.
In my case (and I guess many others), websites that do not work with the password manager require me to use a very simple uncomplicated password that I can easily remember, while for websites where I can save password, I can use complicated and more secure passwords because I don't need to remember them (as password manager does that for me in a secure way).

Of course, it's always legitimate for a user to say they do not want a password to be saved, and Firefox asks before saving a password, every single time (unless you turn off saving passwords, then we don't ask and don't save).
This bug is too easily misunderstood by people who don't bother to read it. Can we please leave the discussion at the last few comments and lock comments? This is a verified fixed bug and any further questions, comments, or issues should really be in a new bug or on the mailing list or support forum.
(In reply to Dave Garrett from comment #93)
> This bug is too easily misunderstood by people who don't bother to read it.
> Can we please leave the discussion at the last few comments and lock
> comments? This is a verified fixed bug and any further questions, comments,
> or issues should really be in a new bug or on the mailing list or support
> forum.

That could work. An alternative is to write a summary comment, add a mention of it to the whiteboard, and obsolete most of the comments.
Regarding the suggestion of " removing support for autocomplete="off" entirely ", I've not read the whole thread as it's long so forgive me if this sort of thing has already been mentioned.
Having the ability to turn off autocomplete is very helpful for internal company sites, and I assume by extension on certain areas of the public internet too.
If for example I have a web report with umpteen fields that generates a pricelist for a certain distributor category (as for example I do), I want those fields completely UNprefilled as otherwise the resulting prices that result will not be what the user intended, and the wrong prices will then get sent to the distributor, because the user expects to fill in from a clean slate of input fields, not a random-filled one where they will always overlook some of the prefills.
Of course I can JS-code explicit rewriting of the values back to what i want them to be, but that's ridiculous to have an input value ask one thing, then have the browser change it to something else, and then have to overwrite it back to what you asked it for.
The reality is some sites really do need to switch off ALL autocomplete, even if others don't, and I'd say any site with a large number of entry fields is provoking disaster by prefilling them because the user won't notice, whereas they will notice if where's only one or two fields beside each other.
I notice that whereas
document.write("<input id='test'>");
activates autocomplete, the following currently doesn't activate autocomplete:
o=document.createElement('div'); o.innerHTML="<input id='test'>"; o=document.body.appendChild(o);
and I hope autocomplete will never be forced upon post-created input elements any more than on document-written ones because it's a disaster to have prefilling of important forms where users (as is common) don't check properly beyond what they plan to type in.
Finally, in advocating the ability to turn autocomplete off, I wish the attribute could be put on the <body> element or in the <head> and so apply to all elements, since most my forms work by a javascript action and rarely by <form> submission.
Cheers,
david
^ Expressed another way, with some forms the user works from top to bottom and looks at every input element presented, however with other forms a user with a task in mind just goes to particular boxes and types and doesn't review the rest of the form.
d
autocomplete != autofill and this bug is only about username/password fields only so please move this discussion to a mailing list if you think it's necessary.
Thanks I agree they are semantically different but the only way I know of a site overriding fields being autofilled is to use autocomplete='off', and the thread did open with a lot of discussion about removing this attribute altogether. Cheers, d
(In reply to D Merrick from comment #95)
> I've not read the whole thread as it's long so forgive me if
> this sort of thing has already been mentioned.

No. Please read the whole thing or don't post a comment at all.

This bug is not applicable to your issue. For the eleventy billionth time, this change was only to allow the password manager to remember passwords at the request of the user. The autocomplete="off" flag is still intended to work for forms in general as it always has. The password manager and the form autocomplete systems are separate, and this bug was never about the later.
Summary of the change, so people don't have to wade through a long discussion:

 - This change makes it so that `autocomplete=off` does not stop the Password Manager from working. Normal form autofill can be disabled as usual.
 - The password manager *always* prompts if it wants to save a password. Passwords are not saved without permission from the user.
 - We are the third browser to implement this change, after IE and Chrome.
 - This can be undone locally by flipping the `signon.storeWhenAutocompleteOff` pref (from about:config) off.
 - The rationale behind this change was the widespread abuse of the `autocomplete` attribute to prevent password saving where no prevention is required. This change gives users full control over password saving, without compromising on security (again, the user is always prompted).
Whiteboard: p=5 s=it-30c-29a-28b.3 [qa!] → p=5 s=it-30c-29a-28b.3 [qa!][Please see comment 100]
Thanks for the summary. I'm going to restrict further comments on this bug, since it's too long to follow and people obviously are not.

If there are further issues, please (1) actually read through the bug and summary to understand if it's already been addressed, and then either file a new bug or take discussion to firefox-dev.
Restrict Comments: true
(In reply to Kohei Yoshino [:kohei] from comment #102)
> https://twitter.com/FxSiteCompat/status/477243846431354880

Dead link. Intended tweet link is likely:
https://twitter.com/FxSiteCompat/status/477244922387763202
See Also: → 1025703
Depends on: 1061630
Flags: sec-review?(dveditz)
Depends on: 1531135
No longer depends on: 1531135
You need to log in before you can comment on or make changes to this bug.