bordercontrol

Hello, original researcher here. I think part of the difficulty in discussing this issue is that GOS appears to distinguish between different classes of VPN leaks based on how they are triggered. In particular, VPN leaks caused by arbitrary user applications seem to be treated as less significant than leaks caused by race conditions or other behavior that users can trigger more directly.

That difference in prioritization has, in my view, made communication around the issue unnecessarily difficult. Some of the responses have also come across as defensive, as though raising additional VPN leak mechanisms somehow diminishes the value of the work already being done in this area. I do not think that is a productive way to approach security reports. Ideally, each issue should be assessed consistently on its technical merits, regardless of how closely it overlaps with existing work or who discovered it.

The original paper describing the NAT-T keepalive VPN lockdown bypass was published on July 29, exactly eight weeks ago. GOS has since stated publicly that the article had already been shared with them by users before they even checked my email about it, and that they passed it along to the developer working on VPN leaks. In other words, this has been on their radar essentially since the original publication, not only since the GitHub issue was opened several weeks later.

They have also been aware of the specific one-line mitigation since August 31, more than three weeks ago, and it still has not been implemented. Given how small and straightforward the mitigation is, I find that response time difficult to reconcile with the very strong criticism GOS regularly directs at Google and other vendors for slow security responses.

The issue has since received more than 200 points on Hacker News, so this is clearly not an obscure report receiving no external attention. Given that GOS was aware of the underlying issue essentially from the beginning, that eight weeks have passed since publication, that the concrete mitigation has been known for more than three weeks, and that the mitigation itself is a one-line change, I would have expected a substantially faster and more straightforward response. That seems particularly relevant given the standards GOS publicly expects other vendors to meet.

Original author here. I want to separate the technical work from the communication style. At one point I accidentally wrote Daniel's name as "Danielle." His entire response to one of my technical comments was simply, "That is not my name." I apologized, corrected the comment, and also made a point of acknowledging the quality of his work.

I think it was good that this exchange was later deleted, but it would have been better if the interaction had not gone in that direction in the first place. He appears to do strong technical work, and I do not want to diminish that. At the same time, some of his communication can come across as unnecessarily dismissive, confrontational, or unprofessional. That makes already difficult technical discussions harder than they need to be.

Original researcher here. Android could retain its complete platform-managed IKEv2/IPsec VPN implementation for Settings, carriers, and other privileged system components, while requiring third-party VPN applications to use `VpnService` and their own userspace implementation. VPN functionality would remain on both sides.

What would disappear is the narrow hybrid feature that lets an ordinary app configure kernel transport-mode IPsec on individual sockets, along with some performance and provisioning conveniences.

The problem is that Android's IPsec machinery is highly privileged and used by carriers to configure various parts of the telephony stack. Giving third-party apps access to this machinery is extremely bad system architecture.

So, what I am saying is to keep the platform-managed implementation of IKEv2/IPsec VPN and let third-party apps use their own implementations through `VpnService`, as they already do. The two apps you cited, in fact, support both. Most apps support only userspace.

Considering that most apps support only userspace, I think it is safe to assume that most users of these two apps also use only their normal userspace implementation, not the hybrid user-platform implementation.

So, it is not about killing VPN functionality or anything like that, but about imposing a strict boundary between platform-managed, privileged networking and ordinary app-managed networking.

WireGuard, OpenVPN, and other VPN protocols live and thrive in ordinary Android apps through `VpnService` without this platform integration. Currently, there are essentially four functionalities exposed to ordinary apps from the platform stack. The Binder total is 16 methods across three of these groups; the IKE library runs in the app process and adds no Binder surface of its own. This creates a weird hybrid structure.

The same general delegated-send architecture caused the past two major VPN leaks this year, although the QUIC delegated-send issue used a separate but closely related API rather than one of these four groups:

1. Applications may create transport-mode security associations and apply them to individual sockets. (9 Binder methods.)

This is technically the only one that provides any kind of additional functionality rather than a performance or provisioning convenience.

This is the functionality that would actually be lost. Applications that genuinely depend on the legacy API could either migrate to a supported userspace implementation or remain on Android releases where that API is available. It is not Google's job to support legacy technology forever. There are plenty of ways to keep using IPsec VPNs without these specific encryption protocols, so vendors would not need to perform a massive overhaul anyway.

But again, this is an extremely tiny set of users. I could not find any real, official proprietary application from a business that depends on this API. I found only two third-party apps that support the API, and it is almost impossible to find any business with an app that actually uses it. They would then, on top of that, also have to use this specific mode. The real number of users affected by deprecation is extremely low. I cannot even quantify it because there is not a single runtime data point to begin with.

2. The in-app-process IKE library, `IkeSession`. (No Binder interface of its own.)

It already runs in userspace and could, for the most part, be replaced with an app's own userspace IKE implementation.

3. NAT-T keepalive offload optimization. (2 Binder methods.)

The battery impact of two one-byte UDP keepalives per minute is negligible compared with many continuously running application activities, especially advertising and tracking libraries that regularly wake the device and perform background network activity. A continuously active tracker or advertising library can generate far more background network activity than these two keepalives per minute.

It would be nice to have, but for all VPNs and as a generic, separate API available only for active VPNs, not just weird hybrid IPsec VPNs almost nobody uses.

4. `Ikev2VpnProfile` management. (5 Binder methods: four change state and one queries it.)

This is only about profile management; it does not give the app direct control over the underlying kernel transforms. Users can enter all the information themselves in system settings.

It is a little inconvenient, perhaps, and currently some fields are not exposed in the UI, but this particular Android profile-management API never caught on to begin with and is now practically unused. So, it is fair to expect users of this practically unused API to spend one or two minutes entering their own profile data instead of using a proprietary app. However, I was not able to find a proprietary provider app that actually depends on it. It is unclear which provider actually uses automatic `Ikev2VpnProfile` provisioning.

This is also the exact reason why the NAT-T VPN leak happened in this API. The QUIC leak came from a separate but closely related delegated-send API. This is highly privileged machinery that would need a lot of refactoring before it could safely be provided to ordinary user apps. I assume they chose not to add proper safeguards because that refactoring was considered too costly. Developer time obviously costs money and is limited.

> (as someone from Google already suggested they're planning on doing)

Where did you read this exactly?

The joining process is already precisely defined.

Client side end to end encryption is a must have for me when hosting anything nowadays. I am using Cryptomator for this specific reason. It takes away a lot of legal questions because I only need to curate the data to serve my own needs and do not have to curate it for state actors too.

I really wish client side end to end encryption would become more widespread in the developer community. It is not hard to implement anymore and takes away all the headaches of having to comply with certain regulations.

There are so many laws now that regulate copyright and hosting. An accidentally public S3 bucket full of ebooks could technically land you in jail in certain jurisdictions. Automatic shutdown notices. Providers themselves may also automatically scan stored material, and so on. There are so many reasons not to host your media library unencrypted on a third party server.

I recommend using this kind of tool only if you can prove that you are legally allowed to possess every ebook you upload in every jurisdiction you travel to or live in, as well as in the jurisdiction where the server is located.

RIP Aaron Swartz.

I never ask that question. What does knowing the answer actually change by itself?

Any x is a y.

Great write-up. The biggest problem with GLM/Kimi is exactly this: they often miss obvious failure points. Claude/Codex tend to catch these kinds of issues pretty quickly. They’ll basically go, “Wait, step back,” rethink the problem for a while, and start questioning their underlying assumptions.

That’s why I always prompt GLM to explicitly map out and question all of its assumptions. It helps a lot when it gets “stuck” on a wrong line of reasoning.

Honestly, you got me on this one. I probably break my OpenWRT setup every three months or so on average.

I recently decided to stop running anything too fancy on it and keep the router itself simple: just secure, robust networking. All the tinkering has moved to chained network VMs in QubesOS instead.

It was definitely nice having different LAN ports behave differently, multiple VPNs, policy-based routing, filtering, monitoring, and all that. But yeah, every extra thing I add is another chance to break the whole network.

All that said, I could never imagine going back from OpenWRT. The answer to basically any networking idea is always “yes.” There are pretty much no limits. I especially like that it doesn’t try to hide networking terminology or abstract everything away. You really get to understand what you’re actually doing and can choose the exact configuration you need, down to the smallest detail. Everything is exposed.

Try OpenWRT if you want a good OS for routers. No need to change hardware.

Playing the clip yourself would only be the one-click route. The exploit's actual significance is the zero-click path, where Google Messages auto-transcribes incoming audio and triggers the Dolby decode without any interaction at all.

A device running a 6+-month-old GrapheneOS version and having Google Messages installed would be vulnerable to that zero-click. The key question is whether and how it could be utilised to get past BFU mode. Maybe they can find another entry point via cellular/WiFi, as very few GOS users will have Google Messages installed anyway. So this might be the first zero-click on GOS, but it's still very speculative, as there is no public PoC. And it matters only for devices that didn't get updates.

That's the case for most countries in Asia and Africa, from my travel experience. I would spot vulnerabilities that leak extremely sensitive data all the time, just by using the services normally and legally. You immediately see that the verification is broken without even having to investigate. I don't investigate or report them, as it might lead to problems.

Please make it possible to change email addresses, so I don't have to create a new account and verify all domains again. Thank you for the great free service.