final [GrapheneOS] 📱👁️‍🗨️ on Nostr: I posted this note a while back, and we disagree with Mullvad on this. A GrapheneOS ...

I posted this note a while back, and we disagree with Mullvad on this. A GrapheneOS user discovered them and we are aware of some leaks they didn't mention... VPN apps can leak if not implemented properly, that's why not every VPN was affected by this according to their article.

The second issue with leak while the VPN has crashed is likely an OS bug (race condition?) though and what we want to fix. Fortunately this affecting someone should be a very low chance and bo one would go out of their way to reproduce this bug willingly by forcibly disconnecting and timing a DNS query at a precise moment.

quoting
nevent1q…aakd

They would have, but we have heavy disagreements with Mullvad on how they phrase this as they fixed it within their app. If it is possible to set up apps in a way that they don't leak without OS changes then it was an app issue, it's premature to blame the OS. They are being unclear about this. The Android OS VPN implementation is unaffected. The OS could also prevent these leaks but it is possible they may not had viewed this in scope of the feature. DNS is handled in a special way and the VPN gets to set DNS separately from the VPN and can send it through it or outside it, etc.

VPN app developers should also be testing these basic cases themselves already ("only affect certain apps") and it appears they had not. As for the second case ("For a short period of time while a VPN app is re-configuring the tunnel or is being force-stopped/crashes"), this is being investigated. It sounds like an OS bug but a leak is not inherently responsible by the OS. Fortunately that second example is very limited.

It is also worth noting they did not discover these issues first rather they were reported to us by a GrapheneOS user which we posted about days before them. We are also aware of a local network multicast leak which is an actual OS bug which they haven't mentioned.

Also see: https://news.ycombinator.com/item?id=40252719

Mullvad are also linking an older article regarding a connectivity check "leak" which is misleading. That connectivity check is needed for determining which networks work, and triggering captive portals the user can interact with to log into WiFi networks with login pages. This would help you deal with the captive portal *without* disabling the VPN which would make everything else leak. GrapheneOS has also had the option to disable or change it for a long time.