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?

Original post by the author: https://news.ycombinator.com/item?id=49096839

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.

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.

I am the author of the post, paper, and app. The findings were reported to Android's Vulnerability Reward Program on May 15, 2026.

The bypass sends a fixed one-byte NAT-T keepalive outside VPN lockdown every 10 seconds to any IP addresses, including most private and reserved ones. The tested packets all reached the router while VPN lockdown was on. I am selling an app to mitigate this VPN leak. Any app with the default Internet permission can bypass the VPN.

The article contains all disclosures and more details. For the full technical analysis, check the paper linked from the blog post.

I am here for about the next two hours and can answer questions.

This Vice article is a pretty bad sum up, nearly all questions/opinios asked/raised here are commented in this good NZZ article: https://www.nzz.ch/wissenschaft/desert-kites-archaeologen-da...

It's German, but shouldn't matter much in th days of AI.

ChatGPT anwsers to some questions brought up here based on the NZZ article:

1. The "Desert Kites" or stone structures were dated using two methods. The researchers used Carbon-14 (C14) dating on charcoal samples found near the structures. Carbon-14 dating can only be used on once-living material like wood or bone, hence its use on the charcoal. They also used a technique called Optically Stimulated Luminescence (OSL), which measures the last time sand grains were exposed to sunlight, based on the accumulation of electrons in their crystal structure. These two techniques revealed that the structures are between 7560 and 9000 years old.

2. Your instinct aligns with the interpretations of the researchers. The article suggests that the rock carvings depicting these structures may have been created after their construction rather than as blueprints. One reason for this is that the physical structures follow topography, incorporating or based on terrain features which are not reflected in the plans. The researchers propose that these drawings could have been used for hunting planning, demonstrating attributes of the structures that aren't noticeable from ground level. Also, they argue these drawings could serve as a demonstration of knowledge, the ability to depict spatial elements, and the act of transmitting this knowledge. The idea that these could be plans created before construction is less likely but not entirely dismissed.

Why do you think you need to touch them after deployment? You just pay the monthly bill. The thing is you can't just deploy and rest usually as there are often security concerns, your provider could run out of service, various system failures which require a restore of an healthy state or similiar. Even if you serve just static files, there could be the need to adjust your DNS, because the provider changed after 5 years something, or some other provider-related configuration. You really want to care for all those things at your frist deploy if you don't want to care for them long-term. The Hetzner firewall makes frequent security app updates mostly unnecessary, Ubuntu auto updates care for the security of the OS, the backups make recovery easy, if Hetzner goes out of service, you can restore your system wherever you want as it is just an Ubuntu server, by keeping only one app per server you also reduce the complexity of the system, separate the systems, so that failure can't spread.

Managing a server is nowadays with offerings like Hetzner the easiest way to run apps which just need to work and don't need to scale to exponentially over time. Why add anything on top of it? It's done really within 5 minutes if you know what you do.

If you need something which scales and doesn't require file storage / databases, then I'd go for the provider-agnostic Serverless framework. If you need storage and/or databases then it really depends, as Serverless gets costly at these things and more complex and there are more provider-lock-ins. Containers may make mor sense in such cases.

At our company we use these two systems to reduce maintaining basically to zero.

Hetzner Ubuntu Server, a good firewall configuration and automated backups. I can't think of anything easier. I tried a lot of stuff, but this just works. For internal applications I basically block all traffic outside of our office network, activate auto updates for the OS and just stick to one version of the app for as long as I can.

Edit: and only one app per server. Also only the Hetzner Cloud offering with managed backups and managed firewall.

First things first:

- a Google account can have multiple Google Payment profiles and multiple Google Ads profiles

- every Google Ads profile has a Google Payments profile tied to it (if you finished setup and started displaying ads)

- once you started using a Google Ads profile, the link to the payment profile can't be changed anymore

In detail:

- we "transformed" a normal Google account to a Google Business account

- the business account got access to the Google Ads profile and payment profile of the normal account

- the old account stopped existing, you can't log in anymore or recover access somehow. It looks like the old account became the new one.

- the new account has no admin access to the Ads profile, and it doesn't have access to the payments profile linked to the ads profile

- the only admin is the old account, which should be the same as the new one, but it isn't somehow. So the old account is somewhat gone, but not completely, but enough gone, that you can't access it anyhow

- we used it likes this for some time, probably 2–3 years without realising that we have no admin access

- we contacted Google support about 2 years ago due to this, and they gave us admin rights over the ads account

- the payments profile linked to the ads account still can't be accessed, but we never used anything related to this, so we didn't notice

- then some or all (unclear) of our payment profiles got suspended. Google Ads continues to work for another 10 days.

- we immediately take action and fill out the form accordingly to the UI. Open Google Ads -> Your payments profile is suspended [...]. To solve this, click "Fix it". -> click Fix it -> a form opens -> fill out the form -> they say "Open this link and copy the payments ID you see" -> click the link -> copy the ID -> paste it -> send the form

- then the Google support staff starts going crazy, often no responses at all, nearly 2 weeks pending, then the ticket just disappears without further notice, false promises over and over (absolute hell, not the usual stuff, 10+ tickets)

- we learn that usually all payments profiles get blocked if one payment profile gets flagged, but also that usually all get unblocked if we successfully fill out the form. That's why they don't bother to tell you which ID to fill in, just copy any ID from the link, which leads to an ID of any payment profile

- then our payment profiles get unblocked, all, except the crucial one which is tied to the ads profile

- guess what, the payment profile tied to our ads account is somehow not really tied to us, but also isn't closed, it exists and works and Google lets you use it, but no original user can access it, so it doesn't get unblocked automatically with the other profiles, but somehow it got blocked because of the others (?), it looks like that it got blocked 10 days after the other payment profiles got blocked

- The UI at Google Payments tells us now, that all our payments profiles are ready to use, we test it, they work!

- The UI at Google Ads tells us that our payment profile is still suspended. Probably just a delay, right?

- Just in case, as the responsible business we are, we ask Google, they tell us, to fill out the form. We say we did, and it worked, so they say, again, fill out the form without further advice.

- Now, if you click the links send by the Google support or the "Fix it" link by Google Ads, you will end up at the same form which clearly says (with a hyperlink to the Google payments settings): "Enter the 12-digit payments profile ID shown in your Google payments settings." (https://support.google.com/payments/contact/account_verifica...)

- In the end, we filled out the form again with the ID from the Google Ads Settings and got unblocked. However, to realise that we need to do this took some time.

Don't forget to get a really good insurance in case you lose the ability to work in the industry.

That's possible. Install Firefox Nightly, create a custom addon collection on the Firefox addon site, add an user agent switcher to the collection, add the collection to Firefox Nightly. You now owe me a parade.