—Categories: Android, Device neutrality, Google

La fragmentation d’Android : un obstacle pour les apps de contact tracing

Les fabricants de smartphones Android apportent parfois de légères modifications à l’OS de Google. L’une d’entre elles concerne une sécurité apportée par google en 2015 : depuis Android 6 il faut que la localisation soit active pour utiliser certaines fonctionnalités Bluetooth Low Energy (ci-après BLE ou Bluetooth). Cette restriction empêche qu’un utilisateur soit localisé à son insu mais elle est peu documentée et n’a pas été intégrée dans certains smartphones Android. Cette disparité n’avait pas d’effet majeur tant que l’utilisation du BLE pour détecter les appareils se trouvant à proximité était peu répandue, mais elle devient critique maintenant que des millions de smartphones utilisent le BLE pour mesurer des distances. Pour corser le problème, la solution la plus simple pour activer la localisation depuis une app (et donc s’assurer que le BLE fonctionne) implique de remonter des informations de localisation à Google.

Disclamer : Cet article s’appuie essentiellement sur la documentation d’Android et différents articles de blog que j’ai référencés autant que possible. Je n’ai pas pu tester les apps sur plusieurs modèles de smartphones Android, aussi n’hésitez pas à m’indiquer si vous observez des comportements différents sur votre smartphone et/ou à m’indiquer des corrections via twitter (dm open).

Pourquoi demander la localisation pour scanner le Bluetooth

Bien que l’utilisation première du Bluetooth soit de pouvoir connecter des appareils se trouvant à proximité du smartphone (casque, oreillette,…), il peut aussi, tout comme le wifi, être détourné par les apps pour géolocaliser l’utilisateur sans qu’il n’en soit averti[1]. Par exemple, des sociétés proposent de déployer des balises Bluetooth à des fins de géolocalisation dans les magasins[2]. Pour éviter que les utilisateurs soient géolocalisés à leur insu, Google a intégré des protections au niveau d’Android pour avertir les utilisateurs qu’ils pourraient être géolocalisés.

En 2015, Google a intégré à Android une protection pour éviter ce détournement de fonctionnalités : toute app souhaitant utiliser le BLE pour scanner les appareils à proximité est considérée comme une app localisant le smartphone[3]. Ainsi, à partir d’Android 6, pour pouvoir scanner en BLE, une app doit obtenir la permission de localiser un utilisateur. Donc, que ce soit pour le localiser ou non, le BLE ne peut pas être utilisé sans avoir préalablement obtenu la permission de l’utilisateur.

Une documentation vague et un OS fragmenté

A en croire la documentation Android, pour qu’une app puisse scanner les appareils Bluetooth à proximité, il lui suffit d’obtenir la permission de localiser. En pratique, cette permission n’est pas toujours suffisante.

Extrait de la documentation bluetooth

Src : https://developer.android.com/guide/topics/connectivity/bluetooth

En effet, Google a considéré jusqu’au bout qu’une app utilisant le BLE était une app souhaitant localiser l’utilisateur. Or pour qu’une app Android puisse localiser l’utilisateur, il faut non seulement qu’il lui en ait donné la permission, mais aussi que le service de localisation du smartphone soit actif. Google a donc imposé la même contrainte dans son OS : pour qu’une app puisse scanner en Bluetooth, il faut que la localisation du téléphone soit activée. Ainsi, non seulement l’app qui veut scanner le BLE pourra localiser l’utilisateur, mais ce sera aussi le cas pour toutes les applications et services ayant déjà obtenu la permission de localiser le téléphone.

Figure 1 L’app de scan BLE demande la permission de localiser  Figure 2 L’app demande à activer la localisation  

Cette seconde condition n’est pas mentionnée dans la documentation Android citée plus haut et n’est pas non plus complètement intuitive. C’est comme si, par crainte que des voyeurs utilisent des caméras infra-rouges pour épier votre domicile, votre propriétaire (ici Google) décidez d’enlever tous les rideaux aux fenêtres. Certes, vous avez plus conscience des risques de voyeurisme et vous adaptez votre comportement en conséquence, mais vous êtes également visibles par plus de monde. Ici le résultat est le même puisque tous les services et applications qui ont la permission de vous localiser pourront eux aussi accéder à votre localisation et pas seulement l’application utilisant le BLE.

Il aurait été souhaitable de débattre de ce choix technique qui n’est pas anodin et pas forcément compris des utilisateurs ni des développeurs. Cette contrainte technique n’ayant pas été documentée, aucun débat n’a pu avoir lieu sur sa pertinence ou sur les alternatives.

Pour ajouter à la confusion, les fabricants[4] de smartphones Android n’ont pas tous implémenté cette deuxième protection. Sur certains smartphones, il faut que la localisation soit active pour qu’une app puisse détecter les appareils Bluetooth à proximité, mais sur d’autres cela fonctionnera même avec la localisation désactivée.

Etonné par ce comportement incohérent, un développeur a testé plusieurs smartphones et, selon lui, les smartphones Android avec une surcouche « légère » (c’est-à-dire avec une version d’Android très peu modifiée par le fabricant) vérifient bien que la localisation est activée mais les smartphones qui utilisent des versions plus « customisées » ignorent complétement cette contrainte[5]. On peut s’interroger aussi sur l’objectif des fabricants de smartphones qui n’ont pas inclus une protection quand ils ont « customisé » Android. Il n’est d’ailleurs pas certain que Google sache que certains fabricants ont modifié le code d’Android pour enlever cette protection.

Cette fragmentation est problématique pour les développeurs puisqu’elle ne leur permet pas d’avoir un comportement constant d’un smartphone Android à l’autre. Ainsi, les développeurs devraient tester leur apps sur de multiples smartphones pour considérer les différents cas de figure. Cerise sur le gâteau : un smartphone qui bloque le scan BLE ne remontera pas d’erreur mais indiquera seulement qu’il n’a détecté aucun appareil à proximité. L’application ne sera donc pas en mesure de savoir si c’est parce qu’effectivement aucun appareil n’est à proximité ou si c’est parce que l’OS a bloqué le scan.  

L’implication pour les apps de contact tracing

Jusqu’à présent, relativement peu d’applications utilisaient les scan BLE de façon intensive. Mais l’apparition des apps de contacts tracing changent la donne puisque celles-ci reposent principalement sur le bluetooth pour détecter les contacts. Par conséquent, ces apps ont besoin de scanner constamment le BLE à la recherche d’autres appareils à proximité. Or sur certains téléphones, elles ne pourront le faire que si le service de localisation est activé.

Il n’est pas facile d’estimer sur quelle proportion d’appareils le scan BLE est bloqué en l’absence de localisation. D’une part, pour que cette protection soit bloquante, il faut que l’utilisateur n’ai pas la localisation constamment active sur son smartphone. Je n’ai pas trouvé d’estimation du nombre d’utilisateurs qui désactivent la loc sur leur téléphone. Un petit sondage twitter m’indique que près de 50% des personnes qui me suivent coupe la localisation[6], mais cette estimation est probablement biaisée. A ma connaissance, l’étude la plus proche est le baromètre de la CNIL selon lequel 43% des utilisateurs désactivent parfois la localisation[7]. On peut donc considérer qu’une part assez faible d’utilisateurs la désactive fréquemment.

D’autre part la proportion d’appareils qui vérifient que la localisation est activée avant de permettre le scan BLE est à ma connaissance inconnue. Jusqu’à ce qu’il soit demandé aux personnes de se balader constamment avec le Bluetooth allumé pour espérer sauver des vies, les scans BLE étaient rarement utilisés ce qui explique un faible intérêt pour ce problème.

Par curiosité, j’ai effectué un test sur mon smartphone (un Moto G5 Plus avec Lineage) et l’appareil scanne bien en BLE même avec la localisation désactivée. Difficile cependant de savoir si ce comportement relève de l’exception ou de la règle.

Des app de contact tracing avec des stratégies opposées

Pour être assuré de fonctionner parfaitement sur tous les smartphones Android, les applications de contact tracing devraient forcer l’activation de la localisation. En pratique, toutes ne le font pas, soit par omission (puisque ça semble fonctionner sur certains appareils), soit pour éviter que l’utilisateur pense qu’il va être localiser.

Toutes les applications de contact tracing Android qui s’appuient sur l’API Exposure Notificaiton (proposée par Apple et Google) demandent à ce que l’utilisateur active la localisation pour pouvoir fonctionner[8] (sauf sur Android 11). Cet été, Google a d’ailleurs été critiqué car certains y voyaient une tentative pour récupérer plus de données de localisation[9]. En fait, Google ne pouvait pas contourner cette restriction sauf à modifier le code de son OS, et ce n’est que sur Android 11 que Google peut corriger le tir.

En forçant les utilisateurs à activer la localisation, Google s’assure que les applications de contact tracing fonctionneront parfaitement sur tous les terminaux. Mais le corollaire est que certains utilisateurs vont activer la localisation sans que cela n’ait été vraiment nécessaire remontant probablement des données à google (c.f. encadré).

StopCovid et TraceTogether ont une approche différente puisqu’elles peuvent être utilisées même avec la localisation désactivée. Sur mon téléphone, aucune des deux apps n’a vérifié que la localisation était active avant de lancer des scans [11]. Ne sachant pas s’il s’agit d’un bug ou d’une feature, j’ai signalé le problème aux développeurs[10].

Dans les cas où le scan bluetooth est bloqué, StopCovid ne devrait fonctionner qu’à moitié :

TousAntiCovid (i.e. StopCovid v2) semble ne demander l’activation de la localisation que dans une situation précise : si le téléphone est sous Android 10 et qu’il ne supporte pas le batch de scan (je n’ai pas encore pu déterminer si cela réglait le problème).

Extrait du code de “TousAntiCovid”

Google Location Services

Quand une application souhaite localiser un utilisateur, elle peut soit utiliser l’API ouvert d’Android qui utilise le GPS, soit utiliser les Google Location Services (GLS) qui offrent une localisation plus rapide et plus précise. Les GLS font partie des Google Play Services, c’est-à-dire de l’ensemble d’APIs propriétaires qui sont disponibles sur une écrasante majorité de smartphones Android (en dehors de la Chines). Les GLS sont activés par défaut sur la plupart des terminaux Android, et les désactiver nécessite de fouiller dans les paramètres de localisation du smartphone.

Le principal inconvénient des GLS est qu’ils font régulièrement remonter à Google la localisation des utilisateurs. En effet, comme l’explique Google, « des données de localisation de votre appareil sont recueillies régulièrement et utilisées de façon anonyme pour améliorer la précision de la localisation »[12].

Il est important de noter ici une petite subtilité : les données de localisation qui sont envoyées à Google ne sont pas anonymes, seule l’utilisation qui en est faite l’est. Cette description des données remontées par les GLS et de l’usage qui en est fait diffère sensiblement de la description qui en était faite jusqu’en 2018. En effet, jusque-là, Google décrivait les données qui étaient remontées comme anonymes. Ainsi, on observe dans la plainte de NYOB que Google décrivait que « des données de localisation anonymes seront envoyées à Google lorsque l’appareil sera allumé ». 

Extrait de la plainte NYOB

Très peu de documentation explique quelles données sont envoyées par les GLS. Dans une réponse adressée à deux sénateurs américains en janvier 2018, Google précise que les GLS remontent des informations de localisation associées à des identifiants temporaires et tournants[13]. Il s’agit vraisemblablement de données pseudonymisées et selon la méthode et la fréquence avec lesquelles ces pseudonymes sont générés, il est plus ou moins facile pour Google de retrouver à qui ces données de localisation correspondent.

Popup de demande d’activation des GLS dans Google Maps. Les explications (écran de droite) n’apparaissent que si on clique sur la flèche

Les GLS sont souvent activés par les utilisateurs. S’il est vrai qu’ils permettent une localisation plus rapide et plus précise, leur fort taux d’utilisation s’explique aussi par la simplicité de leur activation : lorsqu’une app veut demander à l’utilisateur d’activer la localisation, il est beaucoup plus simple de le faire en utilisant l’API des GLS : un popup apparaît et l’utilisateur n’a qu’à cliquer sur OK. A ma connaissance, il n’existe pas d’API permettant de d’activer aussi simplement la localisation sans activer les GLS.  A contrario désactiver les Google Location Services nécessite de fouiller dans les paramètres du téléphone[14].

Exposure Notification bénéficie d’une API privilégiée

Les applications de contact tracing qui souhaitent pouvoir utiliser le scanner Bluetooth sur la globalité des terminaux Android n’ont, a priori, pas d’autre choix que de s’assurer que la localisation du téléphone est active. Lorsque la localisation n’est pas active, les apps ont deux options pour demander à l’utilisateur de l’activer :

  1. Lui demander de se rendre dans les paramètres du téléphone pour activer la localisation. Cela implique de faire sortir l’utilisateur de l’app pour le diriger vers les paramètres du téléphone puis de le faire revenir dans l’application. Ces opérations sont fastidieuses et nuisent significativement à l’expérience utilisateur.
  2. La seconde option consiste à lui permettre d’activer la localisation via une popup qui apparait dans l’app. Cette seconde option est préférable d’un point de vue expérience utilisateur puisque ce dernier reste dans l’app et n’a pas à naviguer dans les paramètres du téléphone. Plusieurs applications font d’ailleurs apparaitre un tel popup lorsque la localisation n’est pas active. La subtilité est que cette option n’est disponible qu’avec les Google Location Services, il n’est pas possible pour un développeur de faire en sorte que seul le GPS soit activé. En choisissant cette seconde option, le développeur active les GLS et la collecte par Google de données de localisation pseudonymisées.

Les deux options ont leurs inconvénients : la première nuit à l’expérience utilisateur alors que la seconde nuit à sa vie privée Mais pour les applications qui s’appuient sur EN, Google semble avoir apporté une troisième option : ces applications peuvent activer le service de localisation depuis l’app sans pour autant activer les GLS. Elles disposent ainsi des avantages des deux approches : une expérience utilisateur plus fluide qui n’active pas systématiquement de remontée d’informations.

Le fait que toutes les applications basées sur l’API Exposure Notification utilisent exactement le même texte pour décrire l’activation de la localisation indique que c’est au niveau de l’API Exposure Notification que l’opération est effectuée et non au niveau de l’app. Comme pour les GLS Google peut modifier un paramètre depuis une app car les Plays Services disposent des permissions requises pour le faire[15], mais les autres applications n’ont pas accès à ces fonctionnalités (à noter que les apps utilisant EN ne demandent pas non plus la permission de localiser).

Captures de 4 applications de contact tracing basé sur Exposure Notification

Même si la localisation est activée pour les besoins d’une application de contact tracing, les autres applications qui ont la permission d’accéder à la localisation et les services de Google précédemment activés (Location History ou GLS) pourront localiser l’utilisateur. Or une fois encore, on peut se demander qu’elle est la pertinence de permettre la collecte de données de localisation lorsque l’utilisateur souhaite simplement utiliser une app de contact tracing. Google aurait pu aller un cran plus loin et désactiver l’envoi d’informations à destination de ses propres services lorsque la localisation était activée depuis une app de contact tracing.

La voie à suivre ?

Une meilleure solution serait de n’activer la localisation que sur les terminaux Android sur lesquels cela est nécessaire. En effet, comme on l’a vu, du fait de la fragmentation, sur une partie du parc de terminaux Android la localisation n’a pas à être activée pour permettre aux app de contact tracing de fonctionner. Forcer l’activation de la localisation sur ces terminaux n’a donc pas de sens, mais encore faut-il pouvoir les identifier or l’API ne permet pas forcement de le faire.

[1] https://team.inria.fr/privatics/ftc-inmobi-settlement-our-2014-research-predicted-the-abuse-of-the-wifi-permission/

[2] https://www.nytimes.com/interactive/2019/06/14/opinion/bluetooth-wireless-tracking-privacy.html

[3] https://developer.android.com/about/versions/marshmallow/android-6.0-changes#behavior-hardware-id

[4] On entend par fabricant, les sociétés qui vendent des smartphones avec l’OS Android telles que Samsung, Xiaomi, Huawei, LG…

[5] https://www.polidea.com/blog/a-curious-relationship-android-ble-and-location/

[6] https://twitter.com/vtoubiana/status/1309022372142477313

[7] https://linc.cnil.fr/fr/barometre-linc-2019-les-pratiques-de-protection-des-donnees-progressent

[8] https://blog.google/inside-google/company-announcements/update-exposure-notifications

[9] https://www.nytimes.com/2020/07/20/technology/google-covid-tracker-app.html

[10] Si vous souhaitez voir si StopCovid fonctionne correctement sur votre smartphone quand la localisation est désactivée, vous pouvez installer cette version (https://github.com/ofa-/stopcovid-android) qui affiche une notification dès qu’un appareil avec StopCovid passe à proximité. Si après avoir désactiver la localisation, vous lancer l’application puis passez à proximité d’un autre smartphone avec StopCovid et que rien ne s’affiche, c’est probablement que votre smartphone bloque les scans quand la loc n’est pas activée. Si vous ne faites pas confiance au développeur de ce fork, une alternative consiste à télécharger le code puis à débugger l’application pour voir si le scan fonctionne bien.

[11] https://github.com/opentrace-community/opentrace-android/issues/61

[12] https://policies.google.com/technologies/location-data?hl=fr&fg=1#how-find

[13]  “The information Google collects from Android devices for use in GLS is linked to a temporary and rotating device identifier that is not used by or shared with other services.” https://www.accc.gov.au/system/files/Oracle-Submission-2-%28September-2018%29.pdf.

[14] https://support.google.com/accounts/answer/3467281?hl=fr

[15] https://developer.android.com/reference/android/Manifest.permission

Article info

Categories