The autocomplete attribute and web documents using XHTML

Background

When Microsoft introduced form AutoComplete to the web with Internet Explorer 5 in 1999, they also "extended" the form and text and password input elements of HTML 3.2 with an autocomplete attribute which allowed site authors to disable this feature on a case-by-case basis. Gecko-based browsers gained an autocomplete feature in 2000, and by 2001 they too were forced to support the autocomplete attribute (Netscape Devedge: How to Turn Off Form Autocompletion). The primary motivation for the attribute at that time was that banks believed disabling autocomplete was a necessary security measure for the login information on their websites, and would bar from their services browsers that had autocomplete features without support for disabling them.

In practice, disabling autocomplete is not a particularly effective security measure. Even in the days of Internet Explorer 5, any machine could be compromised by keylogging that would of course be undeterred by a mere autocomplete attribute. Thanks to the rise of User-Agent spoofing, it became increasingly difficult to exclude browsers like Opera that support form history but ignore the autocomplete attribute by default (Opera's Settings File Explained). And now that web users increasing edit the content delivered to them from the server to suit their own preferences, circumventing the autocomplete attribute is trivial (Remember Password Bookmarklet) even in Mozilla browsers that claim to support it "perfectly" (Mozilla Developer Center: How To Turn Off Form Autocompletion).

I don't know of a formal statement of the current attitude of banks towards autocomplete, but I suspect many still believe it to be an important safeguard, notwithstanding the flaws I've just mentioned. As late as November 2004, financial standards bodies like APACS were insisting that sensitive systems make use of the attribute and failure to use it could spell public relations disaster (BBC News: Bank moves to close web loophole). Security consultants like McAfee's Corey Benninger continue to recommend that site owners employ the autocomplete attribute (Developer: Browser Cache: Goodies For Hackers). The developers of the Web Forms 2.0 specification were forced to support the autocomplete attribute (http://whatwg.org/specs/web-forms/current-work/#the-autocomplete Web Forms 2.0 Working Draft: The autocomplete attribute) even though they do not believe it offers any genuine security benefits (Lachlan Hunt kicking off an epic thread on the subject at the WHATWG mailing list).

In 2004, Kevin Gibb's Google Suggest found a new use for the autocomplete attribute: disabling the browser's autocompletion in order to allow a website's own JavaScript autocompletion to begin with a blank input field. Although it is possible to achieve a similar effect without the attribute, Google has set a precendent and now such non-standard code is churned out by Ajax developers, libraries, and toolsets everywhere. For example, Ruby on Rails's autocomplete helpers use it.

In summary, it seems that despite being non-standard, having known security flaws, being replicable with alternate techniques, and suffering from limited browser support (e.g. ELinks has form history but does not recognize the attribute), autocomplete is here to stay.

The Problem

1. Mainstream web development should be based on common markup based on some sort of standards.

2. When serving content is important to be accurate about what standard you are following (hence need for the Vary HTTP header, MIME types, document types, XML schema, microformats, etc), or the standards themselves become depreciated.

2. The web is gradually transitioning from HTML to XML-based markup, helped by minority browsers that can parse the application/xhtml+xml internet media type correctly.

3. When writing HTML, it is trivial to express the autocomplete attribute using the SGML standard by creating a custom DTD and using that as your doctype. You can create such a DTD by simply adding the following line to the HTML 4.01 DTD:

<!ATTLIST (form|input) autocomplete (on,off) #IMPLIED>

4. The X in XHTML stands for "extensible". But because all elements and attributes are namespaced in XML and the W3C jealously guard their XHTML namespace from extension by others, a site author may not do the same with XHTML-based markup. While it is certainly possible to build a custom XML DTD to include an autocomplete, the act would be meaningless as the W3C have made it clear they would not regard documents extending the XHTML namespace in this way as even using XHTML at all (XHTML Modularization 1.1: Working Draft: Conformance Definition, also see A List Apart: More About Custom DTDs).

5. Therefore there is no current way to use a simple markup attribute to turn off autocompletion when using XHTML.

Possible solutions

1. The ideal solution would be to persuade the web and financial communities to employ other techniques. Good luck with that.

2. The next-best solution would be to persuade the W3C to include the autocomplete attribute in an XHTML module similar to the Legacy module. But I think that will never happen.

3. More plausibly, we could create and support a microformat (Microformats Wiki: Introduction to Microformats) recognizing a class="disable_form_history" and treating it as equivalent to autocomplete="off". When serving the same resource in an HTML representation (e.g. with content negotiation), it would be simple for an XSLT transformation to add the correct autocomplete attribute and leave the class untouched. For example:

<xsl:template match="xhtml:input[@class=" priority="10"> <xsl:element name="{local-name()}"> <!-- Process attributes --> <xsl:apply-templates select="@*"/> <legend></legend> <!-- Process children --> <xsl:apply-templates select="child::node()"/> </xsl:element> </xsl:template>

Whichever solution is adopted, it is at present only important for Mozilla, KHTML, and WebKit developers to recognize this attribute, as (AFAIK) only browsers based on their engines both correctly parse application/xhtml+xml and claim to allow form history to be disabled by site authors.