Eric Hughes:
Let's take remailers as an example. One current suggestion is to add some sort of money system to the remailers as a condition of use. This is exactly the wrong priority at the current time. The remailers are already hard enough to use, and adding a payment system on top of that will make them used even less. Making a system harder to use increases the transaction cost.
The current priorities should be to lower these costs. When the remailer system begins to be overloaded, then adding some restriction on use, perhaps by means of payment or a payment analogue, will be warranted, because it will lower overall transaction costs, trading off ease of use for throughput and reliability.
What are some of these costs that should be lowered?
-- Finding out that remailers exist and what they do. build a remailer "who" server into each remailer -- Finding a remailer to use. ditto -- Deciding what remailer to use. ditto (remailer server should list remailer properties like keylength, private?, delay length, chaining?, mixing?, padding?, encryption required? etc) -- Figuring out how to use a particular remailer. standardize remailer help system, standard remailer command format (but not neccessaily the commands themselves) Sorta like an SGML for remailers -- Formatting a message for a remailer. see above -- Receiving mail through a remailer. Get/Creating a nice client. At the moment, 100% of the mail in my mailbox is encrypted. I wrote a script called "deliver" which encrypts incoming mail, then pipes it through procmail/slocal. I modified morepgp and made it a lot more user friendly (and recursive).
Reducing complexity cost: All of this could be lowered by creating an easy-to-use remailer client which is compiled (or perl/tcl interpreted) and installed with every unix out there so it becomes ubiquitous. If someone's machine doesn't have a client, they can telnet to a machine where one is set up (just like gopher, archie, www) by some generous cryptoaltruist. The current remailer solution of putting all of the remailer system complexity on the server side can't make remailers too easy to use. My Extropians list software attempted to make it easy to use by allowing commands to be contained in-band with messages to be posted. It's still too complex for the user who wants hot-key style operation. (which is why I will eventually write a client for it) Once you write a generalized client that can communicate with standardized remailers, you can easily include digicash/postage in the system.
There much more need for improving the ease of use of remailers than for paying for them.
Are you objecting to paying for remailers on a philosophical grounds (anti-property/money)? No one has proposed paying real money for remailer use (although that is a future possibility). There needs to be some way to authenticate remailer users and limit use in a "free" sense (instead of top-down rationing) The best way to do this is to use some form of monetary system.
The less expensive privacy is, the more privacy there will be. Privacy has non-linear benefit; the more that people are private, the better any individual's privacy actually is.
Every standard is enhanced by more people using it. However, this alone can't be a justification for making services into public goods which are free to everyone. If the Detweilers of the world take advantage of totally free remailers, they could end up limiting the privacy for all. The same "free" philosophy has killed many a porno/music/book site (or created absolutely long user queues reminiscent of food lines in the xUSSR) Spamming/Spoofing attacks on remailers must be dealt with. The situation is not helped by either-or logic. We need both ease-of-use and some notion of postage. -Ray -- Ray Cromwell | Engineering is the implementation of science; -- -- rjc@gnu.ai.mit.edu | politics is the implementation of faith. --