comment about autocomplete and saving credentials

[John Snyders]

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.

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.
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.

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.

When banks moved the user name and password prompts to different pages
(perhaps to support SiteKey) this kept browsers from associating the two
so they couldn't remember credentials. Then Firefox got smart enough to
handle this case. A side effect is that a password input that has
nothing to do with authentication ends up getting autocompleted in some
cases.

I did some testing and found different behavior among the browsers:
- Safari 4(win) and Opera 9.64 would never auto complete the user name
(regardless of autocomplete setting) and used autocomplete=off on the
user name input to control offering to remember credentials.
- Firefox 2-3.5: autocomplete works as expected on the user name field
to control remembering previous usernames and autocomplete=off on the
user name or password field controls offering to remember credentials.
- Chrome: autocomplete works as expected on the user name field to
control remembering previous usernames and autocomplete=off on the
password field controls offering to remember credentials.
Sorry didn't test any version of IE.

The input password state explicitly allows the autocomplete attribute
but the semantics are not clearly defined.  Clearly it doesn't make
sense to remember the password like you would a text input since a
browser would never present a list of previously entered passwords in
plain text and a list of ******'s isn't helpful either. So it must be
related to remembering login credentials.

Given the current state of browsers if you want to recommend that the
browser not store user login credentials you need to set
autocomplete=off on both the username and password input prompts. In
addition because of Firefox you need to set autocomplete=off on all
password fields that are unrelated to login autentication.

I don't know if the best thing is just to describe current browser
behavior or if there are better recommendations.

Some extreme options are:
- autocomplete should not be used to control saving credentials at all
and either
  - sites have no business telling the browser what to do in this area
(because of Firefox supporting
    username and password on different pages there still needs to be a
way to say a password input
    has nothing to do with authentication)
  - or a new attribute (perhaps on the form) is added to explicitly
state that the site requires the
    highest level of security which the browsers can interpret as a
request (the the user can override)
    to not store the credentials.
- It might be worth while distinguishing a password/pin as part of login
credentials from an ordinary
  secret field (one that does not echo). The first would be called
password and the second would
  be called secret.

Minor things:
In section 4.10.4.2.1the example given seems to be related to the login
credentials case. Consider adding another example that prompts for
something like a social security number. Also the PIN input type should
be type password rather than text to be more realistic.

Perhaps examples, even though they are just examples, should show best
practices such as using a label rather than just text like Account: or PIN:

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.

[Ian Hickson]

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?


> 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?


> 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.


> 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.


> 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.


> 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.


> Also the PIN input type should be type password rather than text to be
> more realistic.

Good point, fixed. Thanks.


> Perhaps examples, even though they are just examples, should show best
> practices such as using a label rather than just text like Account: or
> PIN:

Fixed.


> 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.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[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

[Ian Hickson]

On Thu, 3 Sep 2009, John Snyders wrote:

>
> 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."

I don't really see where in the current spec text it says anything that
assumes any particular behaviour here -- the password behaviour seems to
fit with the spec text just as the other case.

> 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.

I've tried to add an intro section that is in the style of the spec that
helps with this.


> Then make the distinction about autocomplete on a password field.

I don't really understand what distinction you want here.


> 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.

Why isn't this just up to the UA?

> 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.

That really seems up to the UA. I mean, it's common sense that the UA
needs to care about the user's data. Theres no point the spec handholding
the implementors through this. Either they care or they don't, the spec
isn't going to change that.


> 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.

Ok.

> 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.
>
> 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've tried to make that sentence clearer.


> 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.

The "on state" and the "off state" aren't necessarily the same as the
actual values of the attribute:

   http://www.whatwg.org/specs/web-apps/current-work/#attr-form-autocomplete-on-state

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'