3 ms·
surely if you "query the endpoint a few times per day" the captcha indeed shouldn't be an obstacle to that. I thought the idea is to prevent ddos and spam, and
by oolonthegreat 5y ago
surely if you "query the endpoint a few times per day" the captcha indeed shouldn't be an obstacle to that. I thought the idea is to prevent ddos and spam, and not to distinguish between an actual human and bot. like it shouldn't prevent non-harmful scripts like web scraping etc. as long as you don't overtax the servers.
- xg15 5y agoNo, the purpose of captchas has always been to distinguish bot users, no matter what kind of bot. If you don't mind bots but just want to protect against overuse, you can simply set up rate-limiting and be done.
- ncomplex 5y agoI could be wrong, but wouldn't this system "front-load" rather than "back-load" the rate limiting? That is to say: if you rate limit requests globally, it affects all users if one user attempts to spam. On the other hand, this system slows each individual user down without affecting others directly.
- xg15 5y agoGood point. I'm no expert, but I believe rate limiting systems typically use buckets that are partitioned by IP address or network segment or something similar. If there were just a single global bucket, an attacker could exploit the rate-limiter itself to cause a DoS, which is clearly not what the site wants. But yeah, this seems like a way to archive something similar with potentially less complexity. (If you're willing to tolerate the wastefulness, which is still not cool in the age of climate change). A challenge could be correctly invalidating a nonce. You don't want an attacker to reuse a previously solved puzzle for multiple requests - on the other hand, it's difficult to set up a good "time to live" for a nonce as you can't know in advance how much time a user would need to solve this nonce. So I guess some global state to track recently "spent" nonces would be necessary.