> 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.
Security issues considered outside the scope of what they consider a security vulnerability are closed regardless of what they plan to do about the issue. Google primarily uses internal issues to track issues with Android. Public issues and security issues filed by external parties are only used to communicate externally and an internal issue is created for their actual issue tracking.
A security issue being closed means you aren't getting a bounty and it won't be fixed for existing Android releases. It doesn't mean it won't be fixed in a future Android release. They do track VPN leaks as issues internally and regularly ship fixes in new major releases. They unfortunately don't consider those security issues so they don't get prioritized. If they were considered security issues, then they'd likely consider them Low or Moderate severity which means those wouldn't be backported.
Only a large subset of patches for High and Critical severity issues are backported to older releases of Android. Low and Moderate severity issues stopped having patches backported years ago due to volume. High and Critical severity patch backporting is now being scaled down too due to AI accelerated vulnerability discovery. You need the latest yearly or QPR2 release to get full updates.
GrapheneOS has had to fix a bunch of VPN leak issues and we're in the process of fixing more of the issues. We plan to heavily overhaul the VPN implementation to make most forms of leaks nearly impossible rather than continuing to use the current system prone to it.
> 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.
Google considers VPN leaks to be valid bugs but unfortunately doesn't consider them security bugs. Internal issues are created for any issue report considered valid. The external one is only used to communicate with people. If it was filed as a security bug, they'll close it if it isn't considered within the scope of the bounty program.
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 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.
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.
We passed it along to our developer working on solving VPN leaks. We didn't feel it was necessary to reply to a post linking to a public article. The article was shared with us by our users before we checked out emails.
We have a bunch of internally discovered VPN leaks which are already being worked on and this was added to that workload. We've already shipped a bunch of fixes and will ship more soon. We plan to eventually overhaul the whole system to prevent leaks in a much more systemic way.
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)
