[freehaven-cvs] clean up first half of usability 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:
clean up first half of usability chapter


Index: usability.tex
===================================================================
RCS file: /home/freehaven/cvsroot/doc/wupss04/usability.tex,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -d -r1.7 -r1.8
--- usability.tex	30 Oct 2004 18:53:37 -0000	1.7
+++ usability.tex	1 Nov 2004 01:31:30 -0000	1.8
@@ -20,18 +20,17 @@
 \thispagestyle{empty}
 
 Other chapters in this book have talked about how usability impacts
-security. One class of security software is anonymity networks. these
-are useful for ordinary citizens civil liberties but also enterprise
-and government...  
-  Distinguish real anonymity from accidental anonymity.
-  (Accidental security is what you have when your host has not in fact
-  been hacked yet.)
-Usability impacts security for anonymity systems too, but in our case
-the size of the user base also impacts our security.
-Further, in anonymity systems, 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.
+security. One class of security software is anonymity 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
+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.
 
 \section{Usability for others impacts your security}
 
@@ -70,7 +69,7 @@
 can't or won't use it correctly, its ideal security properties are
 irrelevant.
 
-As we read in chapter [Angela's chapter],
+As Angela Sasse wrote in chapter X,
 hard-to-use programs and protocols can hurt security in many ways:
 \begin{tightlist}
 \item Programs with {\it insecure modes of operation} are bound to be used
@@ -113,7 +112,10 @@
 Tor, JAP, Mixminion, and Mixmaster, 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 are used by XXX, XXX, XXX, and XXX.
+These systems have a broad range of users, including ordinary citizens
+who want to maintain their civil liberties, corporations who want to
+analyze their competitors, and government intelligence agencies who need
+to do operations on the Internet without being noticed.
 
 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
@@ -179,53 +181,51 @@
 
 But since many users might find the high-latency network inconvenient,
 suppose that it gets very few actual users---so few, in fact, that its
-maximum anonymity set it too small for our needs.\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.}
+maximum anonymity set it too small for our needs.
+%  \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.}
 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.
 
-- 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?
+This decision is especially messy because even the developers who
+implement these anonymity 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
+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 parameter values to recommend.
 
 \section{Case study: against options}
 
 Too often, designers faced with a security decision bow out, and instead
 leave the choice as an option: protocol designers leave implementors to
-decide, and implementors leave the choice for their users.  This can be bad
-for security systems, and is nearly always bad for privacy systems.
+decide, and implementors leave the choice for their users.  This approach
+can be bad for security systems, and is nearly always bad for privacy
+systems.
 
 With security:
 \begin{tightlist}
-\item Extra options often delegate decisions to those least able to make
-  them.  If the protocol designer can't decide whether AES is better than
+\item Extra options often delegate security decisions to those least
+  able to understand what they imply. If the protocol designer can't
+  decide whether AES is better than
   Twofish, how is the end user supposed to pick?
 \item Options make code harder to audit by increasing the volume of code, by
   increasing the number of possible configurations {\it exponentially}, and
   by guaranteeing that non-default configurations will receive very little
-  testing in the field. If AES is the default, even with several
-  independent implementations, how long will it take to notice that the
-  Twofish implementation is wrong?
+  testing in the field. If AES is always the default, even with several
+  independent implementations of your protocol, how long will it take
+  to notice that the Twofish implementation is wrong?
 \end{tightlist}
 
-% XXXX This next graf is too dry and verbose; make it *fun*.
 Most users stay with default configurations as long as they work,
 and only reconfigure their software as necessary to make it usable.
-%This approach often leads
-%to security choices being made by those least qualified to make them, while
-%giving application developers a false sense of rectitude.
-%% This statement is false and it'll get us hammered. Security isn't
-%% the main goal, *doing stuff* is. So choosing to do stuff rather than
-%% have security is not a bad thing. The above statement is what this
-%% book is trying to dispel. What are we actually trying to say in this
-%% paragraph? That 'default insecure' can be bad? That 'default secure'
-%% will cause some of the users to be upset? The reason lesson is that
-%% it can't be a choice between 'insecure' and 'obnoxious'; but that's
-%% out of scope for this chapter.
 For example,
 suppose the developers of a web browser can't decide whether to support a
 given extension with unknown security implications, so they leave it as a
@@ -235,9 +235,13 @@
 it's secure or not; and if the extension is disabled by default, users will
 tend to enable it first based on their perceived demand for the extension
 rather than their security needs.  Thus, only the most savvy and
-security-conscious users---the ones who know more about web security than the
-developers themselves---will actually wind up deciding based on good
-analysis.
+security-conscious users---the ones who know more about web security
+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
+already made a mistake in designing their application; but that discussion
+is outside the scope of this chapter.
 
 Of course, when end users {\it do} know more about their individual security
 requirements than application designers, then adding options is beneficial,
@@ -275,8 +279,10 @@
 
 \section{Case study: JAP and its anonymity slider}
 
-XXXX
-we should get a screen shot or something. and talk about how communicating
+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.
@@ -287,8 +293,8 @@
 we've also argued that focusing too hard on privacy over usability can hurt
 privacy itself.  What happens when these principles conflict?
 
-We encountered a situation like this when we were designing how the Mixminion
-anonymous email network should handle 
+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
 different email programs are almost always distinguishable by which subsets
 of the format, and which types of encodings, they choose to generate.  Trying
@@ -300,26 +306,26 @@
 from Microsoft Office documents, or imposing a single character
 encoding on each language, would likely be an impossible task.
 
-Other possible ``solutions'' to this problem could include limiting users to
+Other possible solutions to this problem could include limiting users to
 a single fixed email client, or simply banning email formats other than plain
-7-bit ASCII.  But these procrustean approaches would limit usability, and
-turn users away from the Mixminion network.  Since less users mean less
+7-bit ASCII.  But these procrustean approaches limit usability, and
+turn users away from the Mixminion network.  Since fewer users mean less
 anonymity, we had to ask whether users would be better off in a larger
-network where their messages are likelier to be distinguishable by email
+network where their messages are likelier to be distinguishable based on email
 client, or in a smaller network where everyone's email formats look the same.
 
-Some distinguishability, we noted, was inevitable, since users differ in
-their interests, languages, and writing styles: If Alice writes about
-Astronomy in Amharic, her messages are unlikely to be mistaken for Bob's, who
-writes about botany in Basque.  Also, any attempt to restrict formats was
-likely to backfire.  If we limited Mixminion to 7-bit ASCII, users wouldn't
+Some distinguishability is inevitable, since users differ in
+their interests, languages, and writing styles: if Alice writes about
+astronomy in Amharic, her messages are unlikely to be mistaken for Bob's, who
+writes about botany in Basque.  Also, any attempt to restrict formats is
+likely to backfire.  If we limit Mixminion to 7-bit ASCII, users won't
 stop sending each other images, PDF files, and messages in Chinese: they
 would instead follow the same evolutionary path that led to MIME in the first
 place, and encode their messages in a variety of distinguishable formats,
 with each client software implementation having its own {\it ad hoc}
 favorites.  So imposing uniformity in this place would not only drive away
 users, but would probably fail in the long run, and lead to fragmentation at
-least as bad as we were trying to avoid.
+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
@@ -328,28 +334,19 @@
 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 could not defeat them in the worst possible case
+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
-was ever sold), we would provide vulnerable users with protection against
+was ever sold), we can provide vulnerable users with protection against
 weaker adversaries.
 
-In the end, we compromised: we decided to perform as much normalization as we
-could, and warn the user about document types such as MS Word that are
-likely to reveal identifying information, but we not forbid any particular
+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
+likely to reveal identifying information, but we do not forbid any particular
 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{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{Privacy, bootstrapping, and confidence}
 
 Another area where human factors are critical in privacy is in bootstrapping
@@ -403,7 +400,7 @@
 either to configure their applications to pass hostnames to Tor directly by
 using SOCKS4a or the hostname-based variant of SOCKS5; to manually resolve
 hostnames with Tor and pass the resulting IPs to their applications; or to
-direct their applications to application specific proxies which handle each
+direct their applications to application-specific proxies which handle each
 protocol's needs independently.
 
 None of these is easy for an unsophisticated user, and when they misconfigure
@@ -412,7 +409,7 @@
 request whenever he is about to connect to a website, an observer can tell
 that anybody connecting to Alice's website anonymously must not be Bob.
 Thus, experienced users have an interest in making sure inexperienced users
-can use the system correctly: being hard to configure is a weakness for
+can use the system correctly. Tor being hard to configure is a weakness for
 everybody.
 
 We've tried a few solutions that didn't work as well as we hoped.  Improving
@@ -421,14 +418,14 @@
 resulted in several email exchanges to explain DNS to the casual user, who
 had typically no idea how to solve his problem.
 
-At the time of this writing, the most important solutions for these users has
+At the time of this writing, the most important solutions for these users have
 been improve Tor's documentation for how to configure various applications
 to use Tor, to change the warning messages to refer users to a description of
 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) 
+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.
 
@@ -438,6 +435,10 @@
   yet in our context extra features are unsafe.
 
 - 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.
 
 plus tor-and-its-logs. socks extensions? but compatibility.
 
@@ -457,6 +458,5 @@
 predict the behavior of other users? What if they need to behave their
 certain (different) way -- how do they compute the tradeoff and risks?
 
-
 \end{document}
 

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