GrapheneOS argues that Play Integrity and App Attest don't answer 'is this device secure?' but rather 'does Google vouch for this device's software stack?' They demonstrate that GrapheneOS is arguably more secure than stock Android, yet fails attestation checks — proving the mechanism enforces vendor control, not actual security.
GrapheneOS details how the attestation certificate chain leads back to a root certificate controlled by Google, meaning only Google-approved software stacks pass verification. This creates a growing barrier for users of GrapheneOS, LineageOS, CalyxOS, or any alternative distribution — effectively gatekeeping access to banking apps, payment processors, and everyday services behind vendor approval rather than technical merit.
The editorial emphasizes that for the ~99% of users on stock OSes this is invisible, but for anyone running alternative distributions — including developers who unlock bootloaders for legitimate purposes — attestation is an expanding barrier to participating in digital life. The piece frames this as a sleight of hand with implications far beyond mobile OS hobbyists.
The editorial argues that banking apps, streaming services, and payment processors increasingly gate access behind Play Integrity checks without evaluating whether the check actually corresponds to a security risk. By blindly trusting Google's verdict rather than implementing their own risk assessment, these developers entrench the platform monopoly while providing no real additional security benefit.
GrapheneOS — the privacy-focused Android fork widely regarded as one of the most security-hardened mobile operating systems available — published a detailed critique of how hardware attestation mechanisms are being weaponized as monopoly enforcement tools. The post, which hit 1,470 points on Hacker News, lays out a case that developers building on Android and iOS should find deeply uncomfortable: the attestation APIs that Google and Apple provide don't actually measure device security — they measure device compliance with the platform vendor's business model.
The core mechanism is straightforward. Google's Play Integrity API (the successor to SafetyNet Attestation) and Apple's App Attest allow server-side applications to query a device and receive a cryptographic verdict: is this device running an unmodified, vendor-approved OS with a locked bootloader? If the answer is no, the app can refuse to function. Banking apps, payment processors, streaming services, and an expanding list of everyday applications now gate access behind these checks.
For the roughly 99% of users running stock Android or iOS, this is invisible. For anyone running GrapheneOS, LineageOS, CalyxOS, or any other alternative distribution — including developers who unlock their bootloader for legitimate purposes — it's a growing barrier to participating in digital life.
The technical sleight of hand here is worth understanding precisely, because it has implications far beyond mobile OS hobbyists.
Hardware attestation uses a chain of trust rooted in a key burned into the device's secure element at the factory. That key is signed by the device manufacturer (typically Google, Samsung, or Qualcomm), and the attestation certificate chain leads back to a root certificate controlled by Google. When an app calls Play Integrity, it's not asking "is this device secure?" — it's asking "does Google vouch for this device's software stack?" Those are fundamentally different questions.
GrapheneOS demonstrates this gap vividly. The OS implements verified boot, full filesystem encryption, hardened memory allocators, and a sandboxed Google Play compatibility layer that's arguably more secure than Google's own implementation on stock Pixel devices. Independent security audits have consistently rated GrapheneOS's attack surface reduction as superior to stock Android. But none of that matters to Play Integrity's "strong" verdict, which requires hardware-backed attestation keys provisioned through Google's supply chain.
The result is a market structure where security and access are inversely correlated for power users. The more you harden your device, the less you can do with it. A stock Pixel running months-old security patches with dozens of pre-installed Google services passes attestation. A GrapheneOS Pixel running the latest patches with a minimal attack surface fails it.
This isn't a hypothetical concern. Banking apps in Europe, India, and increasingly the US have moved to mandatory Play Integrity checks. Government digital identity apps in several EU member states require attestation. Japan's My Number card app requires it. The practical effect is that choosing an alternative OS now means choosing to be excluded from financial services, government services, and a growing list of commercial applications.
Developers with long memories will recall Google's Web Environment Integrity (WEI) proposal from 2023. The idea was to extend hardware attestation to the browser: websites could request a cryptographic token proving the user's browser and OS were "legitimate" before serving content. The backlash was immediate and fierce — the W3C community, Mozilla, Brave, and the broader web standards community recognized it as DRM for web pages. Google withdrew the proposal.
But the underlying infrastructure never went away. WEI was the logical endpoint of hardware attestation: a world where every interaction with a digital service requires the device to prove fealty to its platform vendor. The mobile app ecosystem is already there. The web narrowly avoided it — for now.
What GrapheneOS is pointing out is that the app-level attestation regime is already doing most of what WEI would have done, just through a different enforcement channel. If every essential app requires attestation, it doesn't matter that the browser is still open. Users are locked into the duopoly regardless.
If you're a developer implementing Play Integrity or App Attest in your app, you're making a choice — and you should make it deliberately rather than by default.
First, ask whether you actually need hardware attestation. Most apps that implement it are doing so because a compliance checklist or a security consultant told them to, not because they've modeled a specific threat that attestation mitigates. If your concern is bot abuse, there are less exclusionary approaches (rate limiting, behavioral analysis, CAPTCHAs). If your concern is rooted devices, consider that a rooted GrapheneOS device with a hardened kernel is a less favorable target than a stock Samsung phone with Knox tripped and six months of unpatched CVEs.
Second, understand the "basic" vs. "strong" distinction. Play Integrity returns three verdict levels: basic, device, and strong. Basic integrity can be satisfied by software-only checks and doesn't exclude alternative OSes as aggressively. Many apps that implement "strong" attestation don't need it — they're just calling the highest-assurance API because it exists. If you're building an app that gates access behind strong hardware attestation, you are actively participating in platform lock-in, whether you intend to or not.
Third, consider the regulatory trajectory. The EU's Digital Markets Act explicitly targets platform gatekeeping. The US DOJ's antitrust case against Google has surfaced internal documents about Play Integrity's competitive effects. Hardware attestation as a lock-in mechanism is on regulators' radar. Building your security model on attestation today may mean scrambling to replace it when regulators force interoperability requirements.
For teams running custom or hardened Android deployments in enterprise or government contexts — and there are more of you than the consumer market suggests — this is an operational risk. If your MDM fleet runs a custom Android build, Play Integrity failures will increasingly break the apps your users depend on.
The hardware attestation debate is really a proxy war for a bigger question: who decides what software is legitimate? The current answer — Google and Apple, through cryptographic mechanisms burned into silicon — is a historically unprecedented concentration of control over general-purpose computing. GrapheneOS, with its HN score suggesting broad developer sympathy, is making the case that this control serves business interests, not security interests. The technical evidence is on their side. Whether regulators and markets will follow is the open question of the next two to three years.
Requiring authorized silicon (and software) isn't even the biggest problem here.They do not use zero knowledge proof systems or blind signatures. So every time you use your device to attest you leave behind something (the attestation packet) that can be used to link the action to your device. T
In 1999, Intel received an absolutely massive amount of opposition when they decided to include a software-readable serial number in their CPUs, so much that they reversed the decision.Then the "security" and Trusted Computing authoritarians continued pushing for TPMs and related tech, and
This is a really good thread on why this technology is becoming a problem for "open" anything. The argument "we can create our own separate web" is fine until all of your services are behind the web that locks you into owning a Google approved or Apple approved mobile device.
This is tyranny: making people powerless, afraid of each other, and submissive, per Aristotle's understanding.[1] The technological means are new, to be sure, but the social strategy is as old as civilization.Mark my words. General purpose computing and private, direct communication are things
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
The superhuman efforts that folks on HN make to find technical workarounds and solutions is wonderful to see, but we must realize that this is not a technical problem. It's a social and legislative one. It can't be fought on technical grounds. The push back has to be via putting pressure o