[freehaven-cvs] Add a section and a little.

[nickm@seul.org (Nick Mathewson)]

Update of /home/freehaven/cvsroot/doc/wupss04
In directory moria.mit.edu:/tmp/cvs-serv3908/wupss04

Modified Files:
	usability.tex 
Log Message:
Add a section and a little.

Index: usability.tex
===================================================================
RCS file: /home/freehaven/cvsroot/doc/wupss04/usability.tex,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -d -r1.6 -r1.7
--- usability.tex	27 Oct 2004 07:06:29 -0000	1.6
+++ usability.tex	30 Oct 2004 18:53:37 -0000	1.7
@@ -75,7 +75,13 @@
 \begin{tightlist}
 \item Programs with {\it insecure modes of operation} are bound to be used
   unknowingly in those modes.
-\item {\it Off switches}, once disabled, are often never re-enabled.
+\item {\it Off switches}, once selected, are often never re-enabled.  For
+  example, many users who try to disable browser cookies for privacy reasons
+  wind up leaving them re-enabled so that they can access sites that require
+  them.
+\item {\it 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.
 \item {\it 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.
@@ -93,6 +99,7 @@
     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.''}
+
 \end{tightlist}
 
 %  - Confusion about what's really happening.
@@ -266,31 +273,73 @@
 with higher latency is worth the decreased anonymity that comes from
 splitting away from the bulk of the user base.
 
-\section{Case study: Tor and its GUI}
-
-- 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.
-
 \section{Case study: JAP and its anonymity slider}
 
+XXXX
 we should get a screen shot or something. 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}
+\section{Case study: Mixminion and MIME}
 
-we try to make users all look the same, but we also want to let them use
-their normal software. but mime is different each time. and writing a mime
-normalizer would really hurt, and still probably not work.
+We've argued that providing too many observable options can hurt privacy, but
+we've also argued that focusing too hard on privacy over usability can hurt
+privacy itself.  What happens when these principles conflict?
 
-by letting people use the software they want to use, we get more users
-and thus have better security than we would if we did mime right but
-nobody wanted to use our own client.
+We encountered a situation like this when we were 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
+to ``normalize'' MIME by converting all mail to a standard only works up to a
+point: it's trivial to convert all encodings to {\it quoted-printable}, for
+example, or to impose a standard order for {\it multipart/alternative} parts,
+but demanding a uniform list of formats for {\it multipart/alternative}
+messages, or trying to normalizing HTML, stripping identifying information
+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
+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
+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
+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
+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.
+
+We also had to consider threat models.  To take advantage of format
+distinguishability, an adversary 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 could not 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
+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
+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}
 
@@ -299,8 +348,7 @@
   incentive for the network to be used for "more reputable" activities
   than their own.
 
-I wonder if this section fits in this chapter. It's neat stuff to talk about,
-and it relates to users, which relates to security. Hm.
+
 
 \section{Privacy, bootstrapping, and confidence}
 
@@ -331,6 +379,68 @@
 if the hype attracts more users---a badly promoted anonymity network provides
 little anonymity.
 
+\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.
+
+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
+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
+when they receive good support themselves.
+
+For example, it has proven difficult to educate less sophisticated users
+about DNS issues.  Anonymizing TCP streams (as Tor does) does no good if
+applications first reveal where they are about to connect to by first
+performing a non-anonymized hostname lookup.  To stay anonymous, users need
+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
+protocol's needs independently.
+
+None of these is easy for an unsophisticated user, and when they misconfigure
+their systems, they not only compromise their own privacy, but also provide
+no cover for the users who {\it are} configured correctly: if Bob leaks a DNS
+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
+everybody.
+
+We've tried a few solutions that didn't work as well as we hoped.  Improving
+documentation only helped the users who read it.  We changed Tor to warn
+users who provided an IP address rather than a hostname, but this usually
+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
+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) 
+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.
+
+- This is a good place to talk about reputability.
+
+plus tor-and-its-logs. socks extensions? but compatibility.
+
 \section{Other anonymity problems that compound this}
 
 - Why it's so hard to estimate anonymity

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