r12371@catbus: nickm | 2007-04-14 20:01:09 -0400

%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}