> A proper fix would require changes in the Android system. The researcher who discovered the leak has reported the issue to the Android Vulnerability Reward Program, but according to the researcher the issue was closed without action. This issue is not public, but based on this information we deem it unlikely that Google will do anything about it. GrapheneOS is aware of the issue and are working on a fix.
If the account given by the researcher is correct, we cannot rule out that Google deliberately introduced or wanted to keep the leak in place.
> we cannot rule out that Google deliberately introduced or wanted to keep the leak in place
I'd say a lot stronger than "cannot rule out". Regardless of how it was introduced, if it is now known and the issue was closed without action, they are actively choosing to keep it.
The GrapheneOS team did not respond to an email report either [0]. Does that mean we can draw similar conclusions from the GrapheneOS team? I don't think that would be fair or correct, so why assume malice from Google just based on the (lack of) response to the report?
N.B. I don't disagree there is a possibility of foul play on Google's part, but I think more evidence / better argument is required.
GOS explicitly stated that they work on a fix, also for other issues and they keep this on their radar.
Google just closed the ticket, without communicating their plan to deal with it. I just stated that we cannot rule out a possibility of foul play, thereby keeping other options open. Keeping that thing in mind which is better know as "the reality" I would be a little bit more wary about Google's stance towards privacy than I would be about GOS though. The difference in how these parties are handling this issue is already a tell.
There's a big difference between "the issue was closed" and "received no acknowledgment". The former is a deliberate action. The latter could be a case of SMTP-ate-my-email.
As a quick kludge use an USB-C wlan network adapter that lacks the functionality for this type of connection (albeit that won't help you with a cellular connection)?
> This issue is not public, but based on this information we deem it unlikely that Google will do anything about it. GrapheneOS is aware of the issue and are working on a fix.
'Closed without action' is the tell. A leak that Google knows about and leaves in place isn't a bug anymore, it's a feature they're comfortable with.
This paper goes into much more detail: https://supuk.ch/papers/android-natt-keepalive-vpn-bypass
> we cannot rule out that Google deliberately introduced or wanted to keep the leak in place
I'd say a lot stronger than "cannot rule out". Regardless of how it was introduced, if it is now known and the issue was closed without action, they are actively choosing to keep it.
The GrapheneOS team did not respond to an email report either [0]. Does that mean we can draw similar conclusions from the GrapheneOS team? I don't think that would be fair or correct, so why assume malice from Google just based on the (lack of) response to the report?
N.B. I don't disagree there is a possibility of foul play on Google's part, but I think more evidence / better argument is required.
[0] https://github.com/GrapheneOS/os-issue-tracker/issues/8617#i...
GOS explicitly stated that they work on a fix, also for other issues and they keep this on their radar.
Google just closed the ticket, without communicating their plan to deal with it. I just stated that we cannot rule out a possibility of foul play, thereby keeping other options open. Keeping that thing in mind which is better know as "the reality" I would be a little bit more wary about Google's stance towards privacy than I would be about GOS though. The difference in how these parties are handling this issue is already a tell.
There's a big difference between "the issue was closed" and "received no acknowledgment". The former is a deliberate action. The latter could be a case of SMTP-ate-my-email.
[delayed]
Mullvad did a really good job writing up this blog post. And yet again GrapheneOS to the rescue.
As a quick kludge use an USB-C wlan network adapter that lacks the functionality for this type of connection (albeit that won't help you with a cellular connection)?
Regarding cellular connection, the proof of concept presented here only works on wifi: https://github.com/GrapheneOS/os-issue-tracker/issues/8617
I have a hunch this leak is bound to wifi hardware only, for details: https://supuk.ch/papers/android-natt-keepalive-vpn-bypass
Surprised this hasn't blown up more!
I guess the best advice remains to only use wifi to connect to a router which forces traffic over a VPN and never use mobile data?
Do any similar leaks exists on iOS currently?
> This issue is not public, but based on this information we deem it unlikely that Google will do anything about it. GrapheneOS is aware of the issue and are working on a fix.
Good guy Google, as usual.
You're definately not hiding something if all your traffic goes out to a single IP address and a single pair of source and destination ports.