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
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
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, 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
On Tue, 17 Jan 1995, Mats Bergstrom wrote: 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
participants (9)
-
anonymous-remailer＠xs4all.nl -
Brian Beattie -
eric＠remailer.net -
Homer Wilson Smith -
James A. Donald -
jrochkin＠cs.oberlin.edu -
Mats Bergstrom -
Perry E. Metzger -
Rick Busdiecker