[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[or-cvs] r9957: Add comments to blocking.tex based on an old email from Ian, (in tor/trunk: . doc/design-paper)
- To: or-cvs@xxxxxxxxxxxxx
- Subject: [or-cvs] r9957: Add comments to blocking.tex based on an old email from Ian, (in tor/trunk: . doc/design-paper)
- From: nickm@xxxxxxxx
- Date: Sat, 14 Apr 2007 20:29:13 -0400 (EDT)
- Delivered-to: archiver@seul.org
- Delivered-to: or-cvs-outgoing@seul.org
- Delivered-to: or-cvs@seul.org
- Delivery-date: Sat, 14 Apr 2007 20:29:21 -0400
- Reply-to: or-talk@xxxxxxxxxxxxx
- Sender: owner-or-cvs@xxxxxxxxxxxxx
Author: nickm
Date: 2007-04-14 20:29:12 -0400 (Sat, 14 Apr 2007)
New Revision: 9957
Modified:
tor/trunk/
tor/trunk/doc/design-paper/blocking.tex
Log:
r12371@catbus: nickm | 2007-04-14 20:01:09 -0400
Add comments to blocking.tex based on an old email from Ian, so I can get the email out of my todo folder.
Property changes on: tor/trunk
___________________________________________________________________
svk:merge ticket from /tor/trunk [r12371] on 8246c3cf-6607-4228-993b-4d95d33730f1
Modified: tor/trunk/doc/design-paper/blocking.tex
===================================================================
--- tor/trunk/doc/design-paper/blocking.tex 2007-04-14 22:28:50 UTC (rev 9956)
+++ tor/trunk/doc/design-paper/blocking.tex 2007-04-15 00:29:12 UTC (rev 9957)
@@ -1280,6 +1280,9 @@
%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}
@@ -1322,6 +1325,19 @@
%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}
@@ -1588,6 +1604,12 @@
%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}
@@ -1675,6 +1697,9 @@
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}