Comment by ve55 | Hacker News Reader

Comment by ve55 | Hacker News Reader

Parent Full thread

The way I'd put it is that Cloudflare's suggested implementation may have its issues, but the general idea of trying to verify that someone is a human and then providing this verification to services in a way that is 1) anonymous and 2) cross-compatible with other services, is the correct way to go about things (or at least has some very appealing features).

I hope that we have something in the future that does this job very well so that services do not need to verify phone numbers, Google accounts, and even IDs and facial imagery just to allow someone to use them (as this is much easier to do than coming up with new captcha styles that humans can quickly and easily solve, but that basic machine learning and scripting cannot).

Being able to use the Internet with the slightest bit of privacy is already ~impossible for the average user and extremely difficult and tedious for very knowledgeable and experienced ones, so anything that tries to improve the current trend sounds like it's at least attacking a problem worthy of our attention.

Alternatively, if services demand a fee then there is no need for human verification.

Instead of trying to solve anonymous human verification we can as well make micro-payment an option.

Sometimes serving 429s/403s to unauthed users is already costing you too much in egress bandwidth bills. That’s one of Cloudflare’s main propositions: stop that “idiot bot that will never get what it wants, but keeps requesting it anyway” traffic outside your network. (Note: not the same as a DoS! Usually not intentional, and usually not actually bringing your infra down. Just costing you money, while not making you any money.)

Is there a reason Cloudflare can't send a 429/403 in that situation if you're already using it as a middleperson?

It seems like responding to a bot and responding to an unpaid accidental request would take the same amount of energy from Cloudflare. The only difference is that a repetitive unpaid request is probably easier to detect.

Oh, they totally can, but you have to get Cloudflare to be your auth gateway (using e.g. https://www.cloudflare.com/en-ca/teams/access/ .) Usually companies who have this problem already have an auth system in place and well-ossified (i.e. with customers who’ve burned assumptions about it into software like mobile apps, that can’t be “forced” to update.) So it’s pretty hard to do a migration.

I really hate it when I'm trying to spend money at a company and get hit with a captcha box right as I click "checkout". I could see it for selling scarce items like concert tickets, but in general it's very insulting, annoying, and off-putting to me.

Credit card fraud that results in chargebacks is a very significant cost to a lot of online stores. So while it does suck it isn't the shop that is to blame.

A small micropayment makes for a great way for bad actors to test stolen credit card numbers.

You can't do micro payments with credit cards, they have to much $$ overhead. You'd need to pay into a service that'd handle the micro-payments and they'd have minimal packages to buy to mitigate these issues.

Once logged in perhaps. But credential stuffing is a thing.

This general direction could be good if implemented utilizing some zero-knowledge technology (zkSNARKs and closely related families are the most commonly applied recently but ideally it'd be something that doesn't require a secure setup).

Intuitively, you would provide privacy-preserving offline attestations that e.g. one of a set of trusted parties has verified that you're a legal resident of jurisdiction X or over Y years of age, without needing to disclose any private identifiers.

Reply on news.ycombinator.com