The article frames Google's 'acknowledged, won't fix' response as evidence that Android's security model assumes Google's interests and users' interests are aligned — when on VPN behavior, they demonstrably aren't. Connectivity checks reveal a user's real IP to Google's servers, which is exactly what a VPN is supposed to prevent.
The editorial argues that Google has legitimate engineering reasons for connectivity checks but that these reasons don't justify leaking traffic when a user has explicitly toggled 'Block connections without VPN.' The semantics of that toggle create a reasonable user expectation that all traffic is blocked, making Google's position indefensible from a user-trust standpoint.
The editorial emphasizes that for journalists, activists, and security researchers who rely on VPNs to protect their location and identity, leaked connectivity checks and DNS queries during reconnection windows aren't a minor gap — they're 'the gap.' Real IP exposure even momentarily can compromise the safety of vulnerable users.
By reporting the issue with detailed technical evidence and then shipping its own fix after Google declined, GrapheneOS exemplifies how privacy-focused Android forks serve as a necessary corrective layer. The article positions GrapheneOS's patch as proof that the open-source fork model can deliver security outcomes that the upstream vendor refuses to.
The editorial acknowledges that Google has real engineering reasons for the behavior: connectivity checks help determine network state, enable captive portal detection, and feed adaptive connectivity features. The editorial presents this as Google's stated rationale while ultimately arguing it doesn't excuse the user-facing contradiction, but the technical justification itself is not fabricated.
GrapheneOS, the privacy-focused Android fork, has shipped a fix for a VPN traffic leak in Android that Google was notified about but declined to patch. The issue is straightforward and damning: even when users enable Android's "Always-on VPN" and "Block connections without VPN" settings — the combination most people reasonably interpret as a kill switch — Android still sends certain traffic outside the VPN tunnel.
The leaked traffic includes connectivity checks (the requests Android makes to verify internet access), certain DNS queries during VPN reconnection windows, and in some configurations, traffic from system services that bypass the VPN entirely. For users who rely on VPNs to protect their location, identity, or communications — journalists, activists, security researchers — this isn't a minor gap. It's the gap.
GrapheneOS reported the behavior to Google through the Android issue tracker with detailed technical evidence. Google's response: acknowledged, won't fix. Their position is that the connectivity checks and certain system traffic are intentional design decisions, not bugs. From Google's perspective, the VPN kill switch works as designed. From a user's perspective, it doesn't work as advertised.
This story sits at the intersection of two uncomfortable realities in mobile security. First, Android's security model assumes Google's interests and users' interests are aligned — and on VPN behavior, they demonstrably aren't. Google has legitimate engineering reasons for connectivity checks: they help the system determine network state, enable captive portal detection, and feed into adaptive connectivity features. But these checks also reveal your real IP address to Google's servers, which is precisely the thing a VPN is supposed to prevent.
The deeper issue is the semantics of "Block connections without VPN." A reasonable user reads that toggle and assumes it means what it says — block all connections that aren't routed through the VPN. Google interprets it more narrowly: block *app* connections without VPN, but allow system-level traffic that Google deems necessary. This isn't a difference of opinion about an edge case. It's a fundamental disagreement about who the kill switch is for.
The security community's reaction on Hacker News (where the story hit 200+ points) reflects a familiar pattern of frustration. Android's open-source nature means these gaps are discoverable, but Google's dominance means they're not fixable by anyone except Google — or projects like GrapheneOS that maintain their own fork.
GrapheneOS's fix is technically clean: they patched the connectivity check system to route through the VPN tunnel or skip entirely when the kill switch is enabled, and they closed the DNS leak window during VPN reconnection. The fix does exactly what users expected the stock Android toggle to do in the first place. It's the kind of patch that makes you wonder why it wasn't the default behavior.
This isn't the first time GrapheneOS has fixed privacy gaps that Google won't address. The project has previously hardened memory allocation, sandboxed Google Play services (rather than giving them system-level privileges), and implemented per-connection MAC randomization. Each fix follows the same pattern: identify a gap between user expectations and actual behavior, report it upstream, get ignored or rejected, and ship the fix themselves.
If you're building apps that handle sensitive data and you've told users or compliance teams that "we require VPN usage," you need to understand what that actually guarantees on stock Android: less than you think. The VPN kill switch on stock Android is a best-effort feature, not a security boundary. Your threat model should account for DNS and connectivity check leaks.
For developers working on VPN apps themselves, this is a known platform limitation you should document clearly for your users. The Android VPN API (`VpnService`) gives you control over tunnel routing, but it doesn't give you control over what the OS sends outside your tunnel. Consider implementing your own leak detection — monitor for traffic on the physical interface that shouldn't be there.
If you're in an environment where VPN leaks are a genuine security concern (not just a privacy preference), stock Android is not sufficient. GrapheneOS on a Pixel device is currently the strongest option for Android-based secure communications. For organizations, this means maintaining a fleet of Pixel devices running GrapheneOS rather than relying on MDM-enforced VPN policies on stock Android.
For the majority of developers who use VPNs casually — to access geo-restricted resources or connect to corporate networks — this leak is unlikely to matter. But for anyone whose threat model includes a network-level adversary (which includes anyone working on sensitive projects, handling source protection, or operating in hostile network environments), the distinction between "mostly blocks non-VPN traffic" and "actually blocks all non-VPN traffic" is the whole game.
Google's refusal to patch this is consistent with their broader approach to privacy: offer controls that satisfy the average user's expectations while preserving the data flows that Google's services depend on. The bet is that most users won't notice, and the ones who do will either accept it or move to a platform that takes their threat model seriously. GrapheneOS exists because enough people chose the second option. Whether Google eventually adopts these fixes — as they've occasionally done with other GrapheneOS innovations — depends on whether the reputational cost of the leak exceeds the engineering cost of losing connectivity check data. History suggests that takes a lawsuit or a regulation, not a bug report.
Just like manifest v3, it's not in their best interests to disallow snooping. It hurts their business model.
The technical detail that makes this egregious is that the leak happens in system_server, a privileged process. Android’s own lockdown mode explicitly promises that no traffic bypasses the VPN. When the system itself sends the packet over the physical interface, that promise is broken at the kernel
> Google maintained its position, authorizing public disclosure on April 29.I'm surprised they honored the embargo at that point, and delayed the fix until May. Why not just release immediately?
I know there are bad business reasons, but how can someone classify a VPN leak as "not a security issue" and keep their pride?
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
> Because system_server operates with elevated networking privileges and is exempt from VPN routing restrictionsSo a VPN isn't a VPN on Android? Regardless of this bug. Do other locked down operating systems act the same?