The Cone Trees network The UX Bookmark UX Quotes UX Jobs in Singapore Nice one yeah!



Usability Spotter #6- The Twitter login page password revelation issue

On its login page, Twitter uses JavaScript to set focus on the user name text field so the user can sign in to the account with least effort possible.

However, due to the incompleteness and the placement of the JavaScript, there is a possibility that the user’s password may get revealed (in the user name text field of the login form) if the user attempts to enter their account details before the login page completely loads. The description of the usability issue and solution are discussed ahead.

Update (Jan 20, 2010): I informed Twitter about it and Anamitra Banerji from Twitter product got back letting me know he has someone working on fixing it.

Update (Mar 28, 2010): I noticed today that they (finally, one and a half months later) fixed up the issue.

The Issue

Setting focus on text field to increase usability

In order to make the login form easy to use, the technical team at Twitter uses JavaScript to set focus on the user name text field upon loading of the login page. The user is saved time and effort of either:

  1. Having to tab through elements on the page (using the keyboard) in order to set focus upon the ‘username’ input field.
  2. Or moving the mouse to position it over the user name text field and clicking upon it in order to begin entering account details.

Placing JavaScript at the bottom to decrease page loading speed

The team also chose to place this ‘text field focus’ JavaScript at the bottom of the page code right before the closing tag. This makes sense since placing JavaScript at the bottom of the page helps decrease page loading time.

This is because when scripts download, nothing else can be downloaded along with it in parallel (in contrast, multiple images could have come through at the same time). So that is why moving them to the bottom gives a chance for the rest of the page to load up faster.

The above two combined form the issue

The ‘text field focus’ JavaScript, as discusses above, is a good idea, but would however only be effective if the JavaScript loads and sets focus upon the input field before the user manually does so.

And in the case of slower internet connections, since the JavaScript code is placed at the bottom of the page, there is a high possibility that the user may begin to enter their account details before the page fully loads and as a consequence, their password could gets partially or completely revealed.

So lets look at three cases- one where the JavaScript loads on time (before the user manually sets focus on the ‘username’ text field) and the other two, where the JavaScript does not load on time.

1. JavaScript loads before user manually sets focus on the ‘username’ text field and begins typing username

Twitter login form
Everything is fine and as intended. Focus is set on ‘username’ text field. The user can proceed to typing in credentials.

2. JavaScript loads after user manually sets focus on the ‘username’ text field and user is about to begin typing or is already typing in the user name.

If the user is typing in username when JavaScipt loads, there are no problems

The script does not achieve its goal since it failed at setting focus on the ‘username’ text field for the user who had to do so manually. Before the user begins to type in the user name or during the process of doing so, the JavaScript sets focus on an already focused ‘username’ text field. This does not affect the user in any way who can type in the user name without any issues.

3. JavaScript loads after user sets focus manually on the ‘username’ text field, completes typing in username, and now sets focus on the ‘password’ text field, and is either:

  1. Beginning to type in the password
    In the lesser probable case of the two, if the JavaScript loads just when the user is about to begin typing in the password, the JavaScript will shift focus to the ‘username’ field and the while the user begins entering the password, the password will get revealed in the ‘username’ text field since the focus has shifted to it.
    If the JavaScript loads when the user is just beginning to typing in the password, then there is a big issue
    But won’t users notice their password appearing in the username text field? Most probably not until most of or the complete password has been revealed- novice to intermediate computer users will look at the keyboard while typing in the password. Expert users may not have to do so, but since there is also a possibility that expert users will choose complex passwords as compared to novice users, it is probable that they will look at the keyboard too while they type in the password too.
  2. Already typing in password

    If the JavaScript loads when the user is typing in the password, there is a problem
    If the JavaScript loads while the user is already typing in the password in the ‘password’ field, then the focus will shift to the ‘username’ field in between and the password will partially be revealed in the ‘username’ text field as illustrated in the example below.

Severity of the issue

This could be labeled as a usability issue medium to high error severity since the issue translates to a security concern.

Having the password reveal itself without the wishes of the user is bad usability because the application is not behaving as the user expects it to. When a user enters data in a text box, the user expects the data being filled to appear in the text box- either masked or as is depending on whether it is a password text field or not. What the user does not expect is to see the focus of the text box change to another and their password get revealed.

Of equally serious concern is the consequence of the issue- the user’s password is partially or completely revealed, without their intentions of the user wanting to do so. This password may be observed by a passerby who the user does or does not notice, who may then go on to compromise the account.

The Solution

This issue is certainly something Twitter should fix immediately considering low level of effort (LOE) required to plug it up. There are two solutions to the issue, both very simple both with their pros and cons.

Solution 1

By shifting the code and placing it above the ‘username’ field of the login form, it is guaranteed that the script will load before the form loads. And thus, the focus will always be set on the ‘username’ text field.

Pro: Focus will always set on ‘username’ field before the user can attempt to do so
Con: Page loading speed may however be compromised.

Solution 2

This solution mitigates the issue in a different sense. It does not ensure that the goal of the text field focus’ JavaScript is met (which is to manage to always set focus upon the ‘username’ text field before the user can attempt to do so) but ensures that the unintended consequence of password revelation will never occur.

The solution is to modify the code logic and keep it at the position it is currently at- so page loading speed is uncompromised and the issue is not caused either.

Currently, the script simply sets focus on the username text field when the script loads. The script may be modified to set up a condition where the script first checks if the focus is already set on either the ‘username’ or ‘password’ text field of the login form. If so, we do nothing since we can assume that the user is busy entering account details. But if the focus is not set upon either of the fields, then we can, as the script, earlier did, set focus upon the ‘username’ text field.

The advantage here is that we do not compromise page loading speed. We also ensure that the user’s password does not accidentally get revealed. What we don’t ensure is the fact that the user may set focus manually upon the ‘username’ text field before the script does so.

Pro: Page loading speed remains uncompromised and the unintended consequence of password revelation can never occur.
Con: The goal of the ‘text field focus’ solution which was to always set focus on ‘username’ before user can attempt to do so is not met.

Your thoughts?

Here’s hoping to see Twitter patch this up as soon as possible. What are your thoughts?

What is a Browser hijack and how to fix it

Here are two articles on it. I didn’t know you called it a browser hijack (makes sense though now that I know what its called). I kept googling with the phrase ‘browser default address changed’ and then stumbled upon what this is actually called.

Here are two articles I found useful that should help you understand and remove it as well (I still haven’t removed it as yet, but intend to soon)