[freehaven-cvs] Add in old conclusion and a few more notes about rep

[nickm@seul.org (Nick Mathewson)]

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

Modified Files:
	econp2p03.tex 
Log Message:
Add in old conclusion and a few more notes about rep

Index: econp2p03.tex
===================================================================
RCS file: /home/freehaven/cvsroot/doc/econp2p03/econp2p03.tex,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -d -r1.7 -r1.8
--- econp2p03.tex	2 Apr 2003 02:05:06 -0000	1.7
+++ econp2p03.tex	2 Apr 2003 02:32:43 -0000	1.8
@@ -37,8 +37,8 @@
 \email{(syverson@itd.nrl.navy.mil)}}
 
 \maketitle
-\pagestyle{plain} 
- 
+\pagestyle{plain}
+
 \begin{abstract}
 
 Decentralized anonymity systems tend to be unreliable, because users
@@ -74,8 +74,8 @@
 his anonymity. And thirdly, reputation information can be exploited by
 an adversary to better analyze and subvert the anonymity provided.
 
-So we are left with a conundrum: if the networks's stability relies
-on the good performance of individual nodes, reputation may be the
+So we are left with a conundrum: if the network's stability relies
+on the good behavior of individual nodes, reputation may be the
 only way to achieve it.  But reputation data is hard to gather in
 the presence of anonymity, and even when gathered, poses a potential
 vulnerability for an attacker to exploit.
@@ -96,10 +96,12 @@
 others must use the same infrastructure. Anonymity systems use messages
 to hide messages: senders are consumers of anonymity and also providers
 of the cover traffic that creates anonymity for others. Thus users are
-always better off on crowded systems because of the noise they provide.
+always better off on crowded systems because of the noise other users provide.
 
-High traffic is necessary for strong anonymity, which means that the
-incentives of several agents must find a common equilibrium. High traffic
+Because high traffic is necessary for strong anonymity, agents must
+balance their incentives to find a common equilibrium, rather than
+each using a system of their own.
+The high traffic they create together
 also enables better performance: a system that processes only light
 traffic must delay messages to achieve adequately large anonymity sets.
 But systems that process the most traffic do not necessarily provide the
@@ -116,7 +118,7 @@
 user base which in turn affects the degree of anonymity it is possible
 to achieve.'' \cite{back01}
 
-Early work on the economics of anonymity \cite{econymics} focused on
+Early work on the economics of anonymity \cite{econymics} has focused on
 the incentives for participants to act as senders and nodes, providing
 three results:
 
@@ -134,10 +136,15 @@
 \item While there are economic reasons for distributed trust,
 the deployment of a completely decentralized system might involve
 coordination costs which make it unfeasible. A central coordination
-authority to redistribute payments may be more practical.
+authority to redistribute payments may be more practical, but could
+provide a trust bottleneck for an adversary to exploit.
 \end{itemize}
 
-lead in to why we focus on reputation here
+The reputation systems we discuss below would enable users 
+do not direct their traffic to unreliable nodes--thus giving
+high-sensitivity against to provide {\it reliable} service, and making
+the network as a whole more reliable.  Below, we examine several
+designs for reputation systems for anonymity networks.
 
 \section{An Example: Remailer Networks}
 
@@ -201,7 +208,7 @@
 away with trusted witnesses and proofs in favor of self-rating groups
 of remailers. Remailers are arranged in cascades (fixed paths through the
 network, so batches of messages go through in synchrony).
-New cascades are formed at a regular interval (eg daily),
+New cascades are formed at a regular interval (e.g. daily),
 and the formation of cascades is based on a communally generated
 random value so that no set of collaborating remailers can predict which
 remailer will be in which cascade, as long as at least one remailer is
@@ -355,6 +362,65 @@
 
 \section{Conclusion: New Directions, Misdirections, and Other Questions}
 
+Reputation systems are already gathering momentum at the grassroots of the
+Internet. Special-purpose systems---some more {\it ad hoc<} than others---have
+already been rolled into online auction services, messaging protocols, and
+online discussion sites. But despite this growing body of experience at
+building simple reputation systems and designing more complex ones for
+anonymity systems, the questions remain as intriguing as the solutions.
+
+How can we fine-tune a reputation system in response to a specific threat
+model? In a relatively low-threat environment (e.g., tracking ISP uptime),
+ordinary statistical models will suffice. But most statistical models
+assume that data is biased at worst, not maliciously chosen by an adversary
+who wants us to make a particular decision. At this point, the emphasis in
+current research shifts from predicting behavior to minimizing risk. Is it
+really necessary to abandon statistical rigor? The field of machine
+learning has a rich history and a lot of experience at solving related
+problems. Is there some way to adapt these solutions to an adversarial
+context?
+
+Similarly, what can we do when statements aren't verifiable, and where an
+adversary can either lie about real interactions, or fabricate spurious
+interactions and lie about those?  We could try to make credibility charts
+and weight statements by credibility -- but a smart adversary could try to
+trick our credibility calculations as well. If somebody finds a way to
+establish bounds on malicious influence on such a system, the range of
+problems we can solve with reputation would explode overnight.
+
+We have already seen how reputation can enhance privacy. Can we go one step
+farther, and assign reputation based on an expectation of protecting
+privacy? In distributed privacy systems, the privacy provided is typically
+based on an assumption that some subset of system components will both
+perform duties correctly {\it and} will not reveal some parts of their data
+and/or operations. A privacy destroying adversary might offer very reliable
+service while using information from various compromised system elements to
+compromise privacy. Can we say anything meaningful about reputations based
+on reliability at keeping secrets, or are we limited to making statements
+about the probability of privacy compromise given the likelihood and
+structure of component compromise?
+
+What if we treat reputation as currency? Currency implies economics. How do
+you get reputation currency? Do currency-based approaches always imply
+transitive trust? Is the supply of reputation currency constant,
+increasing, or decreasing? Does it expire, or slowly lose value over time?
+Where, ultimately, does a currency come from -- a decentralized Federal
+Reserve? Does it materialize as a side-effect of performing work from the
+system? Is there credit? Or does currency only appear when the system is
+bootstrapped, and if so, how? Is currency global, or do individual servers
+mint their own currencies? Can we evolve a viable market that is scalable
+based on these local currencies issued by individual servers? Can a global
+currency be bootstrapped from local currencies?
+
+The number and diversity of real-world reputation systems is staggering.
+Through a byzantine mass of credit reports, product reviews, earnings
+statements, flat-out gossip, and a thousand other information channels, we
+try to convince one another of our honesty and competence. In the process
+we expose far more detail about ourselves than we might wish. Online
+reputation systems promise to be still more complex and difficult to build
+than their real-world analogues, but they hold out the promise of enabling
+decentralized interaction and protecting privacy in ways that today's
+systems of trust cannot.
 
 \bibliographystyle{plain}
 

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