- From: Thomas Roessler <tlr@w3.org>
- Date: Fri, 14 Apr 2006 17:13:13 +0200
- To: George Staikos <staikos@kde.org>, "Capps, Robert, BKOF" <RCapps756@Worldsavings.com>, Michael.Mccormick@wellsfargo.com
- Cc: public-usable-authentication@w3.org
On 2006-04-11 12:53:23 -0400, George Staikos wrote: > 3) Some forms make it very difficult to make this work > 3a) Script changing the form after page load > 3b) Script changing the form field contents dynamically for "security" > 3c) Just plain weird usage of forms > 3d) Dynamically changing URLs ... > Yes, we could improve forms for this. One thing that > would be nice is to have forms that explicitly state that > they are "wallet-appropriate". Right now we have to guess, > and the guessing doesn't always work right (see #3 above). Additionally, there is of course any number of login-like forms that aren't recognized properly by the form fillers that are currently out there -- e.g., some get confused about which login and password fields belong together; there are composite login fields; and so on; there are "login" forms that ask just for a password; etc. I could imagine some work on annotations that could help take care of these sets of problems, and hence move form-fillers out of the area of second-guessing what sites want. More reliable form-fillers could then be a useful contribution in mitigating those kinds of phishing attacks that attempt to get hold of online login credentials. In scoping this kind of work, we would need to think carefully about which questions benefit most from a consensus answer -- and which ones may more be in the realm of decisions that vendors make. A very narrow scope could, for instance, focus on defining simple login form annotations, microformat style, and could rule any questions about the security of password stores and best practices for form fillers' user interaction out of scope. Some reactions to this strawman would be most useful. On 2006-04-11 18:02:39 -0500, Michael.Mccormick@wellsfargo.com wrote: > Behavior of browser form & password autofill features should > be configurable to both the end user and the web site. If > either the user or the site disables an autofill preference, > the autofill should not happen. This would be a requirement for the annotations discussed above. > Browsers that offer autofill features (esp. for passwords) > should be required to meet some minimal standards for > protecting the cache where they're stored on the user's > computer, such as encryption with a key unique to that user > which is known only to the browser. > Browser or OS install wizards should ask if the computer is > public or not, and if so all autofill features should be > disabled by default. Autofill at airport kiosks and > Internet café PCs represents a common attack vector. I wonder how to best accomodate these kinds of discussions -- they don't really fall into the realm of interoperability work, but much more in general best practices for vendors. Further input welcome! Regards, -- Thomas Roessler, W3C <tlr@w3.org>
Received on Friday, 14 April 2006 16:23:59 UTC