Re: Future of anonymity (short-term vs. long-term)

Sorry, I sent my last message before it was ready (and before it got
divided into two separate messages).  It mostly says what I wanted it
to, so I won't bother you with another version.

On the SHORT-TERM end of things,  I have two more thoughts on how to
make truly anonymous remailers good net citizens:

  1.  Agree on a header line which identifies all messages coming out of 
      our remailers.  If someone wants to filter out all anonymous messages,
      I think we should help them to do so.

  2.  Here's my proposal for what kind of remailer logging to do:
          logging of source-to-destination mapping:  NONE.
          destination logging:  NONE.
          source logging:  on a machine-by-machine basis, log the total
              input volume over a fairly long period, with some random
              noise added.  When a source is providing too much volume,
              and it's not on your local list of "friendly" remailers,
              then take action to reduce the volume.  I suggest that the
              first action should be to INCREASE THE DELAY to reduce the
              volume-per-unit-time of messages from that site.  If the
              volume of spooled traffic from a site reaches a threshold, 
              only then start throwing away messages.


-- Marc Ringuette (mnr@cs.cmu.edu)

Date: Sun, 28 Feb 1993 19:59-EST
   From: Marc.Ringuette@GS80.SP.CS.CMU.EDU

     1.  Agree on a header line which identifies all messages coming out of 
	 our remailers.  If someone wants to filter out all anonymous messages,
	 I think we should help them to do so.

This would indeed be a considerate thing to do.  In the short run, the
only way a mailing list maintainer can avoid being abused by someone
twit determined to hide behind your network of maintainers is to
disallow anonymous postings altogether.

Since John Gilmore, the maintainer of the Cypherpunks mailing list, is
one of the absolute free speach advocates --- let me ask a question
directly at you:  What would you do if sometime next week, someone
decided to flood the Cypherpunks mailing list with a large amount of
trash postings, routed through different combinations of remailers?  Let
us assume that the trash is generated by grabbing varying snippets from
USENET articles, so that current AI technology is not able to
distinguish a true Cypherpunks submission from the flooded trash
postings.  What would you do?  Now let's also suppose someone does the
same thing to all of the GNU newsgroups.  What would you do then?

I ask these questions well aware that somewhere out there, some immature
twit might get an idea from this scenario, and make the above questions
less hypothetical.  :-( 

(Sorry for sounding so cynical, but after being a News admin at MIT for
a long time, and dealing with a lot of people suffering from severe
cases of freshmanitis, I have a less than optimistic view about human
nature.)

	     source logging:  on a machine-by-machine basis, log the total
		 input volume over a fairly long period, with some random
		 noise added.  When a source is providing too much volume,
		 and it's not on your local list of "friendly" remailers,
		 then take action to reduce the volume.  I suggest that the
		 first action should be to INCREASE THE DELAY to reduce the
		 volume-per-unit-time of messages from that site.  If the
		 volume of spooled traffic from a site reaches a threshold, 
		 only then start throwing away messages.

This doesn't work.  Someone clever could easily redirect the message
through different (non-anonymous) SMTP servers before the message
entered the remailer network; this would completely defeat the volume
logging, and while the first hop would still be logged somewhere, unless
the remailer administrator reveals the input/output address mapping,
you'd still have no way to trace the message from the destination to the
source.

							- Ted

Marc's short-term suggestion of bandwidth limiting from a particular
source seems like a reasonable exigency.  Let me suggest a way of
doing that which does not require keeping long-term logs.

Suppose your bandwidth limiter kept totals of all bytes sent in the
last week.  In order to keep that data current, it needs to know when
to remove byte counts that are a week old.  Thus it needs to keep logs
of the last week's worth of messages, at least in byte count form.

Instead of that, you can just make the byte count decay.  Once a day,
a process goes through the byte counts and reduces them.  Remove any
entries are <= 0.  If this decaying byte count is bigger than some
threshold, bounce the message.

I would suggest that the reduction equation be linear: multiply by
some constant between one and zero, and subtract off a fixed amount,
drop the fractional part.  The multiplicative factor, which I would
set between .9 and 1.0, means that an occasional large file could be
sent through without completely eliminating email delivery for a
while.  The subtractive amount cleans out the database more quickly.

Comments?

Eric