Re: "bomb me" traffic
Greg Broiles offered, "I'm sure that the good intentions are appreciated, but I don't see how traffic which is predictable, both in terms of size (~ 45K) and timing (every morning at X:00 AM) is going to make the task of traffic analysis more difficult." What I wrote was a bit misleading. I meant to say the 6-12 rounds in the morning (these days down to ~6) were the MAXIMUM traffic load I expected to send out at once. Given my sleep cycle, this is NOT predictably X:00 AM. I have a convenient internet link on a PowerBook on my desk for which I am logged in most of the day, at least in the background of the Mac Finder. So throughout the day I will get more requests and send off the five mails. The sizes vary from 18K to 46K and are being sent chained between 2 remailers selected at random, including the possibility of those two being the same remailer. I am also sending out a short (but I could make it longer or even of random length if I learn some more Unix/perl) "Ping" through all the mailers on my list a few times a day. I even made a "SuperPing" commands script which sends the short message through all the possible sets of two chained remailers to check the links BETWEEN remailers. I do not do this in both directions; only Me->A->B->Me, not Me->B->A->Me also. Last night the pmantis->hfinney link was not pinging but pmantis and hfinney themselves pinged fine. I need to play more, and recheck my "script" before I comment on the reliability of those remailer-remailer links though. So throughout the day, as especially when I (and thus others) have free time, I will be sending quite a few messages with sizes 18-46K through two random remailers each. It seems to WORK, which is what matters to me. It seems this, in whatever small amount, WILL make traffic analysis more difficult. "Further, the characteristics which have led some remailers to be considered unsuitable for the current project make them stronger, in terms of resistance to traffic analysis - e.g., erratic (or slow) throughput, and loss of "Subject:" lines." I understand this and agree with you completeley. I am considering using those remailers too, as I have already included a header telling people that the pieces are EXPECTED to arrive erraticallly over a day's time. However, I think added delays should eventually involve a few SECONDS, not a few hours. This isn't the fucking postal service I'm trying to use. I like the speed of internet e-mail. Stripping subject headers should be left up to the user of the remailer and is trivial to leave out. Such delays make it impossible to say, cooperate in a timeley manner on this or other mailing lists, or on Usenet. Such is anon.penet.fi's delays, and those of the slow remailers. When ONE e-mail takes upwards of a DAY to arrive, or even a few hours, I just can't carry out my plans for world domination with my co-conspirators ;-). Adding multi-hour delays to my e-mail is just too primative. E-mail is replacing the telephone for many uses so if the remailers ever expect to gain a large base of users, they need to be FUN, and delays are not. Gaining a large number of daily users is the long term solution to traffic analysis worries, but adding hours of delays COMPARED with other fast remailers will make people avoid those remailers. -Xenon
I even made a "SuperPing" commands script which sends the short message through all the possible sets of two chained remailers to check the links BETWEEN remailers.
No *wonder* I've seen 66 messages since midnight. Can't explain jarthur's apparent tendency to introduce random delays. Maybe the messages are cooling their heels on the VMS gateway -- it's been delaying incoming mail the past few days. I'm not inclined to worry about it, since it helps to muddle traffic analysis a bit. Eli ebrandt@jarthur.claremont.edu
participants (2)
-
Eli Brandt -
nobody@soda.berkeley.edu