: Still, though, I think this would do more harm than good. I get about : 20 to 40 messages a day through my remailer, and only 5 or 10 of those are : encrypted. Switching to a policy that would require chaining and encrypt- : ing to make it useful would make it a lot harder to use the remailer. If Agreed, but it would also force us to get off our butts and make integrated remailer-aware mailers work properly, as opposed to the broken kludges we have at the moment. In the long term it would be for the better. (Every single time I've tried anything fancy with chaining and encryption, it hasn't been delivered. And I don't consider myself incompetant.) : The other problem I see with Graham's idea is that I'm not sure the : technology is there to provide good security in the face of this much : information. Not many of the remailers add delay, and a lot of people don't : like it when they do. In that case it may be easy to figure out what Again, fixing this up would be for the better good. You can just imagine that the FBI is already watching all remailers closely under arm-twisting from the Software Publishers Association, not to mention the NSA doing likewise for their own reasons. I think we *should* force ourseles to make traffic analysis visibly impossible. If we can crack an anon posting path with the same information available to an attacker who can monitor all the lines, our system is broken. We should put it up for peer-group testing just like a new encryption algorithm. I believe the security of current remailers is a joke against a real attack. It's *only* good enough to hide identity from other usenet readers. We might as well all use only one-hop remailers and stop kidding ourselves that the multi-hop stuff does any good at all. (I don't believe the anti-traffic analysis support of the current remailers is any good, which is why any postings I've made through remailers have been single-hop in clear. I just don't post anything that would get me in legal trouble. OK, maybe a couple of posts I've made would be personally embarrassing if I were outed, but I wouldn't be by any LEAs that were watching. They'd just be able to use logged postings in criminal cases) : path even a chained encrypted message took. Even the delaying remailers, : if they published message sizes, would usually reveal their in-to-out : correspondance. So I think it is premature to do this. Until we have : remailers which can support cryptographically strong message padding : with standard message sizes, running on un-hackable systems with delays : and batching to confuse the in-out relationships, it would be counter- : productive to do what Graham suggests. Precisely my point. Except I see it the other way - as long as we're not forced to implement these measures properly, they'll never happen. : service it's hard to know what features to provide. In particular, if : cleartext output is prevented, how much does that impair the usefulness of : the network? My instinct is that it hurts a lot, although it would be nice : for the operators since it would eliminate most sources of complaints. I meant that cleartext *input* should be prevented. Cleartext output however can be 'outed' in accordance with policy, even if it's personal mail. Also it can be silently dropped on the floor by the last-hop admin without any comeback, for whatever egregious reason he chooses, or even randomly. It's up to the sender to pick a route that works. If some remailer admin (like JGdeA, or was it John Stanley?) choses to allow M.M.F postings, then he can take the heat for them personally. It's impossible to tell an email recipient apart from a mail to news gateway, so we can't enforce encrypted output only, if we allow posting. However, the 'outing' policy makes it in people's best interests to encrypt to the destination user if they can. Unencrypted *mail* as well as news is also fair game for the last-hop remailer admin to delete on his personal whim. G PS When I say we should out all information, I'm only talking about information that's visible going in and out. If we ever get my earlier idea of chained encrypted reply-addresses to work, with time-sensitive keys that are deleted after a few days, I'm not suggesting publishing those keys. Certainly, we should assume that a few sites will be broken into, or even many sites, but as long as one site remains uncompromised, there's a strong link in the chain that holds up the entire chain.