Proof-of-work systems are cool, but this doesn't work, economically.<p>A proof-of-work system requires a verifiable amount of computation time before you can do something. The idea is that "honest" computers are mostly idle, but that this should slow down spammers.<p>The problem is that it may not be possible to seriously inconvenience spammers without seriously inconveniencing honest clients, <i>even if both run native code</i> (e.g. hashcash). The article limits the honest guy to some crappy smartphone's interpreted Javascript running an algorithm that is very much optimized for 32-bit machine words (instead of Javascript's floats). If the smartphone can do the work in 10sec (which is annoying enough), the spammer should be able to do it in at most .01sec: enough to send ~8.6 million messages per day.
I wouldn't necessarily suggest it, but imagine if this were implemented at the protocol level and handled with native code built into clients.<p>There could be a new HTTP request method called "SUBMIT" which works like a POST request except with an added step for proof of work. When making a SUBMIT request, the client opens a connection to the server, sends the initial request header with the SUBMIT method, and receives a proof of work challenge as an HTTP field in the server's response. The client then processes the challenge and sends its proof of work to the server which verifies it and sends an OK. Then the client sends its url-encoded data to the server, the server sends its response data, and the connection closes.<p>Then performance impact and behavior would be fairly uniform for all clients, especially if a standard library of problems and problem solving code were used by them, so you wouldn't have to worry about finding a problem that isn't too hard for poor Javascript implementations to solve while still being too easy for native code implementations in spamming tools to process. There could even be an added field for the server to inform the client what problem type is being used, allowing the addition of new problem types of different difficulty and performance requirements in the future without any more updates to the protocol.<p>Personally though, I don't like proof of work solutions. Sure, they add some computational cost to spamming, but the mass implementation and use of any proof of work solution would probably just create a new, lucrative market for botnet hackers to sell their services to. Besides that, it just feels like the wrong solution to me.
Messing around with your clients performance doesnt seem like a nice alternative to a captcha for me...<p>There is plenty of people with bloated windows machines that even using a modern browser struggle to perform properly, I dont think overloading them with extra work would help making their experience easy and smooth.<p>Just my 2 cents.
This strangely reminds me of how Bitcoin works under the hood -- basically, a proof of work. Anybody up to creating a Bitcoin plugin for browsers as an alternative to captchas? Either as .xpi or a Flash file to be included on the website?
This wouldn't work would it? If the server sends the client a number (n), surely, I (as a spammer), could simply pre-calculate the largest integer (p) where the hash starts with 0000. The server cannot verify this is the wrong answer, without calculating all the hashes between n and p.<p>So I can send back p as my answer for all values of n, without needing to do any client side calculation
Proof of work surely is a very interesting concept, but I'm not sure it's preferable to other methods.<p>As far as I'm concerned using up 8 seconds of user computation time (during which you <i>cannot</i> guarantee responsiveness) is just as bad as throwing a cryptic CAPTCHA field in her face.<p>Methods such as timestamping, honeypots and dynamically added fields yield very good results for bot recognition.
Isn't that also what "hashcash" is all about?<p><a href="http://www.hashcash.org/" rel="nofollow">http://www.hashcash.org/</a><p><a href="http://drupal.org/project/hashcash" rel="nofollow">http://drupal.org/project/hashcash</a><p><a href="http://wordpress.org/extend/plugins/wp-hashcash/" rel="nofollow">http://wordpress.org/extend/plugins/wp-hashcash/</a>
Is it possible to use in javascript a memory-bound proof of work (<a href="http://www.google.com/search?q=memory+bound+proof+of+work" rel="nofollow">http://www.google.com/search?q=memory+bound+proof+of+work</a>), where the computation speed is bound by memory latency, not CPU speed?
If we could make it work (and I recognise the problems other commenters have noted with this particular implementation) then this would be a big benefit for blind people, for whom CAPTCHAs aren't just inconvenient but impossible. I'm sure they would gladly accept 8 seconds of unresponsiveness while the computer did some verifiable work, if it meant they could pass the test and use the service.
This works well with big forms due to the time it takes to carry it out so it would complete by then. That is, if the user isn't put off by the size of the form. Small forms not so much and the user would be annoyed.<p>It also penalises users who don't use Javascript.<p>Edit: This fails against a botnet where computers can be told to wait(10) [seconds] after filling form out.
If the idea is to create a bottleneck, then why not throttle login at the server? Eg. have mutex for logging in, only allow one request at a time and then slow that down with a slight wait (Say, 1 second). You'll have to balance the exact throttle with the number of legitimate users on the system, and you'd probably want a timeout-and-retry mechanism in place.
I'm sure someone has thought about this before, but instead of having the client do work for a certain amount of time, could you just disable submit, set a javascript timeout for some set amount of time, then enable submit after that?<p>Why does the client need to be processing during the waiting time? Would spambots wait around for the submit button to work?
Don't trust client input!<p>The random number would have to be sent from the server, else the same hash could be used every time.<p>Also MD5 can be easily done on an FPGA at hundreds of millions of tests a second. Other algorithms might be more effective, particularly those which attempt to use large amounts of memory.<p>Nice idea though.
I wonder if there's any way to use this scheme as a distributed computing tool. Maybe give out 3 work-units, one or two of which you know the result for, and the 3rd is unknown. The two known answers could be used to do the check, and the third actually does the work (and provides more known answers for later).
Isn't this what botnets are for?<p>I'm serious - spammers already use packs of porn-hungry humans to process CAPTCHAs; this will only make their lives easier as they already have the botnets available, and botnets don't need porn!