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.
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…
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.
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 :
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.
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).
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 codefish . En réponse au journal A propos des protocoles de traçage pour le Covid-19 : Google/Apple vs. INRIA/Fraunhofer. Évalué à 1.
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.
[^] # Re: Intérêt d'une application de traçage de relations sociales
Posté par codefish . En réponse au journal A propos des protocoles de traçage pour le Covid-19 : Google/Apple vs. INRIA/Fraunhofer. Évalué à 2.
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: Stockage
Posté par codefish . En réponse au journal A propos des protocoles de traçage pour le Covid-19 : Google/Apple vs. INRIA/Fraunhofer. Évalué à 1.
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: info supplémentaire
Posté par codefish . En réponse au journal A propos des protocoles de traçage pour le Covid-19 : Google/Apple vs. INRIA/Fraunhofer. Évalué à 1.
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 :
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).