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.
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)
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.
> I really wish client side end to end encryption would become more widespread in the developer community.
I think asking every self-hosted app to implement their own encryption is a massive waste of resources.
If you need the data encrypted, it should be handled by a dedicated app like Cryptomater or at the OS level.
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.
It's about what prompted asking the question in the first place. For me, and many others, when we notice an article is difficult to read, has lots of lies and hallucinations, and other serious issues that clearly indicate it was not well thought out, edited or written, we usually ask "was it written by AI?" because that's usually the reason today.
Sucks that this has to be the case. But lots of people today are passing off >50% AI written outputs as though they are their own, without attribution. And it results in a lot more effort on the readers' part to do validation on the writing that the writer should have done.
Of course if you have no issue so be it. Several others and myself though feel like its low quality, and also deceptive not to label such outputs in this way. It is also irresponsible because it is requiring significantly more effort on the readers part to discern why things don't make sense and feel so odd and confusing. (not say all AI writing is this way, but the ones that are, well its what I said). edit: I personally would prefer you just share the prompts rather than the output, because the output was not written in the form that I prefer and I want it in the form I choose to make it easy for me to understand. That would mean I would rather have the prompt and make sense of it on my own, or have my own AI synthesize an output in the form that makes sense for me. I don't want the thing you thought I wanted but gave to AI to do since you were too lazy to write yourself. If you did put in the effort to write better, then sometimes it passes my quality bar.
You know you can quickly skim through any user's comment history? I think this one passes the eye test. It's not improbable but I think you're just paranoid if you believe this 2022 account was created to astroturf Kimi/GLM today.
Yeah I was considering this actually, but then I realised that I really want a working LAN 100.0% of the time, so I'd only go tinker mode if I had a backup. So I was gonna be buying a router regardless.
Now I have a Ubiquiti one, it's antithetical to my DIY instincts but I think I'm OK with my router being one of the proprietary appliances in my life.
Plus now the wired section of my LAN is really fast.
Interesting, I don't really have downtime with my OpenWRT setup. Probably because I don't really touch the setup once it's there, other than occasionally doing the firmware updates.
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.
I've just upgraded to an 8Gbit package (50 quid a month, rude not to). I'm having to use the provided router as my old one only has a 2.5Gbit port (still provides wifi however). I'd be keen to know of any fairly decent openwrt compatible routers with 10Gbit/wifi 7 at a reasonable price.
For what it's worth there are now mini PCs on AliExpress with SFP+ ports. I have one running OpenWrt along with some inexpensive SFP+ modules that's been working great. Although with my setup, I opted to have an external wifi AP connected to it instead of relying on an internal wifi card.
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.
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.
reply