Apple and Google are bringing hardware attestation to the web. GrapheneOS says it's a monopoly play.

The GrapheneOS Mastodon thread posted on May 10 hit the top of Hacker News with 1,270 points. The argument: Apple’s App Attest and Google’s Play Integrity API aren’t security primitives. They’re tools to lock the mobile and desktop web to devices Apple or Google has certified, and reCAPTCHA Mobile Verification is bringing that gate to desktops.

GrapheneOS Foundation has been making this case for years. The May 10 thread crystallizes it because of the reCAPTCHA piece. The mobile attestation duopoly was a problem for people running alternative OSes on phones. The reCAPTCHA gate is a problem for everyone running any operating system on any device, because a Google captcha that fails without a certified-phone handshake is a captcha the open web can’t pass.

What hardware attestation actually does

A hardware-attestation API lets an app ask a phone’s secure element to sign a statement of the form “this device is running this specific OS image with these verified-boot keys.” The cryptographic part is real. A secure element on a Pixel or an iPhone can attest to the OS image without trusting anything in software, including the OS itself. That’s how, in principle, GrapheneOS can prove to an app that it’s running a signed GrapheneOS build and not a rooted hack.

The trick is what the app does with that signed statement. The Android hardware attestation API permits arbitrary roots of trust. An app could accept a Pixel running GrapheneOS, a Pixel running stock Android, an iPhone running iOS, or a FreeBSD phone with its own secure element, all in the same code path. That isn’t what most apps do. Most apps call Play Integrity or App Attest, which wrap hardware attestation in a policy that accepts only Apple-signed and Google-Mobile-Services-Android-signed OS images. Everything else gets bounced.

The GrapheneOS thread is blunt about the framing. “The purpose of these systems is disallowing people from using hardware and software not approved by Apple or Google,” the Foundation wrote. “This is wrongly presented as being a security feature.”

What’s actually blocked

The Attestation Compatibility Guide on GrapheneOS’s site catalogs the affected apps. Government services are the headline category: Australia’s myGov, Brazil’s gov.br, Switzerland’s SwissID, Singapore’s Singpass, Italy’s IO and PosteID. Banks and payment apps come next, including Authy, mada Pay, and McDonald’s payment integration. Ride-sharing and ticketing apps (Dott, Ticketcorner) join the list, then health services like Germany’s TK-Doc and TK-App.

The pattern is striking when you read it as policy rather than security. Government-run digital-ID services in the EU, where competition law is supposed to be strongest, are among the most aggressive enforcers of Play Integrity. A user in Brazil reported in the thread that “Brazilian government app ‘gov.br’ requires Play Integrity too. There’s no fallback, no alternative verification method.” A user in Germany wrote that they can only make appointments at local government offices via their spouse’s iPhone.

The web extension

The reCAPTCHA piece is what triggered the May 10 thread. Google’s help page describes Mobile Verification as a captcha-fallback flow. On Apple hardware, it uses Privacy Pass tokens generated by App Attest. On Google-certified Android, it uses Play Integrity. For Windows, desktop Linux, OpenBSD, or anything else, it falls back to a QR-scan handshake that pairs the desktop browser with a certified phone.

GrapheneOS reads the architecture as a deliberate fan-out. “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 Foundation wrote. The current rollout works with sandboxed Google Play on GrapheneOS, but the Foundation argues that’s a transitional state, and the policy layer can tighten at any time without code changes.

There’s a second-order issue the Foundation flagged about Google’s Play Integrity policy: it permits devices with no security patches for 10 years, while banning a strictly more secure GrapheneOS build. The security excuse fails on its own terms when the policy promotes attestation over patch state. Google’s own Play Integrity documentation frames Mobile Verification as a fraud-mitigation tier; the framing only holds if Google-certified Android is meaningfully more secure than GrapheneOS, and on patch latency alone it isn’t.

The current bypass economy is the other piece worth knowing. The Play Integrity device-integrity level can be spoofed by software frameworks that ship leaked Google attestation keys. The strong-integrity level requires keys leaked from a Trusted Execution Environment or Secure Element, which trade on grey markets. Both kinds of bypass are getting harder to maintain because Google can revoke leaked keys server-side at scale, the Foundation says. Long-term, the only reliable way to pass Play Integrity is to be Apple or Google. That is the point.

Regulator capture

Governments would normally be the check on this kind of platform-defined gate. The thread’s most pointed claim is that they’re directly participating instead. EU member states’ mandates on digital ID, age verification, and payments increasingly require Play Integrity or App Attest as a baseline. The U.S. Federal Reserve’s instant-payment scheme has comparable language. Australia’s myGov pulled GrapheneOS off the supported list in 2024. None of these is a private platform choice; each is a regulator backing the duopoly.

The Unified Attestation initiative pushed by several European companies in late 2025 is, per the Foundation, a worse version of the same problem dressed in European-industry clothing. The thread points to that as the direction of travel: attestation becomes a shared infrastructure layer that no individual platform owns but every platform can use to ban anything that isn’t pre-approved.

GrapheneOS has been arguing for the alternative inside the existing API for years. Android’s hardware attestation can verify any operating system, including alternative ones, as long as the app is willing to accept a non-Google root of trust. The Foundation has published the receiver code in the Auditor reference app. App developers don’t have to switch APIs. They have to switch policy. The Foundation’s framing of Google’s position is direct: Google bans GrapheneOS in Play Integrity because GrapheneOS does not license Google Mobile Services, not because of any technical or security gap.

That distinction matters legally. South Korea’s Fair Trade Commission has already ruled that conditioning APIs on GMS licensing is anti-competitive. EU competition law has comparable hooks. The Foundation has signaled it is in contact with regulators, though no formal complaint has been published.

What this means for you

If you run an alternative mobile OS, the gate keeps narrowing. The set of apps that work on GrapheneOS, /e/OS, or any de-Googled Android image continues to shrink as government services, banks, and payment apps adopt Play Integrity. The Foundation has been blunt that the long-term fix is regulatory: an order requiring Play Integrity to accept any OS whose hardware attestation is valid. Until that lands, expect the workable-app list to keep getting smaller.

If you run a desktop OS that isn’t Windows or macOS, the reCAPTCHA Mobile Verification rollout is the thing to watch. The current state is benign. The architecture is not. The moment a major web service decides reCAPTCHA Mobile Verification is its only captcha tier, a Linux user without an iPhone or Google-certified Android phone is locked out.

If you’re a builder, the practical advice is to avoid making Play Integrity or App Attest a hard requirement when a softer signal works. Most apps that gate on Play Integrity don’t need to. The fraud risk is real for a payment processor; it isn’t real for a ticketing app. Defaulting to “attestation or nothing” pushes the lock-in cost onto users who never picked iOS or Google-certified Android in the first place.