Quand la fragmentation d’Android pose des problèmes aux applications de contact tracing

Quand la fragmentation d’Android pose des problèmes aux applications de contact tracing

Quand la fragmentation d’Android pose des problèmes aux applications de contact tracing

Sur son blog personnel, Vincent Toubiana (secrétaire général adjoint du CNNum, passé par l’Arcep et la CNIL) explique en quoi cette fragmentation est « un obstacle pour les applications contact tracing ». En cause, un changement important dans Android depuis la version 6 : « il faut que la localisation soit active pour utiliser certaines fonctionnalités Bluetooth Low Energy »… or elles sont justement nécessaires pour les applications de suivi des contacts.

« Pour corser le problème, explique Vincent Toubiana, la solution la plus simple pour activer la localisation depuis une application (et donc s’assurer que le BLE fonctionne) implique de remonter des informations de localisation à Google ». Cela dépend non seulement de la version d’Android, mais aussi des modifications apportées par les constructeurs.

« 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 », explique-t-il. Conséquence : le comportement peut différer d’un smartphone Android à l’autre. « Ainsi, les développeurs devraient tester leurs applications sur de multiples smartphones pour considérer les différents cas de figure ».

Et pour ne rien arranger, « 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 ».

Pour Toubiana, « une meilleure solution serait de n’activer la localisation que sur les terminaux Android sur lesquels cela est nécessaire […] mais encore faut-il pouvoir les identifier or l’API ne permet pas forcément de le faire ». De son côté, TousAntiCovid (qui vient d’arriver), « 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 », mais sans pour autant pouvoir « déterminer si cela réglait le problème ».

Commentaires (7)


Pour le coup je suis bien d’accord.
Je comprend toujours pas cette obligation de la localisation pour utiliser le BLE, je trouve ça bien chiant au quotidien.


Utiliser une fonction dans un but pas du tout prévu à la base ne fonctionne pas comme désiré à l’origine? Quelle surprise…
(Même si c’est totalement con d’activer la localisation (donc consommer de la batterie) pour avoir un truc qui consomme moins d’énergie)


Si ce sujet avait été réfléchit en amont la France ne serait pas parti avec un système propriétaire, on aurait fait comme le reste de l’Europe et utilisé les API Google/Apple (en plus ça aurait permis que l’application fonctionne correctement en voyageant en Europe).
Bien que je n’en sache rien il est probable qu’avec les API Covid Google les problèmes évoqués ici sont (mieux) adressés.
D’ailleurs je n’ai pas compris de quelle API il est question dans le dernier paragraphe mais ça ne doit pas être celle de Google spécifique pour la Covid (sans doute les API BLE/loclisation “habituelles” hors Covid puisque nous on utilise le protocole ROBERT).


On parle bien des fonctionnalités de localisation, pas du GPS? Pour moi il y a une certaine logique: dans une “SmartCity” (gasp!) on peut tracker le mouvements des terminaux en bluetooth BLE du moment qu’ils tentent de se connecter à quelque chose (en fait, leur proximité à des pnneaux d’arrêt de bus par exemple). Ca ne marche pas il me semble avec un terminal bluetooth “classique” (en tout cas, c’est pas écrit dans les brochures des appareils pour smart cities).



Donc c’est normal que Android englobe dans la “localisation” ces fonctionnalités de bluetooth BLE. Et normalement on indique quel type de localisation on permet (GPS/Wifi/bluetooth).



A vouloir tordre un concept, on n’a rarement une solution universelle.




Patch a dit:


(Même si c’est totalement con d’activer la localisation (donc consommer de la batterie) pour avoir un truc qui consomme moins d’énergie)
Non, dans ce cas on parle d’un nouveau protocole pour de micro-échanges de proximité, et qui dit proximité dit localisation, soit par google, soit par l’opérateur qui a placé en capteur)



Un petit peu triste, car la pandémie, si elle est un désastre sur bien des aspects et marquera notre génération, c’est aussi une merveilleuse occasion de faire bouger des choses autrefois restées en léthargie.
Je pense au télétravail dans le monde. Pour ceux et celles qui ont un métier compatible avec cette pratique, il devient bcp plus facile de trouver des entreprises dans le monde proposant du TT. Tu es français et tu veux bosser pour le Canada, l’Allemagne, un pays nordique ? C’est plus facile qu’avant, partout dans le monde on commence à débloquer le TT, et sans pour autant l’autoriser partout ni le prendre en charge comme il le faudrait, un grand pas en avant a été fait. Cela aurait pris des décennies sans la covid.
Alors je pense maintenant à la fragmentation Android. Encore avant la pandémie, c’était juste un soucis écologique et un soucis économique (tél inutilisable/peu fiable passé deux ans quoi… en gros), or l’écologie et le soucis des consommateurs, ce ne sont pas encore des priorités. Parcontre avec la pandémie, on pourrait arguer que la fragmentation pose cette fois ci un gros soucis pour la gestion de la crise : en effet, c’est bien à cause d’elle que beaucoup de terminaux ne sont pas compatibles. Imposer un meilleur support constructeur dans le temps serait une solution, ou bien forcer Google à revoir sa copie sur les fondations mêmes d’Android (c’est tout à fait réalisable).
Bref, j’aurais aimé que des politiques fassent comme ils ont l’habitude avec les sujets qu’ils défendent bec et ongle : tu veux imposer la surveillance ? Bah tu rabâches les thèmes du terrorisme et de la pédophilie. Ils pourraient avoir la même ferveur pour la fragmentation Android, car là on parle de la covid, de dizaines de milliers de morts en France, d’une crise mondiale, et mon dieu, une société hyper bénéficiaire et monopolistique se permet se mettre des bâtons dans les roues de la gestion de la crise, tout ça pour des histoires de gros sous (dont ils ne paieront même pas les impôts en France).
Franchement, y’a matière à faire scandale et enfin faire la nique à Google. Mais non, je sais que ce n’est qu’un doux rêve… snif. Google ce sont les US, c’est Trump, et la France n’a pas le pouvoir de négociation qu’il faut. On reste un petit pays, même si on se croit tjrs grand.



grsbdl a dit:


Bref, j’aurais aimé que des politiques fassent comme ils ont l’habitude avec les sujets qu’ils défendent bec et ongle : tu veux imposer la surveillance ? Bah tu rabâches les thèmes du terrorisme et de la pédophilie. Ils pourraient avoir la même ferveur pour la fragmentation Android, car là on parle de la covid, de dizaines de milliers de morts en France,




Bah pour le coup, les politiques ne font rien pour rien.
Si ils “rabâchent les thèmes du terrorisme et de la pédophilie” pour la surveillance, c’est aussi car ils veulent la surveillance d’abord pour le contrôle social (autrement appelé “ordre public”).
Mais je ne pense pas qu’ils aient le bagage technique et l’imagination nécessaire pour comprendre le problème de la fragmentation des terminaux téléphonique.
Surtout à un moment où en parallèle les opérateurs commencent à aiguiser leurs armes commerciales pour faire racheter aux gens les terminaux 5G.


Google invoque des raisons de sécurités :
https://developer.android.com/about/versions/marshmallow/android-6.0-changes.html?hl=fr#behavior-hardware-id




Access to Hardware Identifier
To provide users with greater data protection, starting in this release, Android (6.0) removes programmatic access to the device’s local hardware identifier for apps using the Wi-Fi and Bluetooth APIs. The WifiInfo.getMacAddress() and the BluetoothAdapter.getAddress() methods now return a constant value of 02:00:00:00:00:00.



To access the hardware identifiers of nearby external devices via Bluetooth and Wi-Fi scans, your app must now have the ACCESS_FINE_LOCATION or ACCESS_COARSE_LOCATION permissions




Il doit aussi y avoir une raison de cohérence avec les balises beacon bluetooth en liant avec le BLE :
https://developers.google.com/beacons/proximity/guides




The Proximity Beacon API is a part of the Bluetooth low energy (BLE) beacon platform, which also includes Eddystone, an open beacon format from Google.



(quote:1832741:brice.wernet)
On parle bien des fonctionnalités de localisation, pas du GPS?




la permission ACCESS_FINE_LOCATION demandée depuis Android 6 pour obtenir l’identifiant matériel des autres périphériques Bluetooth alentour, c’est une localisation de précision type GPS (ca doit aussi gérer les beacons bluetooth ou la localisation dans les batiments avec le wifi RTT). La localisation “grossière” (COARSE_LOCATION) est aussi demandée d’ailleurs, localisation type triangulation des antennes mobiles / triangulation des point d’accès wifi relevés par les googles cars ou bases de données publiques



https://developers.google.com/maps/documentation/android-sdk/location?hl=fr#location_permissions
https://developer.android.com/guide/topics/connectivity/wifi-rtt


Fermer