Re: Abuse and Remailer Ethics

At 9:21 PM 01/16/95, Homer Wilson Smith wrote:
[snip]
>     Does any single recipient have the right to demand that they be
>blocked from all anon messages.  I would say yes.
>
>     How about demanding blocking anon messages only from some
>senders?  That is harder to implement.  If you block the sender, you
>block ALL his postings, not just to that party.  So you would need to
>block specific From: and To: combinations.  This would not work with
>chaining at all, even if we did share blocking information.  So that
>is out.
>
>     Does a list owner have the right to demand blocking to his list,
>with or without a vote of the list readers?  I would say yes.
>
>     What about a newsgroup?  I would say it takes a vote.  Are anon voites
>allowed?  Touchy question that was important at one time on
>alt.r.scientology.

I agree  with all of that.  Somewhat conditionally with what you say about
newsgroups, because while it sounds nice, it would be hard to implement.
I'm tempted to say that a newsgroup, by it's nature, doesn't have any
mechanism for control/government, once created.  And as such, doesn't have
any way to "decide" not to accept anonymous posts, or posts from a specific
user or remailer.  So I'm tempted to say "tough luck" to newsgroups that
don't like receiving anonymous posts. The alternative is for people
interested to create a moderated newsgroup, where of course the moderator
could refuse to allow anonymosu posts with or without the remailer
operators cooperation.

>     Anyhow I would guess that the correct action here is to write the
>offender and let him know a complaint has been registered against him.
>I would also educate him as to why he was so easily traced and tell
>him that if he wants to avoid such in the future to start chaining.

Yes, I think that is an excellent course of action.

>     However if he is a determined abuser not prone to social
>embarassment, then the sharing of blocking among remailer operators
>might become a very good idea.

I'm not so sure about that.   It might become neccesary, but blocking
remailer delivery to a particular address is a _much_ more desirable
solution, in my opinion.  If a particular person doesn't want to receive
anonymous mail, fine.  And it might be good to have a mechanism by which he
could make those desires known to all remailers, so he doesn't have to do
it individually.  But if he does want to receive mail from the remailers, I
think he's got to receive all mail from the remailers, and not count on the
remailer operators to play Identity Detective and try to screen out people
he doesn't like.  Same with a listserv and the requests of the listserv
operator.  A newsgroup is, of course, more touchy, because there really
_isn't_ a way for "the newsgroup" to decide not to accept anonymous posts.
And I'm not really sure there should be.

Part of the answer relies on how "independent" your remailer is.  If you
_were_ to take no action at all to people who complain about "abuse", would
you get in trouble? (from school, company, service provider, country). If
you would, then you've got to decide if you are willing to take the heat.
And your probably not willing to take the heat for Cantor & Siegel to spam
the net.  So you've got to do what you've got to do.  But, personally, if I
ran a remailer on a machine that wasn't subject to political pressure (from
school, service provider, whatever), I would never make any effort to
cooperate with other operators to track down "offenders", and I'd never
exclude any newsgroups from delivery.   Because I wouldn't want to play
censor and decide what "offense" is worth tracking down, and what isn't.
And because even having the _capability_ to track down people is really
dangerous, when you get pressure to track down someone you _don't_ want to
track down.  Much better to say "Can't be done, don't have logs, can't
figure out who it was," then to have to admit "well, I've tracked down 5
people in the past month cause someone complained about them."  Kind of
ruins the point of anon remailers. Best would be to have tracking down be
impossible, and it would be close to, if not entirely, impossible if the
user took the proper precauations.  But even if it's possible, it's
probably best not to develop a mechanism to do it.

OK, I understood all this.  I am afraid that if we implement a total
no tracing scenario, then remailers will come under heat from the world at
large and the governments.  Maybe not.  Rright now, Rahul (a good guy) is
implementing syslogs whether I want him to or not, and that isn't about to
change.  Really I would have to be the owner of my own system in order to
do what you are suggesting. 

     But then that is what got jpunix shut down. No way to deal with
complaints, and big time abuses going through his server, right JP? 

     But I see the advantage to total no tracing, I am just not sure
all of us are really strong enough yet to implement it and stay
in business.
 
     Homer

This thread illustrates (at least if setup's like this are
worthy of a place in Raph's list) that penet.fi is the safest
way to go for the moment. I would just hate it to have my
head on the plate of a remailer operator who takes an interest
in subtile ethical discussion of whether to sell me out or not.

Mats

In article <Pine.HPP.3.91.950117105356.16699A-100000@cor.sos.sll.se>,
Mats Bergstrom <asgaard@sos.sll.se> wrote:
> 
> This thread illustrates (at least if setup's like this are
> worthy of a place in Raph's list) that penet.fi is the safest
> way to go for the moment. I would just hate it to have my
> head on the plate of a remailer operator who takes an interest
> in subtile ethical discussion of whether to sell me out or not.
> 
> Mats
>  
> 
This comment is grossly unfair.  Obviously Homer is going to a lot of
effort to operate his remailer in the best way possible.  

It's easy for others to be critical.  "head on a plate" is a strong
term to use, given Homer made it clear he would not reveal the
identity of an anonymous user without a court order.  Also, one
wonders to what end remailers are being put by people who are worried
about being "sold out".

It's always been a good policy to use a foreign mailer in a chain
where anonymity is critically important.  That doesn't mean it's OK
to make Homer the whipping boy.

On Tue, 17 Jan 1995, Name withheld on request wrote:

> wonders to what end remailers are being put by people who are worried
> about being "sold out".

The fundamental principle here is that an e-mail message is just so
many bits of 1's and 0's. It can never, in it's own capacity, steal,
molest or kill. It is therefore not unethical to run a no-log 'fortress
remailer' and auto-delete ALL complaints, without exception. It might
not be feasible to do so if one wants to stay out of jail, but hope-
fully this will change with the rapid increase in country domains
and the soon-to-come digicash market. Discussions of programming to
make fortress remailers work and to make them easily exportable to
African Linux-boxes are interesting. So are discussions of expected
repercussions on society. Ethical discussions of what is abuse or not
are better left to the clergy.

Mats

On Tue, 17 Jan 1995, Mats Bergstrom wrote:

> On Tue, 17 Jan 1995, Name withheld on request wrote:
> 
> > wonders to what end remailers are being put by people who are worried
> > about being "sold out".
> 
> The fundamental principle here is that an e-mail message is just so
> many bits of 1's and 0's. It can never, in it's own capacity, steal,
I disagree, one can use e-mail to steal.  E-mail consumes resources,
resources for which the sender may have no right to use.  If the sender
is sending messages which the recipient does not wish to receive then
his resources are being taken.  If the recipient has now way of stopping
the messages then the recipients resources are being taken against the
recipient's will and the recipient should be able to have the messages
stopped before they consume the recipients resources.

Brian Beattie         | [From an MIT job ad] "Applicants must also have
                      | extensive knowledge of UNIX, although they should
beattie@csos.orst.edu | have sufficently good programming taste to not
Fax (503)754-3406     | consider this an achievement."

From: Brian Beattie <beattie@CSOS.ORST.EDU>

   I disagree, one can use e-mail to steal.  E-mail consumes resources,
   resources for which the sender may have no right to use.  

It's not theft if there's no direct benefit to the actor.  It does
consume resources, there's no argument about that.  Note, however,
that the scope of any such resource use is with the message as a bit
sequence; no meaning or interpretation of the content is even
relevant.  That is, the resource use does not relate to the email as
communication, merely as a technical operation.

The question remains whether such resource use can ever be considered
unauthorized.  Certainly it's impolite; that's not at issue.

I argue that if you hook your machine up to the Internet, you've
implicitly authorized people to send you packets -- as many as they
want and of whatever nature as they want.  No service provision I've
ever seen gives any recourse to the end user against the provider for
"bad" packets.

I also think this is the one great flaw in the design of the Internet;
namely, that the sender has all the control over what packets flow
over the net.  A receiver can ask for a slowdown or cessation, but
there's no obligation to do so.  This will be, if anything, the
limiting factor in scalability of the internet.

Eric

Eric Hughes says:
> I argue that if you hook your machine up to the Internet, you've
> implicitly authorized people to send you packets -- as many as they
> want and of whatever nature as they want.  No service provision I've
> ever seen gives any recourse to the end user against the provider for
> "bad" packets.

Be that as it may, people HAVE been kicked off for mischief like
forging routing packets -- and if someone started hosing me down with
any one of several really nasty packet based attacks I'm familiar with
I would expect action to be taken against them.

Remember that degree is important in such instances. You are allowed
to shine a flashlight at your neighbor's house -- you aren't allowed
to shine a fifty megawatt laser. Degree counts.

> I also think this is the one great flaw in the design of the Internet;
> namely, that the sender has all the control over what packets flow
> over the net.  A receiver can ask for a slowdown or cessation, but
> there's no obligation to do so.  This will be, if anything, the
> limiting factor in scalability of the internet.

I doubt it. It really hasn't proved to be an actual problem thus
far. If anything, the limiting factor on scalability is the fact that
the net has no locality of reference, which is making routing design
harder and harder. Routing is currently THE big unsolved problem on
the net -- something outsiders to the IETF rarely suspect, because the
engineers have been faking it so well for so long. Unfortunately, all
the good solutions to the routing problem are mathematically
intractable -- and the practical ones are leading to bad potential
long term problems...

Perry

Eric Hughes says:
> > I argue that if you hook your machine up to the Internet, you've
> > implicitly authorized people to send you packets -- as many as they
> > want and of whatever nature as they want.  No service provision I've
> > ever seen gives any recourse to the end user against the provider for
> > "bad" packets.
 
On Wed, 18 Jan 1995, Perry E. Metzger wrote:
> Be that as it may, people HAVE been kicked off for mischief like
> forging routing packets -- and if someone started hosing me down with
> any one of several really nasty packet based attacks I'm familiar with
> I would expect action to be taken against them.

Unix is broken.  Windows and DOS are fragile and under construction.

Servers should have built in limits, that cause them to spit back
packets from unknown clients that are unreasonable or strain the
system.

For example an SMTP server should have a default limit on volume
per address and per client, with the user being able to vary
such limits for particular clients or addresses -- trusted or
hostile clients.

At present most unix utilities have arbitrary fixed length internal
buffers for processing variable length fields.  If you overflow 
the buffer by sending pathological data you will crash the system.  
If you know machine code, and you overflow the buffer with 
carefully chosen data then instead of a random crash you can
get the server to do some particular unexpected thing -- for
example the internet worm caused the server to execute a
file that the mail server had just received.

This is one of many bugs that make attacks possible.

This is a bug.  It can and regularly does crash your
system and cause loss of data even if nobody attacks.

Every flaw in the system causes more havoc by accident
than it does by malice.  The correct solution is not
to create institutions capable of dealing effectively
with hostile acts.   The big problem is bugs that urgently
need fixing.

Now even if all the bugs were fixed some really evil
packet based attacks are still possible, in which case
social action -- cutting the connectivity of a host
that generates bad packets -- is still necessary, but 
again bad packets are more common by malfunction
than by malice.

> I doubt it. It really hasn't proved to be an actual problem thus
> far. If anything, the limiting factor on scalability is the fact that
> the net has no locality of reference, which is making routing design
> harder and harder. Routing is currently THE big unsolved problem on
> the net -- something outsiders to the IETF rarely suspect, because the
> engineers have been faking it so well for so long. Unfortunately, all
> the good solutions to the routing problem are mathematically
> intractable -- and the practical ones are leading to bad potential
> long term problems..

This is inaccurate.  Optimal solutions to the routing problem are
mathematically intractable.  Tolerable solutions are mathematically
tractable.  For realistic routing problems, tractable approximations
are only worse than an optimal solution by a modest factor.

There are real world problems where tractable approximations
are not good enough, but routing is not one of them.

Of course I am sure Perry is correct when he says that
the tractable approximations that we are currently using 
fail to scale, but this is not a fundamental unsolved 
problem in mathematics -- it is merely yet another bug.

 ---------------------------------------------------------------------
We have the right to defend ourselves and our       
property, because of the kind of animals that we  
are.  True law derives from this right, not from    James A. Donald
the arbitrary power of the omnipotent state.        jamesd@netcom.com

               http://www.catalog.com/jamesd/

"James A. Donald" says:
> On Wed, 18 Jan 1995, Perry E. Metzger wrote:
> > Be that as it may, people HAVE been kicked off for mischief like
> > forging routing packets -- and if someone started hosing me down with
> > any one of several really nasty packet based attacks I'm familiar with
> > I would expect action to be taken against them.
> 
> Unix is broken.  Windows and DOS are fragile and under construction.

This has nothing to do with Unix, Mr. Donald. This has to do with the
nature of internet protocols.

> Servers should have built in limits, that cause them to spit back
> packets from unknown clients that are unreasonable or strain the
> system.

Can't be done. Sorry. There are certain flaws in the design of the
internet protocols down on the transport layer that I'd rather not get
into because they don't seem to be widely known and I'm not interested
in making them better known.

> For example an SMTP server should have a default limit on volume
> per address and per client, with the user being able to vary
> such limits for particular clients or addresses -- trusted or
> hostile clients.

Sendmail already has such limits. Unfortunately they ultimately do no
good. I'd try explaining, but the details get too technical -- if
people insist I'll get into it. The gist is, however, that in the
current network its too easy to fake connections. Even with per client
limits I could still make your machine die a horrible death.

> At present most unix utilities have arbitrary fixed length internal
> buffers for processing variable length fields.  If you overflow 
> the buffer by sending pathological data you will crash the system. 

Not usually, actually. The "utilities" have nothing to do with the
kernel, and the kernel is what can crash the machine.

> If you know machine code, and you overflow the buffer with 
> carefully chosen data then instead of a random crash you can
> get the server to do some particular unexpected thing -- for
> example the internet worm caused the server to execute a
> file that the mail server had just received.

Those sorts of security problems are not only well known but largely
gone. The last one, in sendmail's debug flag, could only hurt a
machine by action of a user on the machine itself, not over the
network. The sorts of things I'm talking about are *inherent* in the
design of TCP and cannot be altered at this point.

> > I doubt it. It really hasn't proved to be an actual problem thus
> > far. If anything, the limiting factor on scalability is the fact that
> > the net has no locality of reference, which is making routing design
> > harder and harder. Routing is currently THE big unsolved problem on
> > the net -- something outsiders to the IETF rarely suspect, because the
> > engineers have been faking it so well for so long. Unfortunately, all
> > the good solutions to the routing problem are mathematically
> > intractable -- and the practical ones are leading to bad potential
> > long term problems..
> 
> This is inaccurate.  Optimal solutions to the routing problem are
> mathematically intractable.  Tolerable solutions are mathematically
> tractable.

Name one, Mr. Donald. Name a single one.

> For realistic routing problems, tractable approximations
> are only worse than an optimal solution by a modest factor.

Sorry, but you just don't know what you are talking about here,
period. We don't know how to solve the routing problem in the general
case. Thats one of the reasons for all the arguments in the IETF
concerning the problems we are getting ourselves into with route
agregation.

(Just so you are clear here, Mr. Donald, the routing problem is NOT
the problem of finding an optimal path between all pairs of nodes on a
network in polynomial time -- thats solved and absolutely useless.)

> Of course I am sure Perry is correct when he says that
> the tractable approximations that we are currently using 
> fail to scale, but this is not a fundamental unsolved 
> problem in mathematics -- it is merely yet another bug.

Nope, not a bug. There are problems that we don't know how to
solve.

The problem is routing agregation, you understand, and the fact that
agregated clouds don't really experience locality of reference. This
means that we end up with nasty and totally artificial network choke
points as the networks scale. If we transmit full information,
however, we no longer get agregation and can no longer store the
tables because they are too big.

Perry

On Wed, 18 Jan 1995, Eric Hughes wrote:

>    From: Brian Beattie <beattie@CSOS.ORST.EDU>
> 
>    I disagree, one can use e-mail to steal.  E-mail consumes resources,
>    resources for which the sender may have no right to use.  
> 
> It's not theft if there's no direct benefit to the actor.  It does

I must assume that the actor who spams me or sends me unsolicited
email or any email for that matter derives some benifit from this 
activity or they would not do it.

> consume resources, there's no argument about that.  Note, however,
> that the scope of any such resource use is with the message as a bit
> sequence; no meaning or interpretation of the content is even
> relevant.  That is, the resource use does not relate to the email as
> communication, merely as a technical operation.

If I make it clear that I do not wish to receive email from an individual
or group and that individual or group continues to send email then I contend
that they are using my resources in a way that I have not authorized.

> 
> The question remains whether such resource use can ever be considered
> unauthorized.  Certainly it's impolite; that's not at issue.
> 
> I argue that if you hook your machine up to the Internet, you've
> implicitly authorized people to send you packets -- as many as they
> want and of whatever nature as they want.

clearly I disagree.

Brian Beattie         | [From an MIT job ad] "Applicants must also have
                      | extensive knowledge of UNIX, although they should
beattie@csos.orst.edu | have sufficently good programming taste to not
Fax (503)754-3406     | consider this an achievement."

From: Brian Beattie <beattie@CSOS.ORST.EDU>

   I must assume that the actor who spams me or sends me unsolicited
   email or any email for that matter derives some benifit from this 
   activity or they would not do it.

Much tort involves perceived gain by the tortfeasor, but that doesn't
make it theft.

   If I make it clear that I do not wish to receive email from an individual
   or group and that individual or group continues to send email then I contend
   that they are using my resources in a way that I have not authorized.

So who are you making it clear to, if the parties sending the email
are anonymous?

Eric

Date: Tue, 17 Jan 1995 11:06:16 +0100 (MET)
    From: Mats Bergstrom <asgaard@sos.sll.se>

    This thread illustrates (at least if setup's like this are
    worthy of a place in Raph's list) that penet.fi is the safest
    way to go for the moment.

That depends on your threat model.  For most, chaining is safer than
penet.

    I would just hate it to have my head on the plate of a remailer
    operator who takes an interest in subtile ethical discussion of
    whether to sell me out or not.

Your characterization of what Homer has said strikes me as extremely
inaccurate.

			Rick

The POINT is that if you chain and use pgp the remailer operator
CAN'T sell you out.  Whether or not the reop discusses or promises never
to sell you out is meaningless when the cards are down.  Trusting someone
because they SAY they are trustable is a fools game. So up front, I say
"Who me, trustable?  Hah!", and then let people use the technology to make
sure their stuff is safe.  PGP can't be broken, and chaining can't be
traced without LOTS of difficulty, and frankly reops have little interest
really in reading people's private mail, especially when it is pgp'd, let
alone tracing them for postings that they don't even know what's being
said in them!  Right? 
 
     Homer

On Tue, 17 Jan 1995, Rick Busdiecker wrote:

>     Date: Tue, 17 Jan 1995 11:06:16 +0100 (MET)
>     From: Mats Bergstrom <asgaard@sos.sll.se>
> 
>     This thread illustrates (at least if setup's like this are
>     worthy of a place in Raph's list) that penet.fi is the safest
>     way to go for the moment.
> 
> That depends on your threat model.  For most, chaining is safer than
> penet.
> 
>     I would just hate it to have my head on the plate of a remailer
>     operator who takes an interest in subtile ethical discussion of
>     whether to sell me out or not.
> 
> Your characterization of what Homer has said strikes me as extremely
> inaccurate.
> 
> 			Rick
> 
>