Anonymity Loves Company: Usability and the Network Effect
Roger Dingledine,Nick Mathewson
Abstract:A growing field of literature is studying how usability impacts security [4]. One class of security software is anonymizing networks— overlay networks on the Internet that provide privacy by letting users transact (for example, fetch a web page or send an email) without revealing their communication partners. In this position paper we focus on the network effects of usability on privacy and security: usability is a factor as before, but the size of the user base also becomes a factor. We show that in anonymizing networks, even if you were smart enough and had enough time to use every system perfectly, you would nevertheless be right to choose your system based in part on its usability for other users. 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, since 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 used 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 likelier that your non-savvy 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 not only usable by yourself, but by the other participants as well. 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: • Programs with insecure modes of operation are bound to be used unknowingly in those modes. • 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 they can access sites that require cookies, and later leaving cookies enabled for all sites. • Badly labeled off switches for security are even worse: not only are they more prone to accidental selection, but they’re more 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 website with an expired or otherwise suspicious SSL certificate. • 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. • 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. • Systems that provide bad mental models for their security can trick users into believing they are more safe than they really are: for example, many users interpret the “lock” icon in their web browsers to mean “You can safely enter personal information,” when its meaning is closer to “Nobody can read your information on its way to the named website.” 2 Usability is even more important for privacy We described above that usability affects security in systems that aim to protect data confidentiality. But when the goal is privacy, it can become even more important. Anonymizing networks such as Tor [8], JAP [3], Mixminion [6], and Mixmaster [12] aim to hide not only what is being said, but also who is communicating with whom, which users are using which websites, and so on. These systems have a broad range of users, including ordinary citizens who want to avoid being profiled for targeted advertisements, corporations who don’t want to reveal information to their competitors, and law enforcement and government intelligence agencies who need to do operations on the Internet without being noticed. 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 website, or who was able to compromise the named website later on. Unless your computer has been compromised already.” Anonymity networks work by hiding users among users. An eavesdropper might be able to tell that Alice, Bob, and Carol are all using the network, but should not be able to tell which of them is talking to Dave. This property is summarized in the notion of an anonymity set—the total set of people who, so far as the attacker can tell, might be the one engaging in some activity of interest. The larger the set, the more anonymous the participants. When more users join the network, existing users become more secure, even if the new users never talk to the existing ones! [1, 2] Thus, “anonymity loves company.” In a data confidentiality system like PGP, Alice and Bob can decide by themselves that they want to get security. As long as they both use the software properly, no third party can intercept the traffic and break their encryption. However, Alice and Bob can’t get anonymity by themselves: they need to participate in an infrastructure that coordinates users to provide cover for each other. No organization can build this infrastructure for its own sole use. If a single corporation or government agency were to build a private network to protect its operations, any connections entering or leaving that network would be obviously linkable to the controlling organization. The members and operations of that agency would be easier, not harder, to distinguish. Thus, to provide anonymity to any of its users, the network must accept traffic from external users, so the various user groups can blend together. In practice, existing commercial anonymity solutions (like Anonymizer.com) are based on a set of single-hop proxies. In these systems, each user connects to a single proxy, which then relays the user’s traffic. Single proxies provide comparatively weak security, since a compromised proxy can trivially observe all of its users’ actions, and an eavesdropper only needs to watch a single proxy to perform timing correlation attacks against all its users’ traffic. Worse, all users need to trust the proxy company to have good security itself as well as to not reveal user activities. The solution is distributed trust: an infrastructure made up of many independently controlled proxies that work together to make sure no transaction’s privacy relies on any single proxy. With distributed-trust anonymity networks, users build tunnels or circuits through a series of servers. They encrypt their traffic in multiple layers of encryption, and each server removes a single layer of encryption. No single server knows the entire path from the user to the user’s chosen destination. Therefore an attacker can’t break the user’s anonymity by compromising or eavesdropping on any one server. 2 Assuming that all participants are equally plausible, of course. If the attacker suspects Alice, Bob, and Carol equally, Alice is more anonymous than if the attacker is 98% suspicious of Alice and 1% suspicious of Bob and Carol, even though the anonymity sets are the same size. Because of this imprecision, research is moving beyond simple anonymity sets to more sophisticated measures based on the attacker’s confidence [7, 14]. 3 This catch-phrase was first made popular in our context by the authors of the Crowds [13] anonymity network. Despite their increased security, distributed-trust anonymity networks have their disadvantages. Because traffic needs to be relayed through multiple servers, performance is often (but not always) worse. Also, the software to implement a distributed-trust anonymity network is significantly more difficult to design and implement. Beyond these issues of the architecture and ownership of the network, however, there is another catch. For users to keep the same anonymity set, they need to act like each other. If Alice’s client acts completely unlike Bob’s client, or if Alice’s messages leave the system acting completely unlike Bob’s, the attacker can use this information. In the worst case, Alice’s messages stand out entering and leaving the network, and the attacker can treat Alice and those like her as if they were on a separate network of their own. But even if Alice’s messages are only recognizable as they leave the network, an attacker can use this information to break exiting messages into “messages from User1,” “messages from User2,” and so on, and can now get away with linking messages to their senders as groups, rather than trying to guess from individual messages [6, 11]. Some of this partitioning is inevitable: if Alice speaks Arabic and Bob speaks Bulgarian, we can’t force them both to learn English in order to mask each other. What does this imply for usability? More so than with encryption systems,