aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorRoger Dingledine <arma@torproject.org>2006-10-29 07:38:49 +0000
committerRoger Dingledine <arma@torproject.org>2006-10-29 07:38:49 +0000
commit4026c0fc2fb5ce1ae4767433137af52d3ef74c2a (patch)
treec40814b938e85f789dacf26d25b89fef6d8a6d88
parentfe11d20600bd4d0cf5620747a8dcac910ffd59a4 (diff)
downloadtor-4026c0fc2fb5ce1ae4767433137af52d3ef74c2a.tar.gz
tor-4026c0fc2fb5ce1ae4767433137af52d3ef74c2a.zip
motivate families-of-bridges better
svn:r8853
-rw-r--r--doc/design-paper/blocking.tex16
1 files changed, 13 insertions, 3 deletions
diff --git a/doc/design-paper/blocking.tex b/doc/design-paper/blocking.tex
index 3ce5595411..bbf6518dbe 100644
--- a/doc/design-paper/blocking.tex
+++ b/doc/design-paper/blocking.tex
@@ -724,8 +724,8 @@ also support an entire community of users. For example, Citizen Lab's
upcoming Psiphon single-hop proxy tool~\cite{psiphon} plans to use this
\emph{social network} approach as its discovery component.
-There are some variations on this design. In the above example, the
-operator of the bridge seeks out and informs each new user about his
+There are some variations on bootstrapping in this design. In the simple
+case, the operator of the bridge informs each chosen user about his
bridge's address information and/or keys. Another approach involves
blocked users introducing new blocked users to the bridges they know.
That is, somebody in the blocked area can pass along a bridge's address to
@@ -734,7 +734,17 @@ theory properties: the blocked user making the decision has an incentive
only to delegate to trustworthy people, since an adversary who learns
the bridge's address and filters it makes it unavailable for both of them.
-\subsection{Families of bridges}
+Note that a central set of bridge directory authorities can still be
+compatible with a decentralized discovery process. That is, how users
+first learn about bridges is entirely up to the bridges, but the process
+of fetching up-to-date descriptors for them can still proceed as described
+in Section~\ref{sec:bridges}. Of course, creating a central place that
+knows about all the bridges may not be smart, especially if every other
+piece of the system is decentralized. Further, if a user only knows
+about one bridge and he loses track of it, it may be quite a hassle to
+reach the bridge authority. We address these concerns next.
+
+\subsection{Families of bridges, no central discovery}
Because the blocked users are running our software too, we have many
opportunities to improve usability or robustness. Our second design builds