Section 26.1. Usability for Others Impacts Your Security

26.1. Usability for Others Impacts Your Security

While security software is the product of developers, the security it provides is a collaboration between developers and users. It's not enough to make software that can be used securely; software that is hard to use often suffers in its security as a result. For example, suppose there are two popular mail encryption programs: HeavyCrypto, which is more secure (when used correctly), and LightCrypto, which is easier to use. Suppose you can use either one, or both. Which should you choose?

You might decide to use HeavyCrypto because it protects your secrets better. But if you do, it's likelier that when your friends send you confidential email , they'll make a mistake and encrypt it badly or not at all. With LightCrypto , you can at least be more certain that all your friends' correspondence with you will get some protection.

What if you use both programs? If your tech-savvy friends use HeavyCrypto and your less sophisticated friends use LightCrypto, then everybody will get as much protection as they can. But can all your friends really judge how able they are? If not, then by supporting a less usable option, you've made it more likely that your nonsavvy friends will shoot themselves in the foot.

The crucial insight here is that for email encryption, security is a collaboration between multiple people: both the sender and the receiver of a secret email must work together to protect its confidentiality. Thus, in order to protect your own security, you need to make sure that the system you use is usable not only by yourself, but also by the other participants.

This observation doesn't mean that it's always better to choose usability over security, of course; if a system doesn't address your threat model, no amount of usability can make it secure. But conversely, if the people who need to use a system can't or won't use it correctly, its ideal security properties are irrelevant.

Hard-to-use programs and protocols can hurt security in many ways:

• Insecure modes of operation. Programs with insecure modes of operation are bound to be used unknowingly in those modes.

• Optional security. Optional security, once disabled, is often never re-enabled. For example, many users who ordinarily disable browser cookies for privacy reasons wind up re-enabling them so that they can access sites that require cookies, and later leaving cookies enabled for all sites.

• Badly labeled off switches. Such switches for security are prone to accidental selection and vulnerable to social attackers who trick users into disabling their security. As an example, consider the page-long warning your browser provides when you go to a web site with an expired or otherwise suspicious SSL certificate.

• Inconvenient security. Inconvenient security is often abandoned in the name of day-to-day efficiency. People often write down difficult passwords to keep from forgetting them, and share passwords in order to work together.

• False sense of security. Systems that provide a false sense of security prevent users from taking real measures to protect themselves. Breakable encryption on zip archives, for example, can fool users into thinking that they don't need to encrypt email containing zip archives.

• Bad mental models. Systems that provide bad mental models for their security can trick users into believing that they are safer than they really are. For example, many users interpret the "lock" icon in their web browsers to mean that "You can safely enter personal information," whereas its actual meaning is closer to "Nobody can read your information on its way to the named web site."^[1]

  ^[1] Or more accurately, "Nobody can read your information on its way to someone who was able to convince one of the dozens to hundreds of CAs configured in your browser that they are the named web site, or who was able to compromise the named web site later onunless your computer has been compromised already."