[or-cvs] r8853: motivate families-of-bridges better (tor/trunk/doc/design-paper)

arma at seul.org arma at seul.org
Sun Oct 29 07:38:49 UTC 2006

Author: arma
Date: 2006-10-29 02:38:49 -0500 (Sun, 29 Oct 2006)
New Revision: 8853

motivate families-of-bridges better

Modified: tor/trunk/doc/design-paper/blocking.tex
--- tor/trunk/doc/design-paper/blocking.tex	2006-10-29 07:38:21 UTC (rev 8852)
+++ tor/trunk/doc/design-paper/blocking.tex	2006-10-29 07:38:49 UTC (rev 8853)
@@ -724,8 +724,8 @@
 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,8 +734,18 @@
 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
 on the first by encouraging volunteers to run several bridges at once

More information about the tor-commits mailing list