Recently I have been testing a few Contact Tracing app on Android and noticed something odd : all apps using Exposure Notification (the API provided by Apple and Google) require that the user enables location (i.e. GPS) while TraceTogether and StopCovid do not require location. According to Google PR, in order to detct Bluetooth devices around an app has to make sure that location is enabled. That would mean that TraceTogether and StopCovid may not work properly when users have disabled the GPS…Turns out they work pretty well on most phones and on Google is needlessly forcing some users to enable GPS on their phone. It’s not trivial to know which phone is affected and Google has no incentive to work on a fix.
Relation between Bluetooth and Location
Although the primary use of Bluetooth is to be able to connect devices that are close to the smartphone (headset, earpiece, …), it could be misused by apps to geolocate the user. Hence, some companies propose to deploy Bluetooth tags for geolocation purposes in stores . To prevent users from being geolocated without their knowledge, Google has integrated protections in Android to warn users that they might be geolocated.
In 2015, Google integrated a protection into Android to prevent this misuse of features: any app scanning with Bluetooth to detect nearby devices is considered a location-aware app . That’s why, starting with Android 6, to be able to scan in BLE, an app must obtain permission he location permission from the user. Therefore, whether it is to locate the user or not, Bluetooth devices cannot be discovered by an app unless the app got the location permission.
An excess of transparency…
According to Android documentation, for an app to scan nearby Bluetooth devices, it only needs the location. In practice, this permission is not always sufficient.
Extract from the bluetooth documentation
Src : https://developer.android.com/guide/topics/connectivity/bluetooth
Indeed, Google has imposed on second constraint on Bluetooth apps: for an app to be able to scan in Bluetooth, the phone’s location service must be activated. That’s an unexpected privacy protection which may defeat its original purpose: not only the app that wants to scan the BLE will be able to locate the user, but this will also be the case for all applications and services that have already obtained permission to locate the phone.
Figure 1 The BLE scan app asks for the permission to locate Figure 2 The app asks to activate the 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 since all services and applications that have permission to locate you will also be able to access your location and not only the application using the BLE. Most notably Google services, one of them being activated by default on most Android phones, will also get access to your location.
It would have been advisable to discuss this technical choice, which is not insignificant and not necessarily understood by users or developers. As this technical constraint has not been documented, no debate could have taken place on its relevance or on the alternatives. It gets even worse : the behavior is not the same on all Android devices, partly to Google’s fault, and it’s fairly complicated for developers to find out which devices are affected.
… not always followed by smartphone manufacturers
To add to the confusion, Google changed this constraint without much notice. On Android 8, apps can’t scan Bluetooth when location services are off but on Android 9 & 10, the behavior changed. An app can scan when location services are off if its filtering the result (i.e. it’s not listening everything but look only for devices using a known app/service).
Apparently, not all Android smartphone manufacturers  have implemented this constraint the same. For instance, on some smartphones with Android 9, location must be active for an app to be able to detect Bluetooth devices nearby, but on others it will work even with location disabled.
Surprised by this inconsistent behavior, one developer has tested several smartphones and, according to him, Android smartphones with a “lightly” modified Android version (i.e. with a version of Android that has been very little modified by the manufacturer) do verify that localization is enabled, but smartphones using more “customized” versions completely ignore this constraint . 5] One may also wonder about the purpose of smartphone manufacturers who did not include protection when they “customized” Android. Moreover, it is not certain that Google is aware that some manufacturers have modified the Android code to remove this protection.
This fragmentation is problematic for developers since it does not allow them to have a consistent behavior from one Android smartphone to another. Thus, developers should test their apps on multiple smartphones to consider the different cases. The icing on the cake: a smartphone that blocks the BLE scan will not report an error to the app but will only indicate that it did not detect any device nearby. The application will therefore not be able to know if it is because no device is actually nearby or if it is because the OS has blocked the scan.
Implications for contact tracing apps
Until now, relatively few applications have used BLE scans intensively. But the emergence of contact tracing apps is changing the picture, since they rely mainly on bluetooth to detect contacts. As a result, these apps need to constantly scan the BLE for other devices in the vicinity. However, on some phones, they will only be able to do so if the location service is activated.
What proportion of users will be affected
It is not easy to estimate on what proportion of devices the BLE scan is blocked in the absence of location. On the one hand, for this protection to be blocking, the user must not have the location constantly active on his smartphone. I did not find an estimate of the number of users who disable the loc on their phones. A small twitter survey tells me that almost 50% of the people following me turn off the loc , but this estimate is probably biased. To my knowledge, the closest study is the CNIL barometer according to which 43% of users sometimes disable the loc . It can therefore be considered that a fairly small proportion of users frequently disable it.
On the other hand, the proportion of devices that check that localization is activated before allowing BLE scanning is unknown to my knowledge. Until people were asked to constantly walk around with Bluetooth turned on in the hope of saving lives, BLE scans were rarely used, which explains the lack of interest for this problem.
Out of curiosity, I did a test on my smartphone (a Moto G5 Plus with Lineage) and the device scans well in BLE even with the localization turned off. However, it is difficult to know if this behavior is the exception or the rule.
Contact tracing apps with opposite strategies
To be sure to work perfectly on all Android smartphones, contact tracing applications should use force location activation. In practice, not all of them do this, either by omission (since it seems to work on some devices) or to prevent the user from thinking that he will be localized.
EN-based applications force to geolocate
All Android contact tracing applications that rely on the Exposure Notificaiton API (proposed by Apple and Google) require the user to activate the localization in order to run  (except on Android 11). This summer, Google has been criticized as an attempt to retrieve more location data . In fact, Google could not get around this restriction unless it changed the code of its OS, and it is only on Android 11 that Google can fix it.
By forcing users to enable tracking, Google ensures that contact tracing applications will work perfectly on all devices. But the corollary is that some users will enable location and Google location without really needing to do so (see box). In fact Google could reduce the number of users who needlessly activate location, but clearly it has no incentive to do so. First, Google should use filtered scanning (apparently this should be done as there is a FIXME comment…from August 25th). Second, Google could test on which devices Exposure Notification works with location off. Devices running Android 9+ are likely to be able to perform (filtered) scan with location off but previous version of Android are more likely to require location.
StopCovid and TraceTogether do not force localization
StopCovid and TraceTogether have a different approach since they can be used even with localization disabled. On my phone, neither of the two apps checked that the localization was active before running scans . Not knowing if it is a bug or a feature, I reported the problem to the developers . The fact that both apps use filtered scanning mean that they are more likely to not be impacted by the location settings.
In cases where the bluetooth scan is blocked, StopCovid should only work halfway :
- Since your smartphone always transmits in bluetooth, if you have passed by a person who tested positive to Covid, you should be notified.
- On the other hand, if you have tested positive yourself you will not be able to notify the people you passed when your scanner was not active.
Google Location Services
When an application wants to locate a user, it can either use Android’s open API that uses GPS, or use Google Location Services (GLS) that offer faster and more accurate location. GLS are part of the Google Play Services, the set of proprietary APIs that are available on an overwhelming majority of Android smartphones (outside of China). GLS are enabled by default on most Android devices, and disabling them requires digiing in the smartphone’s location settings.
The main disadvantage of GLS is that they regularly report users’ location to Google. Indeed, as Google explains, “location data from your device is routinely collected and used anonymously to improve the accuracy of the location” .
 It is important to note a subtlety here: the location data that is sent to Google is not anonymous, only the use that is made of it is anonymous. This description of the data reported by GLS and the use made of it differs significantly from the description that was made until 2018. Until then, Google described the data that was reported as anonymous. For example, the NYOB complaint notes that Google described that “anonymous location data will be sent to Google when the device is turned on.
Excerpt from the NYOB complaint
Very little documentation explains what data is sent by GLS. In a response to two U.S. Senators in January 2018, Google stated that GLS retrieve location information associated with temporary and rotating identifiers . 13] This is likely pseudonymized data and depending on the method and frequency with which these pseudonyms are generated, it is more or less easy for Google to find out to whom this location data corresponds.
Popup requesting GLS activation in Google Maps. The explanations (right screen) only appear if you click on the arrow
GLSs are often activated by users. While it is true that they enable faster and more accurate localization, their high usage rate is also explained by the simplicity of their activation: when an app wants to ask the user to activate localization, it is much simpler to do so using the GLS API: a popup appears and the user just has to click on OK. To my knowledge, there is no API that allows to activate the localization so simply without activating GLS. Disabling Google Location Services requires digging in the phone settings .
Exposure Notification benefits from a privileged API
Contact tracing applications that want to be able to use the Bluetooth scanner on all Android devices have, a priori, no choice but to make sure that the phone’s location is active. When location is not active, apps have two options to ask the user to activate it:
Ask the user to go to the phone settings to activate the location. This involves taking the user out of the app to go to the phone settings and then returning to the app. These operations are tedious and significantly detract from the user experience.
The second option is to allow the user to activate the localization via a popup that appears in the app. This second option is preferable from a user experience point of view since the user remains in the app and doesn’t have to navigate through the phone settings. Many applications display such a popup when the localization is not active. The trick is that this option is only available with Google Location Services, it is not possible for a developer to make sure that only GPS is activated. By choosing this second option, the developer activates GLS and Google’s collection of pseudonymized location data.
Both options have their drawbacks: the first harms the user experience while the second harms the user’s privacy. But for applications that rely on EN, Google seems to have provided a third option: these applications can activate the location service from the app without activating GLS. This gives them the advantages of both approaches: a smoother user experience that does not systematically activate GLS.
The fact that all applications based on the Exposure Notification API use exactly the same text to describe the location activation indicates that the operation is performed at the Exposure Notification API level and not at the app level. As for GLS Google can change a parameter from an app because Plays Services have the required permissions to do so , but other applications do not have access to these features (note that apps using EN do not ask for localization permission either).
Captures of 4 contact tracing applications based on Exposure Notification
Even if location is enabled for the purposes of a contact tracing application, other applications that have permission to access the location and previously enabled Google services (Location History or GLS) will be able to locate the user. However, once again, one may question the relevance of allowing the collection of location data when the user simply wants to use a contact tracing app. Even on devices that require location to be on to perform Bluetooth scan, Google could have gone a step further and deactivated the sending of information to its own services when location was activated from a contact tracing app.
The way forward?
A better solution would be to enable location only on Android devices where it is necessary. Indeed, as we have seen, due to the fragmentation, on a part of the Android devics, location does not have to be activated to allow contact tracing apps to work. It makes no sense to force the activation of location on these terminals, but it is still necessary to be able to identify them, and the API does not necessarily allow this.