Excerpts from mail: 5-Jan-95 Re: Remailer Abuse db@Tadpole.COM (1180*)

Heh. An anonymous remailer paid for by credit card... there'd have to be an additional level of indirection for it to work, which would make the methods for tracking those who don't pay quite problematic.

Again, this comes down to definitions of anonymity. In this case, if you start from the silly assumption that the anonymous remailer actually keeps records that correlate messages to payment mechanisms, Doug is right, but barely. To break the anonymity, you'd need collusion between the operator of the anonymous remailer AND First Virtual, because the former knows which account sent a message, and the latter knows who that account belongs to. (And before you tell me that this sounds a lot like the Clipper key escrow, I would point out that instead of two "trust us, they're independent" agencies of the US government, in this case we're talking about two independent private companies which are probably in two different countries. For my part, I figure that if the government of Finland and the government of the US can actually agree that it's so important to force the sacrifice of anonymity in a given case that they're both willing to coerce companies under their jurisdiction, they will probably have a very good reason for doing so. Maybe I'm too trusting, though.) Moreover, and perhaps most important, even THIS can only be done if the anonymous mailer keeps records of WHICH account paid for WHICH posting, and if I were to operate a for-pay remailer, I wouldn't do that anyway. It sort of defeats the whole point of the service.

Also, most remailer abuse tends to be of the hit-and-run variety, which is still nicely enabled by FV.

Only if you assume that the same people aren't responsible for multiple hit-and-run attacks. I would tend to assume the opposite. Russ Nelson saw the first point quite clearly, and wrote: Excerpts from mail: 5-Jan-95 Re: Remailer Abuse nelson@crynwr.com (1177)

Sure, I'll know who used it, but I'm not going to keep that information. (Yes, yes, FV says that I have to keep records of who bought what, but I'll label all my information with a random number, that simply says that X bought information worth Y, not *what* information.) And if you don't trust a remailer operator, then you won't use it.

All I'd add here is that the requirement to keep records is one that we have to pass on from the credit card world. If you didn't keep ANY records, my understanding is that all that this would really mean in practice is that there would be an extremely strong presumption AGAINST you in certain dispute-resolution situations. That's just my understanding, however, and it doesn't in any way supersede or supplement our legal terms and conditions, available from fineprint@fv.com. (You should try them, I find them more effective than Sominex.) Excerpts from mail: 5-Jan-95 Re: Remailer Abuse wcs@anchor.ho.att.com (2028)

I'd be worried about a couple of issues - one is just the transaction cost - can you successfully market remailer use at a buck a shot or whatever you'd be charging beyond FV's 29c stamp, or would you have some convenient way to aggregate bill?

Depending on how often you aggregate, you can charge almost any amount. 20 cents might be very reasonable. If you run a cron job once a month to post aggregated billings to anyone who had two or more outstanding uses, you'd make only a small amount on the two-time users, but you'd get serious aggregation from the regular users. (You might also want to bill the really-high-volume users weekly, to prevent them from going into shock at their huge monthly bills.)

Beyond that, though, are some traffic analysis problems - remailers require a fair bit of traffic to be useful, and unless you receive a reasonable amount of encrypted traffic, and support encrypted email for purchasing remailer service and other merchandise, an eavesdropper would have a fairly good source of traffic data on your remailer users, especially since buying and using remailer service requires two messages within an hour or so.

Well, I think low-volume remailers are always a bit vulnerable to traffic analysis attacks, aren't they? One thing you could do is build a variable time-delay into the remailer, to make it harder to correlate messages coming in with those going out. To take paranoia a step further, you could allow people to encrypt their mail TO an anonymous remailer with the remailer's public key, and let the remailer send it out unencrypted. No snooper should be able to correlate the *contents* that way, and it avoids lots of key management problems by only using the remailer's key, not the user's.

An alternative billing mechanism, which wouldn't use Chaum-patented cash, would be to sell a bunch of one-shot random-number tokens. When you sell the tokens, you add them to the database of valid tokens, and when one comes in on a message you delete it. This allows you to sell more than one message or service-period per FV transaction, and separates the purchase and use by a longer time, without adding the need for record-keeping based on the user's ID. It obviously does require encrypted reply messages.

I think this could work quite nicely, at first glance. This is also the kind of service for which you might want to wait until after the "yes" reply to deliver the "goods". My only concern, would be the key management issues, but they might be manageable in this case by using the equivalent of a session key, instead of a permanent personal key. I think this is a promising idea. -- Nathaniel