March 12, 2005 by Ping

Welcome to this blog.  Though there’s a lot of good writing out there about usability and security as separate topics, the intersection of the two is only just beginning to gather interest.  The communities of researchers and practitioners in both fields need to start talking to each other.  I couldn’t find any blogs focused on usability and security, so I thought it was time to start one.  (If you’ve seen any other blogs on this topic, let us know about them.)

My colleagues and I enjoy thinking and talking about how usability and security affect each other.  We’ll post our ideas and news here from time to time.  I hope you find the articles and discussions here interesting and useful.  If you have something to say, jump right in.

Useless security?
(this is what came into my mind when I read your blogs title, sorry…)

In my opinion, you must not sacrifice security for usability. Any attemt to do so will usually undermine your whole security concept.
Think of Windows - it should have never allowed you to login as Administrator in first place, that is one of the main reasons for windows virus problems.

But you are right, people need to talk to each other. The usability people need to understand where to integrate security into the processes, and the security people need to talk to the usability people on how to make secure but usable authentication schemes.

The schemes in Linux are often very nice, IMHO. Take a Ubuntu Linux box. You login as your user, and when you select the user manager it will prompt you for the password to confirm that action. Assuming that people read what they are being prompted for, this is quite secure. Your random email trojan will not be able to use this to add a new user in the background. The random attacker at your box you left unattended neither.


This system is called gksudo; it’s part of the gksu package. It’s not as secure as it looks. Your random email trojan can remain running in the background and can pop up a dialog box that looks exactly the same as the “real” one — in fact, it can even wait until the real one pops up, then pop up its own dialog on top of it. (I also suspect that it can just register to receive the keypress events on the real dialog when it sees it, but that’s a potentially correctable flaw, and indeed, gksu is documented to support keyboard grabbing, although for some reason it doesn’t work.) Ubuntu’s X servers have the XTEST extension enabled, so your trojan can feed the keystrokes it receives to the real dialog box so that everything works correctly from the user’s point of view. (It’s possible that the real dialog box in that case might be able to notice that it didn’t have keyboard focus, but I doubt that it does.)

It also seems to retain some kind of “ticket” like sudo’s, so that for some period of time after you type in your password, you don’t have to type it again; and this ticket remains valid even after you log out. This means that an email trojan that runs a few minutes after you launched the “users & groups” manager could easily … launch “users & groups” again. Or whatever else that ticket grants you permission to do. My experimentation suggests that gksudo ‘cat /etc/shadow’ works just fine.


So what would you suggest are the main things worth reading for usable security? Roger Dingledine & company did a nice job with the anonymity bibliography at

at assembling a bunch of resources that had been widely distributed. Doing something that comprehensive is a lot of work, but off the top of your head, what are some things that people should be familiar with? “Why Johnny Can’t Encrypt” is certainly on that list. What else?

Josh Levenberg wrote:

How do we suggest questions/topics for this blog? I have dozens. Broadly:
* How can we create an OS with sufficient security primitives? (that is actually two different questions with the same text)
* Given such an OS, how do we make a usable interface?
* How can we get adoption of such an OS?

Is this blog about design questions or acquiring man power?


Good luck on your new blog!


“They that can give up essential usability to obtain a little temporary security deserve neither.”

(with apologies to Benjamin Franklin)

Nice meeting you at SXSW, Ping, and I look forward to reading what you have to say here.

Steve Chan wrote:

“In my opinion, you must not sacrifice security for usability. Any attemt to do so will usually undermine your whole security concept.”

Why do we have systems, if not for the people who use them? And what security concept do you operate under? What are the real risks and costs associated with security?

I’ve worked on operational security teams (as opposed to research on security, or developers who code security tools) for the past 3 years, and I assure you that successful professional security staff always need to balance security against usability (and cost).

The main problem with security is that as a “feature”, it is hard to justify the expense of implementing things correctly in the first place. Good security is not something that people notice and appreciate, until they suffer from the security failure (and then, there is a short lived period when it is a frantically high priority).

As a consequence, outside of relatively small communities, good intrinsic security doesn’t drive adoption or increased sales - except as an after fact product.

David Hopwood wrote:

“The main problem with security is that as a ‘feature’, it is hard to justify the expense of implementing things correctly in the first place. Good security is not something that people notice and appreciate, until they suffer from the security failure (and then, there is a short lived period when it is a frantically high priority).”

Security is not fundamentally different from safety in a safety-critical system. Customers aren’t expected to (and normally don’t) ask for particular safety mechanisms. It isn’t the customer’s job to know in detail what mechanisms are needed; that’s the system designers’ responsibility.

So, I disagree that it is hard to justify implementing things correctly in the first place. The main justification (legal issues aside) is the ethical responsibility not to produce a shoddy and unsafe product.

And incidentally, there are now *large* communities crying out for better computer security. Unfortunately, most non-technical users find it difficult to distinguish between software that is merely claimed to be secure by its providers, and software that really is.


All the best with the new blog. I look forward to reading your thoughts on this subject.


I’m subscribed, and I look forward to your thoughts and advice that I can use to improve my applications so as to be usable but secure.


I have written several blog entries about the intersection of security and usability:

http://www.squarefree.com/2004/07/01/race-conditions-in-security-dialogs (IE is still vulnerable!)

I’m also working on http://www.squarefree.com/securitytips/users.html, which attempts to document everything users need to know in order to be secure while using Firefox. This could turn into something for advanced users to read, or it could serve as motivation for fixing long-standing security problems.

The fact that there are four of you at Berkeley makes me think I should have come to Berkeley for graduate school. Few UCSD profs are interested in usability *or* security. I also enjoy playing with algorithms and complexity, but I don’t feel like I’ll contribute much to those fields.

David Hopwood wrote:


“[Once bug 252811 is fixed...] Look at the hostname in the status bar instead of in the address bar. The status bar cannot be spoofed because web sites cannot hide it when they create new windows.”

More precisely, whether the status bar can be hidden is controlled by dom.disable_window_open_feature.status. Defaults to true (cannot be hidden) as of Firefox 1.0.4, I think. Note that bug 252811 is about whether scripts can by default change the text in the left-hand part of the status bar, as opposed to the domain name on the right.


“In my opinion, you must not sacrifice security for usability. Any attemt to do so will usually undermine your whole security concept.”

The most important thing to realize is that it does not have to be a tradeoff of one for the other. And that even when it is, sometimes you get more security in practice by giving up something that is more secure in principle.

For example…imagine an OS that prompted you for a password every time any program in the system wanted to read from disk. For one thing, it would be so annoying to use that nobody would use it; but aside from that you have now run into the problem that even if you forced people to use it there would be the problems that 1) people would have to constantly being entering their password and would therefore likely choose very simple/short passwords (like, say, “a”), and 2) whether or not they chose a decent password their would be a significant danger of somebody “shoulder-surfing” to get the password. Besides which, such a scheme does nothing to address the problem that people seem to have some psychological issues that keep them from respecting/understanding the security notion behind keeping passwords secret.

Now…that example is rather extreme…but the idea is there. Let’s consider a more realistic example: Simson Garfinkel proposed an e-mail gateway that would automatically encrypt any outgoing messages so that they were protected in transit. This clearly lacks the security of something like PGP…but in practice it adds a layer of security that just isn’t there in general. (And, happily, helps avoid the annoying federal wiretap issue where they tried claiming that police did not need a warrant to read e-mails that were waiting in a mailbox because they were in storage, not in transit.)

The idea can be taken to a point where it is troubling…something like arguing that users should be allowed to use passwords that are as simple as they want and never be required to change them because they you wouldn’t have so many problems with people writting down their passwords. Obviously this is not a secure idea. The trick here is that there is some sort of balance to be struck…but people have to realize that often security and usability can be made to coincide if people focus on practical security rather than theoretical models.



Welcome to the Security and User Experience region of the blogosphere! Glad to see you’ve put up a stand and started hawking your opinions. We need more of that.

You said you couldn’t find any blogs focused on usability and security, and wanted to know of any other blogs on this topic. To whit, my professional blog: “strawberryJAMM’s Security and User Experience WebLog: The delicate balancing act between intuitive user experience and secure software systems” (http://blogs.technet.com/strawberryjamm/) Please do check it out!


Hi! Do not prompt as me to send e-mail? = (


Prompt how to get rid of advertising?


I can not find coordinates for a feedback.


Hi! Prompt, how to me to you to get?