My newsgroup-RemailerNet ideas seem to be getting mixed reviews, but I think that part of the p roblem is that some people don't understand what I'm trying to accomplish. There are several features I think are extremely desirable in a remailernet infrastructure, which our current infrastructure doesn't accomplish, and which no proposed infrastructure that I've seen accomplishes either. I'm not certain my newsgroup/pinging idea addresses these concerns, either, but I'm going to lay them all out, and y'all can see what you think. These points aren't distinct, I realize. They're all interrelated somewhat. 1) New remailers should be able to enter the "remailernet" easily, and with a minimum of human intervention. If I decide to run a remailer, the infrastructure should provide a way to make it visible to all other particpants in the remailer net, other remailers and users. Whether the other participants make use of it or not, is another question, and would presumably depend on a web-of-trust kind of situation. But currently, someone who wants to stay current with this kind of info basically has to read cypherpunks, and take notes when people announce new remailers. Better, would be if this sort of "new remailer" info could be distributed automatically, to both users and other remailers. 2) Remailers should be able to leave the remailernet without devestating it. If my remailer is temporarily, or permanently, down, the remailernet should route around it. Again, the current way for operators to announce this would basically be to post to cypherpunks list, and maybe alt.security.pgp too. If other remailernet particpants miss the announcement, havok can ensue. If a middle link of your remailer chain is down, all you know is your messages aren't getting to their destination, you won't know which link is down. We shouldn't require all particpants to read cypherpunks religiously, and if an operator isnt' conscientious enough to post to the expected places, it shouldn't be fatal. Both users and remailers should have an automatic way of finding out about down remailers. 3) Remailers themselves should have a way of automatically learning the topography of the remailernet. If we want to form a cohesive black-box remailernet, remailers are going to need this info. Maybe they're sending fake padding between themselves to thwart traffic analysis. Maybe they're encrypting with the key of the next remailer down the line automatically for you. I don't know enough about it to know what methods are best, but it seems probable from discussion that remailers are going to need to do something that requires knowing about all the other remailers, and their PGP keys and such. 4) Users should have a way of learning the topography of the remailernet too. A way which doesn't require so much human intervention. I should be able to tell my software "send an anon message to X, put 10 links in the remailer chain," and it will do it. To use the remailer net, I shouldn't need to read cypherpunks in order to keep track of all various remailers, and which are up, and which are down. My software should do that for me. And again, your software doesn't need to use all the remailers that it knows about, it can rely on web-of-trust based on PGP signatures and such. [Although I'm not certain this is neccesary, as I've come to the same conclusion as Hal Finney: as long as you've got one (or maybe two) trustworthy remailers in the chain, you are pretty much okay. Although Jim Dixon points out that a concerted effort by the TLAs could make even finding one trustworthy remailer a serious chore. But this is an implementation problem; we're talking theory here at the moment.] 5) No one entity participating in the remailer net structure should be able to compromise the security of the net acting alone. For example, An "evil remai ler" operating solely for the purpose of compromising the remailernet shouldn't be fatal. This is a matter of degree to some extent: if everyone but you is "evil", you're going to be out of luck in just about any system. But the more robust the infrastructure is, the more evil participants it can handle before it cracks, the better. The current remailer net actually fulfills this requirement fairly well, but it's an important one, and worth noting anyhow. Now I think the infrastructure I've proposed that uses a newsgroup, as well as a pinging mechanism, fulfills all these requirements. But I'm not going to try to defend it now, instead, what do you all think about those requirements? Are they all in fact neccesary? Or desirable? Are there any more that should be added? Can you think of any infrastructure systems that might fill some or all of them?