From: Greg Broiles <gbroiles@netbox.com>
To: “Geoffrey C. Grabow” <gcg@pb.net>
Message Hash: 35d12cb5ad580c7c601de59c978decf4f1ece1ed6825904645fd399d6e7c98e3
Message ID: <3.0b28.32.19961001030608.006af114@ricochet.net>
Reply To: N/A
UTC Datetime: 1996-10-01 12:37:41 UTC
Raw Date: Tue, 1 Oct 1996 20:37:41 +0800
From: Greg Broiles <gbroiles@netbox.com>
Date: Tue, 1 Oct 1996 20:37:41 +0800
To: "Geoffrey C. Grabow" <gcg@pb.net>
Subject: Re: What about making re-mailers automatically chain?
Message-ID: <3.0b28.32.19961001030608.006af114@ricochet.net>
MIME-Version: 1.0
Content-Type: text/plain
Removing knowledge of the path from the sender is a plus. This prevents
anyone, even the sender, from being able to give up any useful info even if
under court order.
<<<<
Why is information about the path useful (or harmful) once the sender is
identified? Once the sender is identified, if they're subject to
questioning, they can be asked to identify the destination of the
message(s). Introducing indeterminacy into the middle of the route won't
prevent them from answering questions about the other endpoint.
>>>>
Adding "random" traffic is helpful 'cause many people (including myself)
use pre-fab anon scripts and therefore use the same anon paths all the time
(I should stop that). This opens those messages up to some analysis and
the possibility of the sender being revealed.
<<<<
Now I see why you want this. Isn't this the sort of feature which should be
added to client software, not remailers? That way, all clients can get as
much or as little security as they need.
--
Greg Broiles | "We pretend to be their friends,
gbroiles@netbox.com | but they fuck with our heads."
http://www.io.com/~gbroiles |
|
Return to October 1996
Return to “Greg Broiles <gbroiles@netbox.com>”
1996-10-01 (Tue, 1 Oct 1996 20:37:41 +0800) - Re: What about making re-mailers automatically chain? - Greg Broiles <gbroiles@netbox.com>