W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2005

[whatwg] [WF2] Objection to autocomplete Attribute

From: Chris Holland <frenchy@gmail.com>
Date: Mon, 21 Mar 2005 17:30:16 -0800
Message-ID: <8da6ad50050321173063f4eefc@mail.gmail.com>
i need to better articulate what i had in mind for a "sensitiveinput"
attribute to form or form elements:

Let's forget about "autocomplete" for a second, and focus on a
different specific feature, which is "saving passwords".

Today, all browsers ask you whether or not you wish to save passwords
on a given site. If they don't ask you via prompt, they let you
specify it in a preference.

A browser identifies a "password' field through an attribute "type"
whose value is "password".

If a user has explicitly allowed their browser to save passwords for a
given site, the next time they come back to this input box, their
password will be pre-filled with dots *******.

Now, I would like "sensitiveinput" to be a part of this specific
behavior, enabled based on the exact same preference that governs
password auto-completion. Imagine "sensitiveinput" being just like
making all your sensitive text inputs of type "password": their
auto-completion behavior mirrors that of passwords, yet their display
isn't as obfuscated.

SO, whenever a user, at any given time, is asked by their browser "do
you wish to remember passwords for this site?", if they click Yes, the
browser will not only remember passwords for this site, but also all
inputs that are marked with the "sensitiveinput" attribute, on-top of
remembering non-sensitive inputs.

If the user answers "NO", then the browser will make a point of NOT
remembering passwords and inputs with the "sensitiveinput" attribute.
It may remember other inputs that are not marked "sensitive".

With all this in mind, the message that today, in most browsers, says
something like "do you wish to remember passwords for this site?"
might be reworded to "do you wish to remember passwords and other
entries of sensitive nature for this site?".  ... or not ...

Again, i'm not talking about "adding yet another warning for sensitive
inputs", i'm talking about leveraging an existing warning, and
extending its behavior to a new type of attributes.

With that said, this is all ideal-world speculation, likely not
something that we'll be able to put into a draft or anything, but i
just wanted to at least clarify the idea so it can rear its head back
up should an implementation opportunity arise.

-chris





On Tue, 22 Mar 2005 09:39:44 +1100, Lachlan Hunt
<lachlan.hunt at lachy.id.au> wrote:
> Olav Junker Kj?r wrote:
> > If I understand correctly, your objection against "autocomplete" is that
> > it specifies UI behavior rather than semantic information about the data
> > (like a "sensitiveinput" attribute would).
> 
> Yes, that and the fact that it provides control of a user agent feature
> to an author which, as I stated in my initial post, is a user-hostile act.
> 
> Although sensitiveinput is a slightly more semantic name, the problem
> with it is not only because it's not already supported; but because,
> theoretically, any form with a password could be considered sensitive
> input, which may result in many more authors making use of it believing
> they are doing the right thing by adding more semantics, yet effectively
> preventing password managers storing any passwords at the expense of the
> user.
> 
> > This could easily be solved by keeping the name "autocomplete" but
> > redefine its sematics as indicating that the input data is sensitive.
> 
> Redefining its semantics would be an improvement.  Although it's not an
> ideal solution, it's one I may just have to accept.
> 
> --
> Lachlan Hunt
> http://lachy.id.au/
> http://GetFirefox.com/     Rediscover the Web
> http://GetThunderbird.com/ Reclaim your Inbox
> 
> 


-- 
Chris Holland
http://chrisholland.blogspot.com/
Received on Monday, 21 March 2005 17:30:16 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:39 UTC