Live data from Hacker News

Google Cloud fraud defense, the next evolution of reCAPTCHA

cloud.google.com

281–290 of 467 posts

Re: Google Cloud fraud defense, the next evolution of reCAPTCHA

#281
post #269
post #8

The requirements for the mobile devices are listed here: https://support.google.com/recaptcha/answer/16609652 So it seems that you will need a modern Android device with Google Play Services installed or a modern iPhone/iPad to be allowed to browse the web in the future. No mention of device integrity verification yet, but the writing is on the wall.

And you must be signed in. I frequently get flagged as suspicious activity and have to pass a captcha when trying to use the Google verbatim search function on a signed out Firefox browser on android.

I get it all the time on my Mac with Safari using iCloud private relay

Re: Google Cloud fraud defense, the next evolution of reCAPTCHA

#282
post #99

I can't believe promoting the QR code-based challenge as the agentic way of fraud defense. Having non-human readable data input is dangerous if somehow the QR code is comprised with a zero-day URL, it's game-over. Note: I know QR code is ubiquitous these days, but still blinding scanning a QR code to go to accessing an URL is like running a binary downloaded from the internet. Note2: yes, the `curl $URL | bash` insta…

Unregulated greed doesn't care if every user gets robbed and their identity stolen.

Re: Google Cloud fraud defense, the next evolution of reCAPTCHA

#283
post #31

Earlier quoted context omitted.

No browser supports Bluetooth.

These passkey QR codes don't need to use Web Bluetooth API, because they utilize the WebAuthn API. The website itself isn't given access to the bluetooth, the task is handed off to the browser, which as a native application, can access bluetooth and abstracts the bluetooth away.

That's passkey QR codes generated by the browser, it has nothing to do with random QR codes offered by websites.

Re: Google Cloud fraud defense, the next evolution of reCAPTCHA

#284
post #31

Earlier quoted context omitted.

No browser supports Bluetooth.

Chrome does...

That's news to me https://developer.mozilla.org/en-US/docs/Web/API/Web_Bluetoo...

Websites cannot use Bluetooth anywhere. The QR codes shown in the blog post are not passkey QR codes, which is likely what's confusing you.

Re: Google Cloud fraud defense, the next evolution of reCAPTCHA

#288

Any company that requires me to scan a QR code to make a purchase is losing my purchase.

Scanning QR in your bank app for payment is near universal in Europe. In fact, it is considered very annoying if a site does not provide the option.

I’m European, never encountered the system you describe.

What is it and why does it exist? Apple Pay has been widely available since 2016. Why would anyone want to use some clunky QR-code thing instead?

Re: Google Cloud fraud defense, the next evolution of reCAPTCHA

#289

Earlier quoted context omitted.

In this specific case, why fear the government? My government has already seen my government-issued ID. If my government hasn't worked out my phone number, they can always ask the phone company. My address is required for the ID, voting, and filing taxes. I don't see how the government learns anything from this? Conversely, I would like to believe most companies do not have my government-issued ID, nor a lot of the i…

From an American perspective, i don't trust the government with the implementation details, nor do I trust our political climate, misaligned incentives, and general disinterest in good governance to implement something so sensitive. If I lived in say, Sweden, I feel much more comfortable trusting their government to implement. In America, I feel I must always vote in a way that prevents giving any power to the govern…

In said US of America, when the government wants to know something about you, they will get everything they want from the companies - it's even written clearly in the US laws. So I'm not sure why (or where) you draw that line...

Re: Google Cloud fraud defense, the next evolution of reCAPTCHA

#290

Earlier quoted context omitted.

The alternative would be tar traps that only a bot would “see” and interact with and thus be caught by. Default to annoying machines not people.

Your idea works for generic crawlers. That doesn't work for targeted bots. A major benfit of device attestation is to stop the hordes of custom bot creators who try all sorts of ways to make a buck off of your platform such as sms toll fraud, credit card testing, ad fraud, account takeovers, stolen card laundering, gift card laundering, botting for pay for platform / ecosystem benefits, paid harassment, the list just…

> A major benfit of device attestation is to stop the hordes of custom bot creators

Attestation is extremely ineffective at preventing this because it requires attackers be unable to compromise their own devices, even when they have permanent physical access to the hardware and can choose which model to buy and get devices known to be vulnerable.

For example, CVE-2026-31431 is from only a week ago. It's a major local privilege escalation vulnerability. If you can run unprivileged code you get root. How many people have Android phones that can pass attestation but will never see the patch because the OEM has already abandoned updating them? Tens of millions, hundreds of millions?

Attackers can trivially get root on a device that passes attestation. Many devices even have vulnerabilities that allow the private keys to be extracted.

The main thing attestation actually does is beset honest users who just want to use their non-Android/iOS device without getting a million captchas, because they chose the device they wanted to use as a real human person instead of doing as the attackers do and choosing a device for the purpose of defeating the attestation.

And it's easy to confuse this with real effectiveness because whenever you roll out any security change, the attacks may subside for a short period of time as the attackers adapt to it. But that's why it makes sense to avoid things that screw innocent people or entrench monopolies -- while the temporary effectiveness wears off, the screwing becomes permanent. Meanwhile spending the same resources on any other method of shuffling things around to make them adapt will give you the same temporary effectiveness without hurting your legitimate users.

Post reply on HN