Hacker News Reader

Comment by bobbiechen | Hacker News Reader

Yeah, I had the same question myself. I think that's what you would want to do to make it airtight (plus some amount of rate limiting or flagging for devices that are part of dedicated device farms).

But even if not, there's still value in raising the barrier to entry. For example, you can buy 1000 reCaptcha solves for $1-2 from various captcha-solver services. And yet that $0.001-per-request fee does discourage mass-scale bot attacks.

View on HN

... You... think... it would be a good thing.

Don't you...

I do. It has downsides of course, but what's the alternative at this point?

I suspect that the HN crowd is somehow insulated from the river of crap and fraud that is the internet experience for a majority of the population.

99% of the crap and fraud comes from ads, aka Google. Thanks, Google. Just run an ad blocker, there goes most of the scams you'll see.

Also putting QR codes before every webpage doesn't make the web less shitty. It obviously makes it more shitty. And this will 100% be used for fraud. Phishing websites can get away with QR codes now, great.

> the internet experience for a majority of the population

> Just run an ad blocker,

This reads as "I am fine, so you should be fine". The median internet user has a phone so chock full of cancerous malware.

And if a tool gets good enough to interfere with tech firms ad revenue, they find ways to stop it. See whats happening to ad blockers.

Depends on your specific problem. Usually redesign your system not to need to care if the other end is a bot or not.

How though? Can you also avoid DDoS simply by designing your system to not care if the requester is a bot or not.

Let's say I'm running https://grep.app/ for example. AI bots start heavily using it, costing me a ton of money. How would you magically design this so it doesn't matter if the end bots are using it?

Rate limit individual clients.

Let's play this out: how do you determine individual clients? By ip? By seasionid?

How do you "determine" individual clients to show them CAPTCHAs? Yes, you can, and probably should, make some use of IP addresses, although that would work better if idiots hadn't polluted the Internet with quite so much NAT.

But you don't have to, and you definitely don't have to completely rely on it. Look for a cookie. If you don't see it, route the client through a page that sets it.

Yes, this is subject to flooding attacks... in exactly the same way that every CAPTCHA system is subject to flooding attacks. But it actually uses fewer resources per request than showing the CAPTCHA would.

> How do you "determine" individual clients to show them CAPTCHAs?

Cookies.

> Yes, this is subject to flooding attacks

Err... Yeah exactly.

> in exactly the same way that every CAPTCHA system is subject to flooding attacks.

Uhm no the whole point of captchas is that it requires (or used to anyway) humans to solve them, thus limiting the rate to human speeds.

> Uhm no the whole point of captchas is that it requires (or used to anyway) humans to solve them, thus limiting the rate to human speeds.

The CAPTCHA challenge page itself has to be served to a client that has not yet given any evidence that it's not a bot. It's just as expensive to serve the challenge page as it is to serve a cookie-setting page. Bots can infinitely retrieve the challenge page (and can also infinitely try to retrieve the underlying "authenticated" page, forcing you to process redirects).

The only reason it looks better to you is that a third party is serving the CAPTCHA. You could also have a third party serve the cookie-setting page.

Reply on news.ycombinator.com