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?
Android NAT-T keepalive offload bypasses VPN lockdown
11–20 of 68 posts
Re: Android NAT-T keepalive offload bypasses VPN lockdown
#12> 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 acc…
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...
Re: Android NAT-T keepalive offload bypasses VPN lockdown
#13Surprised this hasn't blown up more!
Re: Android NAT-T keepalive offload bypasses VPN lockdown
#14> 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 acc…
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://githu…
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.
Re: Android NAT-T keepalive offload bypasses VPN lockdown
#15> 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 acc…
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://githu…
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 known 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.
Re: Android NAT-T keepalive offload bypasses VPN lockdown
#16You'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.
Re: Android NAT-T keepalive offload bypasses VPN lockdown
#17'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.
Re: Android NAT-T keepalive offload bypasses VPN lockdown
#18Mullvad did a really good job writing up this blog post. And yet again GrapheneOS to the rescue.
Re: Android NAT-T keepalive offload bypasses VPN lockdown
#19Earlier quoted context omitted.
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://githu…
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.
Issue could have been closed by a mis-click, an AI bot gone wrong, a misunderstanding of the issue etc. You can't assert it was deliberate unless e.g. you work in the team that handled it and have inside knowledge. Agree GOS should have benefit of the doubt (too)
Re: Android NAT-T keepalive offload bypasses VPN lockdown
#20You'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.
A business: hiding everything is expected. To do otherwise is negligence
An individual: you're a pedo if you use a VPN
Give over.