Re: Pay per use remailers and remailer reliability tracking.
As much as I love the idea of using electronic cash for remailers, given the current state of things, I think it's not the first thing which should be done for remailers. 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. (unless you used a system like hashcash, which will eliminate spam, but not compensate remailer operators) 2) Remailed messages would fall into the "millicent ghetto" -- how much do you think messages will cost? If the goal is ecash, why not focus on higher-value but clear market-demand apps? If the goal is improving remailers, there are some other things which can be done first (and which are essential steps to an ecash based remailer anyway). If the goal is actually ecash-based remailers just as a cool thing, then please do the other fixes first anyway :) 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. 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. There's certainly a need to compensate remailer operators, but the $10/month or so a remailer network would likely provide through ecash is probably not the way to do it. What does it cost to run a remailer: * A box (pretty low spec; mine is a 533Mhz celeron and does other stuff too, and has never had a problem) * Reasonable network connectivity (56Kbps fulltime, DSL, leased...maybe moving on to DSL or leased at a minimum for interesting stuff) * Some level of agility or fault-tolerance on the link, so you can operate in the face of complaints * A "fuck the law" attitude (.45s or J.D. optional) What do remailer operators want: * Ego boost * "Doing something cool" * Social respect from peers. * Low overhead and hassle * Entertainment (I *love* reading abuse@remailer.havenco.com) * Personal use of remailer for nefarious purposes (freedom of anonymity only truly belongs to he who owns the anonymizer) I think the best way to get remailers widely deployed is: 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. 2) Make it easy to install a remailer; "apt-get install mixmaster" and maybe a few questions, all of which should have sensible defaults, so you can just hold down return and get a working, productive (if not optimal) remailer. 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. 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) 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. 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. 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. 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) 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 :) -- Ryan Lackey [RL7618 RL5931-RIPE] ryan@havenco.com CTO and Co-founder, HavenCo Ltd. +44 7970 633 277 the free world just milliseconds away http://www.havenco.com/ OpenPGP 4096: B8B8 3D95 F940 9760 C64B DE90 07AD BE07 D2E0 301F
At 11:52 PM 12/20/2001 +0000, Ryan Lackey wrote:
As much as I love the idea of using electronic cash for remailers, given the current state of things, I think it's not the first thing which should be done for remailers.
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. (unless you used a system like hashcash, which will eliminate spam, but not compensate remailer operators)
2) Remailed messages would fall into the "millicent ghetto" -- how much do you think messages will cost? If the goal is ecash, why not focus on higher-value but clear market-demand apps? If the goal is improving remailers, there are some other things which can be done first (and which are essential steps to an ecash based remailer anyway). If the goal is actually ecash-based remailers just as a cool thing, then please do the other fixes first anyway :)
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.
I don't run a mixmaster because: - its not been easy to get running - it uses SMTP ports which are filtered on my AT&T cable system. The remailer reference lists need to include port number references so users on these "restricted" ISPs can participate. Since the traffic is encrypted it might make sense for operators to choose port numbers used by P2P applications which currently encrypt traffic (I believe Morpheus does). - it didn't run under Windows (until the other day)
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.
There needs to be an automated way to anonymously and securely determine if your messages have gotten stuck at a particular remailer.
There's certainly a need to compensate remailer operators, but the $10/month or so a remailer network would likely provide through ecash is probably not the way to do it. What does it cost to run a remailer:
* A box (pretty low spec; mine is a 533Mhz celeron and does other stuff too, and has never had a problem) * Reasonable network connectivity (56Kbps fulltime, DSL, leased...maybe moving on to DSL or leased at a minimum for interesting stuff) * Some level of agility or fault-tolerance on the link, so you can operate in the face of complaints * A "fuck the law" attitude (.45s or J.D. optional)
What do remailer operators want: * Ego boost * "Doing something cool" * Social respect from peers. * Low overhead and hassle * Entertainment (I *love* reading abuse@remailer.havenco.com) * Personal use of remailer for nefarious purposes (freedom of anonymity only truly belongs to he who owns the anonymizer)
I think the best way to get remailers widely deployed is:
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.
2) Make it easy to install a remailer; "apt-get install mixmaster" and maybe a few questions, all of which should have sensible defaults, so you can just hold down return and get a working, productive (if not optimal) remailer.
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.
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)
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.
I won't run an exit remailer because of the obvious risks Does Ian G's Hotmail exit code still work? Is this practical?
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.
The only client I frequently used was Geoff Keating's Java applet. It was excellent and simple. Has anyone looked into freshening it up? steve
Quoting Steve Schear <schear@lvcm.com>:
I don't run a mixmaster because: - its not been easy to get running - it uses SMTP ports which are filtered on my AT&T cable system. The remailer reference lists need to include port number references so users on these "restricted" ISPs can participate. Since the traffic is encrypted it might make sense for operators to choose port numbers used by P2P applications which currently encrypt traffic (I believe Morpheus does). - it didn't run under Windows (until the other day)
[admittedly, I'm very biased, since I have more of a network engineering/admin point of view than a normal end-user cypherpunk point of view] I'm wary of doing things which violate internet standards and generally complicate application design to support: 1) Windows users trying to run servers 2) People running reliable servers on filtered networks (just get a tunnel if you really care) I don't see there being a huge need for middleman/remix-only nodes. There is a huge need for well-configured, production-grade exit hosts with testicular fortitude and a bad attitude. Are there *any* documented cases of people subpoenaing more than one layer deep in a remailer net? Or even actively fucking with a single remailer who simply says "I keep no logs" successfully enough to do any more than shut him down? (mixmaster, not penet) Things like the hotmail exit code are foiled these days by the "prove you are a real human or a turing-test-complete AI to open an account" Relying on services which are in violation of terms of service (running a remailing server on a consumer dialup or cablemodem with a no-servers policy, abusing stupid web email providers to take the heat) is not a good way for high-visibility, high-abuse postions of the network to operate, if reliability is key (as it is for non-abusive remailer users). Until there is evidence otherwise, I think 5-10 well-administered, professionally maintained remailers, run by reasonably well known organizations, with sufficient legal firepower to defend themselves, running a codebase which is as reliable as a standard MTA, with best-efforts spam and abuse prevention, would provide a better service to users than 100 99% reliable remailers running on cablemodems which can be incapacitated by a single email to noc@home.net or blown power supply or whatever. Simultaneously raise the bar in some ways (require better network, maintenance, etc.) but lower it in the ways which influence TCO for a professional organization (install and maintenance admin time). Provide a way to inject messages into the system without identifying the user as "member of the set of remailer users"; put up a web interface accessible via a quality anonymizing proxy, or pick up encrypted messages from USENET, or encourage dummy traffic from end users (put a nice web anonymizer and/or SSL web server with general-interest content right next to the remailer, ideally, for plausible deniability, and use JS or java or something so normal browsing sessions and remailer-interaction sessions are similar).
There needs to be an automated way to anonymously and securely determine if your messages have gotten stuck at a particular remailer.
Given the level of latency and standard deviation for messages, I'm not sure if this would provide a reasonable level of quality of service, using today's remailer population. -- Ryan Lackey [RL7618 RL5931-RIPE] ryan@havenco.com CTO and Co-founder, HavenCo Ltd. +44 7970 633 277 the free world just milliseconds away http://www.havenco.com/ OpenPGP 4096: B8B8 3D95 F940 9760 C64B DE90 07AD BE07 D2E0 301F
At 06:54 AM 12/21/2001 +0000, you wrote:
Quoting Steve Schear <schear@lvcm.com>:
I don't run a mixmaster because: - its not been easy to get running - it uses SMTP ports which are filtered on my AT&T cable system. The remailer reference lists need to include port number references so
users on
these "restricted" ISPs can participate. Since the traffic is encrypted it might make sense for operators to choose port numbers used by P2P applications which currently encrypt traffic (I believe Morpheus does). - it didn't run under Windows (until the other day)
[admittedly, I'm very biased, since I have more of a network engineering/admin point of view than a normal end-user cypherpunk point of view]
I'm wary of doing things which violate internet standards and generally complicate application design to support: 1) Windows users trying to run servers
You must mean non-commercial users since substantial number, probably a majority of commercial servers run this crud.
2) People running reliable servers on filtered networks (just get a tunnel if you really care)
Are there good free one's?
I don't see there being a huge need for middleman/remix-only nodes.
Why?
There is a huge need for well-configured, production-grade exit hosts with testicular fortitude and a bad attitude.
But these are likely to be the most difficult to find and persist. I think its a bad idea to hinge remailer network improvements on the participation of deep pocket parties who need convincing that this is a ideological fight they should take on and risk their resources and public image upon.
Things like the hotmail exit code are foiled these days by the "prove you are a real human or a turing-test-complete AI to open an account"
I'll look into this and report.
Relying on services which are in violation of terms of service (running a remailing server on a consumer dialup or cablemodem with a no-servers policy, abusing stupid web email providers to take the heat) is not a good way for high-visibility, high-abuse postions of the network to operate, if reliability is key (as it is for non-abusive remailer users).
These restrictive ISP policies are almost always aimed at web hosting and mail and rarely against other ports or services (e.g., P2P) which are major driving forces for consumers purchasing broadband connections. As for the judgement of whether something is wise I would love the remailer network to work as even as well as Gnutella or Freenet.
Until there is evidence otherwise, I think 5-10 well-administered, professionally maintained remailers, run by reasonably well known organizations, with sufficient legal firepower to defend themselves, running a codebase which is as reliable as a standard MTA, with best-efforts spam and abuse prevention, would provide a better service to users than 100 99% reliable remailers running on cablemodems which can be incapacitated by a single email to noc@home.net or blown power supply or whatever.
I see no need to follow only one path which might become a dead end.
Simultaneously raise the bar in some ways (require better network, maintenance, etc.) but lower it in the ways which influence TCO for a professional organization (install and maintenance admin time).
I think architectures which lower the bar should be equally be explored. Alternatives are the life blood of any business strategy. Commitment to a single avenue increases risks.
Provide a way to inject messages into the system without identifying the user as "member of the set of remailer users"; put up a web interface accessible via a quality anonymizing proxy, or pick up encrypted messages from USENET, or encourage dummy traffic from end users (put a nice web anonymizer and/or SSL web server with general-interest content right next to the remailer, ideally, for plausible deniability, and use JS or java or something so normal browsing sessions and remailer-interaction sessions are similar).
Excellent.
There needs to be an automated way to anonymously and securely determine if your messages have gotten stuck at a particular remailer.
If clients generate message digests for each link in the daisy chain then the Web interface to the remailers could enable automated checking whether a message was received and successfully processed by each remailer. Provacy could be maintained by having the remailer response include all MDs for some client selected/fixed window.
Given the level of latency and standard deviation for messages, I'm not sure if this would provide a reasonable level of quality of service, using today's remailer population.
Well certainly the few brave operators we currently have. steve
participants (2)
-
Ryan Lackey
-
Steve Schear