Re: [Asrg] Re: the e-postage argument

On Apr 20, 2004, at 3:56, John R Levine wrote:
> I need to keep rewriting my epostage paper to make the fundamental 
> points
> clearer.  The three big issues are transaction costs, settlements, and
> identity.  Another is that no postage scheme in the history of mankind 
> has
> existed to deter use rather than to pay delivery costs, but let's skip
> that one and decide to innovate.
That last point is merely taking a narrow view of what constitutes a 
"cost". Ultimately, the purpose of communication is delivering a 
message from brain A to brain B. The cognitive cost of doing so is part 
of the total cost, and something which has a definite monetary 
equivalent value--if it didn't, good writing wouldn't be worth 
anything. In other words, the fact that e-mail has to get through the 
spam noise is part of its cost of delivery.
> The transaction cost issue is the simplest: any kind of e-postage 
> system
> is going to need a transaction per message to check the stamps.  
> Spammers
> are going to put bogus e-postage on their mail, and the only way to 
> see if
> an e-stamp is valid is to check with the issuer.  Even if you use a 
> crypto
> signature scheme to see if the stamp is real, you still need to ask 
> issuer
> if it's already been used somewhere else.
No you don't. Public key crypto is your friend. If the digital postage 
cash is minted by one of a number of known sources, you can make an 
initial test for validity by simply checking the signature against the 
list of public keys of recognized mints.
It's fundamentally no different to the way your browser verifies an SSL 
connection by checking the certificate presented by the remote site.
There are some issues around what you do if a mint's private key gets 
compromised, but they're solveable.
> I have yet to see a faintly plausible plan that would build and pay 
> for a transaction system big enough to handle the world's e-mail.  I'm 
> not talking about settlements here, just whether the stamp is OK.  The 
> biggest transaction system to date is the one for Master Card and 
> Visa, and it's both too small and too expensive by several orders of 
> magnitude each.
It's exactly the same problem as checking the signature on this e-mail. 
You seem to be arguing that it's uneconomical to solve. I think the 
people who use S/MIME every day would argue otherwise.
> > You settle at the ISP level ...
> Settlements: You run an ISP, you tell us.  There are something like 
> 5000
> ISPs in the U.S. and probably at least that many outside the U.S.  Are 
> you
> going to send out 5000 checks every month for your settlements?  (Or 
> net
> it out with each, so it's on average only 2500.)  How are you going to
> keep track of whether the other ISPs have paid up, and if they don't, 
> what
> will you do about it?  You can't wave these issues away, these are the
> nuts and bolts that make a payment system work or not, and if you don't
> shut down the deadbeats, the e-postage stops being real money.
My ISP has 3.3 million customers. Surely it's infeasible for them to 
send a bill to every single one of those customers, once every month? 
My god, how could they ever hope to do that, for a sum of money which 
might be as small as $30? Clearly this whole ISP thing is just totally 
impossible.
Come to think of it, the US has around 10,000 banks (or similar savings 
institutions). Is it really feasible that all those banks be somehow 
able to process small monetary transfers between each other, often many 
times a day? Ludicrous!  I mean, anyone could just set up a bank and 
send out fake checks and never pay up, and you'd never be able to do 
anything about it. Clearly checks are utterly impossible, in fact the 
entire banking system must be the product of a deranged imagination.
> If the ISPs do the settlements on behalf of their customers, the ISPs 
> are
> acting as banks, with all of the fraud and default problems that 
> regular
> banks have, and which they spend a lot of money to handle.  Real banks
> handle the clearing problem with centralized clearing systems they all
> join, Mastercard/Visa for credit cards, NYCE, Cirrus, and PLUS for ATM
> transactions, and the Federal Reserve for checks.
However, none of those systems actually use cryptography for security, 
except incidentally for encrypting transmissions. There's no way to 
check the validity of a check or credit card without making a network 
connection, and that's what makes fraud easy and drives up the cost.
If credit card numbers were secured with SSL-like public key 
certificates, you'd wipe out all the current 'small transaction' scams 
involving generation of random credit card numbers for starters. Do the 
same with checks and there goes check fraud.
Sure, you'd still have the occasional Savings & Loan or BCCI scandal, 
but the average day-to-day fraud rate by random criminals would be far 
lower.
> Even worse, what about the ISPs that aren't in the US?  How do you send
> 50 cents to each of five ISPs in Bangladesh?  Credit cards?
The idea that I should be able to phone Bangladesh is ridiculous. I 
mean, how is my 20 cents going to get to the Bangladesh phone company? 
Credit cards?
> Identity: lots of people have pointed out the zombie problem, that
> spammers will hijack Aunt Betsy's computer and charge the postage to 
> her.
> The response I usually hear from epostage enthusiasts is that Aunt 
> Betsy
> won't let the zombies on her PC once she's had to pay a few hundred 
> bucks
> in spam epostage.  Based on my observation of the real world, that's 
> not
> gonna happen.  Every month you see the predictable story about some 
> loser
> whose PC got misconfigured or got a Moldavian dialer installed or
> something, and was shocked to get a thousand dollar phone bill.  Do 
> they
> actually pay the thousand bucks?  Never.  They negotiate it down, stiff
> the phone company, or something.
Have you seen any stories about people who have done that *repeatedly*?

I doubt it, because I expect after the second or third such incident 
they'd find it tough to get the phone company to continue to do 
business with them.
So maybe Aunt Betsy would be unable to get an ISP to do business with 
her, because of her chronic inability to either use a computer safely 
or pay the cost of her own incompetence. In which case, that's her 
problem.
> ISPs would be stuck in a no-win situation where their customers will 
> hate them if they try to collect, and their e-mail peers will hate 
> them if they don't.
One word: Pre-payment.

I purchase $20 of e-postage to last me a few months. If I lose it for 
whatever reason, the ISP doesn't have to spend any money collecting 
anything. Just like if I lose a book of stamps from my wallet or have 
it stolen, the Post Office doesn't have to chase me for the price of a 
book of stamps.
In fact, you even explain the system to the user in exactly those terms.

> Here's a thought experiment: imagine that you run a store in some part 
> of
> the wild west, and 90% of the cash that people offer you to pay for 
> stuff
> is bogus.  How are you going to handle transactions?  How long will you
> spend examining each coin?  Will you refuse to do business with anyone
> who's offered you bogus money?  What about people who've gotten it in
> change somewhere else and didn't notice?  This is the environment
> e-postage has to face, not a little fraud, but vastly more bogus
> transactions (at least attempted ones) than real ones.  I don't know of
> any financial system that works in an environment like that.
That's easy: vending machines in colleges. Tiny transactions, no 
foolproof security, and a population rich in engineers who are short on 
cash and have lots of time for experimentation.
Clearly Coke and Pepsi will never find it cost-effective to put vending 
machines at MIT, for example.
> > It's time to go for an e-postage system that simply reflects the
> > resources being used.
> OK, so build one.  I don't know how to build one where the transaction
> costs aren't 10 times greater than the costs that the transactions are
> supposed to cover, despite a decade of micropayment research, but maybe
> we've overlooked something.
Well, there are David Chaum's papers on the subject for starters. 
Digicash didn't fail because it was technically impossible; it failed 
because it didn't offer compelling benefits to the people who would 
have needed to implement it, the banks and merchants and governments. 
In fact, it had major negatives from their point of view, like offering 
anonymity for customers.

mathew

smime.p7s
Description: S/MIME cryptographic signature