1996-05-25 - Re: An alternative to remailer shutdowns

Header Data

From: “E. ALLEN SMITH” <EALLENSMITH@ocelot.Rutgers.EDU>
To: unicorn@schloss.li
Message Hash: 4cfc7a5b9f30a04685b29a5bb350db0383771845b51cee30e7516c2ae0888bdc
Message ID: <01I53PQSSUL88Y4ZAY@mbcl.rutgers.edu>
Reply To: N/A
UTC Datetime: 1996-05-25 09:03:27 UTC
Raw Date: Sat, 25 May 1996 17:03:27 +0800

Raw message

From: "E. ALLEN SMITH" <EALLENSMITH@ocelot.Rutgers.EDU>
Date: Sat, 25 May 1996 17:03:27 +0800
To: unicorn@schloss.li
Subject: Re: An alternative to remailer shutdowns
Message-ID: <01I53PQSSUL88Y4ZAY@mbcl.rutgers.edu>
MIME-Version: 1.0
Content-Type: text/plain


From:	IN%"unicorn@schloss.li"  "Black Unicorn" 24-MAY-1996 22:52:03.64

>Remailers on the attack points (first in chain, last in chain) simply MUST
>be disposable as tissue.  They must be run as anonymously as possible,
>with as little connection to the ISP's assets as possible and immediately
>disposable.  They must be easy to set up, runable without root and there
>must be a much more efficent tracking mechanism.  (Mr. Levin has done a
>terrific job, but even more needs to be done).

	Why the first in chain? If the anti-traffic-analysis provisions are
working properly, it should be impossible to prove that a given first remailer
was the first remailer for any particular message. I had thought that even
civil courts required that you be the person who committed some act, not the
person who _might_ have committed some act. Otherwise, all the remailers are
in danger. This is even if someone tries an entrapment by sending through some
illegal material - if the courts accept that they should be allowed to do this,
then all the remailers they chained are going to be hit.

>This wanton suing, as I think we all know, is an abuse of the copyright
>protections and their intent.  The only way to really deal with it is make
>remailers unassailable.  Doing that with tricky dick type legal arguments
>will, in my view, eventually fail.

	Ultimately, I have to agree. Protect the remailers as much as possible
with the legal arguments... but don't depend on them. The government in general
has no motivation to protect the remailers. They've got a motivation to protect
ISPs, and thus may put in protections for them regarding liability.

>It only takes ONE operator to get a tiny ($2500-$10,000) fine or judgement
>and that will be the end of most of the mailers.  Poof.

	What, pray tell, is the result of a judgement in which the person
manifestedly doesn't have the money to pay? I couldn't pay a 10,000 dollar
judgement; I don't have that much money. I would guess it'd be some form
of attachment of income; this wouldn't get them much...

>This we cannot allow.

	Quite.

>I wouldn't go this far.  It is an excellent argument for picking juries
>that are experts with regard to the subject at hand.

	One step in this direction would be requiring some level of education
from juries. If the defendant is someone with a college degree, require the
jurors to have a college degree. If the defendant is someone with a Ph.D.,
require the jurors to have a Ph.D. or similarly high equivalent (J.D., M.D.,
etcetera). While this doesn't mean that the jury will necessarily know what's
being talked about (I've given presentations to _graduate_ school seminars in
which I went well over the heads of everyone in the class - including the
professor - after spending maybe four weeks working on the project), it does
increase the chance that they're at least teachable.

>In my view trying to balance bias rather than eliminate it is much more
>effective.

	Modification of jury selection? Removal of some of the preemptory
challenges? Hmm... some challenges are for cause, as I recall. Unless it's
a particulary egregious case of such, I'd suggest allowing the other side to
override such with expenditure of a preemptory challenge.

>If harassing mail is the issue, I can see how this might help in terms of
>image.  I don't think its a complete solution however.

>Again, I think the attack points have to be protected.

	Agreed.
	-Allen





Thread