Re: comment about autocomplete and saving credentials

[John Snyders]

Ian Hickson wrote: On Mon, 31 Aug 2009, John Snyders wrote: I have a few comments on the autocomplete attribute section 4.10.4.2.1 I think a distinction needs to be made between browsers remembering a list of values for a single input and a browser offering to remember login credentials. The first case is clearly described and easy to understand. The second case is more complicated. Browsers somehow associate the username and password as a pair and offer to remember them. Ideally browsers should store the credentials in a secure manner. What distinction would you want the spec to make? Basically that autocomplete on passwords works different from other inputs. I went back and read what Microsoft has to say about autocomplete (since they started this). The MSDN topic "Using AutoComplete in HTML Forms" says: "The AutoComplete feature does not operate in the same fashion with password fields as with regular text fields." The whole autocomplete section starts off with an assumption that we all know what the auto complete browser feature is, which we do. But someone that just arrived on this planet wouldn't know from the spec what the autocomplete attribute controls. An intro such as this may help: User agents may have a feature that remembers and later prefills input values. The autocomplete attribute allows sites to make recommendations about how this feature treats input values. Then describe the states and their meaning. Then make the distinction about autocomplete on a password field. Remembered values for passwords are treated differently. A password value is not stored on its own but is paired with a user name or id to make a credential. If a password input cannot be associated with another input to make a credential then it must not be stored. The autocomplete state on a password input controls the remembering of the credentials. But this is where my testing of current browser behavior shows that there is disagreement.  Safari and Opera seem to ignore autocomplete on password and use it on the username to control remembering credentials. I don't like the idea of using autocomplete on username to control remembering credentials because it possible (perhaps even desireable) that you want to remember credentials but you don't want to be presented with a list of previous usernames to pick from. I think that means that Chrome works exactly as I would expect in this regard. I'm concerned about the arms race between the banks not wanting the browsers to store the users credentials and the users wanting the convenience of having their credentials remembered. It seems the banks don't trust the browsers. But most browsers have the option of keeping credentials in a secure store using a master password and two way encryption. I think the spec should explicitly state that a user agent that is going to store credentials should allow the user the option of using a master password protected store or an OS provided equivalent. That's entirely up to the UA, and out of scope of the spec, as far as I can tell. The UA can store the passwords on punched cards guarded by small trolls, for all the spec cares, no? Yes there is an important distinction between the HTML5 standard and implementations. And the standard should not go too far into the details. However there are already many places where the spec makes recommendations about what the UA should or may do. In this section alone there is an implied recommendation in "...the user can expect to be able to rely on his user agent to remember values..." when in fact there is no rule that a UA has to implement any kind of auto complete or credentials remembering feature. The last paragraph makes it clear that the UA may put the user in full control of this functionality. It also specifies how the elements value is modified when a remembered value is chosen. I don't want to say exactly how to store the data but just to characterize the data as sensitive/private. How about adding something like: A user agent may store information entered into inputs (just the inputs that support autocomplete attribute right?) for the benefit of the user when filling out that input or ones like it in the future unless the resulting autocomplete state is off. How stored values are associated with an input is up to the user agent.  The stored information must never be made available through the DOM or any other API. A user agent should consider that even when the autocomplete state is on the user may still consider the information stored to be sensitive so appropriate security measures should be taken to protect the data.  If storing passwords as part of credentials they must be considered highly sensitive. The browser should also provide some kind of warning to the user about the dangers of remembering passwords without a master password. If this were done perhaps the banks would trust the browsers and we could do away with autocomplete having anything to do with saving credentials. I don't think the spec should be mandating warnings of any kind. Agree this comment is more for the browser vendors than the spec. The spec does have a paragraph about the user agent giving the user the ability to override autocomplete but there should be two separate options one for single value autocomplete and another for storing credentials. That's up to the UA. I don't think the spec should be getting into that kind of discussion. Thats OK as long as the distinction is made about passwords in the beginning. I don't know if the best thing is just to describe current browser behavior or if there are better recommendations. Isn't what the spec says now adequate? It lets implementations have the flexibility to provide new features, while defining the minimum they must do to be compatible with sites. I just want the semantics of autocomplete attribute to be clear. You can't just say there's an autocomplete attribute use it for whatever you like (not that the spec does but it can do better). In section 4.10.4.2.1 the example given seems to be related to the login credentials case. Consider adding another example that prompts for something like a social security number. I don't really want to encourage people to use this feature too much, so I'd rather not have too many examples. I understand not wanting to have too many examples and agree that autocomplete isn't used often in practice. My concern is to make sure people know what autocomplete means so they will use it appropriately. Probably one example is fine. The paragraph on how autocomplete defaults is difficult to follow. The long sentence should be broken down into simpler parts perhaps indented or use pseudo code. I'm not sure which sentence you mean. Here it is: When an input element's autocomplete attribute is in the on state, when an input element's autocomplete attribute is in the default state, and the element has no form owner, and when an input element's autocomplete attribute is in the default state, and the element's form owner's autocomplete attribute is in the on state, the input element's resulting autocompletion state is on. Otherwise, the input element's resulting autocompletion state is off. Here is what what I think it should be: When an input element's autocomplete attribute is: -  in the on state, or -  when an input element's autocomplete attribute is in the default state, and the element has no form owner, or -  when an input element's autocomplete attribute is in the default state, and the element's form owner's autocomplete attribute is in the on state, the input element's resulting autocompletion state is on. Otherwise, the input element's resulting autocompletion state is off. I also wonder if the 3rd case should be: -  when an input element's autocomplete attribute is in the default state, and the element's form owner's  resulting autocomplete state is on, Microsoft documentation says any value other than off means on but I prefer they way HTML5 spec is specific that the values are on and off. Thanks, -John