The editorial frames Volkswagen's block as emblematic of a broader industry pattern: 'modified OS' has become a default reason to refuse service, with vendors unilaterally defining what counts as modified. VW sold cars marketed as 'connected,' but that connectivity now requires a Google-blessed phone image, effectively gating paid functionality behind OS vendor approval.
The submitter surfaced the GrapheneOS forum thread to Hacker News where it reached 281 points, framing it as Volkswagen actively blocking a privacy-focused OS rather than a neutral compatibility issue. The high score and engagement signal community alignment that this is a notable overreach worth amplifying.
The editorial points out that GrapheneOS passes Play Integrity's basic and device integrity verdicts via Pixel's hardware-backed keystore — meaning the device is provably genuine and the bootloader state is attested. VW is keying off the strong verdict, which requires Google-certified software specifically, conflating 'not stock Google' with 'untrustworthy' even when hardware attestation proves otherwise.
The editorial explicitly notes GrapheneOS's small user base is a rounding error against VW's sales volume, so the impact isn't the affected user count. The real concern is that the definition of 'modified' is set unilaterally by app vendors on a per-Tuesday basis, establishing that buyers don't actually own the remote functions of cars they purchased.
GrapheneOS users running the official Volkswagen companion app — variously branded My Volkswagen and We Connect ID. depending on region and model year — started seeing a hard refusal screen this month. The app loads, checks the device, and exits with a generic 'modified operating system detected' message. The thread on the GrapheneOS forum is now three pages deep, mirrored on Hacker News at 281 points, with users reporting the same behavior across Pixel 7, 8, and 9 hardware running current GrapheneOS releases.
The block is not subtle. It's not a warning, not a degraded-mode fallback, not a 'some features unavailable.' The app simply will not run. That matters because the VW companion app is the only first-party way to do remote lock/unlock, climate pre-conditioning, charge scheduling on the ID. line, and — for newer model years — the only way to view trip data without plugging in a laptop. Volkswagen sold the car as 'connected.' The connection now requires a phone Volkswagen approves of.
The technical detail worth noting: GrapheneOS passes Google's Play Integrity API basic and device integrity verdicts on Pixel hardware, because Pixels' hardware-backed keystore can attest the bootloader state and GrapheneOS preserves that attestation chain. It fails the *strong* integrity verdict, which requires Google-certified software specifically. VW's app is reading the strong verdict — or layering its own SafetyNet-style check on top — and rejecting anything that isn't a stock Google-blessed image.
This isn't really a GrapheneOS story. GrapheneOS has roughly 100,000 users; Volkswagen sells that many cars in Germany alone in a slow month. The story is that 'modified OS' is now an industry-default reason to refuse service, and the definition of 'modified' is whatever the app vendor decides on a given Tuesday.
The Play Integrity API has three verdict tiers. MEETS_DEVICE_INTEGRITY says the device is genuine and unrooted. MEETS_BASIC_INTEGRITY is a weaker signal that the device hasn't been obviously tampered with. MEETS_STRONG_INTEGRITY additionally requires that the OS is Google-certified — i.e., stock Android shipped by an OEM through Google's compatibility program. GrapheneOS clears the first two on Pixels. It cannot clear the third by design, because the third is essentially 'is this Google's Android.' Banking apps started enforcing strong integrity in 2023. Streaming DRM apps followed. Now: car apps.
Volkswagen has not published a security rationale, and the community has not produced a credible one. A car's remote-unlock flow lives behind OAuth and per-account credentials on VW's side; the threat model the app block addresses is unclear. The likeliest explanation is the unsexy one: VW's mobile team turned on a compliance toggle, the toggle defaults to strong integrity, and nobody internally pushed back because the affected user count rounds to zero. The community thread includes one user who got through to a VW support rep and was told, verbatim, that 'rooted or modified devices' aren't supported — language that strongly suggests a checkbox, not a policy.
The deeper pattern: every layer of the modern app stack is converging on attested, OEM-blessed execution environments as the default trust signal, and 'I compiled my own OS' is becoming functionally equivalent to 'I am running malware.' Apple's App Attest, Google's Play Integrity, Microsoft's Pluton, the EU's eIDAS wallet attestation requirements — they all assume the user does not own the trust root on their own device. For a developer audience, that's the part to sit with. The phones you ship to are increasingly devices where *you* don't get to decide what counts as a trustworthy runtime; a remote vendor does.
Community reaction in the HN thread split predictably. The right-to-repair / digital-sovereignty camp framed it as exactly the dystopia they warned about: you bought the hardware, you don't own the software, and the manufacturer can revoke functionality post-sale by changing an API check. The pragmatist camp pointed out that GrapheneOS users self-selected into a tradeoff and this is the bill arriving. Both are correct. The interesting question isn't who's right — it's whether a single VW support ticket can ever reverse a decision that was almost certainly made by a config flag nobody at VW remembers turning on.
If you ship a mobile app and you're using Play Integrity, decide today which verdict tier you actually need, and document it. Defaulting to strong integrity because the SDK makes it one line means you're blocking GrapheneOS, CalyxOS, /e/OS, LineageOS, every custom ROM, and — periodically — beta channels of stock Android where attestation lags. The maintenance cost of those false positives shows up later, in support tickets you'll route to /dev/null because the user 'modified' their device.
If you're a developer on GrapheneOS (and a non-trivial slice of the security-conscious dev community is), the practical playbook is unchanged but worth restating: keep a stock-Android secondary device for vendor apps that refuse to negotiate, prefer web-based control panels where the manufacturer offers one (VW's does, partially), and treat any 'connected car' feature as something the OEM can withdraw at will. The honest version of the connected-car value proposition is now 'features available while your phone remains compliant.'
For architects making platform decisions: if your product roadmap assumes 'mobile is the control plane,' the trust model under that control plane is hardening into something you don't control. A web-first or open-API fallback isn't just a nice-to-have for the 0.1% of users on custom ROMs — it's the only path that survives the next round of attestation tightening, which will inevitably catch some sliver of stock devices too. Ask anyone who shipped during the SafetyNet → Play Integrity transition in 2024.
The VW block will probably be quietly reversed — not because of principle, but because the GrapheneOS community is unusually well-organized at getting these decisions in front of someone with authority to flip the flag back. (See: the Revolut and Wise reversals in 2024.) The structural trend is the one to watch. Every quarter, more apps gate on stronger attestation, and every quarter, the set of acceptable Android distributions shrinks toward exactly one: the one Google ships, on the phone Google certified, on the carrier Google blessed. A connected car that refuses to talk to a Pixel running open-source Android is a small story. A consumer-electronics ecosystem where 'open' is being slowly redefined as 'unsupported' is a much bigger one.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.