A very strange way to reason about killing an API instead of fixing the VPN issue (as someone from Google already suggested they're planning on doing). "Only 4 million people use this, we should kill it" is exactly the kind of reasoning Microsoft in the 2000s would use to kill the ability to install Linux on a PC.
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?