[freehaven-cvs] flesh out second half of chapter.

[arma@seul.org (Roger Dingledine)]

Update of /home/freehaven/cvsroot/doc/wupss04
In directory moria.mit.edu:/home2/arma/work/freehaven/doc/wupss04

Modified Files:
	usability.tex 
Log Message:
flesh out second half of chapter.
also, adversary->attack, and anonymity network->anonymizing network


Index: usability.tex
===================================================================
RCS file: /home/freehaven/cvsroot/doc/wupss04/usability.tex,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -d -r1.8 -r1.9
--- usability.tex	1 Nov 2004 01:31:30 -0000	1.8
+++ usability.tex	1 Nov 2004 10:44:00 -0000	1.9
@@ -12,7 +12,7 @@
 
 \begin{document}
 
-\title{Anonymity Loves Company -- Usability as a Security Parameter}
+\title{Anonymity Loves Company --\\ Usability and the Network Effect}
 \author{Roger Dingledine \\ The Free Haven Project \\ arma@freehaven.net \and
 Nick Mathewson \\ The Free Haven Project \\ nickm@freehaven.net}
 
@@ -20,14 +20,14 @@
 \thispagestyle{empty}
 
 Other chapters in this book have talked about how usability impacts
-security. One class of security software is anonymity networks --
+security. One class of security software is anonymizing networks --
 overlay networks on the Internet that let their users transact (for
 example, fetch a web page or send an email) without revealing their
 communication partners.
 
 In this chapter we're going to focus on the \emph{network effects} of
 usability: usability is a factor as before, but the size of the user
-base also becomes a factor.  Further, in anonymity systems, even if you
+base also becomes a factor.  Further, in anonymizing systems, even if you
 were smart enough and had enough time to use every conceivable system
 perfectly, you would \emph{nevertheless} be right to choose your system
 based in part on its usability.
@@ -130,7 +130,10 @@
 size.  Because of this, recent research is moving beyond simple anonymity
 sets to more sophisticated measures based on the attacker's confidence.}
 Therefore, when more users join the network, existing users become more
-secure, even if the new users never talk to the existing ones!
+secure, even if the new users never talk to the existing
+ones!\footnote{``On the Economics of Anonymity''.  Alessandro Acquisti,
+  Roger Dingledine, Paul Syverson.  {\em Proceedings of the Seventh
+  International Financial Cryptography Conference}, January 2003.}
 
 There is a catch, however.  For users to keep the same anonymity set, they
 need to act like each other.  If Alice's client acts completely unlike Bob's
@@ -148,13 +151,13 @@
 them both to learn English in order to mask each other.
 
 What does this imply for usability?  More so than with encryption systems,
-users of anonymity
+users of anonymizing
 networks may need to choose their systems based on how usable others will
 find them, in order to get the protection of a larger anonymity set.
 
 \section{Case study: Usability means users, users mean security}
 
-We'll consider an example.  Practical anonymity networks fall into two broad
+We'll consider an example.  Practical anonymizing networks fall into two broad
 classes. {\it High-latency} networks like Mixminion or Mixmaster can resist
 strong attackers who can watch the whole network and control a large part of
 the network infrastructure.  To prevent this ``global attacker'' from linking
@@ -168,7 +171,7 @@
 controls both ends of a communication can trivially correlate message timing
 and link the communicating parties.
 
-Clearly, users who need to resist strong adversaries need to choose
+Clearly, users who need to resist strong attackers need to choose
 high-latency networks or nothing at all, and users who need to anonymize
 interactive applications need to choose low-latency networks or nothing at
 all.  But what should flexible users choose?  Against an unknown threat
@@ -185,21 +188,21 @@
 %  \footnote{This is
 %  hypothetical, but not wholly unreasonable.  The most popular high-latency
 %  network, FOO, has approximately BAR users, whereas the most popular
-%  commercial low-latency anonymity system, BAZ, advertises QUUX users.}
+%  commercial low-latency anonymizing system, BAZ, advertises QUUX users.}
 In this case, we need to pick the low-latency system, since the high-latency
 system, though it always protects us, never protects us enough; whereas the
 low-latency system can give us enough protection against at least {\it some}
-adversaries.
+attackers.
 
 This decision is especially messy because even the developers who
-implement these anonymity networks can't recommend which approach is
+implement these anonymizing networks can't recommend which approach is
 safer, since they can't predict how many users each network will get
-and they can't predict the capabilities of the adversaries we might
+and they can't predict the capabilities of the attackers we might
 see in the wild. Worse, the anonymity research field is still young,
 and doesn't have many convincing techniques for measuring and comparing
 the protection we get from various situations. So even if the developers
 or users could somehow divine what level of anonymity they require and
-what their expected adversary can do, the researchers still don't know
+what their expected attacker can do, the researchers still don't know
 what parameter values to recommend.
 
 \section{Case study: against options}
@@ -239,9 +242,9 @@
 than the developers themselves---will actually wind up understanding
 the security implications of their decision. The real issue here is that
 designers often end up with a situation where they need to choose between
-`insecure' and `obnoxious' as the default configuration---meaning they've
+`insecure' and `inconvenient' as the default configuration---meaning they've
 already made a mistake in designing their application; but that discussion
-is outside the scope of this chapter.
+is left to chapters X and Y.
 
 Of course, when end users {\it do} know more about their individual security
 requirements than application designers, then adding options is beneficial,
@@ -253,7 +256,7 @@
 are many different possible configurations, eavesdroppers and insiders
 can often tell users apart by
 which settings they choose.  For example, the Type I or ``Cypherpunk''
-anonymity network uses the OpenPGP message format, which supports many
+anonymizing network uses the OpenPGP message format, which supports many
 symmetric and asymmetric ciphers.  Because different users may prefer
 different ciphers, and because different versions of the PGP and GnuPG
 implementations of OpenPGP use different ciphersuites, users with uncommon
@@ -262,13 +265,13 @@
 so that an eavesdropper can't correlate the sizes of messages passing through
 the network---but it forces the user to decide what size of padding to use!
 Unless a user can guess which padding size will happen to be most popular,
-the option provides adversaries with another way to tell users apart.
+the option provides attackers with another way to tell users apart.
 
 Even when users' needs genuinely vary, adding options does not necessarily
 serve their privacy.  In practice, the default option usually prevails for
 casual users, and therefore needs to prevail for security-conscious users
 {\it even when it would not otherwise be their best choice.}  For example,
-when an anonymity network allows user-selected message latency (like
+when an anonymizing network allows user-selected message latency (like
 Type I does), most users tend to use whichever setting is the default,
 so long as
 it works.  Of the fraction of users who change the default at all, most will
@@ -277,16 +280,6 @@
 with higher latency is worth the decreased anonymity that comes from
 splitting away from the bulk of the user base.
 
-\section{Case study: JAP and its anonymity slider}
-
-Screenshot:
-\begin{verbatim} http://anon.inf.tu-dresden.de/img/screen_de.jpg \end{verbatim}
-
- and talk about how communicating
-the protection you're getting is great. though in the case of jap we think
-it lies, since end-to-end timing correlation works so anonymity set is not
-the right measure.
-
 \section{Case study: Mixminion and MIME}
 
 We've argued that providing too many observable options can hurt privacy, but
@@ -294,8 +287,13 @@
 privacy itself.  What happens when these principles conflict?
 
 We encountered a situation like this when designing how the Mixminion
-anonymous email network should handle
-MIME-encoded data.  As a standard, MIME is so permissive and flexible that
+anonymous email network\footnote{``Mixminion: Design of a type {III}
+  anonymous remailer protocol''.  George Danezis, Roger Dingledine,
+  and Nick Mathewson.  {\em Proc. 2003 IEEE Symposium on Security and
+  Privacy}, pages 2--15.} should handle MIME-encoded data. MIME
+(Multipurpose Internet Mail Extensions) is the way a mail client tells
+the receiving mail client about attachments, which character set was used,
+and so on. As a standard, MIME is so permissive and flexible that
 different email programs are almost always distinguishable by which subsets
 of the format, and which types of encodings, they choose to generate.  Trying
 to ``normalize'' MIME by converting all mail to a standard only works up to a
@@ -328,16 +326,16 @@
 least as dangerous as we were trying to avoid.
 
 We also had to consider threat models.  To take advantage of format
-distinguishability, an adversary needs to observe messages leaving the
+distinguishability, an attacker needs to observe messages leaving the
 network, and either exploit prior knowledge of suspected senders (``Alice is
 the only user who owns a 1995 copy of Eudora''), or feed message format
 information into traffic analysis approaches (``Since half of the messages to
 Alice are written in English, I'll assume they mostly come from different
 senders than the ones in Amharic.'').  Neither attack is certain or easy for
-all adversaries; even if we can't defeat them in the worst possible case
-(where the adversary knows, for example, that only one copy of LeetMailPro
+all attackers; even if we can't defeat them in the worst possible case
+(where the attacker knows, for example, that only one copy of LeetMailPro
 was ever sold), we can provide vulnerable users with protection against
-weaker adversaries.
+weaker attackers.
 
 In the end, we compromised: we perform as much normalization as we
 can, and warn the user about document types such as MS Word that are
@@ -345,49 +343,24 @@
 format or client software.  This way, users are informed about how to blend
 with the largest possible anonymity set, but users who prefer to use
 distinguishable formats rather than nothing at all still receive and
-contribute protection against certain adversaries.
-
-\section{Privacy, bootstrapping, and confidence}
-
-Another area where human factors are critical in privacy is in bootstrapping
-new systems.  Since new systems start out with few users, they initially
-provide only very small anonymity sets.  This creates a dilemma: a new system
-with improved privacy properties will only attract users once they believe it
-is popular and therefore has high anonymity sets; but a system cannot be
-popular without attracting users.  New systems need users for privacy, but
-need privacy for users.
-
-Low-needs users can break the deadlock.  For the earliest stages of a
-system's lifetime, anonymity networks tend to build themselves with users who
-need only to resist weak adversaries who can't know which users are using the
-network and thus can't learn the contents of the small anoymity set.  This
-reverses the early adopter trends of many security systems: rather than
-attracting first the most security-conscious users, privacy applications
-must begin by attracting low-needs users and hobbyists.
-
-But this analysis relies on users' accurate perceptions of present and future
-anonymity set size.  As in market economics, expectations can bring about
-trends themselves: a privacy system which people believe to be secure and
-popular will gain users, thus becoming (all things equal) more secure and
-popular.  Thus, security depends not only on usability, but on {\it
-  perceived usability by others}, and hence on the quality of the provider's
-marketing and public relations.  Perversely, over-hyped systems (if they are
-not actually broken) may be a better choice than modestly promoted ones,
-if the hype attracts more users---a badly promoted anonymity network provides
-little anonymity.
+contribute protection against certain attackers.
 
-\section{Case study: Tor Installation, Marketing, and GUI}
+\section{Case study: Tor Installation} %, Marketing, and GUI}
 
-Usability and marketing have proved important in another project of ours,
-Tor, a low-latency anonymity network for TCP traffic.  The technical
-challenges Tor has solved and still needs to address are described elsewhere
-(XXXX cite tor-design? XXXX), but at this point, many of the most crucial
-challenges are in adoption and usability.
+Usability and marketing have also proved important in the development
+of Tor, a low-latency anonymizing network for TCP traffic.  The technical
+challenges Tor has solved, and the ones it still needs to address, are
+described in its design paper\footnote{``Tor: The
+  Second-Generation Onion Router''.  Roger Dingledine, Nick Mathewson,
+  and Paul Syverson.  {\em Proceedings of the 13th USENIX Security
+  Symposium}, August 2004.},
+but at this point many of the most crucial challenges are in adoption
+and usability.
 
 While Tor was in it earliest stages, its user base was a small number of
 fairly sophisticated privacy enthusiasts with experience running Unix
-services, who wanted to experiment with the network.\footnote{Or so they say;
-by design, we don't track our users.}  As the project gained more attention
+services, who wanted to experiment with the network (or so they say;
+by design, we don't track our users).  As the project gained more attention
 from venues including security conferences and articles on Slashdot.org and
 Wired News, we added more users with less technical expertise.  These users
 can now provide a broader base of anonymity for high-needs users, but only
@@ -424,39 +397,170 @@
 the solution (``You are insecure. See this webpage.'') instead of a
 description of the problem (``Your application is sending IPs instead of
 hostnames, which may leak information. Consider using SOCKS4a instead.''),
-and
-%  (XXXX this will happen before publication but not before Nov 1)
-to bundle Tor with the support tools that it needs, rather than relying on
-users to find and configure them on their own.
+and to bundle Tor with the support tools that it needs, rather than
+relying on users to find and configure them on 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.
+plus tor-and-its-logs. socks extensions? but compatibility.
 
-- This is a good place to talk about reputability.
-  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.
+\section{Case study: JAP and its anonym-o-meter}
 
-plus tor-and-its-logs. socks extensions? but compatibility.
+The Java Anon Proxy (JAP) is a low-latency anonymizing network for web
+browsing developed and deployed by the Technical University of Dresden
+in Germany.\footnote{``Web MIXes: A system for anonymous and unobservable
+  Internet access''. Oliver Berthold, Hannes Federrath, and Stefan
+  K\"opsell. {\em Proceedings of PET2000}, July 2000.} Unlike Tor, which
+uses a \emph{free-route} topology where each user can choose where to
+enter the network and where to exit, JAP has fixed-route \emph{cascades}
+that aggregate user traffic into a single entry point and a single
+exit point.
 
-\section{Other anonymity problems that compound this}
+The JAP client includes a GUI (screenshot in Figure 1).
+Screenshot:
+\begin{verbatim} http://anon.inf.tu-dresden.de/img/screen_en.jpg \end{verbatim}
+Notice the `anonymity meter' giving the user an impression of the level
+of protection for his current traffic.
 
-- Why it's so hard to estimate anonymity
-  - Sybil attack
-  - freeloaders and why you can't easily detect them
+How do we decide the value that the anonym-o-meter should report? In JAP's case,
+it's based on the number of other users traveling through the cascade
+at the same time. But alas, since JAP aims for quick transmission of
+bytes from one end of the cascade to the other, it falls prey to the
+same end-to-end timing correlation attacks as we described above. That
+is, an attacker who can watch both ends of the cascade won't actually
+be distracted by the other users.\footnote{``The Traffic Analysis of
+  Continuous-Time Mixes''. George Danezis. {\em Proceedings of PET2004},
+  May 2004.} The JAP
+team has plans to implement full-scale padding from every user (sending
+packets all the time even when they have nothing to send), but ---
+for usability reasons --- they haven't gone forward with these plans.
+They're stuck in limbo with a design that needs padding to be secure,
+but can't afford padding because it would make the system unusable.
 
-\section{Bringing it all together}
+But even though the anonymity set is probably not the right measure for
+assessing a JAP user's safety, the anonym-o-meter still seems like a
+great idea that gives an \emph{impression} of usability and thus security.
+...
 
-% we need to pick a take-away message. "this is hard"? "this is neat"?
-% "we're on our way to solving this"?
+%% Probably don't need to talk about the following:
+%- 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.
+
+\section{Bootstrapping, confidence, and reputability}
+
+Another area where human factors are critical in privacy is in bootstrapping
+new systems.  Since new systems start out with few users, they initially
+provide only very small anonymity sets.  This creates a dilemma: a new system
+with improved privacy properties will only attract users once they believe it
+is popular and therefore has high anonymity sets; but a system cannot be
+popular without attracting users.  New systems need users for privacy, but
+need privacy for users.
+
+Low-needs users can break the deadlock.  For the earliest stages of a
+system's lifetime, anonymizing networks tend to build themselves with users who
+need only to resist weak attackers who can't know which users are using the
+network and thus can't learn the contents of the small anoymity set.  This
+reverses the early adopter trends of many security systems: rather than
+attracting first the most security-conscious users, privacy applications
+must begin by attracting low-needs users and hobbyists.
+
+But this analysis relies on users' accurate perceptions of present and future
+anonymity set size.  As in market economics, expectations themselves can
+bring about trends: a privacy system which people believe to be secure and
+popular will gain users, thus becoming (all things equal) more secure and
+popular.  Thus, security depends not only on usability, but on {\it
+  perceived usability by others}, and hence on the quality of the provider's
+marketing and public relations.  Perversely, over-hyped systems (if they are
+not too broken) may be a better choice than modestly promoted ones,
+if the hype attracts more users---a badly promoted anonymizing network
+provides little anonymity.
+
+%The safety of a given network is not solely based on number of users
+%and how well the users blend with each other.
+Yet another factor in the safety of a given network is its reputability:
+the perception of its social value based on its current users. If I'm the
+only user of a system, it might be socially accepted, but I'm not getting
+any anonymity. Add a thousand Communists, and I'm anonymous, but
+everyone thinks I'm a Commie. Add a thousand random citizens (cancer
+survivors, privacy enthusiasts, and so on) and now I'm hard to profile.
+
+The more cancer survivors on Tor, the better for the human rights
+activists. The more script kiddies, the worse it is for the normal
+users. On the surface this may not appear to be an anonymity issue,
+but it is for two reasons. First, it impacts the sustainability of the
+network: a network that's always about to be shut down has difficulty
+attracting and keeping users, so its anonymity set suffers. Second,
+it attracts the attention of powerful attackers who may not mind
+revealing the identities of all the users to uncover the few bad ones.
+
+While people therefore have an incentive for the network to be used for
+``more reputable'' activities than their own, there are still tradeoffs
+involved when it comes to anonymity. To follow the above example, a
+network used entirely by cancer survivors might welcome some Communists
+onto the network, though of course they'd prefer a wider variety of users.
+
+The impact of public perception on security is especially important
+during the bootstrapping phase of the network, where the first few widely
+publicized uses of the network can dictate the types of users it attracts.
+
+\section{Technical challenges to guessing the number of users in
+a network}
+
+In addition to the social problems we describe above that make it
+difficult for a typical user to guess which anonymizing network will be most
+popular, there are some technical challenges as well. These stem from the
+fact that anonymizing networks are good at hiding what's going on, even from
+their users. For example, one of the toughest attacks to solve is that
+an attacker might sign up many users to artificially inflate the apparent
+size of the network. Not only does this \emph{Sybil attack} increase the
+odds that the attacker will be able to successfully compromise a given
+user transaction\footnote{``The Sybil Attack''. John Douceur. {\em
+  Proceedings of IPTPS02}, March 2002.}, but it might also trick
+users into thinking a given network is safer than it actually is.
+
+And finally, as we saw in the above discussion about JAP, it's hard to
+be able to guess how much a given other user is contributing to your
+anonymity. Even if he's not actively trying to trick you, he can still
+fail to mix well with you, either because his behavior is sufficiently
+different from yours (he's active during the day, and you're active at
+night), because his transactions are different (he talks about physics,
+you talk about AIDS), or because network design parameters (such as
+low delay for messages) mean the attacker is able to track transactions
+more easily.
+
+%  - freeloaders and why you can't easily detect them
+%% I wonder what I meant by that.
+
+\section{Bringing it all together}
 
-This is tricky stuff.
 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?
+predict the behavior of other users? If they need to behave in a way
+that's different from the rest of the users, how do they compute the
+tradeoff and risks?
+
+There are several lessons we might take away from researching anonymity
+and usability. On the one hand, we might remark that anonymity is already
+tricky from a technical standpoint, and if we're required to get usability
+right as well before anybody can be safe, it will be very hard indeed
+to come up with a good design. That is, if lack of anonymity means lack
+of users, then we're stuck in a depressing loop. On the other hand, the
+loop has an optimistic side too. Good anonymity can mean more users: if we
+can make good headway on usability, then as long as the technical designs
+are adequate, we'll end up with enough users to make everything work out.
+
+In any case, choosing not to figure out a good solution means leaving most
+users to a less secure network or no anonymizing network at all. Cancer
+survivors and abuse victims are going to continue communications and
+research over the Internet, risking social or employment problems; human
+rights workers in oppressive countries are going to continue publishing
+their stories; witty finishing clause here.
 
 \end{document}
 
+% Things we haven't talked about and maybe should:
+%   - accidental anonymity vs intentional anonymity
+%   - the motivation for distributing trust. and how it gets us a more
+%     sustainable network.
+%   - the usability advantages of a single-hop proxy, in terms of
+%     speed, and in terms of how users can comprehend it.
+

***********************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe freehaven-cvs       in the body. http://freehaven.net/