Ryan Lackey writes:
1) We don't yet *have* an electronic cash system with sufficient volume to cover this -- you'd want a general-use electronic cash system where purposes like this were a small part, otherwise the billing records show all remailer users.
It's largely a myth that the set of users of remailers is anonymous. Remailer operators collectively know them all; individual operators know a substantial percentage of them if people vary the remailers they use; anyone surveilling the remailer network knows them all. Hiding one's membership in the set of remailer users cannot be a high priority. And there's no need for remailer users to be anonymous, either. Anyone should be proud to be counted as a member of that group. It's no more incriminating than being a subscriber to the cypherpunks mailing list or any of dozens of similar lists. No doubt thousands of people would put their names on the list even if they have no intention of ever using remailers.
3) Ease of use -- it's hard enough to run mixmaster already. The low hanging fruit would be in automating key management, packaging *well* for debian, redhat, etc., and fixing a bunch of the random bugs in mixmaster which cause it to blow up on certain From: addresses. If it were possible to run mixmaster 3 with *no* real user intervention (no need to subscribe to flamey mailing lists, no need to manually fuck with people who change keys, no need to watch a list to edit people's capstrings, etc. -- then more people would run remailers.
Part of the problem has been focus on adding features to mixmaster rather than improving security and reliability. Transparent remixing (where the remailer chooses part of the path for you), support for the old insecure cypherpunk mode, automated flood detection, all add administrative complexity for questionable benefit. With a good high speed connection, floods and such are much less of an issue. Things like remixing should be done by the clients; it was a mistake to put this into the remailer software.
This goes double for clients. In the case of remailers, increasing volume *does* enhance privacy; if we didn't care about volume, we'd just use a bunch of rooted boxes through netcafes to send high-value anonymous messages...remailers are only useful with volume, and legitimate applications make them easier to defend.
Absolutely. For all those people saying, what can I do to support remailers, here's an easy answer: use them. Get a client, figure out how it works, and send an anonymous message or two. It doesn't hurt. Much. You may even find it liberating. Challenge the orthodoxy and start thinking for yourself.
I think the best way to get remailers widely deployed is:
You skipped step 0, which is to inform people of what it is like to run a remailer. It doesn't do anyone any good for remailers to pop up and immediately shut down when the complaints come in. Here's a good litmus test: if you wouldn't be able to spam at reasonably high volumes from your address without getting shut down, you probably shouldn't be trying to run a remailer (unless in middleman mode).
1) Create a version of mixmaster which is much more self-running, at least on UNIX, OSX, and cygwin, and allows cpunks, mixmaster, and maybe future constant-rate or stego or other interesting transports as plugins -- make keying be a policy decision but with the code smart enough to handle updates within authority delegated to it by the operator.
A good idea. See the recent proposal for a P2P style always-connected remailer network which will bypass sendmail and all the other RFC2822 cruft. Plugable transports would be a great way to accomplish this.
3) Promote the remailer and applications which make use of the remailer (there's nothing I've seen, other than pingers and remailer infrastructure, which uses remailers programmatically in some cool way. Some kind of ok-with-high-latency application -- ecash tunneled through remailers? Another blacknet test? An anonymous-only message board? Web publishing? Whatever.
Eric Hughes had a cool idea a while back: encourage CP technologies by allowing them to bypass built-in mailing list latency. Create a CP node which forwards PGP-signed and remailed messages with higher priority than others. Signing up for this node is a way of showing support for freedom enhancing technology.
4) Some kind of internal or external benefits to remailer operators. Something along the lines of "I will throw a party at DefCon with free (heh) ---- and -----s for the first 20 people who can prove control of mixmaster remailer keys which transit test messages I send throughout the year (selected based on normal client criteria, such as uptime, latency, etc.)". Someone could presumably donate money in a similar fashion. This would provide some level of decoupling from "bank accounts of those who sponsor remailers" and "remailer users". ("convince legions of 18-25 year old females that remailer operators are the best in bed" would be ideal, but is probably not going to happen)
Maybe Tim May could donate his Y2K beans and rice as a prize, since he's never been willing to use his millions to subsidize bonuses of this type.
5) Get more companies, universities, and non-profits to run remailers, as they have machines, relatively untouchable network feeds. Why is there no EFF remailer? Why is there no ACLU remailer? Why is there no ZKS remailer? I mainly started the havenco remailer for social and intellectual purposes, but there are slight marketing benefits to it as well. I'm sure people (me. you?) would be willing to provide time to help worthwhile organizations set up remailers. Back in the day big companies would run public ftp sites for the common good; I think any organization dealing with any volume of mail today should feel socially pressured to run a remailer.
Keep in mind that our perception of remailers is at odds with that of the world at large. Fellow travellers like the EFF can't afford to be that closely tied to a technology which most people view as an obnoxious nuisance at best and a terrorist tool at worst.
6) Deal with the spam issue -- integrate something like nilsima into mixmaster directly, none of this procmail hackery (which I haven't bothered to configure myself). This would eliminate "whitelists" and other cruft which decrease the reliability of the remailer network substantially. Doesn't stop mailing list or newsgroup spam, but it's fucking 2001 (almost 2002) -- if you care that much about the 0.1 seconds of time to delete a piece of spam, your list should be filtered, moderated, or posting limited to subscribers only.
Absolutely. Simplicity and reliability have been overlooked as goals for the remailer network. You shouldn't start adding new features until the old ones (like successfully remailing messages without dropping them) work. Nevertheless there is a political over-reaction to commercial spam, and it can be a major source of complaints about the remailer. Per-link hashcash would be a better deterrant than black lists, which ultimately depend on entry remailers to do a favor for exit remailers.
7) Provide a UI which doesn't suck for users -- including better web-based interfaces (perhaps as part of the base distribution?) with anti-spam measures (mixmaster+nilsima may be enough, but "copy this image number down" might be needed.
Split out the client, including web-based clients, from the server. They have different needs. If you want to promote good, reliable servers there is no need to also make them be web clients.
8) Some kind of two-way communications -- which I will happily host, as I'm sure others will as well -- providing remailer-accessed mailboxes, return addresses, etc. Less private, more linkable, but still pretty anonymous, as you could require all the messages to be encrypted (or not), and the initial user-to-mailbox delivery is reliable; even if the remailer network is unreliable, you could do return receipts with your own client such that it will retransmit through the chain of remailers a couple times if need be, until you can guarantee receipt, before deleting from the server. Most of the "antisocial" remailer-facilitated activities are hit-and-run; most of the *good* remailer uses require a persistent identity and two-way communications. (and, paying for a real mailbox is something which is not in the millicent ghetto; $20/year for a mailbox is entirely common, and people might be willing to pay a substantial premium for anonymity)
The Freedom network had the right idea here: pipenet access to an ordinary POP mailbox. If remailers are joined in an always-connected P2P network it could be used as a specialized pipenet for just this purpose. No ZKS anti-abuse nym protocols necessary since exit points would be restricted to the special POP mailboxes.
So, while I'd really like to see ecash, I think remailers need some > other work first, before they could really benefit from the effort > required to create an ecash system from scratch, deploy it, scale it, and then use it for this application. Not that I'm saying an ecash > system isn't worthwhile for its own sake, though :)
Non-monetary ecash does have one advantage over hashcash for proof of work postage: it is transferable. With hashcash, once it's spent, it's gone and can't be reused. With ecash (purchased by hashcash) the payee gets to keep it and can spend it himself in the future. In other words, remailer operators would build up riches in ecash. Now, all it's good for is sending anonymous messages, so they're not going to retire on it. But still this can fund pingers run (or paid for) by the remops themselves. And there could eventually be a secondary market in remailer ecash. Remailer users would seek it as an alternative to hashcash if it were easier to get. They might be willing to perform services in exchange for remailer ecash payment. This could produce some backing for the currency and it might come to be traded even among people who had no desire to use remailers. (Services might be, e.g. ripping a requested copy protected CD via an analog connection, or digitizing a TV show unavailable to the requestor.)