Schneier on Security
A blog covering security and security technology.
« Sometimes it Is a Bomb |
| Quantum Computation Research Center in Singapore »
May 10, 2007
1933 Anti-Spam Doorbell
Here's a great description of an anti-spam doorbell from 1933. A visitor had to deposit a dime into a slot to make the doorbell ring. If the homeowner appreciated the visit, he would return the dime. Otherwise, the dime became the cost of disturbing the homeowner.
This kind of system has been proposed for e-mail as well: the sender has to pay the receiver -- or someone else in the system -- a nominal amount for each e-mail sent. This money is returned if the e-mail is wanted, and forfeited if it is spam. The result would be to raise the cost of sending spam to the point where it is uneconomical.
I think it's worth comparing the two systems -- the doorbell system and the e-mail system -- to demonstrate why it won't work for spam.
The doorbell system fails for three reasons: the percentage of annoying visitors is small enough to make the system largely unnecessary, visitors don't generally have dimes on them (presumably fixable if the system becomes ubiquitous), and it's too easy to successfully bypass the system by knocking (not true for an apartment building).
The anti-spam system doesn't suffer from the first two problems: spam is an enormous percentage of total e-mail, and an automated accounting system makes the financial mechanics easy. But the anti-spam system is too easy to bypass, and it's too easy to hack. And once you set up a financial system, you're simply inviting hacks.
The anti-spam system fails because spammers don't have to send e-mail directly -- they can take over innocent computers and send it from them. So it's the people whose computers have been hacked into, victims in their own right, who will end up paying for spam. This risk can be limited by letting people put an upper limit on the money in their accounts, but it is still serious.
And criminals can exploit the system in the other direction, too. They could hack into innocent computers and have them send "spam" to their email addresses, collecting money in the process.
Trying to impose some sort of economic penalty on unwanted e-mail is a good idea, but it won't work unless the endpoints are trusted. And we're nowhere near that trust today.
Posted on May 10, 2007 at 5:57 AM
• 56 Comments
To receive these entries once a month by e-mail, sign up for the Crypto-Gram Newsletter.
There are other ways to change the economics of spam, for example duping the spammer into a time wasting exchange of emails by pretending to be interested. The Spamlet system from the U. of Illinois at Chicago AI lab does this. (http://www.realtime-websecurity.com/podcast/2007/04/5_new_antispam_techniques_prom.html)
Actually, both of the problems you list are actually features. They increase the cost of having an insecure computer on the net. As long as the maximum loss is reasonable, this is a benefit.
Richard Braakman: If we're to add a financial cost for having an insecure computer on the net, can a user reasonably collect from their security software provider if they've installed all updates and are paying these fees anyway? (EULAs being what they are, it might be difficult to enforce, but as a matter of fairness, if I'm paying you for security you don't provide, at minimum I should be able to recover what I've paid you.) Also, that's one more thing that would be trivial for careless people from well-to-do families, and a real problem for working-class people who can barely afford to get online, or libraries that want to provide access but can't afford a staffer to guard the machines every minute.
On top of those good points, there's a further problem; I wouldn't call the financial mechanics of an anti-spam payment infrastructure "easy".
A micropayment system that can handle the current scale of SMTP email would need to be of hitherto-unprecedented scale, dwarfing all other payment infrastructures seen to date, including the current credit-card infrastructure. (see John Levine's paper on the subject: http://www.taugh.com/epostage.pdf )
I'm with Richard, if doing this makes the cost of having an insecure computer rise, people will start to insist that their vendors write more secure systems.
There's currently very little incentive for someone to secure their system at the moment, which is why so many systems are part of botnets. If we can give people a reason to secure their system, they'll do so. (Like you keep mentioning with banks and fraud - as long as banks are not liable for the cost of fraud, they won't bother to do anything to combat it.)
But it might be difficult to fine people for "having an unsecured computer on the internet" - that's a little vague, and just having an unsecured computer is not a problem in itself. If we link payments to actions that cause problems, e.g. sending spam, then that would probably be more politically acceptable.
For people with insecure computers that have been taken over and are causing harm, the fines/payments levied against them would give them an incentive to either secure their system, or demand that their vendor secures their system, or move to a different system that is already more secure than the one they're currently using.
As a result, the number of 0wned computers might actually fall, and less spam would get sent. Or if it was sent, it would be send more centrally, making it easier to track down.
You have forgotten one important point,
Email is relativly instant financial transactions are not, are people going to wait for their EMail to clear payment?
No mater how you cut and slice the rest of the security issues it takes time to deal with money and the current back end systems are not at all close to being up to the job (the nearest is telcos and SMS).
And as you have pointed out in the past the financial organisations tend to externalise as many costs as they can.
If you assume a simple pre-pay system where you buy a token (E-Stamp) from a "trusted supplier" (if it is ever possible to get one). How will these "E-Stamps" work...
Lets assume that they are infact a digital cert, then there is the huge cost in processing power alone of just checking the cert for a large site with hundreds of Email accounts. Unlike an E-Store the size of the transactions is not likley to pay a return on investment before the equipment becomes obsoleat.
Then assuming that the cert is valid how do you stop double usage by the sender?
There are two basic ways either an online or offline system.
If it is an online system (the simplest to envisage) you then have all the overhead of sending the cert off to the issuing organisation and waiting for a response from them. The issuing organisation has to pay for the required infrestructure to support this, the faster it works the higher the price. So in a competative market I cannot realy see it happening this way.
This leaves an offline system and nobody has yet come up with a satisfactory system that is fraud proof (remember a SPAMER is unlikly to care if they are caught double issuing if the message gets through 10% or more of the time).
Then you need to have a reconciliation process to move small amounts of money around on the thousands of millions of EMail messages that will be sent in a day. How much is this going to cost to set up, and who will pay?
Finaly just to "drive a nail in the coffin" of the idea we are starting to see the equivalent of spam being sent out as SMS messages to peoples phones.
Unless fraudulent sending an SMS incures a cost to the sender. If this cost is not detering the SPAM sender do you realy think a charge per Email will actually work either?
Basicaly the whole idea of a payment system to stop spam is a real non starter. This however will not stop the idea being talked to death in the same way as PKI has largly been.
What if the email accounts that people used had a capped variable rate they could sent email at? Lets say you could send an email copied to as many people as you wanted, but you can only send email every 3 minutes, and if you send emails in quick succession, the number of CCs you can attach goes down. That would limit the exposure to end user fraud quite a bit. Don't forget, we're probably talking about less than a cent to sent 1000 emails in a day. It's when you hit 3 million that it starts to add up.
Big corporate mailers (like tickle or tigerdirect who have spam "newsletters" you can unsubscribe from) would have a parallel system in place where they would be able to send as many emails as they want, but they would still have to pay the door fee.
If the "money" can take the form of CPU cycles, you get Hash Cash: ttp://www.hashcash.org/
The sender proves that his CPU took some time (parameterizable) before sending the email, while the recipient can verify this almost instantaneously.
The question is: Is it enough to make spamming uneconomical?
Richard is exactly right: making it costly for the "victim" of a computer takeover is an added benefit of this plan.
Bruce, you've been saying for years that the cost of insecurity needs to be incorporated into the insecure actions, rather than pushed to other players. This would be one way to do that. And there are two other aspects of sender-pays email that may mitigate your concerns:
1. Most ISPs would pick a reasonable maximum outgoing-mail-per-unit-time for their subscribers, to limit the financial damage if their computer is taken over remotely (or locally: an angry teenager sending himself 10,000 emails from mom's computer, at a nickel apiece, is another attack vector).
2. A market for computer insurance could finally become viable, once there is the potential for a compromised computer costing its owner money. And, of course, if sending mail on a Windows machine now costs consumers $10/month more than OS X or Linux, that is a good thing, since it reflects (some of the) actual costs.
The endpoints don't have to be trusted; the endpoints of email will never be trusted by all parties. The point is to shift costs from the victims back to the parties who bear some responsibility for poor security, and let the market sort it out.
"Actually, both of the problems you list are actually features. They increase the cost of having an insecure computer on the net. As long as the maximum loss is reasonable, this is a benefit."
In a sense, you're right, but I don't know if the mechanism will work properly. Consider the average home user: my mother. Right now she doesn't really care if her computer is used to send spam, and she doesn't know how to prevent it if she wanted to. Under this pay system, she's going to be surprised by a large bill at some point -- when her computer is hacked to send spam. The question is: can we really hold her to the charge, and force her to upgrade her security? I don't know if we can.
"There are other ways to change the economics of spam, for example duping the spammer into a time wasting exchange of emails by pretending to be interested."
Right. It's the same economic change, only using a different mechanism.
"Email is relativly instant financial transactions are not, are people going to wait for their EMail to clear payment?"
Good point. There will have to be some mechanism to deal with this.
If "the endpoints are trusted", we've solved the problem anyways, and won't need micropayments to stop spam.
Don't forget, most spam is selling a product and that means there's someone to levy the charges against even if the spam is being sent through hijacked personal computers. You don't have to charge Jim Homeowner because his hijacked PC just sent 10 million Vi*gra! spams, you go after the business being advertised and they'll reveal the spammer real quick to avoid paying.
> The question is: can we really hold her to the charge, and force her to upgrade her security? >I don't know if we can.
Well, we don't want to immediately and out of the blue hit her with a giant bill. But that doesn't mean we can't have a good transition, for instance by having the first three months of 'billing' be 'for information only' rather than payable bills.
I mean, it's not like we can put in a pay-for-email system next month or anything. It's going to need enough transition time to be able to warn people, and give them a chance to secure things.
It's people whose home computers are connected to the Internet who should be posting a bond, with their ISPs. And if their box gets recruited into a botnet, the bond should be forfeit.
@Carlo: Forfeit to whom? And when is this determined? All you've done with a bond-posting system is enact the attention-bond system but forced everyone to pay in advance. Not very economically efficient.
I believe that anyone should be free to wall off their own portion of the net with attention bonds or anything else, but I wish they wouldn't try to rope me in too.
I like the idea of a "Velocity-Limited" email system. That sounds like it could be implemented fairly simply for the vast majority of computer-users (via HotMail/ MSN/AOL/Yahoo/Google). The user doesn't even have to be particularly aware of it - if several messages are sent too quickly, just put the "excesses" in a queue, to send later.
The problem, of course, is "private" email systems. Not only corporate POP/MAPI servers, but 'Bot servers (there's no reason a hijacked computer couldn't be made to run an email server). If we had some sort of mandatory server-registry, with an associated nominal cost (that reflected the allowed message-volume), then this might work. No registration, no eMail acceptance/delivery from other systems.
Of course, this would required significant changes to one of the most widely-deployed systems on the 'Net, and would initially cause all kinds of problems.
The simple solution is to report all spammers, either through something like spamcop, or gmail's notification that this is spam or pshing. Secondly, delete all spam without opening.
As long as no one replies to, or responds by purchasing spammer's products there is no economy in spam.
The problem with the doorbell idea is that it has a 'backdoor'. What's to stop someone from knocking?
"What if the email accounts that people used had a capped variable rate they could sent email at?"
Where do you ensure this? Of course, we can't trust the MUA to limit email sending, and so it'd have to be done on the SMTP server level. But how does the SMTP server know who's who? IP addresses doesn't work (multiple people behind a NAT router), and who the email's claimed as being from isn't useful either (trivially spoofed). Once you get down to SMTP, as it's currently incarnated, rate-limiting is basically impossible.
Also, what about legitimately large-group distribution lists? I don't see why someone sending an email to the 50 people in their family should have to pay $5.00 for it, or hundreds for people legitimately posting to internet mailing lists with thousands of people on it.
This could be made to work if the charges were done at ISP level.
The ISP changes the sending ISP 1 cent for each mail received and refunds the sending ISP 1 cent for each mail that passes the spam filter and/or is not reported by the end user as spam.
This would give ISPs a tremendous incentive to detect spammers and botnets among thier users.
The payments infrastructure -- a clearing system between some 10,000 ISPs -- while not trivial is a lot more do-able than a clearing system involving millions of end users.
So, if you wanted to redesign e-mail delivery to control spam, what would you need to do? Would you have to give up the ability to send anonymous e-mail? What sorts of flexibility would you lose?
I can't think of a way to eliminate it completely, but I can think of a few technical (rather than, say, legal) ways to reduce it. But everything I've been able to think of so far has side effects.
For instance, you might require each message to bear a digital signature, which pushes the authentication problem one step closer to the user, but it also does away with anonymous messages.
Or you might use Supersnail's approach, but going that route might also create an incentive for Google and Yahoo to shut down their SMTP servers because each outgoing message requires them to commit a penny to the system for a period of time, which means at any given time they'd have to float quite a lot of cash, and ad revenues might not give them the spare cash to do that. (It might also give the receiving ISP an incentive to drag its feet on refunding the money in order to collect the interest on that money, which would give a boost to those ISPs that receive more e-mail than they send.)
The solution is to increase not the financial cost, but the computational cost. It will directly decrease the amount of spam and also act as a signal to the zombie owner that it's time to reformat that Windows machine.
Of course, since system like PGP decentralized keyservers have never caught on, it's politically difficult. If we could get critical mass going, I'd dump all unsigned mail. Instead, we get this crap from commercial authenticators which will never be financially feasible for consumer use.
> But how does the SMTP server know who's who?
By SMTP authentication, of course; see RFC 2554. When the user clicks "send", his MUA authenticates to his ISP's MTA.
> [SMTP] rate-limiting is basically impossible.
BS. I operate the spam defenses where I work. Part of their repertoire includes rate limiting, in which IP addresses deemed "suspicious" (by numerous criteria), are limited in the number of recipients they are able to submit. This is done by rejecting each RCPT TO: in excess of the limit with a 452 error, forcing the sender to try it again later. This mechanism could be adapted to enforce rate limiting on customers submitting mail to their ISPs.
> I don't see why someone sending an email to the 50 people in their family should have to pay $5.00 for it
ISPs could have rate plans similar to cell phone companies: you pay $X/month and get the first Y recipients as part of the deal, or maybe a maximum rate of Y recipients/hour. In excess of that, you pay $Z for each additional recipient (Z might be less than 1). You either tack the charges onto next month's bill, or you start enforcing the rate limit and require the user to visit a web page in order to pre-pay. Basil's idea would require the latter.
> people legitimately posting to internet mailing lists with thousands of people on it
Such a message would only have one initial recipient on it: the list address. That's all the originating ISP would see and therefore all it would bill for.
The solution to the email spam problem is to make it more difficult to set up a server to send email from. We have to let SMTP die and move on to a protocol that allows us to authenticate the sending server (probably could be done with SSL certificates). If a simple security certificate was required to be a trusted outgoing email server, then the difficulty of setting up a botnet to send email from becomes much harder. The easiest way would be for the spammer to actually hack email accounts to send from (it wouldn't neccessarily mean they'd have to hack the computer owner's email account, but they would need one somewhere). The harder way would be to set up the bot as an authenticated server, but I think aquirering a certificate for each bot in the net would incur more cost and risk than the spammer could tolerate. The problem with this system is that it requires that all sending servers use the new protocol, otherwise we still need to rely on the old protocol to receive some mail and the spammers will continue to utilize it. I think the way to start is for major ISPs to develop and implement such a protocol and use it where availible. Gradually as more and more legitimate mail comes over the new protocol, insecure mail would be trusted less. Eventually one could offer email service that only accepts mail on the secure protocol and completely ignore attempts to send mail over SMTP. The important thing is that the servers would each need to be authenticated in the protocol, but the servers could authenticate their own users in any manner that they choose - the receiving server doesn't need to authenticate the sending user. An insecure server would run the risk of being blacklisted and needing to apply for a new certificate.
> visitors don't generally have dimes on them
It may have been a different story in 1933. A modernized (and significantly more expensive) version for today might have a dollar bill slot on it instead, or maybe a credit card slot.
> it's too easy to successfully bypass the system by knocking
You can eliminate this problem with a "knocks will not be answered" sign. A solicitor isn't going to waste his valuable time knocking until someone answers the door. He'll either see the sign and move on; or he'll knock, get no answer, and move on. Someone can still annoy you by knocking repeatedly, but that's a different problem (DoS rather than spam).
My personal choice would be a "solicitors will be attacked by vicious dogs" sign, backed up by dogs specially trained to chase and act vicious without actually inflicting harm (I don't want to be arrested or sued for assault, just to scare the living daylights out of violators). :-)
Dealing with spam in isolation in the botnet era is in some sense a movie plot solution. The root problem isn't spam, it's botnets.
People who run 'victim' computers in botnets are no more victims than people who drive down the street in grossly unsafe vehicles. These people are either too ignorant or too selfish to care about the consequences their actions have on others. Just as motorists get fined if they operate a vehicle without working brake lights, computer owners should be punished if their systems participate in a botnet.
Deal with the botnets and dealing with spam becomes far easier.
Having been through this debate many years ago (I even brought a coin-operated doorbell to a conference :-), I hesitate to dive in again, but something that seems to have been mised is that once you charge for "expedited delivery" (or "get out of spam-box vouchers), you have, in essence, legitimized spamming for the level of direct-mailer just above Spamford Wallace.
There is probably no price that would be acceptable to the average casual user but too high for those who could use payment of that price to avoid prosecution for spamming.
I could imagine an almost entirely separate email infrastructure, composed of trusted MTA (with certs and all), that fed into the normal person's email-box beside the common cesspool, but which was guaranteed immunity from buggy spam-filters. The barrier for entry would have to be high, and the cost to users of the service would of course rise. Then the questions are how soon everybody would just blackhole anything _not_ from the "Trusted Postoffice", and how long before they sold out to spammers or started charging extortionate rates.
Not a technical problem, folks. A people problem.
"Not a technical problem, folks. A people problem"
Yes and one without a technical solution.
History has taught us that most of the sugestions posted here will be got around by spamers or other criminaly incentivised people if they are implemented (think just how difficult even simple security protocols are to get right and then multiply that effort by a large random number ;)
Also I cannot see people wanting to get rid of SMTP it works way to well and the old razor "If it ain't broke don't fix it" will apply for many many people and organisations. Also any changes will break to many things like mail lists etc that currently do sterling work for open source developers etc.
I am not sure that Black List systems will remain in vogue as the trafic involved starts to equal the amount of legitimate Email sent.
I suspect that what will eventualy happen is an extension of current techniques where each user will have a series of white lists and an A.I. filter that learns their likes and dislikes. Likewise these filters will appear on mail lists etc to check for content before posting out.
Trying to get money involved will only attract undesirables like governments and less than scrupled corperates who will view it as a new way to raise revenue and corner market share.
How is the system to know who to bill the email to? The trivially spoofed SMTP headers? This would be much the same as having the post office accept unstamped mail and billing to the person on the return address.
Until that problem is solved, the question of what to do to the sender is moot (as Goatrider said above). Once it is solved, there are more direct ways to deal with it than erecting a vast financial infrastructure.
Minor comment regarding "hacks" of the coin-op door bell....
Looking at the description of the device, it uses the dime to close a circuit, allowing the bell to get the current.
A "slug", a disc of metal that fits the slot and closes the circuit would work.
Brazing, soldering, etc. a piece of piano wire could allow retrieval of the coin or slug after ringing the bell. A set of wire probes might also do the job.
A nasty one is pouring salt water in hopes of closing the circuit.
(Modern vending machines and their coin mechanisms have some counter-measures for such techniques.)
These methods, however, can be quickly discovered as the person inside the house comes to the door and sees no dime or a puddle. Not likely to open the door give a pleasant greeting to the visitor. Automatic penalty for salespeople. Pranksters, who just want to ring the bell and bother the people inside, would not have this penalty.
In a way, this pondering raises a technology versus people factors matter. Getting the bell to ring, a technical factor, is not difficult. Getting the person inside the house to respond in a desired manner is another thing.
"The anti-spam system fails because spammers don't have to send e-mail directly -- they can take over innocent computers and send it from them. So it's the people whose computers have been hacked into, victims in their own right, who will end up paying for spam. This risk can be limited by letting people put an upper limit on the money in their accounts, but it is still serious."
I don't see this as a problem but rather as a very nice advantage. People will finally have to pay for disturbing "the internet" and having other people "suffer" because of their bad systemadministration. Would be very nice.
However, I'm still not in favor of this system and I wouldn't want it to become "the standard".
The historically minded will notice that the dime-operated doorbell was being marketed, was during the depths of the Depression. In 1933, hungry people would ring doorbells and beg for a dime or a sandwich. The doorbell was probably especially effective against people who didn't have a dime to their names. In the ad, it seems implicit that they're a major target, perhaps even more than salesmen. The way I read it, the last line of text--"Dimes kept by the device provide a fund for charities"--supports this idea. It sounds less heartless to take dimes from the desperate if you donate them to charity.
Do we want to set up systems that make it even harder for poor people to participate in public discourse by further restricting their access to email?
"ISPs could have rate plans similar to cell phone companies: you pay $X/month and get the first Y recipients as part of the deal, or maybe a maximum rate of Y recipients/hour. In excess of that, you pay $Z for each additional recipient (Z might be less than 1)."
Oh great, you want to give your ISP an excuse to get an extra $30/month out of you? You don't think that they'd start with the current unlimited plan and charge LESS for limited plans, do you?
The other thing I think nobody's remarked on yet is that postage is most emphatically not a hindrance to mail spam. I, for one, still get a not-insignificant amount of junk mail, mainly for credit card offers of course. And those are costing $.40 each, even before you count paper and printing.
The spammers will just factor it into the cost of doing business.
I think this idea would be workable IF the volume of microtransactions could be processed in a tolerable time and the microtransaction system secure enough. Say the fee is $0.10 per e-mail (and I think this is higher than needed). Then the service providers could set a default limit of, say, $10 on the account. Business accounts will have to raise that limit, but how many people send out 100 e-mails a month from their personal, non-business account? You hit the limit, and you get a screen telling you that you have to put in more money, and suggesting some ways of cleaning your system if you didn't choose to send so much e-mail. The less sophisticated users are thus generally protected from losing more than $10 at a shot, without crippling those of us who know enough to secure our system and be on the lookout for a bot takeover, or who have a sysadmin watching over our business network.
However, I do wonder why it's necessary. The spammer might hide his identity, but he's just a middleman. If commercial spam is going to, say, sell viagra, then there's got to be something in there that tells a very unsophisticated user (that's PC talk for "idiot") where to buy the little blue pills - and at the end of that financial trail is the main guilty party. Even if they're in a country with no extradition treaty, along that financial trail you should have found seizable assets...
> Oh great, you want to give your ISP an excuse to get an extra $30/month out of you? You don't think that they'd start with the current unlimited plan and charge LESS for limited plans, do you?
Most people don't seem to have a problem with cell phones being a metered service (given the raging popularity of cell phones), so why are there objections about making e-mail a metered service? The answer (or at least part of it), is because from day one people have been perceiving e-mail as a free and limitless resource. That has always been one of its big attractions. No one wants to be required to start paying for something that was previously free to them. But it is this very same characteristic that makes spamming attractive, which is why we're in the situation we're in now.
In truth, I don't think metering e-mail at the ISP level would do much good. In fact, just requiring SMTP authentication (and TLS of course) from your subscribers and blocking outbound access to port 25 would do as much good, because as far as I know the current generation of spambots still don't know how to steal and use SMTP credentials. This would put a crimp in botnet spamming operations, but spammers would just change tactics again. Mainly I was responding to Steve's contention that metering couldn't be done.
It's pretty obvious from your response that part of your dislike of the metering idea stems from a fear that ISPs will abuse it to gouge their customers. In a more perfect world (i.e. one in which there was real competition in the ISP marketplace), I'd be content to let the market sort things out. But we don't live in that world, so I share your suspicion.
> [P]ostage is most emphatically not a hindrance to mail spam.
True, but the stuff you get via third class bulk mail tends to have a higher response rate than spam. Spam has a truly abysmal response rate. Spammers are able to make a profit off such thin returns only because spamming has almost no marginal costs. A significant marginal cost, in the form of some equivalent to postage, would ruin that economic model. (OTOH, increasing their fixed costs via things like aggresive spam filtering just drives them to spam even more to make up for it). The problem is finding some way to impose that marginal cost on people who are criminals. No one has been able to come up with a reliable way to do that.
Two words: "Joe Job"
Just to generalize what Sellig and UNTER mentioned about computational cost, the technical problem is that bulk email is far more expensive to consume (for the final recipients and for the network infrastructure) than it is to produce.
I was a little surprised that Bruce's post focused on actual money as the mechanism for moving those costs back onto spammers, when (as others noted) money is a notoriously tricky commodity to interface elegantly with software.
Computational cost is as good a place to start as any, because it's an area where we can at least think clearly about shifting cost away from intrastructure and recipients.
And on the topic of spammers "just factoring sending costs into the cost of doing business": we don't need sending to cost a furtune, but we may need it to cost Something.
If and when the costs to senders (in aggregate) exceed the costs of transmission and reception (ie - create a net benefit for the ecosystem), maybe email spam is only as bothersome as paper spam.
At which point, problem solved?
I wonder why people spend so much time worrying about spam anyway. I get junk paper mail and throw it in the garbage, and I get junk email which ends up in a bulk folder and eventually expires. It's the least of my problems.
"Just as motorists get fined if they operate a vehicle without working brake lights, computer owners should be punished if their systems participate in a botnet."
This is an awful analogy. Unsafe drivers kill people unfortunate enough to be on or near the same road. OTOH, zombified computers send electronic packets that obey all relevant protocols to other computers. Such packets may be ignored, forwarded to blacklists, used to train spam filters, etc., automatically, based on the preferences of whoever administers the downstream host. You point the finger at the zombie box, but why not blame whoever is operating your POP or IMAP server? They're operating a host that isn't smart enough to filter out email from botnets. How is that different from operating a host that isn't smart enough not to get pwned? The difference, of course, is that you already have a relationship with your email provider and are free to encourage an improvement in service.
Sure, it's difficult to eliminate all such mail given the protocols in use today. If this really had such dire consequences, people who cared would be using different protocols. If it's really very important that you only receive email from certain people, that's easy enough to implement. Of course that isn't important, as much of the value of email comes from the fact that anyone can send it to anyone else.
At a higher level, introducing prices, control, laws, and scarcity into a system that has never required them is embarrassingly old-fashioned. Those who care enough about spam already don't get much. Those who don't accept the standard email protocols are free to develop new ones (and many such people are doing just that). If we want real solutions to real problems, real innovation is always more effective than scapegoating.
@bruce: "Right now she doesn't really care if her computer is used to send spam, and she doesn't know how to prevent it if she wanted to. Under this pay system, she's going to be surprised by a large bill at some point -- when her computer is hacked to send spam. The question is: can we really hold her to the charge, and force her to upgrade her security? I don't know if we can."
I agree with other posters, the hitch is in the payment infrastructure, not here. If we say email costs a small amount (refunded on receipt), then everything else takes care of itself. This isn't a simple 'stamp' equivalent, since the money gets returned unless misuse occurs, so it's essentially a bond. The bond need only be large enough to cover the number of unacknowledged emails you'll have out there simultaneously. For your mother, that's a small number, and let's say $20 covers it.
It also needn't be trivial to refill or open-ended on a credit card account...refilling could require phone calls or paper bills or something. So your mother's computer is cracked, she gets a phone call saying she's out $20, and now she either decides to patch security (or gets you to patch...that's how my mom would handle it), or she leaves the bond empty and communicates by IM or something for a while. If the products she uses are inadequate (too complicated, too expensive, too inconvenient), she finds out from friends what to switch to.
My (eighty-year-old) mother could handle that, and any system providing this system with usability adequate for 'ordinary users' would become highly popular, and the competitors would scramble to adapt.
I'm just imagining implementing the payment infrastructure itself. Some issues there.
We can't assume that we'll move to a payment system by fiat. What aspects of such a system would encourage users to use it instead of what we have? The benefits seem to accrue to recipients while the costs go to the senders. You could probably convince people to start receiving email under the new regime (as well as continuing to receive the old type too), but they'll be hesitant to start sending it that way.
If we can continue to use the "your mom" example, what on earth would convince her to send money to some entity she has no reason to trust to use a service she doesn't consider vital? She trusts her bank, but she hears that if she doesn't do everything right at its website she could lose all her money. She isn't eager for more such stress online. She has also heard that email used to be free; who had the bright idea to start charging for it?
I know, Mom also gets annoyed by spam. At some point, she'll either live with it, stop using email, or find a provider that can keep spam to a minimum. At no point will she be sending in a check or entering her bank account number. Mom may not be up on her RFCs, but she knows a scam when she sees it.
"Unsafe drivers kill people unfortunate enough to be on or near the same road. OTOH, zombified computers send electronic packets that obey all relevant protocols to other computers."
Both operating an unsafe vehicle and an insecure computer impose the costs of ignorance, selfishness and/or negligence onto third parties. The exact mechanics, magnitude of risks, and compliance to standards (or lack therefore of) are irrelevant.
"Both operating an unsafe vehicle and an insecure computer impose the costs of ignorance, selfishness and/or negligence onto third parties."
True enough, although the mechanisms governing this are different. If the analogy held, you could see me as recommending that people drive tanks and SUVs to prevent others from harming them on the street. However, I feel this would be a much more onerous expectation, and much less in keeping with the operational context, than a suggestion to use a spam filter. Thus the analogy does not hold.
"The exact mechanics, magnitude of risks, and compliance to standards (or lack thereof) are irrelevant."
Of course, we disagree on this point. I don't think we can resolve this, because you're taking the irrelevance as a given and I reject it out of hand. The "information highway" metaphor really can be taken too far.
Having worked at an ISP, I believe that it is the ISPs responsibility to do a lot more. Bogon filters caught an amazing amount of rogue traffic passed to us by large upstream ISPs. Downstream reverse-path filters caught misconfigured user traffic. Outgoing SMTP should be blocked except via the ISPs rate limited mail server (by IP - these are home users we're talking about - not many emails). If you want port 25 outbound then you post a bond agreeing to accept the ToS which states that you implement suitable security. Most people don't need SMTP outbound (except to their ISPs server) and those that do need to take responsibility for securing their machine.
Any ISP that wants to force my outgoing SMTP traffic through their server had better be offering a service level agreement guaranteeing not only uptime but also traffic privacy (including against legal threats such as subpoenas), and post a bond of their own backing it up.
Bruce, I like the post, but I respectfully beg to differ. I co-authored one of the articles showing how this kind of anti-spam mechanism can create more value for consumers than technology filters (sometimes but not always!). Berkeley Press just published a summary http://www.bepress.com/ev/vol4/iss2/art4
There may be arguments against payment systems to fight spam, but the likelihood that a stable system will be hacked at a rate sufficient to create net negative value is not one of them. Would you be willing to engage on this one? I'm willing to bet I can win this argument. If I lose, I'll buy dinner at the restaurant of your choice in Mountain View or Boston. If I win, you concede only that this is not a problem -- you don't have to endorse this as the right technology.
The lines I will argue with are:
"The [bonded] anti-spam system fails because spammers don't have to send e-mail directly -- they can take over innocent computers...So it's the people whose computers have been hacked into ... who will end up paying for spam.
Consider the average home user: my mother. Right now she doesn't really care if her computer is used to send spam, and she doesn't know how to prevent it if she wanted to. Under this pay system, she's going to be surprised by a large bill at some point -- when her computer is hacked to send spam. The question is: can we really hold her to the charge, and force her to upgrade her security? I don't know if we can. "
I bet that I can show exactly how we can protect your Mum.
Marshall Van Alstyne
People who's computers have been taken over are victims in their own right, ok â€“ but right now most of those will have neglected patching and protecting their system. If such behavior, which is simply anti-social because it causes a lot of people a lot of trouble and makes the e-mail-system near-unusable, would not only put you in danger of losing money (it already does that), but would garantee you to lose money, then maybe people would start considering a book about the basics of their OS and about basic security and learn how to securely operate their machines. It would also increase the pressure on OS vendorsâ€¦
Anyway, the pay-per-spam-idea isn't that realistic and still, the effect would soon wear off, because crackers would move to unpatched vulnerabilities, if everyone regularily patched their system.
Nice dream though.
There was a high tech version of this gadget in, "The Cat Who Walks Through Walls" by Robert A Heinlein. You inserted a credit card.
"This is the recorded voice of Gwen Novak. I've gone to bed and am, I hope, happily asleep. If your visit is truly an emergency, deposit one hundred crowns via your credit code. If I agree that waking me is justified, I will return your money. If I disagree - laugh, chortle, chuckle!- I'll spend it on gin and keep you out anyhow."
IMHO pay-per-mail systems are difficult to translate into public policy, as there's no way to harmonize such techniques globally. There will always remain some territories that don't comply. Furthermore e-mail communication will become less affordable to the lower social class. Someone had to compensate the administrative expenditure, which, compared to the single transferred fees, would be immense. Besides, the assertion of such rules would result in an exagerrated regulation of the Internet and a further loss of privacy.
Hashcash OTOH offers an opportunity to reduce spam significantly. You only need a hashcash minter intercepting every outgoing mail, automatically adding a token related to every recipient's address and the current date, and at the destination a spam filter capable of rating messages based on the validity and precision of that token. Even web-interfaces aren't big a problem, as applets can be used to enlist the local machine to do the calculations. The transition can take place smoothly with a profit for every participant right from the start. BTW, the unfortunate mom involuntarily running a spam relay would quickly hear her feverish computer gasping for breath and realize how sick it actually is, whilst the hijackers had to deal with the limited throughput.
I'm sorry I missed this discussion when it was more timely. Almost all the objections to this system disappear if you don't use money as a bond - use effort instead. My system (at www.drdmail.com) uses captchas as bonds - senders need to fill out a captcha (visual puzzle) correctly to create a bond, which then can be used to bond messages. If the bond is not forfeited, it can be used again to send another message. I have an answer to just about every objection, I think.
Schneier.com is a personal website. Opinions expressed are not necessarily those of BT.