Should Contact-Tracing apps really require to enable GPS?
In the last blog post, I looked at how Google nudges user towards its location service through which it can collect non-anonymous location data. Even on devices which use Google location services, location data can only be collected when the Android Location Setting (ALS) is on. In this blog post, we discuss one instance on which Android is designed to force users to turn on ALS without any justification: when they wan to scan Bluetooth. Indeed, since Android 6, in addition to having to obtain the location permission (a relevant requirement), apps that want to scan BLE must also make sure that ALS is on. To the best of our knowledge, this second restriction (wich we will refer as the “ALS restriction”) has never been documented or justified and is quite meaningless. Incidentally, until recently, it could have been circumvented and some contact tracing app unintentionally did.
This blog post has been co-authored by Vincent Toubiana and Mathieu Cunche
Relation between Bluetooth and Location
First, we have to understand that there is indeed a link between location tracking and Bluetooth as this may not be obvious. While, the primary use of Bluetooth is to be able to connect nearby devices (headset, earpiece, gamepad…) it could be misused by apps to determine the user location. As a matter of fact, access to WiFi scans has been abused by mobile applications to obtain user’s location without asking for the location permission. The same could have been done with Bluetooth scans and companies deploy Bluetooth beacons in stores for location tracking purposes.
In an attempt to inform users that they can be tracked by Bluetooth; Google has integrated protections in Android. Since 2015, any app scanning with Bluetooth to detect nearby devices is considered a location-aware app. That’s why, to be able to scan in BLE, an app must obtain permission the location permission from the user. Therefore, whether it is to locate the user or not an app is not supposed to be able to search for nearby Bluetooth devices unless it has the location permission.
This feature is good for users privacy: it gives them more control and prevent stealth Bluetooth based location tracking.
A questionable design
The Android documentation only mentions the location permission constraint to explain how/when an app can scan using BLE.
Another document mention the need to have “location access” which mostly refers to the location permission as well.
The documentation is in fact not comprehensive. Indeed, Google has imposed a second constraint on BLE apps: for an app to be able to scan in Bluetooth, the Android Location Service (i.e. GPS) must be activated. That’s an unexpected privacy protection which may defeat its original purpose for two reasons:
- Unlike GPS, BLE can not be used everywhere to locate users (it requires to deploy beacons).
- Even more worrying: when ALS is active, all applications and services having the permission to locate the phone will have access to user location.
This second condition is not mentioned in the Android documentation cited above, nor is it completely intuitive. It’s as if, for fear that voyeurs might use infrared cameras to spy on your home, your landlord (here Google) decides to remove all curtains in your condo. Of course, you are more aware of the risks of voyeurism and you adapt your behavior accordingly, but you are also visible to more people. Here the result is the same : all services and applications that have permission to locate you will also be able to access your location and not only the application scanning BLE. It’s only since Android 10 that Android offers the possibility to the users to only allow apps to access location only when they are in use (and that does not affect Google Location Services). Before that, all apps with the location permission could still access to your location when running in background.
It would have been advisable to discuss the technical choice of forcing apps scanning BLE to require location services to be activated. This feature is not insignificant and not necessarily understood by users and developers. As this technical constraint has not been documented, no debate could have taken place on its relevance or on the alternatives… until this summer.
WiFi scanning documentation
The very same constraints apply to WiFi scanning, but at least the WiFi scanning documentation is quite explicit about these constraints. Indeed, for Android 9+, the documentation specifies that the Location Services have to be enabled for apps to perform a scan (see bellow).
Looking for an explanation
To be honest, we were unaware that apps had to verify that ALS was on in order to scan BLE. This “protection” has never been documented it is totally unknown by most users and developers. This design choice has been discussed this summer as users of contact tracing applications were surprised that they had to turn on GPS in order to use apps that clearly put in front that they were not locating users… Google wrote a response on the official blog post and stated that “So in 2015, with privacy in mind, we designed the Android operating system to prevent Bluetooth scanning unless the device location setting is on. »
What is the rationale behind this design? Google never cared to explain or document this design choice leaving us guessing why it’s here. As mentioned earlier, this design does not seem to bring much in term of privacy. Taking the metaphor of the curtain, the only good thing with this design is that users may be more aware that they can be tracked as they could see the “location” icon on their Android device but that’s far fetch. Other than that, this design does not make sense because it exposes users to more location tracking by Google (though Location History and GLS) and third-party applications.
Even more surprising, not all Android devices require that ALS is on to let an app scan BLE. For some years, Android let OEM decide if they want to enforce this constraint on their devices. Indeed, there is a config file that OEM can edit to disable the ‘location required’ constraint. So, some devices running Android 8(Oreo) and 9 (Pie) can scan devices even when the location services are off, but this choice is at the manufacturer discretion. Initially, this option was offered to devices that had not location settings (e.g. Wear), but if the rationale behind this design is privacy, it is weird to let OEM decide. Even more bizarre: the “strict_location_check” parameter is still defined in Android 10 and 11, but it is never used. It seems to be just an artifact of previous Android version which have not been clean.
Now this whole designed constraint might just be a misunderstanding. Android developers may have push the metaphor a bit to far when making sure that apps scanning BLE were subject to the exact same constraints that apps locating users with GPS for instance.
But if that’s the case, it’s surprising that this mistake has been live for so long and has not been questioned earlier. Now one of the reasons this design was never questioned might be that it does not hurt Google business. If anything, this constraint forces users to enable location and, on the majority of devices using Google Location Services, Google will be able to collect location data to improve its services.
Bypassing the ALS restriction
The French contact tracing application is not based on the Exposure Notification API but make almost a direct use of the Android BLE API. TousAntiCovid uses the Nordic library which, almost by default, returns detected BLE devices by batches instead of returning them as they are heard. Coincidentally, due to an Android flaw (that we disclosed) the fact that TousAntiCovid uses batch BLE scanning instead of regular scans meant that the app bypassed the test that was checking that the ALS was on.
Should the flaw just have only this consequence, this would have been a good thing and we would not have disclosed it. But this flaw also allowed apps to not ask the location permission, meaning that malicious apps could have used BLE scans to track the location of users without their consent. This second issue was more serious because, as explained earlier, there are good reasons for Android to make sure that an app has obtained the location permission before it can scan BLE devices. The flaw has been disclosed (see CVE-2021-0328) and has now been fixed.
Conclusion
In this blog post, we discuss a curious restriction introduced by Android in 2015. Because the restriction only affects BLE scanning, it has not been subject to any scrutiny until this summer. Clearly, the debate that took place this summer shows that this design choice should be subject to more debate, and we should not accept the argument “with privacy in mind” without further explanation.