Hacker News Reader

Comment by viraptor | Hacker News Reader

I really like the idea, but... I'm not sure it's possible to achieve right kind of cost balance here. Some assumptions at first: every device has to use the same work scaling factor (because you can always pretend you're running something slower), any cloud server runs at least 10x faster computations than a low-end mobile phone where this captcha has to also work.

That means that even if you scale the work to take at most 10 seconds on the client machine, you'll be able to crack 1/s on a $5/mo on digitalocean. That's ~2.6M answers a month. That's $0.002 per 1000 captchas, instead of $0.70 mentioned on the website and as a bonus it removes the part where you rely on people who could mistype things.

I really want it to work, but does the economic balance actually work here against the spammers or for them?

View on HN

This is the key point I think. From my desktop (Intel Xeon CPU E5-1620) the example takes 12 seconds to run, on my phone (ARM Cortex-A7 MPCore) it's taking about 120 seconds to run.

If you don't want to annoy your visitors you're going to need to have the max runtime on any device at around 25 seconds.

Now you can't scale this per device, because you can't rule out devices spoofing what they are. So this means you're looking at barely a few seconds to break it on any sort of desktop hardware, and even less on any dedicated server.

Spammers are probably waiting longer than that to just load the page they want to spam, so it wont slow them down. For this to work you need to solve this issue, and I hope you can, but I don't see how.

If the workload is made to be very large, say 30 seconds on a recent desktop, it could fall back to a captcha for slower devices. At least people visiting with fast computers could be spared the captcha.

That's a very good idea, coupled with what other people have suggested (Increase the time on the fly for devices/IPs making repeated or spammy looking requests) I could see this working.

(haven't read the article yet, keep getting 504s)

Regarding feasibility & cost, what do you think of the old '"Proof-of-Work" Proves Not to Work' paper? [1] From what I remember, the time to hash adequately would be too long to be of practical use/benefit.

[1] http://www.hashcash.org/papers/proof-work.pdf

Further, since the computation is implemented in Javascript, it should be possible for a spammer to take the code and make a much more efficient implementation in a machine-near language, such as C. Let's hand-wave and say that would raise performance by a magnitude - and that's probably very pessimistic, really.

At least it is not fixed cost/complexity. If you see large number of attacks/spam, you response by increasing complexity (and cpu cycles required to solve it)

And you remove CAPTCHA :)

Yes, you could change the scale. But the processing power ratio stays the same. At the price per 1k you listed, it's still cost-effective to crack this captcha at 1 per 10s automatically. But noone will accept waiting 100s to post anything.

If you start calculating the hash in the background, that could be useful. I might not want to wait 100 seconds after I've finished my reply, but I don't imagine I'd mind waiting 100 seconds from the time I first opened the thread or started typing.

Reply on news.ycombinator.com