%bridge authority, in a way that's sticky even when we add bridge
%directory authorities, but isn't sticky when our authority goes
%away. Does this exist?)
+% [[Ian says: What about just using something like hash table chaining?
+% This should work, so long as the client knows which authorities currently
+% exist.]]
%\subsection{Discovery based on social networks}
%Nick, want to rewrite/elaborate on this section?
+%Ian suggests:
+% Possession of Tor: this is totally of-the-cuff, and there are lots of
+% security issues to think about, but what about an ActiveX version of
+% Tor? The magic you learn (as opposed to a bridge address) is a plain
+% old HTTPS server, which feeds you an ActiveX applet pre-configured with
+% some bridge address (possibly on the same machine). For bonus points,
+% somehow arrange that (a) the applet is signed in some way the user can
+% reliably check, but (b) don't end up with anything like an incriminating
+% long-term cert stored on the user's computer. This may be marginally
+% useful in some Internet-cafe situations as well, though (a) is even
+% harder to get right there.
+
+
\subsection{Observers can tell who is publishing and who is reading}
\label{subsec:upload-padding}
%it has received a message it does not understand (as would be the
%case were it not a bridge).
+% Ian suggests a ``socialist millionaires'' protocol here, for something.
+
+% Did we once mention knocking here? it's a good idea, but we should clarify
+% what we mean. Ian also notes that knocking itself is very fingerprintable,
+% and we should beware.
+
\subsection{How to motivate people to run bridge relays}
\label{subsec:incentives}
copy.
See Section~\ref{subsec:first-bridge} for more discussion.
+% Ian suggests that we have every tor server distribute a signed copy of the
+% software.
+
\section{Future designs}
\label{sec:future}