Usable Security

While in Montréal, i came across this article on Bruce Schneier’s blog, which points to Paul Thurrott’s scathing review of Vista’s new security restrictions.  In a test build of Vista, even simple operations now trigger popup prompts asking the user for confirmation.  In the reviewer’s example, installing Firefox left a shortcut to Firefox on the desktop, so he attempted to delete the shortcut — which triggered a security dialog asking for confirmation:

But it’s worse than that.  Clicking “Continue” on this dialog only brought up a second dialog, even less helpful than the first:

This second dialog says nothing about the action that’s about to be authorized, the file it will be performed on, or the purpose for which it is being performed.  And how is anyone supposed to know “the source” of “File Operation”?  The first dialog provides no clarity on the meaning of “Repeat my answer” — does it apply to all deletions?  All shortcuts?  All shortcuts on the desktop?  And if you select “Repeat my answer”, what do you do if you want to make an exception later?

These dialogs are the returned ghosts of my all-time favourite example of a bad security dialog, this gem from Netscape 6:

Isn’t that perfect?  There’s no information on what privileges, what purpose, what program, what source, or what possible consequences there might be.  It’s a bit like pointing a revolver at your own head with an unknown number of chambers loaded — except, to make the analogy complete, you are also required to pull the trigger before being allowed to get up from your chair.  But if you blow your head off, the lawyers can say it was your own fault.

That was 2002.  Vista is supposed to be out in 2007.  We haven’t made much progress in five years.

Where do these horrible user interfaces come from?  What software designer in their right mind could expect a user to make such a meaningless decision?

From the perspective of the programmers who implemented these dialogs, there probably seemed to be no better option.  Perhaps they were aware that users would find them annoying and unhelpful, but in the context in which they were working, they could see no way to validate the action other than asking the user.  Since the computer can’t read the user’s mind, the best it can do is to ask, right?

Maybe not.  Let’s step back and look at the context in which dialogs like these are created.  In our shortcut deletion scenario, the user does some mouse operations (like dropping the shortcut in the trash).  These mouse operations are interpreted by the desktop UI as a deletion command and communicated to the operating system.  This may result in messages being sent around among various parts of the operating system.  Eventually, the file system is told to delete the file.

The file system now has to decide whether to honour that request.

From the file system’s perspective, all it knows is that a deletion command has just arrived.  It could have come from anywhere — from the user, from a friendly program, from a malicious program — it has no idea.

Starting from there, the file system really has no way to know what the user wanted, except by asking.  But it’s already too late.  Asking won’t help; it will only frustrate users and train them to ignore these dialogs, since they ask users to repeat a request that’s already been clearly expressed.

The user has just issued a command to delete the shortcut.  Obviously the system understood that command, or it wouldn’t be trying to delete the file.  That it has to ask the user again is a blatant indication that the system’s right hand doesn’t know what its left hand is doing.

In this respect, Vista achieves a whole new level of dysfunction: it outdoes all the other systems i’ve seen by striving to be a system with two right hands, neither of which knows what any of the other hands are doing.  It’s clear that the programmers who created these two dialogs didn’t talk to each other.  If either of them had tested their dialog in the context of the whole system, the redundancy would have been obvious.  And you can even see that the dialogs have very different styles — the first uses the Tahoma typeface, while the second is in Segoe; the first selects Continue by default, while the second selects Cancel by default.  These are all hints that the developers weren’t following a well-thought-out, uniform process in deciding when security dialogs are needed, what they should say, and what they should look like.

Even though the problem is manifested in these security dialogs, the place to fix the problem isn’t the security dialogs.  This isn’t a matter of making these dialogs better or more noticeable, or intelligently predicting how the user will answer these dialogs.  It’s too late to intervene there, because the vital information — user intent — has already been lost.  The correct place to fix the problem is back at the point where the desktop UI first determined the user’s intentions.

The question isn’t “How can the system figure out whether the user really wanted this file deleted?” It’s “Why did the system forget that the user wanted this file deleted?”

The designation of what action to do — delete the shortcut — has become separated from the authorization to do it.  That leaves the file system stuck with the problem of obtaining that authorization from some other source, which is bound to be inaccurate.  The design lesson, therefore, is never to separate designation from authorization.

This entry was posted on Thursday, May 18, 2006 at 11:50 under General, Opinions. You can leave a comment here or trackback from your own site. Use the comment feed to follow comments on this entry.