[whatwg] [WF2] Objection to autocomplete Attribute
frenchy at gmail.com
Sat Mar 12 13:11:44 PST 2005
How about this. Instead of an autocomplete attribute to specific form
elements, how about an attribute that is less specific about
instructing the user agent what to do:
we could place it over a form element or an input element.
>From here, here's what we do: the main issue revolves around shared
computers in public places. Administrators of those computers SHOULD
be instructed to go into their user agent's preferences and enable a
feature that would take steps to protect sensitive information. This
"step" would look into various things, disabling autocomplete on forms
or form elements with the "sensitiveinput" attribute would be one of
the things such preference setting would do.
I'd keep the feature turned-off by default, while making it fairly
easy to enable in the preferences pane.
Upon the first installation of a user agent, upon the first encounter
for a "sensitiveinput" attribbute on a form, a user agent might
consider warning the user. In fact, i would throw this functionality
in the same bag as "password reminder" and "password manager"
features. The existing dialogs could be modified to talk about
"sensitive information and passwords". So, when a user elects to "save
passwords for this site", they'll also be electing to "save sensitive
information" for this site.
that should keep everybody happy, no?
On Sat, 12 Mar 2005 14:15:40 +0000, Matthew Thomas <mpt at myrealbox.com> wrote:
> Lachlan Hunt wrote:
> > Because autocomplete is a user agent feature designed to assist the user
> > with filling out forms, the decision for whether or not to use it should
> > lie with the user. You should also keep in mind that a user agent
> > should act on behalf of the user at all times.
> I fully support your sentiment, but all this part of the spec is doing
> is more closely matching unavoidable reality. In the current market,
> form control vendors *will* support autocomplete="off" -- whether it's
> in any spec is completely irrelevant.
> It's a prisoners' dilemma that works like this:
> 1. Stupid banks and other e-commerce sites (which is a substantial
> proportion of them) think autocomplete="off" improves their
> 2. If any free-as-in-beer browser implements autocomplete="off" while
> other browsers do not, these sites will *block the browsers* that do
> not, telling visitors to "upgrade" to the browser that does. (That's
> presumably why Microsoft implemented it in the first place.)
> 3. In the absence of collaboration between them, all browser vendors
> are forced to cave and recognize autocomplete="off", because not
> being able to save data entered on the site is a much better user
> experience than not being allowed to use the site at all.
> So if you want user agents to ignore autocomplete=, your most hopeful
> course of action is to take it up with Microsoft. They are, currently,
> the only UA vendor with enough (relatively) immovable market share to
> de-implement autocomplete=, say "stuff you" to the banks and e-commerce
> sites, and (by sheer weight of users) to force the sites to let them in
> anyway. (Even then, a few would force their customers to use Firefox,
> while others would convert their forms to non-autocompletable Flash,
> Java, or PDF. Yes, that would be stupid, but I already said they were
> stupid. And that's why I said "form control vendors" above, rather than
> "browser vendors".)
> A much longer-term strategy is to continue working toward wide use of
> standards-compliant browsers (and Free plug-ins for Java and Flash that
> implement auto-completion uncompromisingly), and then toward neutering
> any ability for sites to tell what browser you're using. Then sites
> won't be able to tell whether your browser or plug-ins support
> autocomplete="off" or not, there will be nothing they can do about it,
> and you'll be able to use autocomplete with impunity.
> Matthew Thomas
More information about the whatwg