
Key takeaways
- Google's reCAPTCHA Mobile Verification now requires hardware attestation via Play Integrity API or Apple's Privacy Pass to pass certain challenges
- GrapheneOS posted a 14-tweet thread on May 10 calling the change anti-competitive and warning it locks out alternative operating systems from the web
- The system extends to Windows, Linux, and desktop platforms by requiring users to scan a QR code from a certified iOS or Android device
The Move
Google announced an update to reCAPTCHA Mobile Verification at Google Cloud Next on April 22, replacing image puzzles with a QR-code challenge for suspicious traffic. The mechanism leans on hardware attestation. To pass, the device has to prove it is either a certified Apple device using Apple's Privacy Pass or a Google-certified Android device running an unmodified copy of Google Play Services 25.41.30 or later. Stock Android passes. iOS passes. Custom Android ROMs do not.
The most affected category is privacy-focused Android variants like GrapheneOS, CalyxOS, and /e/OS. These projects deliberately strip out or sandbox Google services to reduce telemetry and tighten the security model. Users running these systems can no longer reliably complete certain reCAPTCHA challenges, which means they can no longer reliably access whatever websites and services those challenges gate.
GrapheneOS Is Not Mincing Words
GrapheneOS posted a long thread on X on May 10 framing the change as a tool to enforce the Apple-Google mobile duopoly. The project pointed out that its operating system is more secure than the stock Android builds that Google whitelists, and that Play Integrity API permits devices with no security patches for up to ten years while banning GrapheneOS outright.
'Control over reCAPTCHA puts Google in a position where they can require having either iOS or a certified Android device to use an enormous amount of the web.'
The thread also flagged a broader vector. Apple's Privacy Pass already exports hardware attestation from iOS to the web. Google has telegraphed similar plans, and the QR-code path lets it impose mobile attestation even on Windows, desktop Linux, and OpenBSD machines. A laptop user without an approved smartphone in arm's reach could find themselves locked out of reCAPTCHA-gated sites entirely.
Where Bitcoin Sits In This
Many Bitcoiners run GrapheneOS for the same reasons they run their own node: trust minimization, sovereignty over the device, and exit from surveillance defaults. Sparrow Wallet, Bitcoin Core, Wasabi, and several Lightning wallets all run cleanly on GrapheneOS. The risk is not to those local apps, which do not need Google's permission. The risk is to the web-based services around them: exchanges with reCAPTCHA-gated logins, know-your-customer (KYC) providers, custodial backstops, banking on-ramps and off-ramps. The friction is asymmetric. The harder the web gets for non-approved devices, the more the convenience tax pushes users back onto stock smartphones with full Google or Apple telemetry.
Why It Matters
This is the device-attestation version of the same fight Bitcoiners have always had with state and corporate gatekeepers. The argument is framed as security, but the practical outcome is control. Google permits unpatched devices for a decade and bans a more secure alternative because the alternative does not license Google Mobile Services. That is anti-competitive behavior, not a security model, and South Korean regulators have previously ruled adjacent Google Mobile Services bundling practices unlawful. For Bitcoiners, the lesson is durable: anything that depends on a permission slip from Apple or Google is a permissioned system. Self-host where you can. Use Bitcoin services that work without attestation. And keep voting with your hardware.



































































