ZDNet’s “Zero Day” blog has an interesting post on the gray-market economy in solving CAPTCHAs.
CAPTCHAs are those online tests that ask you to type in a sequence of characters from a hard-to-read image. By doing this, you prove that you’re a real person and not an automated bot – the assumption being that bots cannot decipher the CAPTCHA images reliably. The goal of CAPTCHAs is to raise the price of access to a resource, by requiring a small quantum of human attention, in the hope that legitimate human users will be willing to expend a little attention but spammers, password guessers, and other unwanted users will not.
It’s no surprise, then, that a gray market in CAPTCHA-solving has developed, and that that market uses technology to deliver CAPTCHAs efficiently to low-wage workers who solve many CAPTCHAs per hour. It’s no surprise, either, that there is vigorous competition between CAPTCHA-solving firms in India and elsewhere. The going rate, for high-volume buyers, seems to be about $0.002 per CAPTCHA solved.
I would happily pay that rate to have somebody else solve the CAPTCHAs I encounter. I see two or three CAPTCHAs a week, so this would cost me about twenty-five cents a year. I assume most of you, and most people in the developed world, would happily pay that much to never see CAPTCHAs. There’s an obvious business opportunity here, to provide a browser plugin that recognizes CAPTCHAs and outsources them to low-wage solvers – if some entrepreneur can overcome transaction costs and any legal issues.
Of course, the fact that CAPTCHAs can be solved for a small fee, and even that most users are willing to pay that fee, does not make CAPTCHAs useless. They still do raise the cost of spamming and other undesired behavior. The key question is whether imposing a $0.002 fee on certain kinds of accesses deters enough bad behavior. That’s an empirical question that is answerable in principle. We might not have the data to answer it in practice, at least not yet.
Another interesting question is whether it’s good public policy to try to stop CAPTCHA-solving services. It’s not clear whether governments can actually hinder CAPTCHA-solving services enough to raise the price (or risk) of using them. But even assuming that governments can raise the price of CAPTCHA-solving, the price increase will deter some bad behavior but will also prevent some beneficial transactions such as outsourcing by legitimate customers. Whether the bad behavior deterred outweighs the good behavior deterred is another empirical question we probably can’t answer yet.
On the first question – the impact of cheap CAPTCHA-solving – we’re starting a real-world experiment, like it or not.
I hope the petty little group that tried to stifle free speech with said spurious DMCAs gets their ass handed to them. I would say this even if it was the creationists who were being picked on through illegal means, really – free speech is free speech!
Ironically, I’ve never heard of that anti-creationism group before, and what’ll probably happen here is it’ll backfire on the creationist group, creating more publicity for people they perceive to be a threat – thus ensuring that more people will check the other group out, and MAKING them more of a threat. Not to mention the legal trouble the creationist group is liable to get into over this.
Isn’t justice beatiful when it’s poetic?
danke admin?m
danket admi
No robots please. Using humans to get around blocks made for robots. Seems that it costs $0.002 to solve a CAPTCHA. slot.it, find it in noticias de scalextric
Please refer to the project’s website for the most up to date information as there existed much improvement to the project since the writing of this article.
Couple of noticeable changes are :
(1) Writing of MXML_BASIC renderKit that wraps around HTML_BASIC renderKit of Myfaces + Mojarra implementation. This will allow users to use HTML components alongside JSF Flex components. So the name of component14, component15 projects have been changed to renderKit14, renderKit15 projects, with renderers generating the preMxml, mxml, swc, swf, and etcetera contents. Of course the actual task of creating preMxml, mxml, swc, and etcetera are still handled by the other maven projects [commonTaskRunnerImpl, fileManipulatorTaskRunnerImpl, and flexTaskRunnerImpl]. Love modularization!!!
(2) All the JSF Flex components should still be under , but this tag must belong beneath .
(3) There now exists debugging enabled for FireFox:FireBug for ActionScript actions.
(4) JsfFlexHttpServicePhaseListener will be added this weekend or the following weekend for service calls from ActionScript to back end for populating complex components [i.e. DataGrid components which allow dataBinding by having DataGridColumns component’s columnData field].
(5) Usage of Dojo 1.2 with breakage in MyFaces tomahawk component [don’t remember if this writing was prior to or after the breakage in dependency]. So there exists no longer any dependency other than impl to MyFaces project, which is implied in prior statement with current support for MyFaces + Mojarra 1.2 impl.
(6) Usage of JSON jar for cleaner code and for future preparation when there might be more service requests from client side to server side.
(7) Added components under mx.states package.
(8) Added Jython Flex Runner impl which will be tested when Jython > 2.5 is publicly released for maven repo. Default is Ant Flex Runner impl and I simply created Jython to simply play around with it and for Python lovers out there.
(9) Improvement in various parts of the code [i.e better packaging of javascript and actionscript files and etcetera] too many to name [still ongoing].
Thanks for the interest in the project and if interested please sign up to project’s mailing list!
Jeff MacKie-Mason and I have a paper where we analyze captchas as an economic screening mechanism, which they are. One of the really important features of screening mechanisms is that, as you make the task harder, the bad guys (spammers) are increasingly more burdened than the good guys. (Technically, the cross derivative is positive — known as the Spense-Mirlees condition.) As long as that is true, then you can find some level of difficulty that effectively screens out the spammers. However, since they have started outsourcing captcha solving, that makes increases in captcha difficulty equal for both spammers and legit users. This means that no amount of increasing the difficulty of captchas will continue to help.
Security When People Matter: Structuring Incentives for User Behavior. Rick Wash and Jeffrey K. MacKie-Mason. International Conference on Electronic Commerce, 2007. http://www-personal.si.umich.edu/~rwash/pubs/icec702w-wash.pdf
Personally I like the idea of a small fee for the kinds of things that CAPTCH’a generally protect, but to impose it would require a mcropayment infrastructure. When the internet was getting popular in the early nineties there were several proposals for creating such an infrastructure. I personally invested in a startup that was trying to create one. Micropayments never caught on. It seems that websites decided they could generate more revenue by selling adds than by charging two cents (say) for a search.
“there’d be a significant delay between when the captcha was presented and when it was solved”
No, there wouldn’t.
A computer-time cost is another option. Require a code to be broken that can be brute-forced, but takes a few minutes of CPU time on a modern machine to do so. Email clients and a browser plugin would exist to do it.
Effect on legitimate users: their sent emails aren’t received as promptly at the other end.
Effect on spammers: a huge drop in volume. Using many/faster computers to counter this results in a huge increase in hardware and electricity costs.
I completely agree with John Millington and I think one question we need to ask about this is do want to have a group of people whose task is to solve captchas all day? Why not make the hurdle purely economic instead of outsourcing human attention.
I want to agree with John Millington. Oftentimes the answer proposed to spam (usually e-mail spam, but it can apply to registration spam and comment spam as well) has been to impose some small charge on each message/registration/comment. The idea being that this is only a small inconvenience to legitimate users, while it completely destroys the spammers’ business model. This idea keep getting rejected on the grounds that users would not agree to it.
But now, with the creation of CAPTCHAs, and then the growth of a paying industry for solving them, we see the market itself taking a roundabout route towards essentially the same solution.
At this price, the captchas are pretty much down in the noise as far as cost goes for setting up a fake account or creating comment spam or all of the other kinds of fraud they can be used for. The cost of other paraphernalia (and programmer time) for committing frauds is going to be rather higher. So not much deterrent effect at all.
Of course, the article also suggests that captcha-sellers may be offering more than they can actually deliver, in which case these numbers are about as accurate as “electricity too cheap to meter”.
How much would you be willing to pay for a service that forges your signature so that you can skip authorizing credit card transactions?
Some real customers may be blind. And yes, some sites support audio cues, but no that is not the norm at the moment.
So, here’s an idea. Captchas are more or less culturally neutral, assuming the solver knows the western alphabet. What if captchas asked questions or required solutions that had a cultural framework? The attempt would be to make captchas only a bit more difficult to a US user, for example, while making them quite a bit more difficult for low wage employees of an Indian captcha solving company. Geolocating an IP address is easy, so serving a relevant captcha is certainly possible.
It seems like this reasoning just leads to the idea of getting rid of captchas altogether, and replacing access with a tiny charge (why have the middle man?). If you’re willing to pay $0.002 then maybe you’re willing to pay ten times as much, IF it can be conveniently done without the transactional overhead of the usual financial institutions. I might pay $.02 to post a comment to some blog, but someone working on a mass-scale (i.e. a spammer) would see that as a loss.
It is not useful for solving captchas for real customers since there’d be a significant delay between when the captcha was presented and when it was solved. It would nearly always be faster to just solve it yourself rather than submit it to a service and wait 20 seconds or so for it to be solved for you.
So while you might pay this rate not to see captchas, in reality the service doesn’t work like you hope it might in order that you don’t see captchas. The only real purpose for this service is spammers.
However, captcha companies could simply set a price that allows anyone to pay a small fee instead of solving the captcha. I imagine there wouldn’t be a whole lot of uptake in this service, but at least then the money is going to the right people, and there’s no need to build a wasteful infrastructure.