Comment by protoduction | Hacker News Reader

Comment by protoduction | Hacker News Reader

Parent Full thread

Everybody gets the same difficulty initially which you determine as a site admin, so one should base this on their audience (e.g. Gitlab would have a different device profile from a government website).

The solving can be a few times slower on a low end device which you should keep in mind. To aid with this when setting the difficulty for your website it shows you an estimate for various device types. This is indeed a downside of PoW approaches.

There is one factor that helps: you can start solving as soon as the form loads, so as the user enters their details/comment it can start solving - I have a hunch that people on mobile devices are inherently slower at entering their data which should help a bit..

Anyway - if you set the difficulty quite high and the solving takes 30 seconds, it takes the user 15 seconds to enter the form - the user would still have to wait 15 seconds. That's not very different from the time to solve image captchas (it's actually lower and doesn't come with a 2MB payload download which isn't great on phones either, and they can keep their privacy + sanity). You could give the user something to do that makes sense for your website (ask them for feedback?).

> I have a hunch that people on mobile devices are inherently slower at entering their data.

In general, I use form autocomplete to fill this quickly. And on the contrary, my mobile signups are faster than desktop because the lastpass firefox extension on desktop takes longer to detect the form before the autocomplete can begin than my phone does.

Why bother with a proof of work scheme when you can just rate-limit directly? It accomplishes the same thing, while eating way fewer CPU cycles, doesn’t require JavaScript, and guarantees uniform cost between all client types.

This sibling comment was responding to you: https://news.ycombinator.com/item?id=25215024

So, if your app takes off on a college campus, you’d block them?

Do you collect metrics on how many people end up waiting for the PoW and share that with the admins?

In all, this sounds really promising though. I’d venture that most spammers already have higher end machines than end-users to solve existing captchas.

I’d probably approach this with a different strategy. I’d send an encrypted time stamp as the nonce. On the client, I’d first do a few easy PoW tasks and estimate the PoW difficulty for the given machine that would take at least X seconds to do. Then, send the PoW, the encrypted time stamp, and difficulty to the backend. If it’s been shorter than X (with a margin of error), or the PoW is wrong, it’s not valid.

In this scheme, it doesn’t matter how powerful the device is, a core is going to do some work for X seconds or at least be throttled by time.

> Why bother with a proof of work scheme when you can just rate-limit directly?

Tad amusing after all this time people still don't understand why proof-of-work schemes exist.

Rate limiting has zero cost to an adversary. PoW has physical costs. It's in the name :)

Reply on news.ycombinator.com