[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[freehaven-cvs] much improved intro



Update of /home/freehaven/cvsroot/doc/fc03
In directory moria.seul.org:/home/arma/work/freehaven/doc/fc03

Modified Files:
	econymics.bib econymics.tex 
Log Message:
much improved intro


Index: econymics.bib
===================================================================
RCS file: /home/freehaven/cvsroot/doc/fc03/econymics.bib,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -d -r1.6 -r1.7
--- econymics.bib	15 Sep 2002 06:05:24 -0000	1.6
+++ econymics.bib	15 Sep 2002 06:18:03 -0000	1.7
@@ -77,7 +77,7 @@
 @InProceedings{Serj02,
   author = 	 {Andrei Serjantov and George Danezis},
   title = 	 {Towards an Information Theoretic Metric for Anonymity},
-  booktitle =    {Privacy Enhacing Technologies (PET 2002)},
+  booktitle =    {Privacy Enhancing Technologies (PET 2002)},
   year = 	 2002,
   editor =	 {Paul Syverson and Roger Dingledine},
   publisher =	 {Springer Verlag, LNCS (forthcoming)}
@@ -154,6 +154,19 @@
   month = Mar,
   year = 2002,
   url = {\url{http://www.cs.rice.edu/Conferences/IPTPS02/}}
+}
+
+@InProceedings{raymond00,
+  author =       {J. F. Raymond},
+  title =        {{Traffic Analysis: Protocols, Attacks, Design Issues,
+                  and Open Problems}}, 
+  booktitle =    {Designing Privacy Enhancing Technologies: Workshop
+                  on Design Issue in Anonymity and Unobservability},  
+  year =         2000,
+  month =        {July},
+  pages =	 {96--114},
+  editor =	 {H. Federrath},
+  publisher =	 {Springer Verlag, LNCS 2009},
 }
 
 @InProceedings{syverson_2000,

Index: econymics.tex
===================================================================
RCS file: /home/freehaven/cvsroot/doc/fc03/econymics.tex,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -d -r1.8 -r1.9
--- econymics.tex	14 Sep 2002 03:12:55 -0000	1.8
+++ econymics.tex	15 Sep 2002 06:18:03 -0000	1.9
@@ -87,11 +87,14 @@
 
 Decentralized anonymity infrastructures are still not in wide use today.
 Here we explore some reasons why anonymity systems are particularly
-hard to successfully deploy, enumerate the incentives people have to
+hard to deploy, enumerate the incentives people have to
 participate either as senders or as nodes, and build a general model to
 take into account each of these incentives. We then describe and justify
 some simplifying assumptions to make the model manageable, and compare
 optimal strategies for participants based on a variety of scenarios.
+Ultimately we aim to uncover some new insights about how to align
+incentives to create an economically workable system for both users and
+node operators.
 
 \end{abstract}
 
@@ -102,13 +105,18 @@
 \section{Introduction}
 \label{sec:intro}
 
-Anonymity in communication over public networks such as the Internet
-is widely (though not
-uncontroversially) regarded as both desirable and necessary. People
-want to be able to surf the Web, purchase online, send email, etc.\
-without revealing their information, interests, and activities to
-others. Corporate and military entities have an even stronger need for
-this technology. With all these interested users,
+Individuals and organizations have both a need and a desire for
+anonymity on public networks like the Internet. People want to be able
+to surf the Web, purchase online, and send email without revealing
+their identities, interests, and activities to others. Corporate and
+military entities must negotiate and communicate with other organizations
+without revealing the existence of their interactions to competitors and
+enemies. Firewalls, VPNs, and encrypted communication do not provide this
+protection --- indeed, Whit Diffie has remarked that traffic analysis
+is the backbone of communications intelligence, not cryptanalysis
+\cite{diffiebook}.
+
+With all these interested users,
 it might seem that there is a ready market for services in this area ---
 that is, it should be possible to offer such services and develop a
 paying customer base. However, with one notable exception (the
@@ -118,100 +126,85 @@
 uncharted, and we can also point to the current economic environment in
 general. However, this is not the whole story.
 
+Here we explore the incentives of participants to both offer and use
+anonymity services. We set a foundation for understanding and clarifying
+our speculations about the influences and interactions based on these
+incentives. Ultimately we aim to uncover some new insights about how
+to align incentives to create an economically workable system for both
+users and node operators.
+
+Section \ref{sec:overview} gives an overview of the
+ideas behind our model, and Section \ref{sec:model} goes on to describe
+a variety of (often conflicting) incentives and build a general model
+to incorporate many of them. We then bring to light some simplifying
+assumptions in Section \ref{sec:application} and draw conclusions
+about certain scenarios. Sections \ref{sec:alternate-incentives} and
+\ref{sec:roadblocks} describe some alternate approaches and problems we
+encounter in designing and deploying strong anonymity systems.
+
+\section{An Economics of Anonymity}
+\label{sec:overview}
+
 Single-hop web proxies like the Anonymizer can probably protect
 end users from simple threats like profile-creating websites.
-On the other hand, such commercial proxies must be trusted
-completely with respect to protecting traffic information.
-Many users, particularly large organizations, would be rightly
+On the other hand, users of such commercial proxies are forced to
+trust them to protect traffic information.
+Many users, particularly large organizations, are rightly
 hesitant to use an anonymity infrastructure they do not control.
 However, a system that carries traffic for only one organization does
 not provide much protection at all --- it must carry traffic from
 others to provide cover. Yet those others don't want to trust their
-traffic to just one entity either. The only viable solution is
+traffic to a single entity either. The only viable solution is
 to distribute trust. Each organization or other entity runs
 a node in a shared \emph{strong anonymity} infrastructure. Users with
 more modest budgets or shorter-term interest in the system also
 benefit from this decentralized model, because they can be confident
 that a few colluding nodes are unlikely to uncover their anonymity.
 
-However, nobody really wants to run one of these; exit abuse; free
-loading; etc. [Expand]
-
-Here we explore the incentives of participants to both offer and use
-anonymity services. We aim to set a foundation for understanding and
-clarifying our speculations about the influences and interactions based
-on these incentives. Section \ref{sec:overview} gives an overview of the
-ideas behind our model, and Section \ref{sec:model} goes on to detail
-a variety of (often conflicting) incentives and build a general model
-to incorporate many of them. We then bring to light some simplifying
-assumptions in Section \ref{sec:application} and draw conclusions
-about certain scenarios. Sections \ref{sec:alternate-incentives} and
-\ref{sec:roadblocks} describe some alternate approaches and problems we
-encounter in designing and deploying strong anonymity systems.
-
-\section{An Economics of Anonymity}
-\label{sec:overview}
+However, so far few people or organizations are willing to run these
+nodes. In addition to the complexities of configuring current anonymity
+software like Mixmaster, providing a node costs significant amounts of
+bandwidth and processing power, most of which will be used by `freeloading'
+users who do not themselves run nodes. Furthermore, when administrators
+are faced with abuse complaints concerning illegal or antisocial use of
+their systems, the very anonymity that they're providing makes it very
+difficult to take the usual solutions of suspending users or otherwise
+holding them accountable.
 
-Anonymity systems use messages to hide messages --- senders are both
-consumers and providers of anonymity. From an anonymity perspective,
-users are always better off going where the noise is provided.
+Unlike encryption (confidentality), it's not enough for the communicating
+end parties to cooperate on anonymity simply using whatever communications
+infrastructure is available. Alice cannot decide by herself that she
+wants her message to be anonymous --- the infrastructure itself must
+cooperate. Anonymity systems use messages to hide messages: senders
+are consumers of anonymity and also providers of the cover traffic that
+creates anonymity for others. From an anonymity perspective, users are
+always better off going where the noise is provided.
 
 High traffic is necessary for strong anonymity. High traffic and
-better performance complement each other: a system that processes only
-light traffic must delay service to achieve adequately large anonymity
-sets. Better performance attracts users both for its convenience value
-and the better potential anonymity protection. But systems processing
-the most traffic do not necessarily provide the best hiding. If trust
-is not well distributed, a high volume system is a point of
-vulnerability, both from insiders and from attackers who try to bridge
-the trust bottlenecks. Systems must also be robust against active
-attacks, e.g., trickle attacks in which known traffic is mixed with
-targeted traffic \cite{trickle02}.
-
-Also, censorship-resistant publishing systems, and to some extent any
-Internet sites that aim to be resistant to DDoS, can benefit from
-\emph{location protection} of their servers --- effectively hiding
-them behind several levels of indirection so the location or IP is
-hidden from direct attack. Indeed, for companies that are
-protecting high-value corporate information, relying on firewalls,
-VPNs, and encrypted communication may not be quite the right
-approach. Whit Diffie has remarked that traffic analysis is the
-backbone of communications intelligence, not cryptanalysis
-\cite{diffiebook}. Perhaps there is a need for strong anonymity,
-but this has simply not been recognized or been given a viable business
-model.
-
-
-We will primarily
-focus on the strategic motivations of honest agents. However, the
-motivations of dishonest agents are at least as important.  For
-example, note that an anonymity-breaking adversary with an adequate
-budget would do best to provide very good service, possibly also
-attempting DoS against other high-quality providers. None of the usual
-metrics of performance and efficiency will help tell who the bad guys
-are in this instance. Further, who assigns those metrics and how?  If
-they depend on a centralized trusted authority, the advantages of
-diffusion are lost. But, a reliability-breaking adversary will
-obviously have very different goals and approaches.  The complexity of
-representing both honest and dishonest agents strategically is beyond
-the scope of the current study, and so we treat dishonest agents as just
-part of a given \emph{adversary}, a context within which strategic
-agents must operate.
+better performance complement each other: a system that processes
+only light traffic must delay messages to achieve adequately large
+anonymity sets. Thus better performance attracts users both for its
+convenience value and the better potential anonymity protection. But
+systems processing the most traffic do not necessarily provide the best
+hiding. If trust is not well distributed, a high volume system is a
+point of vulnerability, both from insiders and from attackers who try
+to bridge the trust bottlenecks.
 
+Anonymity systems must also be robust against a surprisingly wide variety
+of active attacks to break anonymity \cite{back01,raymond00}. Adversaries
+can also attack to reduce the efficiency or reliability of nodes, or
+to make it more expensive for operators to continue running nodes. All
+of these factors combine to threaten the \emph{anonymity} of the system
+as well. Back et al point out that ``in anonymity systems usability,
+efficiency, reliability and cost become \emph{security} objectives because
+they affect the size of the user base which in turn affects the degree
+of anonymity it is possible to achieve'' \cite{back01}.
 
-alessandrocomment\{I feel that, possibly, even more
-of the material that you guys had already written could be used for a
-general section - like this one - on top of the Introduction/Motivation
-above. My feeling is that 1) this section could be used to frame the problem
-from an economic perspective (while the Introduction might focus on the
-technical perspective and highlight the *need* for an economic perspective);
-2) this section would ``prepare'' the analytic framework below; 3)\ it would
-also suggest that our work is more general than the specific
-model/application presented one section below, in that such model is a
-preliminary applications of the views we are presenting here.\}
+We must balance all of these tradeoffs while we examine the incentives
+for users and node operators to participate in the system.
 
 \section{Analytic Framework}
-\ref{sec:model}
+\label{sec:model}
 
 We study the incentives for agents to send messages anonymously through
 mix-net like systems.
@@ -675,6 +668,7 @@
 \end{enumerate}
 
 \section{Alternate incentive mechanisms}
+\label{sec:alternate-incentives}
 
 Reputation: this comes either in the form of "i want a higher reputation
 so i can get more cover traffic", as explained above, but also is "i think
@@ -691,6 +685,7 @@
 as applicable here as we might hope.
 
 \section{A few more roadblocks}
+\label{sec:roadblocks}
 
 \subsection{Authentication in a volunteer economy}
 
@@ -701,9 +696,17 @@
 the overall system.
 
 However, volunteers are problems: users don't know who they're dealing
-with. A disruptive bad guy can do whatever he wants. We can try to monitor
-system components, but this is harder to do in a decentralized dynamic
-system. It is possible to structure system protocols to create better
+with. In this work we primarily focus on the strategic motivations of
+honest agents, but the motivations of dishonest agents are at least as
+important.  An anonymity-breaking adversary with an adequate budget would
+do best to provide very good service, possibly also attempting DoS against
+other high-quality providers. None of the usual metrics of performance and
+efficiency will help tell who the bad guys are in this instance. Further,
+who assigns those metrics and how? If they depend on a centralized trusted
+authority, the advantages of diffusion are lost. A reliability-breaking
+adversary will have still different goals and approaches.
+
+It is possible to structure system protocols to create better
 incentives for honest principals and to catch bad performance by others
 \cite{mix-acc,casc-rep}. But even when this is feasible, identifying
 individuals is a problem. Classic authentication considers whether it's
@@ -737,14 +740,15 @@
 for better service or preferential treatment --- the hordes in the coach
 seats are probably better off anonymity-wise than those in first class.
 
-\subsection{Usability}
+This requirement to pidgeonhole users into a few behavior classes
+conflicts with the fact that real-world users have different interests
+and different approaches. Heterogeneity in its users is what makes the
+Internet so lively and successful. Reduced options can lead to reduced
+usability, scaring away the users and leaving a useless anonymity system.
 
-However, ``in anonymity systems usability, efficiency, reliability and
-cost become \emph{security} objectives because they affect the size of the
-user base which in turn affects the degree of anonymity it is possible
-to achieve'' \cite{back01}. It remains to be seen whether designs and
-incentives, for both system users and system components, can be structured
-to meet all of these objectives sufficiently to create viable systems.
+% It remains to be seen whether designs and
+%incentives, for both system users and system components, can be structured
+%to meet all of these objectives sufficiently to create viable systems.
 
 \section{Future Work}
 

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