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.
Google Cloud fraud defense, the next evolution of reCAPTCHA
281–290 of 467 posts
Re: Google Cloud fraud defense, the next evolution of reCAPTCHA
#282I 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…
Re: Google Cloud fraud defense, the next evolution of reCAPTCHA
#283Earlier 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.
Re: Google Cloud fraud defense, the next evolution of reCAPTCHA
#284Earlier quoted context omitted.
No browser supports Bluetooth.
Chrome does...
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
#285Re: Google Cloud fraud defense, the next evolution of reCAPTCHA
#286Re: Google Cloud fraud defense, the next evolution of reCAPTCHA
#287Re: Google Cloud fraud defense, the next evolution of reCAPTCHA
#288Any 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.
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
#289Earlier 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…
Re: Google Cloud fraud defense, the next evolution of reCAPTCHA
#290Earlier 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…
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.