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.)
