-----BEGIN PGP SIGNED MESSAGE----- Timothy C. May writes:
Isn't this what "alt.anonymous.messages" is all about?
(It's been at my Netcom site for many months now...I don't recall who created it, but it seems to me it was one of us.)
Alas, it is not available at MIT. I'll have to scrounge for a server that carries it (volunteerings of feeds welcome!); Though netcom is our IP provider, I'd rather not get news from them.
Folks spend a lot of time bemoaning the transience of specific instances of remailer nodes: why not turn this into an advantage by architecting a network of system that is resilient against the destruction and/or compromise of individual nodes?
I'm not sure what you mean by this. More remailers are always a good thing, and offshore sites are especially good, but I'm not sure what you mean by your last point.
(Following details of the current system might be wrong. Please correct me where necessary.) My thought is this: If we were to design and implement a system, perhaps a two-tiered system with "fortress" and "intermediary" remailers as has been suggested, it's desirable to build a system that will continue to work even if a large portion of the nodes are removed (whether by Earthquake of Sun Devil). This is the system we'll have to build if we stop resisting the notion that remailers regularly come and go with little warning. The rendezvous problem is not currently addressed in a satisfactory way: premail/remailer-ping, or its equivalent, hardwires in the location of a known set of remailers and finds the subset that corresponds to remailers having a common characteristic (usually just whether they're working reliably or not). That's not a very good approach: a human has to add a new remailer into the "net" by adding it to the systems polled. Not only is the human intervention a Bad Thing, but having a central registry of remailers is bad infrastructure. A more "web-of-trust"-like mechanism is desirable. So, a dispersed view of the remailer net, both entry points and intermediary points, is necessary. In order to build such a system, we must solve the rendezvous problem: how does "premail++" know where to send its mail and how does remailer A know where to find remailer B (and B find exit point C)? This is where my train of thought dovetails with the newsgroup question: bringing a new remailer on line could be achieved by broadcasting a message through a newsgroup specifying the location and type of the remailer. If necessary, one or more pseudonymous automatic testing agents could pick up the message and put the remailer through a barrage of tests, broadcasting a "remailer certification" with a certain duration. "Premail++" and remailers could find their next hop by examining current certifications and choosing one with desired characteristics, scoring by trusted testing agents and other criteria (including the passage of time since the last certification). If an exit-remailer is chosen early in the game, multiple paths to the exit-remailer can be used to improve reliability (exit- remailers would also probably have a shorter cycle of certification). Technically, this is feasible. I could write the code fairly easily (though I'm not offering to do so at this time: if I do, pieces will be offered as fait accompli). My question is whether this strikes anybody else as a desirable design: we would end up with a net of remailers that is fairly resilient and not dependent upon any one list of remailers. If a node goes down, the net adjusts in rather short order and service is not disrupted. This picture needs to be fleshed out a bit more, but I thought I'd bounce this around before solidifying it in any particular way. - -- Todd Masco | "'When _I_ use a word,' Humpty-Dumpty said, in a rather cactus@hks.net | scornful tone, 'it means just what I choose it to mean - cactus@bb.com | neither more nor less.'" - Lewis Carroll - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBLuuBmSoZzwIn1bdtAQEI9QF/fX2LPoUwzlKYJqJ1s0vb/mIX4NzT1jOo UNHdiOYNJ+vgpPQyIZ9OQynMuKfSVgU/ =vn6H -----END PGP SIGNATURE-----