O'Reilly chapter outline: "Anonymity loves company -- usability as a security parameter." Roger Dingledine & Nick Mathewson Piece one: * Motivation for anonymity networks. Talk about the range of deployed systems out there. * Anonymity is unique in that you can get better security by behaving like others. * Some others in this book are talking about how to achieve usability. Here we're going to talk about the importance of usability (and users) in getting our security. Piece two: What else is quite like anonymity? Encryption? How careful people are in certifying other GPG keys? Internet host security to prevent DDoS and spam against others? They all seem to share some qualities, but none of them match up exactly. Piece three: Let's give you an overview of what we're trying to tell you here, so you'll have it in mind when we explain some example systems. Piece four: Example systems. Cypherpunks remailers. PGP/GPG. Tor (JAP, "trust us" proxies). Mixminion. Their basic architectures, and how deployed they are. Piece five: Observations, Recommendations, Open research questions. - Talk about protections you can get from more users with a high-latency system, and about in what ways that degrades as you move to low-latency. Standard Econ Graph: increased anonymity as we slow things down, but decreased user base (and thus decreased anonymity) as we slow things down. - The importance of choosing good defaults: since most people will use the defaults, you've made the decision for everybody. - Don't try to get the user to answer questions you can't answer yourself. - Especially messy because even the researchers don't know the answers, and don't understand the tradeoffs. E.g., who is the adversary really, and what can they do? - Users' safety relies on them behaving like other users. How do they predict the behavior of other users? What if they need to behave their certain (different) way -- how do they compute the tradeoff and risks? - The importance of smart users / educating your users, so they know what they're getting into, so they can compare systems better, so people will be willing to use the better systems. Public perception as a security parameter. Good marketing as a security parameter? (Since most people will believe it, and therefore you need to take it into account even if you know better.) - Not just about numbers and blending, also about reputability. A network used only by criminals is not the one you want. People have an incentive for the network to be used for "more reputable" activities than their own. - The importance of a GUI. Users evaluate the quality of a product by the quality of its GUI. Cf Tor's choice not to have a gui so far, and problems with that. They also judge quality based on feature-lists; yet in our context extra features are unsafe. - Bootstrapping. How do we get any users? High-needs users are never first joiners. Low-needs users won't join if it's secure enough (read: slow enough) that it meets the high-needs users' needs. Notes: - Start with some talk on anonymity; software aimed to provide anonymity; etc. Distinguish real anonymity from accidental anonymity. (Accidental security is what you have when your host has not in fact been hacked yet.) - Key point: In anonymity, even if you were smart enough and had enough time to use every conceivable system perfectly, you would *nevertheless* be right to choose your system based in part on its usability. - Brainstorm: What else besides anonymity systems has the property that lowered usability lowers _everyone's_ security, and/or that I am better off behaving like everyone else than being different? - A more usable PGP-lite would make more of the mail sent to me confidential, and more of the mail I send confidential, thus improving my security. But I'd still use a more secure PGP when I could. This doesn't have the property that I should switch to always use PGP-lite. - Also if there's a PGP-heavier that's better than PGP if used right, but where it's easy to screw up and use bad encryption, maybe I shouldn't even generate a PGP-heavier key. But this doesn't have the property that even if all the smart people (who don't screw up) use PGP-heavier, they're still worse off. - Internet security analogy: I should make sure everybody can have a good usable firewall, so I can be more DDOS resistant. - What else? I worry that people will just say, "I'm not writing an anonymity system!" and skip the chapter. Hmn. - Privacy/anonymity is like security in that there is no sharp division between "privacy" apps and others. Any app can leak privacy, so if any of your users care about privacy, you should too. - Security *is* a prerequisite for privacy: data security often means privacy. Most security breaks impact privacy. - (Security is "Even when others try to make your stuff do something that you wouldn't want it to, your stuff does what you want.") - hypothesis: Most security breaks have obvious and easy-to-articulate impact; many privacy breaks have slow, cumulative impact. - Other people will talk about how to get usability. We'll talk about what kinds of usability are good for security and what are bad. - From privacy and anonymity POV, getting users to appear similar is vital. "Features" are often the enemy of this. "Power-user mode" is often the enemy of this. - In a confidentiality system, a secure use is always secure. But in an anonymity system, your security is limited by the number of people who have sufficiently similar security parameters. - Hard-to-use systems lead to multiple weirdo oddball frontends lead to differing user behavior. - Sometimes users with more specialized needs are better off having those needs unsatisfied, if satisfying them would require splitting from the crowd. - Don't try to get the user to answer questions you can't answer yourself. This is "bad options". - Does the property pertain only to the user's situation? If so, try to chunk users into as few classes as possible. Ask whether people in smaller classes wouldn't be better joining with others, despite their different needs. - What *is* a better/more 'usable' system here? Is it the one that does what I tell it, or the one that keeps me anonymous? Maybe it gives me a choice, but gives me the _right_ choice, which is what-I-want vs anonymity. How do I communicate the idea of "how secure"? How do I even understand what it is I *want* to communicate? - Does the property pertain to everyone? If you can't make a decision, why think your average user will? Here's what happens, typically: 95% of users use the defaults unless they break. >95% of the remaining users don't have any more clue than you which option is better. Most will choose weird divergent combinations of settings to make themselves distinguishable. Of the remaining <1/400 users, they have to decide: will the increased security you get with the optimal settings outweigh the anonymity you lose by being in a tiny set? If they're smart, they'll conclude that the right choice isn't changing the settings; it's getting you to patch the next version to do the right thing. - Your choice of defaults would still matter most, even if you give options. If you choose a secure default, >95% of the people are ok. If you choose a bad default, *everybody* is hurt, even the people who choose better than you. - When designing protocols, assume that every option you give the implementor will be passed on to the user in an obscure preferences menu. Implementors are often dumb this way. - Say something about how this is hard stuff where sometimes there aren't "good" solutions. But go on to say that this doesn't let you the designer off the hook. - Systems/ideas to discuss: - Cpunk - PGP/GPG for pseudonymity - Low-latency versus high-latency - On low-latency vs high-latency: If your attacker can beat LL, you should go with HL always and hope that others do. But if your attacker can't beat LL, you should just use it...maybe even when you could afford HL. - Limiting factor, of course, is that users _want_ to be distinguishable in their actions. They d/l different web pages; they post messages with different contents. - The more cancer survivors on tor, the better for the activists. This is a reputability issue, not anonymity. - "innocuousness" - Just me: i'm screwed. Add a thousand communists, and I'm anonymous, but everyone thinks I'm a commie. Add a thousand J Random Citizens (cancer survivors, privacy enthusiasts, etc) and I'm not profile-able. - Maybe the cancer survivors want some commies on the system too? They'd prefer J Random Non-cancer-survivors. - Public perception is a security parameter (tor-design) - Other people are using chapters to plug their usability. If we plug anything, it's importance of our approach. - Look at econymics paper; recap ideas; add caveats to results: - We claim that people who care a lot will run servers... but that makes them higher profile... which probably they don't want. - Roger says results don't extend to low-latency. Nick disagrees. - You should use the most popular system where your adversary doesn't win. - There is incentive in both cases to run a server. Other human factors: - Evaluating business model of provider is important. Advertising is security. Marketing as a security parameter. - ZKS didn't convince people that "don't trust us" was valid business idea. Advertising is security!!!! - Aside: why didn't people go for it ("don't trust us")? Maybe because the unsophisticated user *had* to trust ZKS (since users couldn't evaluate ZKS claims) - Users make security decisions based on pretty blinkenlights and long feature lists. But long feature lists are a bad bad idea. Fear. - How are *we* supposed to know what the adversaries are?? And if not us, who? - Not everything in the security realm is as amazingly secure as encryption; adding more bits for overkill doesn't seem to work anywhere else. - Roger wants a Standard Econ Graph: increasing anonymity as we slow things down, but decreasing user base (and thus decreasing anonymity) as we slow things down. Other stuff to say: - Why it's so hard to estimate anonymity - Sybil attack - freeloaders and why you can't easily detect them - Why bootstrapping is hard: how do I get anybody on the system? High-needs users are never first joiners. Low-needs users won't join if it meets the high-needs users' needs.