Usable Security

This year I attended South by Southwest for the first time and enjoyed meeting lots of interesting folks.  During a session about decentralized social networks, the panelists mentioned the problem that bloggers (especially beginning bloggers) sometimes post personal information about themselves in public without realizing the risks.  Often they may be unaware of the size of their audience — maybe they think only a few friends are reading, or they forget that the posts are public on the Web and show up in Google.  The individual tidbit of information being posted may seem insignificant but can be combined with other posts to yield a detailed personal profile.

The reactions that followed provided absolutely perfect examples of the two classic kinds of responses to security problems.  I really couldn’t have asked for better examples to illustrate my point, even if I had cleverly planted co-conspirators in the audience to read scripted statements.  (And you know I would never do that.)

Classic response #1: Blame the user. One audience member pointed out that the button to publish a blog post says “Publish.” He argued that users ought to know what “publish” means — of course it means their posts will be public.  If they’re clueless enough to publish personal information that puts them at risk, it’s their own fault.

Well, fine.  It is their own fault.  But so what?  That doesn’t make the problem go away.  When we arrive at a “solution” that consists of blaming the user, it’s time to take a step back and ask ourselves what we’re really trying to accomplish.  Is the primary goal to serve the user’s needs or merely to disclaim responsibility?  If we’re really interested in serving the user’s needs, then whether the user is at fault is beside the point.  Users are bound to be at fault sometimes; after all, they are human.  The real issue is whether we, as designers of the tools, can do any better.  If we can improve the user’s chances of getting it right, we should.

Classic response #2: Annoy the user. Blasting the user with warnings is a common quick fix.  Someone at the session recalled the warning message that used to be displayed by Usenet clients when posting to a newsgroup.  (Remember Usenet?  In its day, folks read news an awful lot.  The command to read news was just two letters — rn — rivalling the importance of all the other cryptic two-letter commands like ls and rm and cc.) Before posting an article, the newsreader program would show a scary warning message like this:

This program posts news to thousands of machines throughout the entire civilized world.  Your message will cost the net hundreds if not thousands of dollars to send everywhere.  Please be sure you know what you are doing.  Are you absolutely sure that you want to do this?

One might imagine a similar warning for users of blogging software:

This program posts your article at a public website, where it can be indexed by search engines and viewed on millions of machines throughout the entire civilized world.  This article could be read by your mother, your boss, the CEO of your company, or someone your future self wants to ask out on a date.  Please be sure you know what you are doing.  Are you absolutely sure you want to do this?

In general, I don’t favour warning prompts.  Although warnings may get noticed the first couple of times, they quickly become a pointless irritation.  Warning prompts train users to hit “Okay” without thinking: interrupting the user’s workflow makes the user eager to dismiss the interruption quickly in order to continue the expected workflow.

A case could be made that a warning prompt is adequate in this situation because it’s intended for beginning users.  Maybe it only matters that they notice it the first couple of times.  But after it becomes ineffective, it’s still annoying, which leaves us worse off than we were in the first place.  The industry standard solution is to add a checkbox to the prompt to let the user turn off the warning.

Can we do better? Let’s come at this from a different angle by considering the user’s path of least resistance.

I use LiveJournal to keep a personal journal.  When I post an entry, there’s a little listbox labelled “Security” that looks like this:

The options are “Public”, “Private”, “Friends”, and “Custom”, with “Public” selected by default.  If I take the path of least resistance and just post the entry, it will be published for my mother and the CEO to see.  LJ doesn’t have a separate way to save a draft of the entry; to do that, I have to post it as Private.  But sometimes I forget.  Also, on LJ, the button to post the entry doesn’t say “Publish”.  It just says “Update Journal”.

In short, doing the safer thing (saving the entry privately) requires more work — I have to remember to change the Security setting.  Doing the riskier thing (publishing the entry to the whole world) requires less work — I just click the button and boom, it’s public.  That’s backwards.

I use WordPress to run this blog.  At the bottom of the box where I’m typing in these words, there are three buttons:

It takes an equal amount of effort to save the post privately as it does to make it public.  That’s better.  Also, the “Save” button is labelled in bold, suggesting that it’s the default.  That has no effect on the operation of the buttons, but it leans slightly in favour of the safer option.

I went over to TypePad today to see how they handle this issue.  At TypePad, you decide whether your entire blog is public or private.

The default is Publicized, the most risky option.  This is arguably a less dangerous context than the moment one posts an entry, though, since nothing has been written yet.  And maybe most users would devote more time and attention to making the choice here since it affects the entire blog.

I wondered what I would do if I changed my mind about this setting.  After the blog was set up, I went to the options.  It took a bit of clicking around to find the privacy setting — it’s not in the Control Panel under “Site Access” as one might expect, but instead within “Publicity & Feeds”, which is inside “Edit Configuration”, which you see after you select your blog from the Weblogs list.  Here it is:

(I was surprised to find it set to “No” since I had just proceeded with a choice of “Publicized”.)

This is where it gets really interesting.  The question asks whether I would like the weblog to be public, but choosing “No” doesn’t really mean “No”.  “No” means “leave everything publicly viewable but don’t announce the existence of this blog.” A sidebar on the page tries to clarify the issue:

The combined effect of all this is too prone to error and confusion.  That last sentence of the question seems especially dubious: “If you do not want the general public to know about your weblog, select ‘no’.” I think it suggests an inaccurate level of assurance.  There are lots of ways for people to find out about a blog besides seeing it on TypePad’s lists.

Finally, what about the moment of posting?  TypePad has an option list that defaults to “Publish Now”:

The buttons provide two possible actions, previewing or saving the entry:

So, to save a draft I have to notice the “Posting Status” option, change it to “Draft”, and then press “Save”.  To publish immediately, I just press “Save” (notice this button doesn’t say “Publish” either).  Again, backwards.

My point?  Consider the possible outcomes and evaluate how much risk each one involves.  The higher-risk outcomes should require greater attention and effort; the lower-risk outcomes should require less.  Ideally, if you arranged all the outcomes in order by risk, they would correspond exactly to arranging the possible user actions in order by difficulty.  That way, when the user makes a mistake, they’re more likely to do something safer than what they wanted instead of something more dangerous than what they wanted.  I like to call this the Principle of the Path of Least Resistance.

Of course, I don’t assume that just switching around the buttons would eliminate the problem of people putting themselves and their jobs at risk by writing stupid things on their blogs.  User education is still important.  The tools themselves can help promote awareness and understanding of the medium: for example, the “Publish” button might be given a slightly more explicit label such as “Post for Public Viewing”.  Collecting and providing readership statistics would help dispel a false sense of privacy—an estimate of the number of unique visitors could be shown right near that “Publish” button.  On posts, an indication of which countries have visited might remind the author of the broad scope of the Internet.  There are lots of possibilities; the important point is that these kinds of information can be provided without interrupting the user with a big warning prompt.  By encouraging awareness without hampering workflow and setting up a safe path of least resistance, we improve the chances that things will turn out the way the user wanted.

This entry was posted on Thursday, March 17, 2005 at 03:40 under Ideas, Opinions. You can leave a comment here or trackback from your own site. Use the comment feed to follow comments on this entry.