GrapheneOS fixes Android VPN leak Google refused to patch

Original Article ↗ Hacker News Discussion ↗

Android’s handling of VPN traffic is under fire after researchers showed that a privileged system component could bypass “always‑on” VPNs, leaking data outside the encrypted tunnel — an issue Google declined to treat as a security bug. GrapheneOS, a privacy-focused Android fork for Pixel devices, has already mitigated the flaw by disabling the QUIC-related optimization that enabled the leak and says it is working on broader VPN hardening. Commenters use the case to highlight systemic problems in mobile privacy, from OS‑level traffic exemptions and carrier lock‑in to dependence on Google’s ecosystem, while weighing alternatives like future Motorola-based GrapheneOS phones, Linux phones, and other custom ROMs.

Google’s handling of the VPN leak

  • Many commenters criticize Google for classifying the leak as “not a security issue,” especially because it occurs in system_server, a privileged process.
  • Android’s own lockdown mode promises that no traffic bypasses the VPN; this behavior violates that promise at the kernel level.
  • Some see this as a clear security bug (sandbox escape / privilege escalation); others suggest Google may be operating under a narrower definition linked to its bug bounty program.

What a VPN should guarantee

  • Disagreement over the role of VPNs:
    • One view: VPNs were originally for corporate network access; privacy/anonymity guarantees were never core.
    • Another view: Modern users reasonably expect “all traffic goes through the tunnel,” so any bypass is a critical privacy failure.
  • It’s noted that iOS and macOS have had similar “always-on VPN” bypasses, suggesting a broader OS design pattern.

GrapheneOS’s fix and broader VPN work

  • GrapheneOS mitigates the leak by disabling the registerQuicConnectionClosePayload optimization; VPN functionality and QUIC still work.
  • Developers mention they have already fixed multiple Android VPN leaks and plan deeper architectural changes (e.g., better per-profile isolation, potential VM-based app isolation).

Trust, surveillance, and platform incentives

  • Several comments frame stock Android as adware/spyware, arguing that Google’s ad and offense-related business interests disincentivize strict VPN enforcement.
  • Some speculate that governments and large organizations value such de-anonymization vectors, though concrete evidence is not provided in-thread.
  • There’s discussion that terms like “private” and “trust” are easily misunderstood by non-experts.

Hardware support: Pixels, bootloaders, and Motorola

  • GrapheneOS currently targets Pixels; some are reluctant to buy Google hardware for ethical or reliability reasons, despite others praising the security features (MTE, Titan M2) and long support windows.
  • Carrier-locked Pixels (especially Verizon in the US) often cannot unlock bootloaders, blocking GrapheneOS installs; buying directly from Google or proven-unlockable used devices is advised.
  • A partnership with Motorola is discussed; support is expected in future models, but price and timeline details remain uncertain/unclear.

Alternatives: other ROMs and Linux phones

  • LineageOS is praised for UX; GrapheneOS for security; CalyxOS for a more “vanilla” feel, though its security posture and bundled apps are heavily criticized by some.
  • Linux phones (Librem, postmarketOS devices, Fairphone) are mentioned:
    • Pros: independence from Google, free software drivers where possible.
    • Cons: weak hardware, poor performance, and often inadequate security hardening and update policies.

App distribution and F-Droid debate

  • GrapheneOS ships a minimal first-party App Store and mirrors Accrescent and Google Play. Community often recommends Obtainium for fetching developer-signed releases.
  • Some users dislike the “Russian doll” of multiple app sources and prefer a single F-Droid-style repository.
  • Strong criticism of F-Droid appears: outdated infrastructure, security weaknesses, and rebuilding/signing apps themselves.
  • Others defend F-Droid as a valuable, transparent intermediary that centralizes trust and tries to catch malicious changes, arguing this is safer than trusting “millions of developers” individually.