- From: Chris Holland <frenchy@gmail.com>
- Date: Sat, 12 Mar 2005 13:11:44 -0800
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: sensitiveinput="yes" 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? -chris 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 > security. > 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 > http://mpt.net.nz/ > -- Chris Holland http://chrisholland.blogspot.com/
Received on Saturday, 12 March 2005 13:11:44 UTC