Autocomplete. It’s a convenient evil common and popular among today’s browsers. The ability for Autocomplete to store certain bits of form data for return visits can be greatly convenient when filling out a variety of forms on the Internet today. However, in order for Autocomplete to work, the data in question must be saved somewhere, and that somewhere needs to be accessible in the browser. The claim on many is that on Mac OS X, Safari stores it’s autocomplete data in the Key Ring, which is saved to disk using strong encryption (though the keyring password is always in memory, and susceptible to certain types of DMA attacks). Internet Explorer and Firefox are not designed to integrate tightly with such software, so while they may obfuscate their representations of saved data, the data is still easy to recover.

And this is the inherent evil in Autocomplete. The feature can and will save immense amounts of personally identifiable information, from usernames and passwords, to addresses, credit card numbers, etc. Credit Cards are, of course, the issue where most people get up in arms about Autocomplete.

At some point, the browser developers decided that, if a field wasn’t supposed to utilize autocomplete, that it was the responsibility of web developers to tell them when fields were supposed to not utilize the Autocomplete feature. Some people argue that it is important that the web developer do this, for the instance where the user is inputting ‘protected’ information into a public terminal, which, unfortunately, rarely have autocomplete disabled. Frankly, if it’s a public terminal, you shouldn’t be putting any information you care about keeping confidential into it. What part of public do people fail to understand?

This issue was initially raised on SomethingAwful.com, where a forums user requested that the site stop offering to helpfully fill in his credit card information in the forums store. The near immediate response from the (non-technical) lead of the forums? That we’ll gladly disable our psychic ability to guess your credit card number. Even without fragmaster’s comment, an argument ensued about whether or not this was the responsibility of the site. My argument is that sites legal responsibility to protect user data extends only as far as the data-link used to connect the client to the server.

The very nature of the web demands this, as the very nature of the web is such that we, as web developers, have no control over the client that is being used to connect to our system. Attempts to limit which client browsers connectivity can be thwarted with relative ease. It is our responsibility to ensure that we’re not serving up confidential information to the wrong people; to ensure that the data in our possession is properly secured, and that the links on which that data travels are properly secured as well.

The PCI Data Security Standard, a Credit-Card industry think-tank, requires that stored cardholder data is to be secured in a reasonable fashion, utilizing encryption and access restrictions and implementing a data retention/disposal policy regarding cardholder data. The PCI DSS is not a law, however, so while not following it’s guidelines can cause the merchant providers to revoke ability to use their service, there are different sets of laws (and legal requirements) regarding data breaches.

The question becomes who is liable for the security of this data. I argue that it is the cardholder who is ultimately responsible for who they provide their card information to. Once that card information has been provided, it is the responsibility of the storing party to secure it. As a web-developer, I am not responsible for the security of your browser. I am responsible for securing my databases. I am responsible for protecting the SSL Certificate that we use to communicate. I am responsible for any content served to you from my servers. But, I am not responsible for your decision for ensuring that your browser or operating system are secure.

If an attacker is able to access your autocomplete files, then they can very likely implement another form of attack that completely circumvents the issue of autocomplete all together, be it by sniffing traffic for web forms with credit card numbers, or logging keystrokes, or any other mechanism. As a web developer, I can’t be held liable if your credit card number is intercepted due to malware installed on your machine, and in the case of Autocomplete, the browser is behaving in a malware-like manner. If it is any software-vendor’s responsibility to ensure the security of any data subject to autocomplete, it is the browser vendors responsibility.

Admittedly, Internet Explorer, Firefox, and Safari all three support an extension to the <input> and <form> tags, which can disable autocomplete. However, this is a non-standard extension, which causes failed validations, and frankly, disguises the risk inherent in autocomplete. A more standards-compliant mechanism to support this would be using Javascript to set the autocomplete variable to “false”, like the in following:

        // Disables autocomplete on the Google search box
        document.forms[0].q.autocomplete = "false";
        

Alternatively, register an “onfocus” event with the input field can accomplish the same thing. For browsers that don’t support the option, nothing happens, and for browsers that do, this is a standards-compliant means to disable autocomplete for the given field.

It’s a relatively easy thing to do, adding only a small amount of bandwidth to each pageload, on pages that aren’t accessed as frequently as many other pages. So, why do I feel it’s such a waste? Because it makes people feel that an inherently insecure feature is more safe than it really is. Plus, my responsibility to protect their data should extend no further than my ability to control their data extends. Users can choose to override this option, a users credit card number might be stolen by someone looking over their shoulder as they enter it in, someone could be watching the desktop through a VNC-like service.

This has not, to the best of my knowledge, been tested in court. Many organizations are going to cover their own asses by simply adding code to disable this, which may not be wholly unreasonable to do, though I’d suggest going the Javascript route, for compatibilities sake.

The question of who is responsible if a credit card is stolen from autocomplete data is a complicated one. Is it the Application Vendor? I feel that it obviously is not, since the autocomplete is a feature of the browser, not the application. Is it the browser vendor? Probably not, they do ask the user if they want autocomplete, though they do make it easy for the user to zip by and enable it without thinking too hard about it. So, who’s left? The person who owns the computer from which the compromised data was recovered from? If it’s a public terminal, whoever configured it should never have allowed autocomplete to be active. However, the person still expressed an implicit trust to the owner of the system when they put their credit card information into it. On a public terminal this is always dangerous. Using a computer owned by someone else always implies that you trust that person enough that they won’t misuse it.

Users need to be aware of the risks. Using autocomplete has the risk of revealing personal, confidential information. It is up to the user to ensure that they only entrust the data to people whom they feel are trustworthy. Once the seller has secured their database and provided encryption for all communication channels over which the card number will travel, then the merchant has done all that they can, and any autocomplete magic that they might attempt is doing nothing more than masking a real risk, or disabling a feature that some users might actually want.