[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[freehaven-cvs] more fixes throughout
Update of /home/freehaven/cvsroot/doc/wupss04
In directory moria.mit.edu:/home2/arma/work/freehaven/doc/wupss04
Modified Files:
usability.tex usability.bib
Log Message:
more fixes throughout
Index: usability.tex
===================================================================
RCS file: /home/freehaven/cvsroot/doc/wupss04/usability.tex,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -d -r1.16 -r1.17
--- usability.tex 31 Dec 2004 18:02:14 -0000 1.16
+++ usability.tex 31 Dec 2004 20:02:28 -0000 1.17
@@ -71,19 +71,22 @@
can't or won't use it correctly, its ideal security properties are
irrelevant.
-As Angela Sasse wrote in chapter X,
-hard-to-use programs and protocols can hurt security in many ways. These
-include:
+% As we've seen in the other chapters in this book,
+Hard-to-use programs and protocols can hurt security in many ways:
+% These include:
\begin{tightlist}
\item Programs with {\it insecure modes of operation} are bound to be used
unknowingly in those modes.
-\item {\it Off switches}, once selected, are often never re-enabled. For
+\item {\it 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.
-\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 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.
\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.
@@ -115,8 +118,8 @@
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 maintain their civil liberties, corporations who don't want
-to reveal information to
+who want to avoid being profiled for targeted advertisements, corporations
+who don't want to reveal information to
their competitors, and government intelligence agencies who need
to do operations on the Internet without being noticed.
@@ -134,8 +137,8 @@
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! \cite{econymics} Thus, ``anonymity loves company.''\footnote{This
- catch-phrase was first originated, we believe, by the authors of the
+ones! \cite{econymics,back01} Thus, ``anonymity loves company.''\footnote{This
+ catch-phrase was first made popular in our context by the authors of the
Crowds~\cite{crowds:tissec} anonymity network.}
There is a catch, however. For users to keep the same anonymity set, they
@@ -187,7 +190,7 @@
But since many users might find the high-latency network inconvenient,
suppose that it gets few actual users---so few, in fact, that its
-maximum anonymity set it too small for our needs.
+maximum anonymity set is 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
@@ -243,7 +246,9 @@
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 understanding
-the security implications of their decision. The real issue here is that
+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 `inconvenient' as the default configuration---meaning they've
already made a mistake in designing their application; but that discussion
@@ -259,8 +264,8 @@
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''
-anonymizing network uses the OpenPGP encrypted message format, which supports
-many
+anonymous email network uses the OpenPGP encrypted message format,
+which supports many
symmetric and asymmetric ciphers. Because different users prefer
different ciphers, and because different versions of encryption programs
implementing
@@ -302,14 +307,14 @@
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,
+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
+messages, normalizing HTML, stripping identifying information
from Microsoft Office documents, or imposing a single character
-encoding on each language, would likely be an impossible task.
+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
+a single email client, or simply banning email formats other than plain
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
@@ -368,7 +373,7 @@
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
+applications reveal where they are about to connect 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
@@ -428,13 +433,19 @@
is, an attacker who can watch both ends of the cascade won't actually
be distracted by the other users \cite{danezis-pet2004}. 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.
+and receiving 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.
+
As the system is now, anonymity sets don't provide a real measure of
-security, since any attacker who can watch both ends of the cascade wins, and
-the number of users on the network is no obstacle to this attack.
+security for JAP, since any attacker who can watch both ends of the
+cascade wins, and the number of users on the network is no obstacle
+to this attack. However, we think the anonym-o-meter is a great way to
+present security information to the user, and we hope to see a variant
+of it deployed one day for a high-latency system like Mixminion, where
+the amount of current traffic in the system is more directly related to
+the protection it offers.
%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
@@ -457,10 +468,10 @@
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
+Low-needs users can break the deadlock. The earliest stages of an
+anonymizing network's lifetime tend to involve 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
+network and thus can't learn the contents of the small anonymity 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.
@@ -473,8 +484,10 @@
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.
+if the hype attracts more users.
+%---an anonymizing network that isn't
+%well-known
+%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.
@@ -502,7 +515,8 @@
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.
+publicized uses of the network can dictate the types of users it
+attracts next.
\section{Technical challenges to guessing the number of users in
a network}
@@ -510,7 +524,7 @@
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
+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
@@ -529,9 +543,6 @@
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}
Users' safety relies on them behaving like other users. But how can they
@@ -558,8 +569,8 @@
The temptation to focus on designing a perfectly usable system before
building it can be self-defeating, since obstacles to usability are often
-unforeseen. Because of this, we believe that we need to focus on continuing
-experimental deployment.
+unforeseen. Because of this, we believe that the anonymity community
+needs to focus on continuing experimental deployment.
\bibliographystyle{plain}
\bibliography{usability}
Index: usability.bib
===================================================================
RCS file: /home/freehaven/cvsroot/doc/wupss04/usability.bib,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- usability.bib 31 Dec 2004 17:44:22 -0000 1.2
+++ usability.bib 31 Dec 2004 20:02:28 -0000 1.3
@@ -1,3 +1,13 @@
+@InProceedings{back01,
+ author = {Adam Back and Ulf M\"oller and Anton Stiglic},
+ title = {Traffic Analysis Attacks and Trade-Offs in Anonymity Providing Systems},
+ booktitle = {Information Hiding (IH 2001)},
+ pages = {245--257},
+ year = 2001,
+ editor = {Ira S. Moskowitz},
+ publisher = {Springer-Verlag, LNCS 2137}
+}
+
@InProceedings{sybil,
author = "John Douceur",
title = {{The Sybil Attack}},
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxx with
unsubscribe freehaven-cvs in the body. http://freehaven.net/