IssueTracker

We’ve shared this with our product and engineering teams and will continue to provide updates as more information becomes available.

We have looked into the feature request you have reported and would like to inform you that this is working as intended. We do not think such an option would be understandable by most users, so we don't think there is a strong case for offering this.

As for disabling connectivity checks :

• the VPN might be actually relying on the result of these connectivity checks (they are available through public APIs).
• the VPN may be a split tunnel, letting part of the traffic over the underlying network, or only affect a given set of apps. In both these cases, the connectivity checks are still necessary for smooth operation of all the legitimate traffic that doesn't go over the VPN.
• the connectivity checks are far from the only thing exempted from the VPN ; privileged apps can also bypass the VPN and this is necessary for their operation in many cases. An example is IWLAN, or tethering traffic.
• it's unclear to us what specific privacy impact is meant. The connectivity checks reveal there is an Android device at this address, which is plenty clear from the L2 connection and from the traffic going over the VPN anyway.

Thanks for looking into this and responding to the feature request. We don't fully agree with your decision, and here is our feedback to your response:

We do not think such an option would be understandable by most users

We'd argue that "most users" would never see or understand "Always-on VPN" or "Block connections without VPN" neither. But they don't need to care, because it's deep down in menus they never visit. Out of set of users who do understand and use those two features, we believe that a large part are interested in preventing data leaks of all kinds.

the VPN might be actually relying on the result of these connectivity checks (they are available through public APIs).

Yes, true. But for users who only connect to WiFis without captive portals and don't care about the connectivity check, this traffic serves no purpose but to cause noise and leak metadata. We do understand that this would be a nuisance to most users whos' threat model does not include this type of leak. But we would prefer it if you could disable the connectivity check. Maybe upon connecting to a new WiFi there can be a button asking if the user would like to probe for captive portals, and the check is performed when that is clicked. Just like the notification users currently get when there is a captive portal, allowing them to open the portal, but happening before the check is performed.

the VPN may be a split tunnel, letting part of the traffic over the underlying network, or only affect a given set of apps. In both these cases, the connectivity checks are still necessary for smooth operation of all the legitimate traffic that doesn't go over the VPN.

Enabling split tunneling is opt-in, and connecting to WiFi with captive portals is also voluntary. We don't see why users who don't use either should be forced to leak this traffic on every WiFi connection.

the connectivity checks are far from the only thing exempted from the VPN ; privileged apps can also bypass the VPN and this is necessary for their operation in many cases. An example is IWLAN, or tethering traffic.

Yes, this is very sad. All of those should be possible to disable. Having tethering enabled is definitely opt-in, so not an issue really. But as a side note, I don't understand why Android does not send tethered traffic over the VPN, this is a security and usability concern for us and our users.

If there is a long list of things that Android leaks without the user's consent, that's even more relevant to our other issue then: https://issuetracker.google.com/issues/249990229. The "force all traffic to use the VPN" part of the docs is simply not true, and should probably be improved.

Is there a list of exactly what traffic goes outside the VPN available somewhere?

it's unclear to us what specific privacy impact is meant. The connectivity checks reveal there is an Android device at this address, which is plenty clear from the L2 connection and from the traffic going over the VPN anyway.

At L2, yes. But anything further away does not have access to the L2 data. For example my router can see that an Android device is connected, but anything beyond the router will only see the connectivity check. Let's take my ISP and home as an example. Only my router can see the Android device establishing a WiFi connection. But the ISP can now get a detailed log of when my phone connects, due to the connectivity check. Giving them pretty detailed information about when I come home. Since different versions of Android use different connection check domains, the leaked data is more fine grained than just "some Android device". Let's say I'm one of very few people in my area who uses a specific flavor of Android. A network provider carrying most internet traffic in the area could potentially observe me arriving at a cafe, work, home, gym or whatnot.

Why would it be clear from the traffic going over the VPN that the endpoint is an Android device? That traffic is encrypted. How would an observer on the network be able to differentiate between an Android, iOS or desktop device? Do you mean that the observer would figure it out from timings and packet sizes? That is fixable with for example injected noise.

The following info doesn't solve the issue, but maybe someone will find it relevant.

Although connectivity checks can't be forced through the VPN, they can be customized or disabled. Special ROM support is not needed for this. More details here: https://android.stackexchange.com/questions/186993/captive-portal-parameters/186995#186995

• To disable: adb shell settings put global captive_portal_mode 0
• To undo: adb shell settings delete global captive_portal_mode

This should work with just about any modern (or not-so-modern) Android ROM.

If Mullvad considers this a significant-enough leak, one possibility is that the Mullvad app could check the value of the global settings captive_portal_mode and captive_portal_detection_enabled (the deprecated option) and politely notify the user about this, maybe directing them to information and the impact and how to change it - or something to that effect.

Thanks for the input! We tried that via Termux (which required root), so we were under the wrong impression that it would require root via adb as well. We'll continue to investigate how this might be useful for our users.

You can ask your users to grant WRITE_SECURE_SETTINGS permission to your app once with root or adb, like with adb shell "pm grant com.termux android.permission.WRITE_SECURE_SETTINGS" or su -c "pm grant com.termux android.permission.WRITE_SECURE_SETTINGS" (change package name) and then write the captive_portal_mode setting with Settings.Global.putInt(context.getContentResolver(), "captive_portal_mode", 0). You can read the value without the permission with Settings.Global.getString(context.getContentResolver(), "captive_portal_mode").

Or ask users to directly set the value with root or adb. Termux provides adb binary in android-tools package and adb wireless mode can be used to get adb access directly on device without requiring a pc.

https://www.reddit.com/r/termux/comments/mmu2iu/announce_adb_is_now_packaged_for_termux/

https://cs.android.com/android/platform/superproject/+/android-13.0.0_r8:frameworks/base/core/java/android/provider/Settings.java;l=13113

https://cs.android.com/android/platform/superproject/+/android-13.0.0_r8:packages/modules/Connectivity/service/src/com/android/server/ConnectivityService.java;l=3934

Re-comment#10: Hello, your comments were flagged for review. We understand that you’re frustrated, but please keep your language civil. If you continue to post abusive statements to the Google Issue Tracker, we will be forced to take action by removing your ability to make any comments or changes on the Google Issue Tracker.

Hey! Any chance of re-opening this issue/feature request since it has gotten quite a lot of upvotes?

AOSP based GrapheneOS exposes this functionality in a separate settings screen under "Network & connectivity" -> "Internet connectivity checks" where the user can select one of the following:

• GrapheneOS server
• Standard (Google) server
• Off

Maybe something similar can be done in the AOSP?