GrapheneOS fixes Android VPN leak Google refused to patch

Original Article ↗ Hacker News Discussion ↗

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.