Re: comment about autocomplete and saving credentials

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.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 14 September 2009 08:35:39 UTC