The editorial argues attestation was sold as anti-fraud but is functionally becoming an allowlist of OSes blessed by a single company. It traces the pattern from banks to McDonald's to Netflix to transit apps and now car companion apps, framing VW's choice as another data point in a structural shift.
The editorial highlights that GrapheneOS passes the meaningful integrity checks — verified boot, locked bootloader, hardware-backed key attestation via Titan M2/Tensor — and in many cases offers stronger boot-time guarantees than an unpatched stock Pixel. The block therefore isn't about real security but about the absence of a commercial GMS certification flag.
The GrapheneOS project diagnoses VW's switch to MEETS_STRONG_INTEGRITY as the cause and points out that their OS satisfies the underlying hardware-backed attestation requirements. Their position is that the failure is purely about Google's certification list, not any actual weakness in the device.
Submitted the thread that surfaced the issue to 731 points, capturing the broad user frustration that a high-priced product's companion app can be silently revoked based on OS choice. The framing centers consumer ownership rights and the absurdity of a car you bought refusing to talk to a phone you own.
The editorial stresses that Play Integrity exposes three explicit verdict tiers and developers must consciously pick one. VW picked the tier Google's own docs describe as gating apps to 'Google-certified Android devices,' meaning the exclusion of GrapheneOS, CalyxOS, LineageOS and /e/OS is a chosen policy, not a side effect.
Volkswagen's MyVW companion app — the thing you use to unlock your car, check charge state, and pre-condition the cabin — stopped working on GrapheneOS this week. The thread on discuss.grapheneos.org hit 731 on Hacker News, and the diagnosis from the GrapheneOS team is unambiguous: VW switched on the strictest tier of Google's Play Integrity API, the one that demands `MEETS_STRONG_INTEGRITY` plus Google's Play Protect certification, and GrapheneOS — by design — is not on Google's certification list.
GrapheneOS actually passes the meaningful integrity checks: verified boot, locked bootloader, hardware-backed key attestation via the Titan M2 or Tensor security chip. What it doesn't carry is Google's commercial seal of approval, because it isn't shipped by an OEM that signed a GMS license. So VW's app sees a phone with stronger boot-time guarantees than a stock Pixel running an unpatched two-year-old build, looks at the certification flag, and bounces the user to an error screen.
This isn't an oversight. The Play Integrity API has three verdict tiers — `MEETS_BASIC_INTEGRITY`, `MEETS_DEVICE_INTEGRITY`, and `MEETS_STRONG_INTEGRITY` — and developers explicitly choose which one to require. VW chose the tier that, in Google's own documentation, is described as gating apps to "Google-certified Android devices." The decision excludes GrapheneOS, CalyxOS, LineageOS, /e/OS, and roughly every custom Android distribution that has ever existed.
The immediate reaction in the thread is the obvious one — "so I bought a $50,000 car and now I can't use the app on my phone" — but the structural story is more interesting. Attestation was sold to the ecosystem as an anti-fraud tool; in practice it's becoming an OS allowlist, and the allowlist is maintained by exactly one company. Banks pioneered this. Then McDonald's, then Netflix, then state transit apps. Now it's reaching the cabin of your car.
The GrapheneOS project has been the loudest critic of this drift for years, and their argument is technically sharp: Play Integrity does not actually measure security. It measures *compliance with Google's commercial program*. A Samsung phone three major versions behind on patches passes `STRONG_INTEGRITY` because Samsung is on the list. A GrapheneOS Pixel 9 running this month's security patch, with a verified boot chain and hardware attestation, fails — because the project isn't on the list and Google has refused to add a path for it to be. Daniel Micay and the GrapheneOS team have repeatedly pointed out that Android's own remote attestation primitives are publicly documented and could be used directly by any developer who actually cared about device security rather than ecosystem lock-in. Almost nobody does.
VW's specific situation has an extra wrinkle: cars are increasingly companion-app-dependent for features the owner paid for. Remote start, climate pre-conditioning, charge scheduling, and on some trims even valet mode are app-gated. When a car manufacturer outsources its identity check to Google's certification program, it has effectively delegated "can this customer use the product they bought" to a third party with no contractual obligation to that customer. If Google decides tomorrow that a particular OEM is non-compliant, every car owner running that phone loses functionality. The GrapheneOS thread surfaced exactly this: users reporting that the MyAudi and MySkoda apps (same VW Group backend) are showing identical behavior, suggesting a platform-wide rollout, not a one-team mistake.
The community response has been blunt. Several commenters pointed out that VW has a non-trivial security-research user base — the kind of people who *should* be running hardened operating systems — and the company has just told them to either downgrade their OS or stop using paid features. Others noted the irony of an automaker whose 2015 emissions scandal hinged on detecting test environments now deploying an attestation system whose entire purpose is detecting non-standard environments.
If you ship a mobile app and you're considering enabling Play Integrity's strictest tier, the GrapheneOS thread is worth reading before you do. The tradeoff is not "more security vs. less security" — it's "fewer fraud incidents from a small population of advanced users vs. permanent exclusion of every privacy-conscious customer you have." For most consumer apps, the fraud math probably doesn't justify it. For banking and payments there's a regulatory argument; for unlocking a car door, there isn't one.
The practical alternative exists and is well-documented: use `MEETS_DEVICE_INTEGRITY` (which GrapheneOS passes) instead of `MEETS_STRONG_INTEGRITY`, or — for genuinely high-value flows — use Android's hardware-backed `KeyAttestation` directly. Both approaches give you cryptographic evidence the device hasn't been tampered with, without delegating the policy decision to Google's certification team. The reason most developers don't is that the strict-tier flag is a one-line config change and the direct attestation path takes a week of engineering. That's a defensible product decision, but it should be made knowingly, not by reflex.
For anyone running a hardened OS as a daily driver: the workaround pattern is now well-established. A secondary profile (GrapheneOS supports up to 32) with sandboxed Google Play installed gives you a contained environment to run attestation-gated apps without compromising the main profile. It's inconvenient. It's also the only path that doesn't involve trusting a stock Android build with your full digital life just to start your car remotely.
The regulatory pressure on this is building. The EU's Digital Markets Act already classifies Google as a gatekeeper, and there's a live argument — pushed hardest by the GrapheneOS project itself — that Play Integrity's certification requirement constitutes an anti-competitive restriction on alternative Android distributions. Expect this fight to land in Brussels before it lands in any US courtroom, and expect car manufacturers to be the sympathetic defendants regulators use to make the point. Until then, the practical advice is unchanged: assume every consumer app you don't control may revoke access to your device next quarter, and architect your dependence on them accordingly.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.