Now, it could technically only communicate with other apps that have Google libraries. I doubt these libraries include any code that does that. They are not that big, and we can reverse-engineer them very well nowadays with AI.

A targeted attack is still possible, but they won't systematically exfiltrate your pictures through other apps. That's way too much traffic. They would easily get caught if they did this, for example, on my network.

This is a cyber-attack made possible through severe negligence on the victims’ part. It’s like a home burglary where the victim left the door wide open for months without ever checking on their home.

Therefore, the news should be about that negligence. That's the interesting part.

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.

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.

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?

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.

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.

Comments URL: https://news.ycombinator.com/item?id=49216630

Points: 4

# Comments: 2

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.

Comments URL: https://news.ycombinator.com/item?id=49096839

Points: 2

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=42467532

Points: 9

# Comments: 1

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.

Comments URL: https://news.ycombinator.com/item?id=35601147

Points: 51

# Comments: 29

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.