StopCovid, un projet porté à bout de bras par Cédric O
De StopCovid, on connaît surtout la facette technique. Dans son édition du jour, Le Canard enchaîné lève un coin du voile sur la facette politique.
Le journal fait état des « réticences » d'Emmanuel Macron et d'Édouard Philippe, « guère enthousiastes » au sujet de cette application de traçage des contacts. Au début du mois, le ministre de la Santé s'était également montré très prudent quant à la concrétisation du projet, une déclaration qui, coïncidence ou non, avait été suivie le lendemain par un long plaidoyer sur StopCovid de la part du secrétaire d'État au numérique.
C'est « soutenu par un petit cercle de technophiles montés en graine sous la Macronie » que Cédric O a choisi d'adopter le modèle centralisé pour l'application, un modèle incompatible avec l'API proposée par Apple et Google (seul moyen d'exploiter pleinement le Bluetooth de l'iPhone), mais un modèle plus souverain.
Le journal satirique relève que Bruno Sportisse, le PDG de l'Inria, l'organisme de recherche qui chapeaute le développement de l'application, est un proche de Cédric O. StopCovid a d'ailleurs provoqué des remous au sein de l'Inria : mi-avril, un groupe de chercheurs de l'institut a publié une mise en garde contre les technologies de traçage des contacts.
Enfin, le Canard rappelle la participation d'Aymeril Hoang, qui, à la tête d'une structure de conseil privé, s'était vu confier fin mars « une mission d'analyse des propositions numériques à la crise sanitaire » puis a été nommé dans la foulée expert numérique du Conseil scientifique. Une « double casquette » épinglée par certains sénateurs.
https://media0.giphy.com/media/l0IsIZw8doJm3ysRq/giphy.gif?cid=4d1e4f291...
Un projet porte à bout de bras par Cédric O le manchot
@corben
Un peu de respect s’il te plaît.
@corben
Cédric O va s’y brûler les L.
@FloMo
Merci :) ça me fait des documents en plus ^^
R.I.P StopCovid. Projet mort avant même sa naissance.
Finalement c’est “Stop-StopCovid” 😅😅😅
Le nom était prémonitoire !
@RenaudL
Tout se résumer à la France... comme d'habitude quoi.
Et si on citait plutôt les décideurs politiques un peu ? Parce qu'en France, il y a quand même des choses positives.
Qu’il se crée déjà un blase correct 🙄
@anonx
J’ai honte, mais j’ai bien ri. 😅
@pat3
Non mais c’est vrai. Dites-le à voix haute, on se croirait dans men in black. Mr O, agent O 😂
Ou alors on dirait qu’on parle d’un suspect dont on a censuré le nom..
@pat3
Idem 😂
@anonx
https://media2.giphy.com/media/11tbqNLytB25q0/giphy.gif?cid=4d1e4f296b5b...
Bel exemple des effets du copinage, réseautage à la Française 😢.
Vivement l’explosion de ce projet pour clôturer cette gabegie.
Ah ces commentaires de gus qui ne sauraient même pas serrer un boulon. Ces gus d’un orgueil stratosphérique qui en remontraient à la terre entière et qui jugent à partir d’informations, fausses, parcellaires, biaisées et à charge. Un article qui remet les pendules à l’heure : https://www.mac4ever.com/dossiers/153431_stopcovid-les-secrets-d-un-challenge-technique-on-vous-dit-tout
Non la France n’est ni isolée, ni en retard. Oui dans le monde une minorité utilisera l’API d’Apple/Google API qui vient à peine de sortir. Oui le projet français avance, tient compte des contraintes techniques et éthiques. Oui dans le monde partout il y a des débats tant pour savoir si on utilise une application ou non et quel système on va mettre en place : avec ou sans l’API. Et pas seulement en France.
Toutes les informations sur ce site sont orientées quand deux articles ne se contredisent pas d’un jour à l’autre : RU cela ne marchera pas et trois jours après il y a 40.000 téléchargements pour une petite île, la France ne diffusera pas le code source, l’angle mort pour dire cinq jours après que les chercheurs pensent que cela ne posera pas de problème et que cette histoire de Bluetooth est un faux problème bien que cet article en remette une couche alors que cela est maintenant prouvé c’est du bidon, mais il faut bien casser ce que fait le pouvoir tout en insultant allègrement toutes les personnes qui y bossent les supposant incompétentes, stupides. Ceci dit à voir qui les insultent c’est plutôt un compliment.
@Inconnu-Soldat
tu es français, pote avec Cedric O ou les deux non 😆?
@Mageekmomo
Encore plus simple que ça : Il s’ennuie
@Inconnu-Soldat
L’article en question n’est pas si neutre qu’il semble le faire penser. Il y a pas mal d’omissions (involontaires). Qui vont de fait dans le sens du centralisé.
Mais c’est technique.
Et, dans ce domaine, on peut difficilement juger des intentions.
Seulement s’appuyer sur les faits.
@FloMo
+1
@FloMo
oui, le canard quoi :)
Mais ce qui est dommage c'est qu'à chaque fois qu'on sort ici un article sur stop covid ca defouraille dans les commentaires, ca insulte etc..
Si, d'un coté, je comprend que ca puisse etre positif pour le trafic et visiblement ca interesse les lecteurs, d'un autre, ca fait un peu "article pour rameuter du clic".
Et puis, enfin, cette histoire d'app, pour contre peutêtre, bien fait, pas bien fait, dangereuse, sauveuse etc...
Je crois qu'on a tout lu à peu pret sur ce sujet. Je propose de ne plus en parler avant qu'elle ne sorte :)
... oui je sais, je rêve, un nouvel article arrivera dans les 3 jours. Mais bon, au moins je l'ai dit
@Inconnu-Soldat
Très bon le coup on est pas en retard au regard de la fin de l’article que vous donnez en exemple. Oui on n’est pas en retard pour la prochaine épidémie. Très bon. Cédric O. Sort de ce corps.
Ne pas utiliser l’API avait tout son sens pour sortir rapidement une application comme l’on fait de nombreux Pays plus rapide.
Dans ceux qui ont le mieux marché en terme d’installation et tout en restant en Europe, il y a celle de l’Islande avec 38%. Dans ce Pays très réactif face au COVID (Tests, postage, isolement) le retour d’un responsable du pôle islandais en charge de remonter les chaînes de contamination juge que son utilité est limitée pour ne pas dire inutile face aux techniques traditionnelles.
https://www.usine-digitale.fr/article/covid-19-en-islande-l-application-de-pistage-du-gouvernement-ne-porte-pas-ses-fruits.N963576
@c0by
meme si elle ne peut sauver qu'une personne, alors c'est comme l'apple watch, ca vaudra le coup de l'utiliser.
Depuis le début il est clairement dit (peu dans les commentaires) que c'est un truc en plus, pas LA solution, meme pas forcement la principale, mais une des techniques parmi beaucoup d'autres pour tenter de prevenir un retour de l'epidémie.
Soldat-inconnu a un ton péremptoire, et est un poil exagéré dans ses propos, mais bon, je suis +1 avec lui et CedricO n'est pas dans mon corps.
@raoolito
Je pense que le principe d’une app de traçage fait quasiment l’unanimité dans le débat scientifique. Le dernière publication dans la revue Science va en ce sens.
Par contre, concernant l’approche centralisée / décentralisée, il y a débat entre la France (+2/3 pays) et le reste du monde.
Le sujet n’est pas l’efficacité du procédé : il est globalement identique partout.
La dépendance à Apple / Google est également hors sujet : on va concevoir une app qui s’installe dans le système qu’ils ont construits. Ils ont de fait potentiellement accès à tout, quelle que soit la solution.
Le vrai sujet est la protection des données personnelles. Et là, c’est un épais mystère.
Quelle solution peuvent bien avoir trouvé les amis de Cédric O, au point de défier les plus grands experts mondiaux en termes de vie privée et de sécurité ?
Il ne faut pas oublier la mise en garde de 300 chercheurs du monde entier à propos de l’approche centralisée par rapport au risque encouru vis à vis de la vie privée.
Et du coup, forcément, ça rend curieux. Et le débat est passionnant. On veut tous savoir quelle est cette fameuse technologie qui nous est annoncée. Ce sera une révolution dans le monde de la cyber sécurité.
@FloMo
De toute façon, il semblerait que certains gouvernements aient décidé de passer outre un consentement pour alimenter une autre base de données via les médecins eux-mêmes (et certains sont ulcérés).
@xDave
L’objectif n’est pas de « tracker » mais bien de « tracer ».
Et le traçage se fait en France depuis le début de la pandémie, en appelant les contacts potentiels au téléphone.
Là, l’objectif est d’aller plus vite en automatisant le processus. Ça permet de passer de quelques jours pour informer le contact à quelques heures.
Et, d’après Science, ça change tout. Celui qui se sait potentiellement malade doit être mis en quatorzaine et donc cela limite la propogation du virus pendant la période d’incubation.
@FloMo
Je n’ai pas dit tracker ni tracer ni traquer. 😬
Pour ta dernière phrase, oui une personne qui se sait malade devrait rester chez elle.
Mais une potentiellement malade devrait surtout se faire tester.
Sinon, tout le monde est potentiellement malade si on va par là.
@xDave
Les algorithmes des apps limitent les faux positifs justement.
Par exemple, si on est proche d’une personne moins de 5 minutes, ce n’est pas considéré comme un contact. (En tout cas, dans l’API COVID G/A)
C’est également un bon moyen d’éviter le sniffing Bluetooth.
Un léger décalage horaire est également appliqué pour éviter le rapprochement d’informations. Sans pénaliser le diagnostic.
Et les critères de diagnostic sont déterminés par un paramétrage. Paramétrage qui peut évoluer. Il est juste borné sur une plage définie en fonction du consensus scientifique. Chaque organisme de santé de chaque nation peut alors régler ses critères à sa sauce.
À la fin, le risque est nul, faible, modéré, élevé ou très élevé.
Vraiment un sujet passionnant 😁
@xDave
Les médecins ont déjà l’obligation de déclarer un paquet de maladies :
https://www.conseil-national.medecin.fr/medecin/sante-publique/maladies-declaration-obligatoire#sommaire-id-1
Ils ne veulent pas avoir à déclarer leurs contacts.
Ils ne veulent pas que des personnes non soumises au secret médical aient accès à ces données.
Ils se posent des questions quant à la sécurité du système.
Et c’est bien ainsi.
@DG33
Merci je suis au courant. Et c’est ce à quoi je faisais référence justement.
C’est une dérive de plus.
Mais je n’allais pas rentrer dans le détail.
@xDave
J’ai bien lu ton « dans une autre base de données » (tout est dans le « autre », qui y aura accès en lecture et stats, sa sécurisation, sa durée de conservation, etc), mais tout un chacun aurait pu croire que c’était nouveau de devoir faire le signalement pour les patients atteints de Covid-19.
> La dépendance à Apple / Google est également hors sujet : on va concevoir une
> app qui s’installe dans le système qu’ils ont construits.
La dépendance, justement, c'est d'avoir une solution qui n'est pas facilement portable sur d'autres plateformes, qui *dépend* donc des spécificités d'une plateforme.
Ici, la dépendance, c'est l'API de contact tracing. L'adopter, c'est de facto renforcer la part de marché de ces plateformes (et même, dans le cas présent, les versions récentes uniquement), ce qui est dans l'intérêt des vendeurs de ces
> Ils ont de fait potentiellement accès à tout, quelle que soit la solution.
Et cela va être encore plus facile de le détecter en confiant un pan d'une solution à leur API propriétaire, non transparente !? Par quel miracle ?
Au final, cela se résume à un duel de confiance entre 2 acteurs privés vs le système de gouvernance de votre pays.
Ou alors que l'API soit rendue open source, elle aussi, comme on l'exige des solutions des pays. Pourquoi cette exigence de transparence, légitime, n'est pas la même pour des acteurs privés non dénués d'intérêt financier et qui représente à eux 2 un monopole en terme de plateforme mobile !?
A ce jeu là, confions la gestion de nos mutuelles, nos comptes en banque, nos impôts, nos assurances à des API d'Apple et Google aussi...
@byte_order
En fait, l’API COVID ne leur apporte rien en termes d’informations sur nous.
Ils ont déjà largement plus potentiellement puisque qu’ils ont construit tout l’OS. Et les apps font appel à 100% à l’OS pour fonctionner.
La raison de cacher le fonctionnement de l’API est tout simplement qu’ils vont faire appel à des pilotes de matériel qui sont soumis à licence.
C’est pour cela que même Android et GNU/Linux ne sont pas 100 % open-source, sauf à avoir du matériel open-source.
Et l’autre raison est la sécurité.
En gros, la méthode courante pour pirater une app est d’en prendre le contrôle. Tout le code accessible à l’app est alors accessible au malware par exemple. C’est pour cela que OWASP recommande de protéger les apps contre le jailbreak.
Car les apps profitent d’une protection qui a fait ses preuves depuis des décennies : le sandboxing. Ainsi, l’app n’a accès qu’aux ressources auxquelles elle a droit.
Et ça fonctionne sur nos smartphones depuis des années. Il y a bien une faille de temps en temps dans le procédé, mais globalement, si on se tient à jour, on est bien protégé.
Et donc, en laissant le système gérer la partie COVID, ça évite à l’app d’exposer des données sensibles. En plus, quand une app utilise l’API COVID, elle voit son accès au GPS bloqué.
Et c’est aussi pour ça que le système COVID peut être désactivé par le système d’exploitation quand ce n’est plus nécessaire. Mais aussi par l’utilisateur via un switch externe à l’app.
Si l’app est vérolée, le risque ne se situe plus que sur la partie web. Qui ne communique plus rien de toutes manières si elle est bloquée de l’extérieur.
Et cela explique le danger de tout vouloir traiter par le web et dans l’app : toutes les données sont exposées.
Et donc, l’identifiant de l’utilisateur venant d’internet peut être enregistré temporairement par un malware ou un espion sur le WiFi.
Quand l’utilisateur envoie la liste de ses contacts au serveur central, il suffit d’y associer son propre identifiant pour pouvoir croiser les infos.
Si le Bluetooth n’est pas protégé contre le sniffing, ça augmente encore le risque.
Etc. Etc.
L’intérêt de G / A, c’est juste leur image de marque. A l’instar des dons qu’ils font en masques, en monétaire, etc.
Désolé, mais il me semble que vous melangez beaucoup de choses, et que les notions de sécurité informatique sont un peu complexes que vous ne les voyez.
Le sandboxing que vous citez par exemple, permet également de protéger les applications entre elles, donc il n'y a pas de risque de fuite du sandboxing par une application. Que la Logic covid soit dans le système ou dans l'application, ça ne change rien de ce point de vue.
Que l'API puisse être stoppé, c'est très bien. Dans le mode centralisé, si le serveur est débranché et nettoyé, cela revient à la même chose. Dans les 2 cas, l'utilisateur est tributaire du fait que ça ait été implémenté correctement.
La réalité du débat centralisé vs décentralisé, c'est simplement la nature des informations échangées. Dans le format décentralisé, la vraie critique, c'est que les pseudonymes émis par les personnes qui se sont déclarées malades seront publiques. Ca vient avec son lot de questions. Il suffit typiquement de mettre un webcam devant chez soit qui enregistre les pseudonymes émis par les passants pour savoir qui autour de chez soi est malade. C'est il me semble un vrai argument exposé par le ministre et par les chercheurs de l'INRIA.
L'autre argument clé de l'INRIA, c'est que si le rapprochement est fait par le serveur, on va pouvoir étudier ces rapprochements, comparer avec les données sur le terrain par rapport a de vrais cas, et adapter la logique du "match". Cette logique, on l'a vu dans les commentaires, c'est la clé de la réussite pour trouver le bon compromis et stopper l'épidémie sans trop de faux positifs. Et celà est très compliqué en version décentralisé.
@flagos
A priori, vous avez l’air de vous y connaître. C’est une bonne chose 😊
Je reviens sur le sandboxing. Prenez une attaque de masse par malware, comme on a déjà pu le voir. Le procédé est le même que de contrôler l’app via cycript par exemple.
Dès lors, TOUS les identifiants sont exposés. Car accessibles à l’app.
Et, par attaque « sociale », l’utilisateur peut en plus donner accès au GPS par mégarde.
Le risque est donc considérable.
Maintenant, tout mon traitement de données sensibles sort de l’app, via l’API COVID.
Les identifiants ne sont plus accessibles à l’attaquant.
L’algorithme de diagnostic n’a pas de risque de modification par method swizzling par exemple.
L’accès au GPS est bloqué pour le système dès qu’une app utilise l’API COVID.
L’algorithme Bluetooth de peut pas être « reconstruit » dynamiquement depuis le runtime de l’app pour du sniffing.
Les clés permettant de signer les identifiants ne sont accessibles au runtime que partiellement (clés utilisées lors des contacts, et accès limité à des fenêtres de 24h, avec consentement utilisateur déclenché par l’OS)
Le risque est au niveau du runtime autant que le reste. Cela fait partie du top 10 des attaques mobiles selon OWASP.
Concernant l’approche centralisée / décentralisée, il y a plus de facilités de contrôle du risque.
Mais le fait d’exposer un volume important de données au réseau expose au sniffing (des VPN « gratuits » qui espionnent ont déjà fait les gros titre) : plus il y a de données qui transitent, plus c’est simple de croiser les données et de les exploiter.
C’est quasiment l’équivalent d’une exposition du runtime sur la partie réseau.
Et, encore une fois, connaître les identifiants d’un utilisateur devient potentiellement possible en trouvant une faille dans l’algorithme de chiffrement. C’est du déjà vu. Et c’est pour cela que 300 chercheurs du monde entier déconseillent l’approche centralisée.
Pour l’aspect analyse des données pour apprentissage automatique, j’ai 2 choses qui me viennent en tête :
- confidentialité différentielle
- apprentissage fédéré privé.
Mais je ne peux pas trop m’avancer sur le machine learning. À voir en juin côté Tensorflow et CoreML. (Annoncé en 2019)
Ah ca devient interessant :-)
Comment tu fais pour controler l'app a travers la sandbox ? L’intérêt du container, c'est justement d'isoler le process, ainsi que les fichiers qui ont été écrits. Tu considères le device comme jailbreaké ?
> L’accès au GPS est bloqué pour le système dès qu’une app utilise l’API COVID.
C'est un reproche qu'on peut adresser légitimement a Apple. S'ils avaient ouvert un peu leur API, ils auraient pu inclure le use case de l'INRIA dedans. Là ils ont choisi de fermer le dialogue, laissant leurs utilisateurs sans autre option que de faire confiance à l'INRIA.
> L’algorithme Bluetooth de peut pas être « reconstruit » dynamiquement depuis le runtime de l’app pour du sniffing.
Je comprends pas l'idée ici. Et il me semble que ca suppose encore une fois que le sandboxing ne marche pas.
> connaître les identifiants d’un utilisateur devient potentiellement possible en trouvant une faille dans l’algorithme de chiffrement.
Je me permet de faire remarquer c'est très clairement hypothétique. Un chiffrement sur les données + transmission via SSL/TLS et tout le tintouin, ne devrait pas poser de soucis.
> - confidentialité différentielle
> - apprentissage fédéré privé.
Non ca marche pas. Il faut partir de vrais cas, volontaires, qui acceptent d’être retracés minute par minute et pour lesquels on analyse tous les contacts, bluetooth et réels. On teste ensuite toutes ces personnes et leur demandant également leurs téléphones, volontaires également, et regarde a quels pseudos bluetooth ils correspondent. De cette manière, on peut estimer comment un contact de la vraie vie se traduit en contact bluetooth, et on peut ajuster la sauce.
Pour les méthodes de ML que tu cites, il faudrait beaucoup plus de données pour faire un lien statistique. Or l'idée de l'appli, c'est justement de marcher lorsqu'il y a peu de cas.
> Tu considères le device comme jailbreaké ?
Absolument. Ou au moins en partie. C'est tout l'intérêt de la protection du runtime.
Dans les recommandations OWASP, ça correspond aux points MSTG-RESILIENCE-1 et MSTG-RESILIENCE-2.
> C'est un reproche qu'on peut adresser légitimement a Apple. (blocage du GPS pour API décentralisée uniquement)
Il me semblait que le blocage entre Apple et la France était lié à l'utilisation du Bluetooth en permanence.
> Et il me semble que ça suppose encore une fois que le sandboxing ne marche pas. (L’algorithme Bluetooth reconstruit)
Oui et non. Cela peut être utilisé par un malware ou par des devices malveillants.
> Je me permet de faire remarquer c'est très clairement hypothétique. Un chiffrement sur les données + transmission via SSL/TLS et tout le tintouin, ne devrait pas poser de soucis.
C'est vrai. Mais le principe de base de la sécurité est de minimiser le risque.
Le principe de précaution en somme.
D'autant que les attaques sont en générale multi-factorielles.
En appliquant les principes d'un système "Vauban", on élimine le risque.
> Non ca marche pas.
OK. Je ne suis pas data-scientist.
@FloMo
> En fait, l’API COVID ne leur apporte rien en termes d’informations sur nous.
La dépendance à *cette* API, déjà, et donc à leurs plateformes.
C'est exactement comme si on décidait de faire une solution sanitaire avec l'API de Microsoft.
C'est une dépendance.
Par ailleurs, leurs API collectent les pseudonymes et voient la liste de pseudonymes déclarés exposés au virus.
> Ils ont déjà largement plus potentiellement puisque qu’ils ont construit tout l’OS.
Ah bah alors, pourquoi exiger l'open source pour une solution sanitaire gouvernemental, les organismes publiques de santé ont déjà largement plus d'information sur nous puisque qu'ils ont construit la couverture de santé !?
2 poids, 2 mesures.
> Et les apps font appel à 100% à l’OS pour fonctionner.
Hein !?
Depuis quand les apps sont constituées *exclusivement* d'appel à des API fournis par l'OS !?
Non. Les apps font appel à 100% à l'OS pour pouvoir faire ce qu'elles ne peuvent pas faire sans utiliser l'API de l'OS ou ce qui serait une perte de temps de faire soit-même.
Pour le reste, c'est du code qui tourne sur un CPU.
> Il me semblait que le blocage entre Apple et la France était lié à l'utilisation du
> Bluetooth en permanence.
Non. Il est lié au fait qu'Apple ne propose pas à la France une dérogation pour pouvoir utiliser le Bluetooth en background, mais à la place propose une API tout-ou-rien.
Oui, il est évident qu'en concevant une app qui va sur iOS, on a une dépendance à iOS.
Soit les identifiants sont générés par iOS et transitent jusqu'à l'app en utilisant les API iOS.
Soit les identifiants sont générés à l'extérieur et transitent jusqu'à l'app en utilisant les API iOS.
Au final, ça passe par iOS.
> pourquoi exiger l'open source pour une solution sanitaire gouvernemental
Je ne pense pas qu'il y ait eu d'exigence.
Mais c'est pour pouvoir contribuer à élever le niveau de sécurité. (qui par ailleurs se retrouvent appliqués dans le code source)
https://gitlab.inria.fr/stopcovid19/stopcovid-robertsdk-ios/-/issues
Les gouvernements n'ont pas l'expérience des constructeurs dans ce domaine.
Cela a pu se vérifier avec l'app anglaise qui est un gruyère niveau sécurité. Au sens de l'OWASP.
Même si c'est clean au sens de la société qui a fait un audit préalable. (sic!)
> Depuis quand les apps sont constituées *exclusivement* d'appel à des API fournis par l'OS !?
Depuis toujours. Du moins, les API du runtime.
Il y a des API web, mais elles finissent par transiter via les API du runtime pour finalement arriver à l'app.
Dès lors qu'il y a une app ou un site, on passe par les API d'un constructeur. Directement ou indirectement.
Si le système peut cacher des choses à l'app, l'inverse n'est pas vrai.
> Non. Il est lié au fait qu'Apple ne propose pas à la France une dérogation pour pouvoir utiliser le Bluetooth en background, mais à la place propose une API tout-ou-rien.
Je parlais bien de ça en parlant du Bluetooth.
Et donc, je pense qu'il est négociable avec Apple de demander de bloquer l'accès au GPS pour cette app.
@FloMo
> Si le système peut cacher des choses à l'app, l'inverse n'est pas vrai.
Désolé, mais c'est faux.
On peut parfaitement faire des calculs, de chiffrement par exemple, rien qu'à l'aide d'instruction du CPU, sans aucune aide de l'OS.
Ce que l'OS verra, c'est le résultat chiffré qui transitera par l'une de ses API, mais les données réelles, elles, ils ne les aura pas vu.
Par exemple, vous parfaitement utiliser une librairie openssl enmbarqué directement dans votre code. Ou votre propre code. Vous pouvez même faire du HTTPS vous même, tout ce que verra l'OS c'est que vous transférez des données, pré-chiffrées par des calculs que seul le CPU a vu passé, sur une connexion TCP avec telle destination, tel port.
Non, les apps ne sont pas constituées *exclusivement* d'appels à des API. A un moment ou un autre, elles s'en font toutes, oui, mais cela ne signifie pas que toute fonctionnalité d'une app repose forcément, et donc dépend, des API d'un OS.
Sauf s'il passe son temps à surveiller tout ce qui est dans la mémoire à tout instant, mais ça, cela se verrait déjà si c'était le cas.
@byte_order
Il y a fort à parier qu’une analyse fine des modifications du rythme et des habitudes de vie, des recherches sur les moteurs et des eMails, tenant compte de la géolocalisation et des personnes croisées etc permettrait à X ou Y maîtrisant et ayant accès aux Data d’en déduire que vous êtes atteint de telle ou telle pathologie...
Celui qui ressent les premiers symptômes va se renseigner (historique du moteur, stats d’utilisation ou téléchargement d’App), appeler son médecin (liste d’appels récents, annuaire des professionnels de santé), payer une télé consultation, recevoir une ordo en pdf (analyse d’eMail), se rendre à la pharmacie (GPS, BlueTooth), rester chez lui (alors qu’il bossait), recevoir une infirmière (appel, GPS, BlueTooth), rappeler son médecin appeler ses proches et ses derniers contacts (liste d’appels, BlueTooth, GPS), contacts vont se rendre en laboratoire se faire dépister (GPS) etc.
Puis le patient se rend aux urgences (GPS), il y reste assez conscient (activité sur smartphone) puis passe en réa (plus d’activité). Jusqu’au retour à la maison ou hôtel en quatorze une (GPS, activité) voire au décès (bon là son smartphone ne le suivra sans doute pas).
Bon on espère que ce n’est pas possible et qu’X ou Y se l’interdisent, mais les technologies sont là, le tracking et le tracing sont possibles, et les failles n’attendent qu’à être exploitées (ou comblées avant).
@DG33
> d’en déduire que vous êtes atteint de telle ou telle pathologie...
L'analyse critique de l'INRIA :
https://www.igen.fr/app-store/2020/04/stopcovid-un-vote-au-parlement-et-un-avertissement-de-chercheurs-de-linria-114479
soulignait justement que *meme* sans l'accès aux données, c'était très facile, que l'anonymat est en fait un pseudonymat, et ce quelques soit l'approche centralisée ou décentralisée.
C'est précisement ce que je soulignais : l'usage de cette critique pour justifier la critique que d'une approche en particulier est abusive.
@FloMo
> Dès lors, TOUS les identifiants sont exposés. Car accessibles à l’app.
Les pseudonymes des personnes exposés au virus, dès lors qu'ils doivent transités jusqu'à l'app sur mobile, eux aussi.
> L’accès au GPS est bloqué pour le système dès qu’une app utilise l’API COVID.
Pour toute app s'exécutant en même temps, ou seulement pour celle qui utilise l'API ?
Plus d'aide à la navigation GPS pendant l'usage de l'API !?
Si c'est juste pour l'app qui utilise l'API, qu'est-ce qui empêche une *autre* app, elle, d'utiliser le GPS afin de constituer une trace des endroits fréquentées rapprochable ensuite avec la liste des pseudonymes échangés avec un serveur distant, ce qui a lieu dans les 2 approches ?
> La dépendance à Apple / Google est également hors sujet : on va concevoir
> une app qui s’installe dans le système qu’ils ont construits.
C'est faux. Y'a pas que l'app iOS ou Android qui tourne sur le mobile dans cette histoire.
Imaginez, par exemple, qu'un bracelet peu couteux (quand on voit les prix de certains bracelets connectés c'est envisageable) soit développé spécialement pour une solution de traçage des expositions au virus, lié le fonctionnement de la solution à une API sur l'une des plateforme mobile possible pose un problème de dépendance de la solution à cette plateforme pour la partie mobile de la solution.
Vous ballayez un peu vite ce point. Comme si l'app qui tourne sur le téléphone était l'essentiel de l'app. Alors que sans serveur et sans contrôle de la déclaration légitime d'une exposition, approche "décentralisée" ou pas, l'app mobile, qu'elle soit sur un iPhone ou un smartphone Android ou un bracelet connecté, ben, cela ne marchera pas.
C'est pas du P2P, hein.
> Ils ont de fait potentiellement accès à tout, quelle que soit la solution.
Et que 2 entreprises privées et etrangères le puissent, pas grave, on peut leur faire confiance, mais que des organismes sous notre contrôle citoyen, là, scandale, méfiance !?
> Les pseudonymes des personnes exposés au virus, dès lors qu'ils doivent transités jusqu'à l'app sur mobile, eux aussi.
Je n'ai pas très bien compris la phrase, désolé.
> Pour toute app s'exécutant en même temps, ou seulement pour celle qui utilise l'API ?
Uniquement celles utilisant l'API COVID.
L'idée est qu'en cas de prise de contrôle externe de l'app (malware ou autre) il soit impossible que l'attaquant puisse accéder aux données du GPS.
> Si c'est juste pour l'app qui utilise l'API, qu'est-ce qui empêche une *autre* app, elle, d'utiliser le GPS afin de constituer une trace des endroits fréquentées rapprochable ensuite avec la liste des pseudonymes échangés avec un serveur distant, ce qui a lieu dans les 2 approches ?
Le principe du sandbox fait que plusieurs apps ne peuvent pas discuter entre elles. Sauf volonté du développeur.
Et vous mettez justement le doigt sur le sujet sensible : si les données sont échangées via un serveur, il est potentiellement possible de les intercepter. Contrairement aux données générées et traitées sur l'appareil.
Après, la solution est de brouiller le signal en injectant de fausses données. Mais le fait d'exposer beaucoup d'infos au web est un risque. Clairement.
> Comme si l'app qui tourne sur le téléphone était l'essentiel de l'app.
Tout est dans la phrase. C'est bien la solution proposée à ce jour.
> Et que 2 entreprises privées et etrangères le puissent, pas grave, on peut leur faire confiance, mais que des organismes sous notre contrôle citoyen, là, scandale, méfiance !?
Aucune méfiance ou scandale vis à vis du gouvernement. Ils gèrent bien la crise.
Juste que pour concevoir une app qui va sur les appareils de Google et Apple, ceux qui ont le plus de compétences dans ce domaine sont... Google et Apple.
Et il est dangereux de croire le contraire.
Mais soyons clair : cette app est une bonne chose au sens médical.
Il faut juste qu'elle soit sécurisée et protégée des hackers.
@FloMo
> Je n'ai pas très bien compris la phrase, désolé.
Les données qui seront inévitablement échangées entre un serveur central (quelque soit l'approche, y'en a toujours un, et donc des échanges aussi) et l'app, ces données aussi pourront être captées par une app mal protégée contre le jailbreak, malware etc, qu'elle utilise l'API d'Apple ou pas, ces données là sont exposées tout autant que les pseudonymes qu'une app générerait elle même plutôt que de les laisser cachés derrière l'API Apple/Google.
Dans le premier cas, c'est la liste des pseudonymes des malades, dans le second (approche centralisée) c'est la liste des pseudonymes que vous croisé.
Mais dans les deux cas, ces données là ne sont pas inaccessible derrière une API puisqu'elles partent sur le réseau.
> Juste que pour concevoir une app qui va sur les appareils de Google et Apple,
> ceux qui ont le plus de compétences dans ce domaine sont... Google et Apple.
Je crois pas non. Y'a une sacré nuance entre concevoir un OS et concevoir une app.
Beaucoup d'apps natives d'Apple dans iOS par exemple font pale figure par rapport à d'autres apps concurrentes. Mail ? iMessage ? Plans ?
On en parle du bug dans l'une des 6 (six !!!) bibliothèque de parsing XML à l'origine d'une grosse faille zéro day présente depuis des années, p'tet même depuis le début !?
> Et il est dangereux de croire le contraire.
Je crois qu'il est dangereux de croire qu'un seul acteur est mieux placé que quiconque pour répondre à tous les besoins fonctionnels et qu'en conséquence on doit le laisser faire tout ce qu'il veut, y compris entraver des implémentations tierces ou concurrentes.
Mais je reconnais là bien la docilité pro-"dites nous vos besoins, nous vous expliquerons comment vous en passez pour utiliser notre solution".
Étrangement, la communauté Apple luttait contre l'idée d'un BigBrother. Mais ça, c'était *avant*.
@raoolito
Certes mais l’énergie et le temps passé n’aurait il pas été mieux utilisé et plus efficacement ailleurs dans la lutte actuelle ?
Cette application, avec ces atermoiements, arrive bien tard et dans un contexte de défiance très fort comprenant aussi une partie de l’exécutif et de la majorité.
Contexte qui n’ira pas en s’améliorant avec l’accélération du projet français health data hub dans le cadre du COVID et avec les levés de bouclier qui commencent à s’entendre aussi bien sur le choix de l’hébergement, que de l’utilisation des données très larges. Dans ce data il y aura toutes les données de santés dont celle provenant de la pandémie.
@fondoeil
Vous faites un double procès d'intention là.
Comment juger de l'intérêt dequelque chose pas encore sorti et une partie seulement d'un tout? On ne sait rien et n'en saura jamais probablement car "il aurait fallu que" restera supposition, d'autant que votre "ailleurs " est probablement une opinion qui vous est propre. ( c ou ailleurs? C le meme que le mien?)
Et pour les critiques et accusations de corruption et collusions, bon là c limite attaquable pour diffamation. Donc soit vous porter cela en justice soit vous arretez car ( comme j'aime souvent dire dans ce cas là) " et vous, vous roulez pour qui? C payé combien parvos maitres de poster ca ici?"
( bonne chance pour prouver le contraire)
Pages