-----BEGIN PGP SIGNED MESSAGE----- Mark Terka <werewolf@io.org> writes:
Ok, so what are our options, given that this company seems to think of security in terms of a plastic padlock. From corresponding posts on the list, the only other alternative, Digicash, doesn't seem to be too responsive to anyone's participation right now.
Allow me then to repost this, a summary of how some available payment systems work. It is oriented towards remailers but has info and pointers to several payment systems. - From owner-cypherpunks@toad.com Sat Oct 29 09:35:38 1994 Date: Sat, 29 Oct 1994 09:31:27 -0700 From: Hal <hfinney@shell.portal.com> Message-Id: <199410291631.JAA27105@jobe.shell.portal.com> X-To: cypherpunks@toad.com Subject: Payment systems for remailers This is an edited version of a posting I made to remailer-operators@c2.org, discussing how some of the various payment systems which have recently been introduced on the net might be used to support a for-pay remailer. First I discussed some motivation, such as improving the quality of service and discouraging spam attacks, then this was the part about the various services. If anyone knows of other alternatives please let me know. I know of two systems that are VISA/Mastercard based. One is called First Virtual (http://www.fv.com). They are oriented towards information sales and say that they aren't for service providers, but in practice it looked to me like they could be used for services. When a customer wants to pay, he sends you his FV ID. You send this to FV and they send an email message to the customer asking whether he authorizes the payment. If he says "yes", FV credits your account. You get a check every month. Customers who always say "no" get booted out of the system (as do merchants who submit bogus bills). They charge 29 cents plus 2 percent per transaction, but merchants can batch up multiple orders by a single customer before sending it in. There are a few problems with a system like this, many of which are somewhat generic to our situation. The most fundamental is that we don't know who our customers are much of the time. In fact, the whole point of the remailer network is that we not know that fact for any case except the first hop in the chain. If we required customers to expose their FV account ID at every hop, it would make it a lot easier to track messages through the network (even if the ID's were hidden in the encryption envelope it seems risky). If we then sent a message to FV saying that we needed to charge ID XXX, and FV responds with an email to the person's home address, this offers more possibilities for tracing. One solution would be only to charge on entry into the remailer net. Perhaps remailer operators would even charge each other then, and the first remailer would charge some larger amount to deal with a "typical" chain length? Many interesting possibilities here. Another issue is that the overhead charges by FV would require batching up messages before submitting them. Let me make clear that the batch must consist all of charges to a single user. It doesn't do any good to send one message to FV asking them to please charge a penny to each of 100 VISA accounts. No, you would have to count messages from each user, separately, and when user XXX had sent, say, $1 worth of messages, you could send in the request to FV and get back 70 or so cents. So this adds some overhead and record-keeping that we don't currently have to do, although perhaps it is not so difficult. But it would raise new questions of authenticating FV ID's, and shares some of the negative privacy impacts and message linking issues mentioned above. The other VISA based system is called OpenMarket. I just read about it tonight so I don't know it as well (http://www.openmarket.com). It is pretty tied to the WWW so it would not seem to work for us. Customers get connected to a particular WWW server which authenticates them and charges their VISA card appropriately, then they get redirected to the merchant with some kind of token that says they have paid. The NetBank (email to netbank-intro@agents.com) is a digital-cash like system. Customers get tokens which are basically large secret numbers which have a cash value. They send them to the merchants, and the merchants then send them to the bank which credits their account. The NetBank sends you a check every month. The interesting thing is how customers buy the cash tokens. One way is by connecting to a 900 number with your modem. They charge the customer $10.00 and give him a digital cash token worth that much. Another way is by faxing a check to them. I wasn't clear on how you get the cash token back in that case; I guess they email it to you at an address you specify. From the privacy point of view, these are not that great; 900 numbers have Automatic Number Identification so unless you are willing to tramp out to a pay phone to get your cash then it could be linked to your phone number. And the fax system must have some kind of return address that would link to you. The other problem with NetBank is that the smallest denomination which can be spent is 25 cents. Due to the cash-like nature of the tokens, I don't see a natural way to accumulate several messages into one payment. Maybe we could layer our own low-value digital cash system on top of NetBank, where users could buy our anonymous cash for 25 cents and get enough tokens for 25 messages, then we would settle amongst ourselves (or actually with the anon-mail-token bank). Actually this might help with the privacy problems, too. Anonymous digital cash is heavily patented, though. With a cash-like system, each message would include a numeric token in the header which is the digital cash. The remailer would strip that out and send it in for credit. This is a simple system and could be largely automatic. However there are some tricky issues about cheaters re-using cash. NetBank charges $4 per month, plus, for the 900-number-based cash, 20% off of face value. The last system I'll describe is David Chaum's DigiCash (http://www.digicash.com). Chaum is the inventor of digital cash and he certainly knows his stuff, plus as I said he has the intellectual property pretty well sewed up patent-wise. The DC payment system is also WWW based at present. The customer has to be running a special program on his computer, separate from his web browser. This program holds his digital cash, which is similar conceptually to the NetBank cash but more sophisticated cryptographically. When he wants to buy something, the merchant's web server makes a connection to the customer's DC program, and it transfers the cash to the merchant. DigiCash says they are planning an email based system but for now their emphasis is on the WWW. Right now they are only in beta and not using real money. I don't know when they will be real and email based, and I don't know if they have said what their commission will be. But when this comes up it may be the best approach if small-value transactions can be supported. DigiCash is fully anonymous in the sense that once a customer receives the money, it is "blinded" in a special cryptographic way so that the bank cannot associate it with that customer (and no one else can, either). This kind of anonymity fits in very well with our remailer requirements. Well, I know this is a lot of information to work through, but mostly I want people to be aware of the possibilities. Most of this stuff is very, very new, only weeks old, generally. Probably over the next few months we will see a lot more options appear. I am confident that there will soon be payment systems that would provide the technical basis for fee based remailing. I don't expect anyone to get rich by this, but it might help compensate for the risks we all face, and it might serve to improve the quality of the remailer network. Hal Finney hfinney@shell.portal.com -----BEGIN PGP SIGNATURE----- Version: 2.6 iQBVAwUBLt+fKxnMLJtOy9MBAQG8ZgIAoBMb4Tctn56LUV1RnIkh4ENPYwTVz4Fn b+k2Nl6hPN2UP+llyJHXDS8WTTHUAJ6rzM3oNMDtZcAXRJMBgNmPTg== =hZYK -----END PGP SIGNATURE-----