[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [WEB SECURITY] Autocomplete attribute

Andrew,

Wow! Thanks for that lengthy reply. Some of that went sailing over my head, and some of it touched on major areas of web development that go way beyond my little cleanup operation. Above all I need to respond to:

My major concern is complexity. 

Let me try and alleviate that concern. :)

For example, autocomplete="off" is simple and easy to understand.
Setting four lines of XSL and then
some more code after that which does *EXACTLY* the same thing as the three word version ... but may not be supported in any of the four browsers for some time will simply get no traction. Don't over- engineer the thing. That happened to SAML, and look where it is today. I do not vote for solution 3.

The key purpose of my suggestion is to find an XHTML equivalent for "autocomplete". "Setting four lines of XSL and then some more code after that which does *EXACTLY* the same thing as the three word version" inaccurately appraises the current situation, since *there is no existing version in XHTML at all*, let alone a "three word version".

With my proposal implemented, XHTML 1.0 developers would simply use "class='fh disable_form_history'" where in non-standard HTML they would have used "autocomplete='off'". With modularized XHTML, they would employ a custom doctype including a namespaced attribute. Here's an example document:

http://tinyurl.com/h8rx9

Have a look at the source. That's not quite so bad, is it?

The XSL that horrified you is *only* relevant to the apparently very small group of developers who want to serve modularized XHTML to XHTML clients and HTML4 to HTML clients (sorry if that wasn't at all clear), for use when transforming XHTML+whatever to HTML using XSLT. My little template rules are a drop in the ocean of that complexity, which desperately needs standardization itself (since HTML-only clients aren't about to drop off the edge of the earth).

To try and make the effects of implementing my suggestion more transparent, I've added to my draft an executive summary --

http://wiki.mozilla.org/The_autocomplete_attribute_and_web_documents_using_XHTML#Executive_summary

-- and a section that breaks down those effects depending on what sort of content you're serving:

http://wiki.mozilla.org/The_autocomplete_attribute_and_web_documents_using_XHTML#How_would_Option_4_help_web_authors_if_implemented

Moving on ...

The controls you are talking about deal with state at rest, not
state in transit. Key loggers deal with data that is in transit, not
at rest.

I wasn't quite sure what you were getting at with this. Are you saying that keylogging does *not* compromise the security of the "autocomplete" attribute?

I have a huge problem with the idea that autocomplete is
detrimental.

As my immediate concern is with the somewhat esoteric subject of markup, I am *trying* to represent the balance of the debate. Like I say in my draft: "even technical opinion is divided over whether "autocomplete" offers valuable protection against casual attackers or merely lulls users and web authors into a false sense of security, leaving them vulnerable to more determined assailants."

While, like me, you draw attention to the superficial advantages offered by "autocomplete", perhaps you'd like to offer some arguments against such objections as:

1) The attribute encourages users to take unwarranted risks (e.g. assuming public machines are safe for online banking or that all browsers treat data hinted sensitive similarly).

2) It encourages more amateur web authors to jeopardise their users' security under the illusion that "autocomplete" is reliable.

We need some method of controlling cached state for form data, and
for that to be  enforced. All of the usual suspects are suggestions
only. We rely upon hints like autocomplete to ensure that caching of
private user data is off. We can't guarantee it on any browser
today,  but at least it's ignored. Realistically, we'll continue
to use  autocomplete=off as long as it's supported.

But the whole problem addressed by my suggestion is that it's *not* supported in any shape or form by XHTML markup - not even XForms AFAIK.

I didn't follow what you meant by "at least it's ignored."

With regards to the rest of your post, your suggestions revolve around JavaScript security, whereas "autocomplete" and my solution, in so far as they work at all, function even when JavaScript is disabled (except perhaps for support backported with XUL/XBL). I agree that we need more security built in to JavaScript (and (X)HTML generally). But that's a much bigger project. So while I've added that option to my draft, with a link to your suggestions here, I've made clear that I think XHTML developers need something to tide them over until then, namely a namespaced attribute and microformat.

Out of interest, have you tried putting your suggestions about JavaScript security to the folks working on a standardized XMLHttpRequest (http://www.w3.org/TR/XMLHttpRequest/), or WHATWG (http://www.whatwg.org/), or Brendan Eich and Waldemar Horwat, who are slowly developing JavaScript 2.0 (http://www.mozilla.org/js/language/)

_________________________________________________________________
Windows Live? Messenger has arrived. Click here to download it for free! http://imagine-msn.com/messenger/launch80/?locale=en-gb


----------------------------------------------------------------------------
The Web Security Mailing List: http://www.webappsec.org/lists/websecurity/

The Web Security Mailing List Archives: http://www.webappsec.org/lists/websecurity/archive/
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

Brought to you by http://www.webappsec.org