Journal A propos des protocoles de traçage pour le Covid-19 : Google/Apple vs. INRIA/Fraunhofer

Posté par  . Licence CC By‑SA.
17
25
avr.
2020

Sommaire

Cet article est consacré aux solutions techniques pour le traçage de contacts sociaux dans le cadre de l'épidémie de Covid-19.

Je voudrais consacrer ce journal à la comparaison des deux principales solutions qui émergent des réflexions concernant les protocoles de traçage :

Intérêt d'une application de traçage de relations sociales

L'intérêt de la mise en place d'une application de traçage est de permettre d'informer les gens qui ont été en contact avec des personnes contagieuses (contact ayant lieu alors que ces personnes ne se savaient pas encore infectées). Ainsi la personne informée peut prendre des précautions : se confiner, se faire tester (en supposant que les tests soient en disponibilité suffisante pour cela) et/ou se faire prescrire un traitement préventif avant même l'apparition des symptômes (pas encore connu en l'état actuel des connaissances). Cela peut donc aider à ralentir le rythme de l'épidémie.

Vie privée

Cela pose des questions importantes quant au respect de la vie privée des personnes utilisant une telle application de traçage. En fait on distingue deux types d'intervenants au fonctionnement de l'application : les utilisateurs (citoyens) et l'autorité gérant le système. Les problématiques de vie privée concernent ces deux intervenants :

  • On souhaiterait que l'autorité ne puisse pas pister les utilisateurs et donc par exemple savoir si tel utilisateur a rencontré tel autre utilisateur à certain moment au cours des derniers jours. L'autorité ne doit pas avoir la possibilité de reconstituer les cliques d'utilisateurs avec leurs interactions sociales.
  • On souhaiterait que les utilisateurs ne puissent pas s'espionner entre-eux, c'est-à-dire qu'ils ne puissent pas d'une part arriver à déterminer leurs interactions sociales respectives ou reconstituer leur déplacements et d'autre part déterminer que tel utilisateur est infecté ou pas.

On suppose pour la suite que l'autorité et les utilisateurs sont tous potentiellement «pisteurs» dans le sens où s'ils ont la possibilité technique de pister, ils le feront.
On suppose également que le protocole de traçage est parfaitement connu et que les utilisateurs ont un total contrôle sur l'application qu'ils utilisent (on peut supposer qu'il existe plusieurs implantations d'applications, dont certaines open source et que les utilisateurs ont tout loisir de modifier les applications et donc d'accéder aux données qu'elles manipulent).

Des téléphones devenant des balises Bluetooth Low Energy

Aussi bien pour la solution de Google/Apple que celle de l'INRIA/Fraunhofer, le fonctionnement repose sur l'émission d'identifiants à intervalle de temps régulier en utilisant le Bluetooth Low Energy (BLE) ; un protocole de liaison radio qui diffère du Bluetooth classique dans le sens où il est beaucoup moins énergivore et possède une portée plus limitée. Le BLE est notamment utilisé pour mettre en oeuvre de solutions de localisation en intérieur (là où le signal GPS ne peut passer). On utilise pour cela des balises BLE (beacons) qui émettent leur identifiant avec leur positionnement dans le bâtiment au téléphone de l'utilisateur. Celui-ci peut en associant la force des signaux des balises BLE reçues déterminer par triangulation un positionnement précis dans le bâtiment. Une balise BLE qui annonce son identifiant toutes les secondes peut fonctionner plusieurs années avec une simple pile bouton lithium. Pour le protocole de traçage, le téléphone joue le rôle de balise BLE et émet régulièrement un identifiant.

Ainsi chaque téléphone va jouer le rôle de balise mais également d'écouteur de balises que sont les autres téléphones. L'application pourra mémoriser les identifiants de tous les téléphones qu'elle rencontre. Lorsqu'un utilisateur est testé positif pour le Covid-19, l'autorité récupère son identifiant de balise et le publie. Les autres utilisateurs consultent régulièrement le registre des identifiants des infectés et peuvent donc savoir si ils ont rencontré une personne contagieuse et prendre les mesures nécessaires le cas échéant.

Les avantages d'utiliser le BLE sont d'une part comme on l'a vu que la surconsommation énergétique du téléphone est faible et d'autre part que le risque de faux-positifs est réduit par rapport à un système de communication radio de plus forte portée. Mais dans l'approche qui vient d'être décrite, nous n'avons pas solutionné toutes les problématiques de vie privée posées.

L'autorité recueille et publie les identifiants des diagnostiqués positifs mais elle ne peut pas retracer leurs contacts et déplacements (sauf si elle déploie sur le terrain des récepteurs BLE à cette fin) ; ces informations restent dans la mémoire du téléphone de chacun (à laquelle on suppose que l'autorité n'a pas accès).

En revanche les utilisateurs peuvent se pister entre-eux sans difficulté et déduire l'identité de personnes infectées. Pour retrouver l'identité d'un infecté, il suffit d'associer à chaque identifiant collecté l'instant de collecte plus d'autres informations (position géographique GPS, note manuelle de l'utilisateur…). L'utilisateur pourra se rappeler qui il a croisé à cet instant et à cet endroit ce qui restreint beaucoup le nombre de personnes possibles. Il est possible aussi de placer des petits appareils BLE dans des lieux publics (rue, magasins…) et de faire des statistiques sur les personnes infectées ayant transité dans ces lieux et de désanonymiser ces informations si on les croise avec d'autres sources de données. Par exemple un magasin peut placer près de sa caisse un appareil récoltant les identifiants BLE des téléphones des clients. Si le client X utilise sa carte de fidélité et est déclaré ensuite malade dans le registre des identifiants des infectés, le magasin pourra savoir que X est infecté. On pourrait aussi croiser ces informations avec des vidéos de caméra (mais si X porte un masque, il est plus difficile de l'identifier ;)

Des identifiants éphémères pour limiter les recoupements

Pour limiter le risque de pistage entre utilisateurs, Google et Apple ont proposé dans leur approche que les utilisateurs émettent des identifiants éphémères plutôt que le même identifiant en permanence. Ces identifiants éphémères ont une durée de vie de 15 minutes et sont générés à partir d'une clé maître journalière connue uniquement du téléphone. Il n'est pas possible de retrouver la clé maître à partir des identifiants éphémères. Cette idée permet d'éviter qu'un boîtier BLE dans un lieu public puisse pister les mouvements d'une même personne au cours du temps (par exemple on ne pourra plus savoir qu'une certaine personne s'est rendue dans ce même lieu à tel moment et à tel autre moment). Par contre on peut toujours, si on dispose de donnés de croisement adéquates pour le moment précis, désanonymiser un identifiant même éphémère. Ainsi par exemple si X vient lundi dans le magasin payer avec sa carte de fidélité, on pourra associer son identifiant éphémère à son identité mais si il revient mercredi sans utiliser sa carte, son anonymat restera conservé, alors que si l'on avait utilisé un identifiant permanent on aurait pu le reconnaître également mercredi.

Il est maintenant nécessaire que la base des identifiants des malades contienne pour chaque malade non pas un seul identifiant mais tous ses identifiants éphémères des deux dernières semaines (si l'on suppose que la période d'incubation ne peut pas dépasser cette durée). Si l'on suppose que chaque identifiant tient sur 128 bits, qu'un nouvel identifiant éphémère est utilisé toutes les 15 minutes, cela représente jusqu'à ~21 Ko de données à conserver par malade. En pratique cela sera sûrement moins car on pourra ne pas envoyer les identifiants éphémères produits sur les périodes on l'on aura reçu aucun identifiant d'autres téléphones (par exemple la nuit ou chez soi). Mais ça reste un volume conséquent de données surtout si on le multiplie par le nombre de diagnostiqués positifs. Par exemple sur les 14 derniers jours, il y a eu plus de 400 000 nouveaux cas diagnostiqués aux Etats-Unis, la taille correspondante du registre des identifiants éphémères pourrait atteindre (si tout le monde utilisait une application de traçage) 8 Go pour 14 jours, soit une base journalière de l'ordre de 600 Mo. L'utilisateur qui voudrait savoir si il a croisé une personne qui a été testée positive devra télécharger chaque jour la base de la veille et vérifier si un identifiant éphémère qu'il a collecté y réside. On pourrait imaginer que la base soit fractionnée en bases régionales plus petites. On pourrait aussi avoir un service web à qui l'on fournirait les identifiants éphémères que l'on a collectés pour qu'il nous indique si l'un d'eux correspond à un infecté. Mais dans ce cas le service web en question pourrait obtenir des informations permettant de tracer les utilisateurs qui le sollicitent ; cela resterait uniquement une position de repli pour les utilisateurs ne disposant pas d'une connectivité Internet suffisante. On pourrait également imaginer que le service web soit interrogé en plusieurs fois, en utilisant des proxys web…

Fiabilité du registre des infectés

Mais qu'en est-il de la fiabilité de la base des identifiants éphémères des positifs au Covid-19 ? On pourrait imaginer que n'importe qui puisse prétendre être infecté et envoie ses identifiants éphémères pour qu'ils soient intégrés dans la base (et ainsi inquiéter inutilement les gens rencontrés). Pour éviter ce problème, l'autorité gérant la base peut distribuer des jetons uniques (nombre de 128 bits aléatoires par exemple) aux organismes habilités à diagnostiquer (labos, hôpitaux…). Il faudrait fournir à l'application un de ces jetons uniques qui serait communiqué par l'organisme de diagnostic. L'application enverrait ce jeton avec les identifiants éphémères personnels vers l'autorité (qui vérifierait qu'il s'agit bien d'un jeton qu'elle a émis et qu'il n'a pas été réutilisé). Il reste aussi le problème d'un utilisateur positif qui soumettrait non pas ses propres identifiants éphémères mais des identifiants éphémères d'autres personnes (pour faire croire que ce sont elles qui sont infectées et pas lui). Ce problème est facilement résolvable si l'autorité exige la fourniture des clés maîtres journalières ayant servi à générer les identifiants éphémères. Bien sûr l'autorité ne doit pas publier ces clés maîtres mais elle pourra les utiliser pour vérifier qu'elles génèrent bien les identifiants éphémères communiqués. Comme il n'est pas possible de déduire les clés maîtres des clés éphémères, la seule attaque possible serait une collusion entre plusieurs utilisateurs qui échangeraient les données de leurs téléphones.

Un autre souci serait le cas d'un utilisateur qui collecterait des identifiants éphémères qu'il réémettrait à son propre compte (rejeu d'identifiants). Si les identifiants réémis appartiennent à des personnes diagnostiquées positives plus tard, les personnes les ayant reçus pourraient surestimer leur risque d'infection. Pour éviter les rejeux d'identifiants, on pourrait faire en sorte que ceux-ci soient publiés avec leur date approximative d'émission dans le registre des infectés : si un utilisateur trouve dans le registre un identifiant qu'il a collecté il vérifiera que la date indiquée dans le registre correspond à celle où il a collecté l'identifiant (si ce n'est pas le cas, il l'ignorera).

Conclusion de l'approche décentralisée Google/Apple

On vient de décrire à peu près comment fonctionne l'approche de Google et Apple que l'on peut qualifier de décentralisée dans le sens où ce sont les utilisateurs eux-mêmes qui déterminent si ils sont à risque en consultant un registre central tenu par une autorité, ce registre contenant les identifiants éphémères des personnes diagnostiquées positives. Cette approche est intéressante dans le sens où l'utilisateur reste à tout moment maître de ces données. Il peut installer l'application à n'importe quel moment, commencer la collecte et l'annonce à n'importe quel moment et choisir de révéler ou non au registre s'il a été diagnostiqué positif. Il peut même se comporter de manière égoïste en collectant les identifiants émis dans son voisinage sans activer l'émission d'identifiants par son téléphone. Il reste ainsi invisible mais bénéficie d'alertes si il a croisé une personne à risque. Cette approche offre donc une liberté totale à l'utilisateur. Il faut toutefois qu'il ait conscience que l'action d'envoyer ses identifiants éphémères vers le registre peut potentiellement permettre de l'identifier comme malade auprès de ses contacts. Mais si cet envoi résulte d'un choix éclairé de sa part, on ne peut pas considérer qu'il y a rupture du secret médical. D'autre part l'utilisateur diagnostiqué positif peut choisir de révéler au registre sélectivement ses identifiants éphémères : il pourrait ne pas transmettre les identifiants correspondant à des périodes où il a côtoyé des personnes à qui il ne souhaite pas révéler sa maladie (et qui ne pourront donc pas prendre eux-mêmes des mesures préventives). En reprenant l'exemple évoqué précédemment, il pourrait ne pas transmettre les identifiants correspondant à ses visites au magasin.

Une seconde approche : le protocole de l'INRIA et de l'institut Fraunhofer

La seconde approche, celle développée par l'INRIA et l'institut Fraunhofer a pour objectif principal d'empêcher l'identification des malades par les utilisateurs. Pour arriver à cette fin, l'autorité joue un rôle plus important et plus actif. Lorsqu'un individu est diagnostiqué positif, plutôt que de demander la publication de ses identifiants éphémères dans un registre, il communique à l'autorité les identifiants éphémères de toutes les personnes qu'il a croisées. C'est l'autorité qui aura la charge de notifier ses contacts du risque qu'ils encourent sans jamais révéler la source de l'infection.

Le fonctionnement de l'approche INRIA/Fraunhofer peut ainsi être décrit :
1. L'utilisateur installe l'application sur son téléphone
2. L'application créé un compte sur le serveur de l'autorité. La création du compte est anonyme, le serveur n'étant pas censé récupérer l'identité réelle du participant. Le serveur génère un identifiant maître pour l'utilisateur qu'il conserve secrètement, une clé d'authentification qu'il communique à l'utilisateur (qui servira à authentifier ses communications futures avec le serveur) et un jeu d'identifiants éphémères qui devront être diffusés en BLE à des moments précis par l'utilisateur. Les identifiants éphémères d'un utilisateur sont générés à partir de son identifiant maître (connu uniquement du serveur) ainsi que d'une clé secrète du serveur en utilisant un algorithme de chiffrement symétrique. Cela signifie que le serveur peut aussi retrouver l'identifiant maître à partir des identifiants éphémères mais que les utilisateurs ne le peuvent pas car ils ne possèdent pas la clé secrète du serveur.
3. L'utilisateur diffuse ses identifiants éphémères par BLE et collecte les identifiants des gens avec qui il est physiquement proche.
4. Si l'utilisateur est diagnostiqué positif, il envoie au serveur les identifiants éphémères collectés de ses contacts. Le serveur peut retrouver les identifiants maîtres des contacts à partir des identifiants éphémères et les inscrire sur une liste d'utilisateurs à risque.
5. Chaque utilisateur interroge régulièrement le serveur pour savoir s'il est sur la liste des utilisateurs à risque : pour cela il communique son identifiant éphémère du moment, le serveur retrouve son identifiant maître et peut lui indiquer s'il est sur la liste des utilisateurs à risque. Le serveur ne révélera pas l'origine du risque.

Divulgation de l'identité d'une personne infectée

Les concepteurs de ce protocole ont cherché à minimiser les risques de divulgation de l'identité d'une personne infectée. Toutefois un attaquant motivé peut y parvenir. Il pourra pour cela créer de multiples comptes "jetables" sur le serveur de l'autorité : il les utilisera que pour ne diffuser qu'un seul identifiant éphémère qui sera collecté que par la personne ciblée. Si l'attaquant apprend qu'un de ses comptes jetables fait partie des utilisateurs à risque, il saura avec certitude que la personne ciblée avec ce compte est diagnostiquée positive. Pour rendre ce type d'attaque plus difficile, il est suggéré que le serveur utilise des captchas pour la création d'un compte ainsi que de répondre faussement qu'un utilisateur est à risque (génération de faux-positifs). Ainsi l'attaquant pourra savoir avec une probabilité haute que la personne ciblée est infectée mais pas certaine (mais cela pourrait être contourné par l'usage de multiples comptes ciblant une même personne).

Des fédérations d'autorités

Notons également que le protocole INRIA/Fraunhofer propose un fonctionnement avec une fédération de serveurs : chaque identifiant éphémère est associé avec un code pays chiffré qui ne peut être déchiffré que par une clé secrète partagée par les serveurs de la fédération. Ainsi lorsqu'un utilisateur est diagnostiqué positif, il envoie au serveur de son pays les identifiants éphémères associés au code pays chiffrés et le serveur local peut rediriger les identifiants éphémères étrangers vers les serveurs concernés qui pourront prévenir leurs utilisateurs qu'ils sont à risque.

Conclusion de l'approche INRIA/Fraunhofer

Le principal reproche que l'on peut faire à l'approche INRIA/Fraunhofer est que sous couvert de protéger l'identité des malades elle donne des pouvoirs importants à l'autorité. Si celle-ci est malhonnête, elle pourrait conserver les contacts des personnes infectées, reconstituer leur graphe d'interaction sociale qui pourrait même être désanonymisé si des informations adéquates sont collectées (adresse IP des requêtes et collusion avec les fournisseurs d'accès). Dans la description de la première version du protocole, il est suggéré que les utilisateurs diagnostiqués positifs contactent le serveur en envoyant un par un les identifiants éphémères de leurs contacts en utilisant un MixNet sur une longue période : ainsi le serveur ne peut pas savoir l'identité du malade et le rapprocher de ses contacts. C'est effectivement envisageable mais puisque le serveur n'aurait plus de contrôle sur l'identité de l'émetteur des messages, il ne pourrait pas savoir si ceux-ci correspondent effectivement à un utilisateur diagnostiqué positif. Il serait alors possible de spammer le serveur et de provoquer une grande quantité d'alertes infondées.

Opter pour l'approche de Google/Apple ou celle de l'INRIA/Fraunhofer ?

Pour résumer les deux approches, on pourrait dire que celle de Google/Apple considère les utilisateurs comme responsables et leur laisse le pouvoir de calculer leur exposition au risque. C'est intéressant car on peut savoir à quel moment on a pu être exposé au risque : on peut alors identifier la personne potentiellement contaminante mais on peut également se rappeler de détails qui permettent de mieux apprécier le risque en le contextualisant (portait-on un masque ? respectait-on les distances de sécurité ?). L'autorité ne joue qu'un rôle passif en se contentant de collecter et relayer les identifiants éphémères des personnes infectées.

Avec l'approche INRIA/Fraunhofer, l'autorité est présumée bienveillante, ce sont les utilisateurs dont il faut se méfier car on présume qu'ils chercheront à identifier les malades et à les stigmatiser. L'utilisateur doit donc avoir confiance en l'autorité qui le protégera de ses méchants congénères. L'autorité se contentera de lui indiquer s'il est à risque ou pas (et quelquefois en introduisant volontairement des faux-positifs comme on l'a vu) mais il ne pourra pas contextualiser le risque. Prenons l'exemple d'une caissière de magasin côtoyant quotidiennement des clients avec de bons moyens de protection : visière, masque, paroi de plexiglas et distance de sécurité. Cependant elle rencontre pour ses loisirs des personnes sans protection. Avec l'approche INRIA/Fraunhofer, si celle-ci reçoit une notification lui indiquant qu'elle a rencontré un individu infecté, elle ne pourra pas savoir si cela a eu lieu durant son temps de travail ou lors de ses loisirs. On peut supposer qu'elle serait moins inquiète d'apprendre que c'est l'un de ses clients qui est infecté plutôt qu'une des personnes rencontrées sans protection (information qu'il serait possible de savoir avec l'approche Google/Apple). Avec l'approche INRIA/Fraunhofer pour ne pas être avertie suite au contact avec un client infecté, elle devrait désactiver l'annonce de ses identifiants durant son temps de travail.

Implantation des protocoles sur des bracelets

Pour finir, on peut ouvrir les perspectives sur l'utilisation d'autres appareils que des téléphones Android/iOS pour le protocole de traçage. On pourrait imaginer par exemple des bracelets BLE pour ceux qui n'ont pas de smartphone supportant le BLE. Ceux-ci généreraient ou seraient pré-remplis avec des identifiants éphémères qu'ils diffuseraient périodiquement et ils collecteraient les identifiant reçus. En cas de diagnostic positif, l'hôpital récupérerait du bracelet soit les identifiants diffusés (approche Google/Apple), soit les identifiants collectés (approche INRIA/Fraunhofer) pour les transmettre à l'autorité. Mais comment faire pour que le bracelet puisse informer son utilisateur qu'il a rencontré une personne infectée ? Le bracelet pourrait se connecter à Internet périodiquement mais dans ce cas il faudrait un téléphone ou un ordinateur qui serve de relai. On pourrait imaginer à la place que les données permettant d'informer les utilisateurs à risque soient diffusées par un protocole de radiomessagerie unidirectionnel : le bracelet serait en permanence en écoute pour repérer si un des identifiants collectés est diffusé (approche Google/Apple). Pour l'approche INRIA/Fraunhofer, on peut supposer qu'un identifiant supplémentaire secret soit introduit pour chaque utilisateur qui ne soit connu que de l'autorité et de l'utilisateur lui-même : le bracelet réagirait lorsque cet identifiant serait diffusé. L'intérêt d'utiliser un bracelet est que l'on pourrait y introduire des fonctionnalités complémentaires : prise de pouls, de température, évaluation du sommeil… qui permettraient une meilleure évaluation du risque des malades potentiels et un meilleur suivi des malades confirmés.

  • # info supplémentaire

    Posté par  . Évalué à 10 (+15/-0).

    Ce document, rédigé par des chercheurs spécialistes en sécurité informatique, donne quelques scénarios simples pour casser la sécurité de ces deux approches.

    • [^] # Re: info supplémentaire

      Posté par  (site Web personnel) . Évalué à 10 (+9/-0).

      À noter, ce document liste les attaques de type sociale afin de manipuler le système de détection ou même d'identifier un porteur potentiel et cela peu importe la technologie sous-jacente.

      Personnellement je l'ai trouvé très didactique dans la manière de présenter les différentes attaques possible en dehors de toute technique informatique et sans jargon avancé (sans compter les jeux de mots).

      • [^] # Re: info supplémentaire

        Posté par  . Évalué à 1 (+1/-0).

        Effectivement ce document est assez intéressant avec une touche humoristique. Toutes les approches de traçage qui à l'origine peuvent avoir un objectif légitime (casser les chaînes de transmission du virus) peuvent être détournées pour un usage malveillant. A noter toutefois que le paramétrage de l'application peut limiter ce type de risques.

        L'application de traçage pourrait par exemple avoir 3 modes :

        1. Mode désactivé. L'application n'émet pas d'identifiants et ne collecte aucun identifiant. Ce mode serait en vigueur lorsque l'utilisateur est chez lui (évite les faux-positifs liés à la collecte à travers les murs de voisins contaminés) ou à proximité de son domicile (évite l'espionnage entre voisins). Ce mode pourrait être aussi mis en place lorsque l'utilisateur se déplace (facile à détecter par l'accéléromètre du téléphone) pour éviter les faux-positifs liés à une rencontre brève dans la rue ou dans un magasin.
        2. Mode risque modéré. Ce mode pourrait être actif dès que l'utilisateur devient sédentaire pendant un certain laps de temps (assis dans un transport en commun, salle de réunion…). L'application émettrait alors des identifiants et collecterait ceux des autres utilisateurs. Pour éviter trop de faux positifs, on pourrait ne garder en mémoire que les identifiants éphémères collectés un certain nombre de fois (ce nombre étant à ajuster avec l'expérience).
        3. Mode risque élevé. Ce mode devrait être activé manuellement par l'utilisateur. L'application associerait aux identifiants collectés une étiquette de risque élevé. Ce mode pourrait être utile dans certains cas où la proximité physique est importante et/ou les moyens de protection pas toujours possibles (coiffeur, médecin, dentiste, comédien…). Une alerte reportée liée à l'activation de ce mode serait à prendre beaucoup plus au sérieux.

        L'utilisateur pourrait garder un contrôle total et changer à tout moment le mode de l'application manuellement (en optant par exemple pour une désactivation si le contexte lui fait penser que le risque d'espionnage est fort).

        A ces trois modes, on pourrait rajouter un quatrième (fake mode) au cours duquel l'application émettrait des identifiants aléatoires : elle ferait ainsi croire qu'elle est active sans qu'il y ait de traçage (résout le problème exposé par la scénario 11 du centre commercial La Fayote du document de risques-tracage.fr).

        • [^] # Re: info supplémentaire

          Posté par  . Évalué à 5 (+3/-0).

          Ces modes créent des lourdeurs qu'aucun utilisateur lambda ne saura gérer. Comment l'utilisateur serait en mesure de déterminer le risque d'espionnage si les moyens d'espionnage sont invisibles. Par précaution il faudrait partir du principe que le risque est élevé en permanence et désactiver l'application.

          Je ne vois pas le bénéfice du 4ème mode. Si les identifiants sont diffusés, captés et croisés avec des images de vidéosurveillance la correspondance reste facile.

          • [^] # Re: info supplémentaire

            Posté par  . Évalué à 1 (+1/-0).

            Personne n'oblige l'utilisateur lambda à configurer l'application mais je pense qu'il est préférable de proposer plus de possibilités de configuration que pas assez pour que l'utilisateur ait le maximum de contrôle sur l'application.

            Pour le fake mode, il s'agit de diffuser des données aléatoires qui ne correspondent donc pas à de véritables identifiants éphémères. Pour un observateur extérieur, rien ne les distingue de véritables identifiants. Mais ces données aléatoires ne seront jamais envoyées par l'utilisateur vers le registre en cas d'infection (approche décentralisée Google/Apple). Pour l'approche centralisée INRIA/Fraunhofer, vu qu'il s'agit de données aléatoires, elles ne correspondent à aucun identifiant éphémère généré par l'autorité donc si une personne infectée les ayant capturées les envoie vers l'autorité, elles seront ignorées (l'autorité ne pouvant déterminer leur émetteur).

            En fait la seule chose que peut déduire un observateur extérieur est qu'une transmission radio BLE provient de tel endroit, les données aléatoires transmises ne lui servent à rien.

  • # Tor

    Posté par  . Évalué à 1 (+1/-1).

    On pourrait aussi avoir un service web à qui l'on fournirait les identifiants éphémères que l'on a collectés pour qu'il nous indique si l'un d'eux correspond à un infecté. Mais dans ce cas le service web en question pourrait obtenir des informations permettant de tracer les utilisateurs qui le sollicitent ; cela resterait uniquement une position de repli pour les utilisateurs ne disposant pas d'une connectivité Internet suffisante. On pourrait également imaginer que le service web soit interrogé en plusieurs fois, en utilisant des proxys web…

    Pour ce problème, Tor pourrait être incité/rendu obligatoire ?

  • # Intérêt d'une application de traçage de relations sociales

    Posté par  . Évalué à 10 (+15/-0).

    Je trouve que ce chapitre n'est pas assez élaboré, pas seulement par toi mais aussi par les nombreux articles parlant de ces applications. Hors à mon avis, il y a de vraies problématiques sur la fiabilité des données et sur l'installation en masse des applications.

    Est-ce qu'on a une idée de la proportion de faux positifs ? Exemples : je suis quelqu'un dans la rue à 2 mètres, je parle à quelqu'un à travers une vitre, … ça va être considéré comme étant un contact par l'application alors que le risque de contagion est très faible. Une idée du taux de faux négatifs ? Exemples : j'ai oublié mon portable lors de ma promenade, j'ai éternué sur les fruits au supermarché que quelqu'un va toucher 10 minutes après mon départ…
    Par ailleurs, on ne connaît pas le temps d'exposition et la distance maximale nécessaires pour transmettre le virus et on ne sait pas mesurer de manière fiable la distance entre 2 portables.
    Toutes ces inconnues font qu'on va avoir plein de données dont on ne connaît pas la qualité. On rajoute à ça le fait qu'on n'a pas de tests fiables à 100% (je ne parle même pas de la disponibilité de ces tests) ce qui rajoute de l'aléatoire dans la pertinence de ces données. Du coup, est-ce qu'on saura les exploiter efficacement ?

    Ensuite, est-ce qu'on a un scénario pour que le taux d'installation/activation requis de l'application soit atteint, au moins dans certaines régions ? Le chiffre le plus optimiste semble être que 60% de la population doit l'avoir, ce qui veut dire que au moins 78% des possesseurs de smartphone doivent l'installer. Ça ne va pas se faire naturellement : entre ceux qui ne veulent pas, ceux qui ne savent pas, ceux qui se trompent d'application, ceux qui désactivent le bluetooth, …

    On parle beaucoup des aspects techniques, de vie privée et de sécurité de ces applications. Mais au final la première question à se poser avant toutes les autres, est-ce que ça ne serait pas de savoir si elles répondent, au moins partiellement, à l'objectif ? J'ai l'impression que beaucoup de monde prend ce fait pour acquis, et je ne trouve personne pour détailler pourquoi.

    • [^] # Re: Intérêt d'une application de traçage de relations sociales

      Posté par  . Évalué à 2 (+1/-0).

      J'ai l'impression que beaucoup de monde prend ce fait pour acquis, et je ne trouve personne pour détailler pourquoi.

      Je peux essayer? Avec un tout petit peu d'avocat du diable, mais pas trop.

      L'outil informatique est seulement un complément. S'il n'y a pas de masques, diagnostics et personnels il ne servira pas.

      Pour certaines professions il déclenchera plus de faux positifs qu'autre chose, mais..

      Le chiffre le plus optimiste semble être que 60% de la population doit l'avoir, ce qui veut dire que au moins 78% des possesseurs de smartphone doivent l'installer.

      On parle de 60% de la population, mais je pense qu'on devrait parler de 60% d'une population.

      Certaines populations pour lesquels il n'y a pas vraiment d'autres moyens pour informer les personnes avec lesquelles elles sont entrées en contact, et qui vivent en vase clos

      Par exemple les différents employés travaillant au centre d'affaire de La Défense ne se connaissent pas, mais est une population qui se retrouve régulièrement trop proche les uns des autres pendant 20 minutes ou plus, et sont très équipés de smartphone.

      Il y a d'autres populations qui peuvent vivent presque un vase clos (politiques, journalistes), qui ne se parlent pas, ou ne se connaissentpas, mais sont en contact régulier les uns avec les autres.

      • [^] # Re: Intérêt d'une application de traçage de relations sociales

        Posté par  . Évalué à 2 (+1/-0).

        Par exemple les différents employés travaillant au centre d'affaire de La Défense ne se connaissent pas, mais est une population qui se retrouve régulièrement trop proche les uns des autres pendant 20 minutes ou plus, et sont très équipés de smartphone.

        Mais n'est-ce pas aussi une zone où la proportion de faux positifs va être encore plus élevée ? Il suffit d'y être à l'heure de pointe et en quelques minutes on se retrouve avec des centaines de contacts.

        • [^] # Re: Intérêt d'une application de traçage de relations sociales

          Posté par  . Évalué à 1 (+0/-0).

          Pourquoi faux positifs ?

          Le postier derrière son hygiaphone, s'il reçoit des notifications ou s'il en transmet, c'est des faux positifs, il n'y a pas eu exposition.

          Dans le métro ou une congrégation religieuse, c'est de bonnes conditions pour l'exposition.

          (Ou faux positifs dans le sens beaucoup ne seront pas diagnostiqués ?)

          • [^] # Re: Intérêt d'une application de traçage de relations sociales

            Posté par  . Évalué à 1 (+0/-0).

            Dans le métro ou une congrégation religieuse, c'est de bonnes conditions pour l'exposition.

            Ca dépend de ce qu'on entend par métro.

            Exemple: Je vais dans le métro/rer à la défense. J'attends un peu sur le quai. L'application va enregistrer comme contacts tous les gens de la rame qui est devant moi, voire tous les gens du rer/métro devant moi (si pas de notion de temps d'exposition). Hors tous ceux là sont séparés de moi par des vitres, ce sont tous des faux positifs. Dans une zone où le métro/rer est bondé comme la Defense, le compteur grimpe très vite.

            Puis finalement je rentre dans le métro/rer. A ce moment là, j'enregistre comme contacts tous les gens qui sont sur le quai de toutes les stations où je passe.

            • [^] # Re: Intérêt d'une application de traçage de relations sociales

              Posté par  . Évalué à 0 (+0/-2).

              C'est là ou il va falloir un certain doigté de la part des concepteurs de l'application. Google/Apple ont fait savoir que feront parti de l'algo:
              - la puissance du signal (pour tenir compte de l’éloignement)
              - la durée du contact

              Avec ces 2 ingrédients, on peut éliminer un bon 95% de tes scénarios.

    • [^] # Re: Intérêt d'une application de traçage de relations sociales

      Posté par  . Évalué à 2 (+2/-0).

      Ensuite, est-ce qu'on a un scénario pour que le taux d'installation/activation requis de l'application soit atteint, au moins dans certaines régions ? Le chiffre le plus optimiste semble être que 60% de la population doit l'avoir, ce qui veut dire que au moins 78% des possesseurs de smartphone doivent l'installer.

      Je ne comprends pas bien ce raisonnement qui consiste à dire qu'il faut que N% de la population installe l'application pour qu'elle ait une utilité. A priori si seules deux personnes A et B installent l'application dans la population, qu'elles se croisent et que cela permet à B de savoir que A est contaminé, de se mettre en quarantaine et d'éviter de contaminer C, l'application a une utilité. Certes l'utilité est minime par rapport à l'ensemble de la population mais elle est non nulle.
      Il faut voir l'application comme un complément, sans doute modeste, à d'autre mesures beaucoup plus importantes : distanciation sociale, lavage de mains, port du masque…

      • [^] # Re: Intérêt d'une application de traçage de relations sociales

        Posté par  . Évalué à 3 (+1/-0).

        Un intérêt, sous entendu pour réduire l'épidémie et son fameux R0 de manière significative.

        Si seulement un faible nombre de personnes l'installer, imaginons que cela fassent passer le R0 de disons 3.5 a 3.4, autrement dit cela ne sert a rien car cela a un impact insignifiant pour réduire la propagation du virus.

        Et pour le coup, si tu es le seul a installer a cette application, plus t'as de chances de te faire tracer en tant qu'emetteur de beacons sur patte. Donc autant la désinstaller dans ce cas.

      • [^] # Re: Intérêt d'une application de traçage de relations sociales

        Posté par  (site Web personnel) . Évalué à 3 (+1/-0).

        La plupart (la totalité ?) des chiffres qu'on voit du type « l'application n'est utile que si X% de la population l'utilise » ne définie pas la notion de « utile », et sous-entend « utile » = « suffisant pour faire baisser R0 en dessous de 1 (i.e. faire reculer l'épidémie) sans autre mesure ». Réduire l'utilité d'une mesure à un indicateur binaire « utile » / « pas utile » est une sur-simplification qui à mon avis n'aide pas beaucoup le débat.

  • # Stockage

    Posté par  . Évalué à 2 (+0/-0).

    Merci pour ton journal

    Si l'on suppose que chaque identifiant tient sur 128 bits, qu'un nouvel identifiant éphémère est utilisé toutes les 15 minutes, cela représente jusqu'à ~21 Ko de données à conserver par malade. […] Par exemple sur les 14 derniers jours, il y a eu plus de 400 000 nouveaux cas diagnostiqués aux Etats-Unis, la taille correspondante du registre des identifiants éphémères pourrait atteindre (si tout le monde utilisait une application de traçage) 8 Go pour 14 jours, soit une base journalière de l'ordre de 600 Mo.

    Je n'ai pas bien suivi ton calcul (j'arrive pas à retomber sur tes chiffres). Mais stocker ses identifiants peut être plus efficace. Tu stocke les identifiants dans un arbre binaire. Ça te donne un arbre binaire de profondeur 128. Selon comment on veut gérer le truc on peut partitionner par préfixe (tu peut avoir 16 partitions qui auront chacun un préfixe de 4bits) et/ou éliminer des branches (tous les qui ont un préfixe donné sont considéré comme dangereux).

    Ça permet aussi d'avoir un parcourt assez efficace.

    • [^] # Re: Stockage

      Posté par  . Évalué à 1 (+1/-0).

      Mon calcul était basé sur le fait que :
      * chaque identifiant éphémère est un entier de 128 bits (16 octets)
      * un utilisateur produit 96 identifiants éphémères par jour (1 toutes les 15 minutes)
      * donc sur deux semaines, 14 * 96 = 1344 identifiants éphémères sont produits, soit 1344 * 16 = 21 504 octets
      * ceci est à multiplier par le nombre de malades déclarés car le registre doit conserver leurs identifiants éphémères des 14 derniers jours ; donc si on enregistre 400 000 malades sur 14 jours, la taille du registre sera de : 400 000 * 21 504 ~ 8,6 Go

      C'est une taille brute pour la base que l'on peut effectivement réduire en regroupant les identifiants par préfixe commun (avec un arbre). Cela permet de rechercher plus rapidement dans le registre les identifiants collectés par l'utilisateur.
      On peut aussi proposer le registre en téléchargement sous forme de plusieurs fichiers en regroupant les identifiants de même préfixe (fichier pour les identifiants commençant par les octets 00-00, 00-01…). Cela permet à l'utilisateur de ne télécharger que les portions du registre correspondant aux identifiants qu'il a collectés sans pour autant les exposer explicitement au site. On peut même penser que les fichiers du registre puissent être mis en miroir sur de nombreux sites : l'utilisateur répartirait le téléchargement des fichiers sur plusieurs sites ce qui aurait l'avantage de répartir la charge tout en réduisant les risques de pistage.

      • [^] # Re: Stockage

        Posté par  . Évalué à 2 (+0/-0).

        On peut même penser que les fichiers du registre puissent être mis en miroir sur de nombreux sites : l'utilisateur répartirait le téléchargement des fichiers sur plusieurs sites ce qui aurait l'avantage de répartir la charge tout en réduisant les risques de pistage.

        Tu peut même aller plus loin et mettre en place une DHT avec une signature des index.

  • # Le journal n'a qu'un jour mais déjà dépassé.

    Posté par  (site Web personnel) . Évalué à 4 (+3/-1).

    Avec l'approche INRIA/Fraunhofer, l'autorité est présumée bienveillante,

    Pour l'Allemagne, finalement l'autorité n'est pas présumée bienveillante (source), donc abandon de cette solution.

    La France est bien seule à continuer dans cette voie si je suis bien, et comme cette voie dépend de Google et Apple qui ne veulent pas vraiment…

    Sans parler des doutes

    • [^] # Re: Le journal n'a qu'un jour mais déjà dépassé.

      Posté par  . Évalué à 2 (+1/-1).

      La France est bien seule à continuer dans cette voie si je suis bien, et comme cette voie dépend de Google et Apple qui ne veulent pas vraiment…

      Ce qui en dit beaucoup sur l'état de notre démocratie aujourd'hui : on n'a aucune autonomie technologique aujourd'hui, et on veut s'amuser avec ces outils…

  • # DP³T

    Posté par  . Évalué à 3 (+1/-0).

    A noter que la Suisse avait déjà abandonné le PEPP-PT suite au choix de l'approche centralisé qui n'était pas le point de vue initial des EPF.

    Ils ont donc démarré le projet DP-3T sur cette base, et ont été rejoints par l'Estonie et l'Autriche. On verra ce que va choisir de faire l'Allemagne (qui vient de quitter le PEPP-PT) mais il me semble possible qu'ils choisissent de rejoindre ce nouveau projet.

    https://github.com/DP-3T/documents

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.