Archive for June, 2010

Safari extension: autocomplete

Thursday, June 10th, 2010

Safari has a feature called form autocompletion, or AutoFill, that reads the username and password you type into a web form, saves them to your keychain, and automatically fills them in from the keychain the next time you visit the web form. This feature is completely opt-in: you can enable and disable it in Safari’s preferences, and even when it’s enabled, Safari will ask you before saving the username and password from each web form. Many other web browsers have a similar feature; it appears to have been introduced by Internet Explorer.

Unfortunately, a number of web sites (including my bank, for example) choose to disable autocompletion in a misguided attempt at security. Autocompletion can be disabled by using the attribute autocomplete=off in a web form. The idea behind disabling autocompletion seems to be that it leaves the account holder vulnerable to someone else accessing the computer and logging into the account. I believe that this is misguided for at least two reasons. First, autocompletion is opt-in, so the user can decide whether to save passwords on a particular machine. Anyone who chooses to save their passwords on a public terminal is an idiot. Indeed, anyone who logs in to their bank account on a public terminal deserves to be hacked and lose all their money, because who knows what manner of keyloggers or other malware could be running on the machine? I feel safe turning on AutoFill on my computer because I’m the only person who ever has access to it.

Another reason that disabling autocompletion is misguided is that it encourages the use of weak passwords. For security, I generate very long, random passwords for web sites and save them to my keychain. There’s no way I could memorize even one of my web site passwords, much less all of them. It’s difficult for almost anyone to memorize a bunch of web site passwords. Disabling autocompletion forces the user to type them in manually every time, and this encourages the use of short, easy to remember passwords. Worse, it encourages password sharing among different web sites. Thus, if an attacker can guess or brute-force one password, the attacker suddenly has access of all of a persons’s web site accounts. That’s terrible security.

WebKit, the web engine underlying Safari, respects the autocomplete attribute, and there’s no preference or API to make WebKit ignore the attribute. However, I discovered an excellent script written by Michael Kisor called Autocomplete Always On! that actually patches the WebKit framework itself on your system so that it ignores autocomplete. It works by changing one byte in the file

/System/Library/Frameworks/WebKit.framework/Versions/A/Frameworks/WebCore.framework/Versions/A/WebCore

transforming the string autocomplete into xutocomplete. After that change, WebKit looks for xutocomplete=off but never finds it in the web form, which means autocomplete never gets disabled. WebKit is open source, so we can verify the consequences of the patch.

The only downside of the Autocomplete Always On! script is that it needs to be re-run after any software update to the WebKit framework on your system. I’ve been using the script for years with no trouble … until Safari 5. After installing Safari 5, I discovered that the script was no longer effective in re-enabling autocompletion. This was no flaw in the script, however. Autocomplete Always On! still works as designed on the version of WebKit shipped with Safari 5. The problem is that the Safari 5 binary itself seems to include a new check for the autocomplete attribute in web forms. I’ve verified this behavior in the debugger. If the form contains autocomplete=off, then Safari 5 never calls the (private) WebKit method -[WebHTMLRepresentation elementDoesAutoComplete:], so Safari doesn’t even ask WebKit whether autocomplete is enabled for the web form element. It is possible to patch the Safari binary just like the WebCore binary, after which Safari 5 will call -[WebHTMLRepresentation elementDoesAutoComplete:], making the WebCore patch effective again. Unfortunately, patching the Safari binary breaks codesigning for the application, and the keychain uses codesigning to determine whether an application can access saved passwords.

That’s the bad news. The good news is that Safari 5 also introduced extensions. A Safari extension is like a plug-in, because it can run code inside the browser, but unlike a plug-in, an extension doesn’t run native C or Objective-C code but rather HTML or Javascript code. For example, an extension can specify some Javascript to run on page load. I found a script written by Andreas Huber that removes any autocomplete attributes from a web form, and I cleaned it up a bit for inclusion in a Safari extension. With my autocomplete extension installed, you don’t have to patch WebKit or Safari, because the autocomplete attributes are simply removed from the web page before the browser checks for their existence.

I’m making my autocomplete Safari extension available — in September. No, today! You can download the extension here. To install the extension on your computer, you first need to check “Show Develop menu in menu bar” at the bottom of Safari’s Advanced preferences. Then in the Develop menu, you need to check “Enable Extensions”. After extensions are enabled, you can simply double-click the Safari extension in Finder to install.

Enjoy! In lieu of donations, I am accepting sexual favors. Or an icon.