Des doutes sur la sécurité de SwissCovid, basée sur l'API d'Apple et Google
En Suisse, la sécurité de l'application SwissCovid, qui fait l'objet depuis le début du mois d'une expérimentation auprès de certaines catégories de la population, pose question. L'Office fédéral de l'informatique et de la télécommunication et le Groupe d'intervention informatique de la Confédération ont jugé que l'application de traçage des contacts offrait un degré élevé de sécurité et de protection de la vie privée, rapporte l'agence de presse ATS.
Mais d'un autre côté, deux experts en cryptographie ont pointé un risque de piratage. D'après l'analyse de Serge Vaudenay, chercheur à l'École polytechnique fédérale de Lausanne (EPFL), et Martin Vuagnoux, de l'entreprise Base23, le problème touche l'API d'Apple et Google qui est exploitée par SwissCovid. Selon eux, « les données diffusées par Bluetooth peuvent être modifiées avec malveillance », ce qui peut conduire à des attaques en diffusant de faux cas positifs.
« Tout un chacun peut écouter les "postillons" Bluetooth que vous émettez. Même à plus de 10 mètres ou encore à distance via d'autres applications. Par exemple je peux les capter, les voir, les filtrer. Je détecte ceux qui sont associés à SwissCovid. Avec un bout de code, je peux les modifier et je peux les stocker et j'ai deux heures pour les émettre à d'autres endroits dans la ville », explique Paul-Olivier Dehaye, un autre expert suisse, à RTS.
Des malandrins pourraient exploiter cette vulnérabilité afin de diffuser des faux positifs à certains endroits afin de les faire fermer ou de faire isoler inutilement leurs employés.
L'EPFL, à l'origine de l'app SwissCovid mais aussi de la solution technique proposée par Apple et Google, et la Confédération ont déclaré à RTS que le risque était connu et allait être examiné. Un rapport est prévu à la fin de la phase d'expérimentation.
Par ailleurs, c'est cette semaine que l'Allemagne va lancer son application de traçage des contacts, a fait savoir le ministre de la Santé du pays. Développée notamment par Deutsche Telekom et SAP, elle sera basée sur l'API d'Apple et Google.
"Des malandrins pourraient exploiter cette vulnérabilité afin de diffuser des faux positifs à certains endroits afin de les faire fermer ou de faire isoler inutilement leurs employés."
Mais pourquoi sont-ils si méchants ?
PARCE QUEEEEEEEEEEEE....!!
Du coup, ces émissions malveillantes ne peuvent-elles pas être appliquées à la méthode française avec stop COVID ?
Si. C'est applicable à toutes les apps s'appuyant sur le Bluetooth.
Mais ça me semble un peu tiré par les cheveux. Si c'était si simple, on n'aurait pas eu une étude mais une démonstration.
@FloMo
C’est ce que je pense.
C’est pas donné à n’importe qui ces possibilités d’actions malveillantes.
C’est plus inquiétant de savoir que le Bluetooth permette ce genre d’attaque en général que plus précisément sur les alertes covid19.
Je pense au objets connectés qui s’appuient sur le wifi / Bluetooth que l’évolution voudrait mettre de partout quelqu’en soit l’usage.
@Sindanárië
Quand je dis toutes les apps Bluetooth, ce sont toutes les apps Bluetooth pour combattre la COVID-19 !
Pour l’histoire des jetons qu’on peut rejouer, il ne faut pas oublier la dernière attaque de masse qui a fait tomber les serveurs DNS du monde entier.
La très grande majorité des appareils IoT a été utilisée pour cette attaque. Les appareils HomeKit (Apple) ont fait partie des rares à éviter l’attaque.
CQFD
@Florent Morin
Tu n'as pas ici affaire à des petits hackers ou codeur cherchant des bounty... Ils ont identifié cette faille qui est pour le moins très problématique, bien plus qu'une liste de malade qui circulerait... Et ils en ont rien a battre de faire une démo, ils ont des trucs un peu plus important à faire (regarde juste le pedigree de ces gens).
Joe le rigolo ne va pas utiliser cette faille, par contre je connais un sacré paquets de pays qui sont en guerre commerciale et pour qui ce serait une aubaine de remettre des parties de pays en quarantaines.
C'est une faille critique, car elle impacterait les décisions des gouvernements. Ne pas oublier que toutes les applications StopCovid ne sont pas des twitter ou autre Facebook. Ce sont des applications officielles, la vérité du gouvernement.
Le plus navrant dans cette histoire c'est que et Google et Apple ont pondu ces api en insistant que c'était les seules solutions viables. Et ce n'est pas vrai. Elles ont un trou que certains gouvernements pourraient utiliser...
Si j'étais un peu conspirationniste, je dirais que ces trous ont volontairement été laissé... C'est pas possible que des milliers d'ingénieurs de ces deux boites fassent exactement la même erreur, apportant une possibilité de verrouiller un pays pour qui sait s'y prendre. C'est pas de l'application de macg dont on parle ici... Les implications sont légèrement plus grandes et pourraient même se révéler dramatique, bien plus une fois de plus que de protéger une vulgaire liste de malade dont on se demande bien qu'elle pourraient être le côté néfaste si c'était hacké...
@debione
C’est pour cela que ça parait assez improbable.
En premier lieu, cela ne concerne pas exclusivement l’API Apple / Google.
C’est le principe de jetons Bluetooth qui est en cause.
Il y a une fenêtre de tir de 2 heures pour garantir le respect de la vie privée et s’assurer que techniquement ça passe.
Après, si quelqu’un vient « sniffer » à proximité d’un groupe de malades, de toutes manières, il met en danger autrui s’il s’approche d’un autre groupe.
Et s’il scanne à 10m, il faut qu’il broadcast à moins d’1m de sa cible. Sinon, l’algorithme de diagnostic ne considérera pas le risque.
https://developer.apple.com/documentation/exposurenotification/enexposureconfiguration
Et, pour que le pseudonyme reste enregistré, il faut au moins 5 minutes de contact a moins d’1m. Sinon, le pseudonyme reçu est ignoré.
Le risque est quand même très très faible.
@florent morin
Oui je voit bien que le risque est faible... Par contre c'est inversement proportionnel aux dégâts que cela peut occasionner.
Comme je l'ai dit, ce n'est pas joe le rigolo qui peut être intéressé par ce genre de faille... Par contre, si je reprends un contentieux actuel, il ne serait pas impossible que la Chine l'utilise à l'encontre de l'Australie par exemple...
Cette faille est critique dans les dégats qu'elle peut causer sur l'ensemble d'une population, d'un pays. Le fait que le risque est faible n'enlève rien au désastre que cela pourrait occasionner.
@FloMo
Il doit pouvoir utiliser un émetteur bluetooth plus puissant que celui d'un smartphone standard pour donner l'impression d'être à moins d'1 mètre alors qu'il est à 10m, non?
@Nebukad
L'application française StopCovid ne s'appuie pas sur l'API d'Apple et de Google, et n'utilise pas le même format de données, donc elle ne sera pas concernée si une attaque comme celle décrite dans l'article est effectuée.
Quant à savoir si une attaque similaire serait possible en s'appuyant sur son protocole à elle, c'est à confirmer, mais le risque est nettement moindre puisqu'il n'est (pour l'instant du moins) utilisé qu'en France. Et il sera probablement bien plus compliqué d'émettre de faux signaux.
Avec une simple application Bluetooth du type :
- lightblue
- BLE scanner
Tu peux effectivement copier les trames Bluetooth qui t’entourent.
Ensuite modifier le caractère qui correspond à :
Affection COVID.
Ensuite tu peux émettre cette trame où tu veux et quand tu veux.
Donc potentiellement mettre en quarantaine toute les personnes qui emploient l’application COVID.
Cette trame est propre à chaque application StopCovid. Mais le mécanisme est similaire.
Bonne semaine
@Maliik
étonnant qu'il n'y ait pas encore eu d'attaque ... vu la polarisation que créent ces apps ...
Pour cela, il faudrait accéder à la clé permettant de chiffrer les méta-données.
https://covid19-static.cdn-apple.com/applications/covid19/current/static/contact-tracing/pdf/ExposureNotification-CryptographySpecificationv1.2.pdf
Donc on ne peut pas modifier un caractère comme ça.
Par contre, l'exemple qui est donné est d'aller à un centre de dépistage, scanner les positifs, et dans la fenêtre de 2 heures de validité des trames Bluetooth, aller les rejouer ailleurs.
En théorie, ça fonctionne.
En pratique, Apple recommande de ne pas considérer les 2 heures avant le diagnostic au moment de la réception des clés par le serveur. (le serveur reçoit la clé et la période de validité)
Et, de toutes manières, il faudrait être à environ 1 m de la personne malade, donc s'exposer.
Si on est à plus de 10m, on peut recevoir le signal. Mais si on le rejoue, c'est à 1 m de la cible pendant au moins 5 minutes.
Il me semble avoir compris que l’app française n’utilisait pas de rotation de token. Compte tenu de la simplicité de mise en place de cette technique, et sans rotation de token, le système français serait tout aussi facile à berner, mais sans aucune limite de temps ni possibilité de bloquer l’attaque. L’API Google/Apple, avec la rotation de token, limite au moins la petite blague à une intervention de 2h... la sécurité du système français tiendrait dans la non-divulgation des tokens déclarés positifs au COVID-19 ?
@MarcassinBimbo
Sans doute (je n'en sait rien en fait). Par contre une chose sur, c'est que la technique Apple/Google peut s'appliquer à tous les pays se reposant sur ce système. LA ou il faudrait spécialement viser le système français.
Bref, on retrouve bien la problématique que de déléguer à des GAFAM la sécurité. Demain si le système français est hacker, ils peuvent changer certaines choses pour que cela ne se reproduise plus. La ou nous en Suisse, si cette application est hacker on ne peut que dire "siouplé Google/Apple fait quelque chose". Bref pied et poing lié sur un problème crucial, et sans la certitude qu'il n'y a pas la volonté derrière de laisser une possibilité pour certaines institutions américaines d'avoir un moyen d'action détourné.
@debione
C'est pour ça que l'aspect "souveraineté" d'une telle application a son importance, contrairement à ce qu'on a pu lire ici. Celles qui reposent sur l'API d'Apple et de Google sont entièrement à la merci des changements et correctifs que ces deux sociétés voudront bien (ou non) apporter.
@webHAL1
La « souveraineté » a la même faille.
@FloMo
Quelles sont vos sources ?
Spécifications Bluetooth de ROBERT :
https://github.com/ROBERT-proximity-tracing/documents/blob/master/ROBERT-specification-EN-v1_1.pdf
Spécifications Bluetooth de Exposure Notification :
https://covid19-static.cdn-apple.com/applications/covid19/current/static/contact-tracing/pdf/ExposureNotification-BluetoothSpecificationv1.2.pdf
Le risque vient du fait que le protocole Bluetooth Advertising émet en permanence.
Cette info peut être récupérée et rejouée.
Pour limiter le risque, il faut une double vérification : en émission et en réception.
Les deux font cette double vérification dans une certaine mesure.
Côté Apple, il y a même une vérification supplémentaire recommandée spécifiquement pour le cas exposé.
En gros, les identifiants des 2 dernières heures sont ignorés. Et le problème est résolu. Sans ça, aucune certitude qu'une personne est malade.
Je pense que ROBERT a pris les mêmes précautions.
@FloMo
D'accord. Vous pensez. Vous ne savez pas.
@FloMo
Le point soulevé n'est pas qu'une faille similaire n'existe pas, mais c'est celui de la capacité à en maîtriser la correction sans dépendre du bon vouloir de sociétés tierces.
@r e m y
Il existe des implémentations open-source sur Raspberry Pi du protocole Exposure Notification.
iOS 13.5 a été jailbreaké. Ce qui facilite la recherche de failles.
Le temps que quelques hackers mettent les mains dedans, on aura vite la réponse. 😁
@FloMo
Je crois que vous n'avez toujours pas compris le point soulevé autour de la "souveraineté"... aucun rapport avec la possibilité d'une faille ou la vitesse de sa correction, mais sur l'indépendance qu'un Pays peut vouloir garder quant à sa capacité à se protéger sans dépendre de tiers.
@r e m y
Quand on voit ce qui a été écrit sur ce site au sujet de la souveraineté, on se rend compte que personne dans la rédaction de MacG n'a compris de quoi il s'agit... -_-
@webHAL1
On a la même problématique quand on parle de tous les oeufs dans le même panier... Ne pas être capable de comprendre que d'avoir toutes sa vie (de sa santé à ces comptes bancaires en passant par ces carnets d'adresses, ses préférences musicales et autres) dans une seule boîte est à terme très dommageable. Certains n'auraient pas du dormir pendant les cours d'histoires... ;)
@debione
Oui, mais attention avec cette image : certains œufs (données de santé) sont incomparablement plus précieux que d'autres (préférences musicales).
@debione
Vous partez du principe que ces deux chercheurs (suisses) au pedigree incroyable ont raison sans qu’ils aient à le prouver (lol inside). Et si ils ont autre chose à faire, qu’ils ne viennent pas mettre le bordel sans rien prouver pour commencer. Le protocole que suit Apple+Google est celui d’une université Suisse (tiens donc).
Alors monsieur le complotiste je vous propose celui-là (parce que pourquoi pas) : deux universités Suisses en compétition, une rafle la mise l’autre est jalouse. Allez je vous l’avoue tout de suite, je n’y crois pas… mais encore une fois, pourquoi pas 😊
@Cactaceae
Alors les école polytechnique fédérale ne sont pas... des universités;) Et tout le monde s'accorde à dire qu'ils ont raison. Même sur ce site, Flomo est de cet avis même si il juge difficile à mettre en oeuvre.
Et au passage il n'y a pas que ces deux chercheurs, il y a aussi Paul-Olivier Dehaye, ce nom vous dit peut-être rien, c'est juste le type qui a mis à jour le scandale Cambridge Analytica, et lui n'a rien à voir avec les EPF, et lui aussi juge très problématique cette faille.
Je ne sais pas d'ou vous sortez cette histoire de deux universités en compétition, si ce n'est pour donner un semblant de quelque chose à votre message qui est juste vide, plein de fausseté et de mensonges.
@debione
Si tout donner au même endroit n’est pas très sûr … essaimer ces données à travers le web, l’est plus?
@billytipper2
Oui je le pense... Surtout si vous avez l'habitude de prteger votre nom, votre numero de tel... C'est l'agrégation de donnes qui peut se reveler le plus dangereux. Tout donner a Google ou a Apple ou a Facebook..
Le mieux etant de veiller a ce qu un pays n'aie pas la mainmise sur tout.... Genre si vous utilisez un ios ou Android il serait bien de ne pas utiliser leurs cloud...
@webHAL1
>C'est pour ça que l'aspect "souveraineté" d'une telle application a son importance, contrairement à ce qu'on a pu lire ici. Celles qui reposent sur l'API d'Apple et de Google sont entièrement à la merci des changements et correctifs que ces deux sociétés voudront bien (ou non) apporter.
Si j’ai bien suivi le problème n’est pas au niveau de l’API mais plutôt au niveau du Bluetooth, ... , bien tenté.
@coby
Il est pourtant bien stipulé par les chercheurs que c'est l API de Google et Apple qui est en cause. Le BT n'est que l'émetteur...
" le problème touche l'API d'Apple et Google qui est exploitée par SwissCovid"
Donc...
@c0by
Je crains que vous n'ayez mal suivi. Le fait d'utiliser l'API de Apple et Google rend une application totalement dépendante des changements est/ou des correctifs apportés à celui-ci. Ce n'est pas le cas avec une application reposant sur son propre protocole.
@webHAL1
>Je crains que vous n'ayez mal suivi. Le fait d'utiliser l'API de Apple et Google rend une application totalement dépendante des changements est/ou des correctifs apportés à celui-ci. Ce n'est pas le cas avec une application reposant sur son propre protocole.
Que ce passe t il en cas de changement ou correction lié à l’OS. Vous êtes au courant que ce dernier n’est pas souverain d’autant plus que les dev ont pris quelques libertés afin d’avoir une application fonctionnant sur iOS ?
Idem recapcha de Google utilisé ? Il y a la communication souveraineté et la réalité de la dépendance de fait à des OS.
Pour revenir sur ce que j’ai suivi, compris, la faille étant lié au Bluetooth, elle serait donc reproductible sur toute utilisation de ce dernier du même genre en l’adaptant bien sur. Donc sur l’application souveraine StopCovid ?
@c0by
Tout à fait, les États n'ont aucune souveraineté sur les systèmes d'exploitation mobiles. Mais, personnellement, je n'y vois pas là une raison pour ajouter un risque supplémentaire en utilisant, pour une application utilisée dans un domaine aussi sensible que la santé (on ne parle pas d'une application visant à connaître les préférences de la population en termes d'animaux domestiques), une API qui est globalement une boîte noire si on peut l'éviter.
@c0by
> Que ce passe t il en cas de changement ou correction lié à l’OS.
Si la seule façon de corriger le problème c'est via une correction de l'OS, y'a dépendance.
Si y'a moyen de pallier cela autrement, non.
Dans le cas de l'usage de l'API ExposureNotification, si le problème se situe en dessous, dans son implémentation, dans le protocole qu'il implémente, y'a pas moyen de corriger sans dépendance aux éditeurs de l'OS. De la même manière, s'ils choisissent de modifier l'API ou les fonctionnalités supportées, pareil, y'a dépendance.
> Idem recapcha de Google utilisé ? Il y a la communication souveraineté
> et la réalité de la dépendance de fait à des OS.
Euh, non. reCaptcha n'est pas dans les OS. Et d'ailleurs le projet StopCovid et l'INRIA travaille déjà à se passer de reCaptcha pour utiliser une solution plus souveraine justement, conscient de la polémique (justifiée) que cela soulève.
Et s'ils travaillent déjà dessus, c'est justement parce qu'ils le *peuvent*.
Sans dépendre de l'accord de quiconque.
Ce qui est justement la démonstration inverse de ce que vous tentez de souligner.
Il n'y a rien d'incontournable à l'usage de reCaptcha. Alors que pour certains besoins BLE Advertizing, devoir accepter toute une API "contagion sanitaire" opaque (en terme d'implémentation) d'un OS, c'est bien une dépendance à l'éditeur de l'OS.
@c0by
> Pour revenir sur ce que j’ai suivi, compris, la faille étant lié au Bluetooth, elle serait
> donc reproductible sur toute utilisation de ce dernier du même genre en l’adaptant
> bien sur. Donc sur l’application souveraine StopCovid ?
Probable, oui.
Mais la nuance, c'est qu'un correctif ou du moins une réduction de la faille peut être déployé par une modification du protocole ou de son implémentation sans dépendre du bon vouloir de l'éditeur d'une API tierce, qui en plus se doit de maintenir une rétro-compatibilité minimum de cette API.
@byte_order
Si la souveraineté était la panacée les projets européens ne partiraient pas sur l’API. Les Anglais n’aurait pas fait un appel d’offre pour partir dessus isolant un peu plus le choix français.
L’application souveraine peut avoir des avantages mais elle a aussi un pendant qui est d’avoir plus de moyen pour la maintenir. En contradiction avec le discours actuel de budget minimal.
En cas de problème il faut le contrat de maintenance qui va bien et les sous qui vont avec. Sans oublier que les compétences mobilisées lors de la phase projet vont partir plus ou moins rapidement sur d’autres projets, avec des compétences dans des sociétés qui n’ont pas eu non plus la maintenance.
En tout état de cause le gouvernement c’étant arc-bouté sur une solution centralisée la question ne ce pose pas. On le voit bien pour recaptcha Google qui est devenu problématique quand cela a été connu car en déphasage par rapport à la communication.
@c0by
> Si la souveraineté était la panacée les projets européens ne partiraient pas sur l’API.
D'une part, ici on ne parle pas de souveraineté européenne, vu que la politique de santé reste une prérogative de chaque état de l'UE.
Ensuite, il se trouve que *les* projets ne sont pas européens mais bel et bien des projets de chaque état.
> L’application souveraine peut avoir des avantages mais elle a aussi un pendant qui
> est d’avoir plus de moyen pour la maintenir.
Attention, pour comparer le prix, il faut pouvoir comparer sur la durée totale, pas seulement initial. Le prix de indépendance n'est évidement pas nul, mais le prix de la dépendance non plus.
@byte_order
>> Si la souveraineté était la panacée les projets européens ne partiraient pas sur l’API.
>D'une part, ici on ne parle pas de souveraineté européenne, vu que la politique de santé reste une prérogative de chaque état de l'UE.
>Ensuite, il se trouve que les projets ne sont pas européens mais bel et bien des projets de chaque état.
Oups il y a un morceau qui a sauter dans ma phrase. Il fallait bien évidemment lire : Si la souveraineté était la panacée les projets actuels des pays européens ne partiraient pas sur l’API...
Espérons que dans ce choix souverainiste isolé on n’ait pas les mêmes raisons que celle pour le moteur de recherche Qwant.
@c0by
> Espérons que dans ce choix souverainiste isolé on n’ait pas les mêmes raisons que
> celle pour le moteur de recherche Qwant.
c.a.d ?
Et par ailleurs, contrairement à l'indexation du web, le moteur derrière une solution de détection et d'alerte aux expositions à un virus sont les individus eux-même.
API ou pas, iPhone ou autres, sans les individus, cela ne fonctionne tout simplement pas.
@byte_order
> Espérons que dans ce choix souverainiste isolé on n’ait pas les mêmes raisons que
> celle pour le moteur de recherche Qwant.
>>c.a.d ?
Qwant, les raisons ont été les mêmes d’une solution souveraine face aux moteurs de recherche américains. Le ministre en charge était E. Macron. Une fois devenue président l’appuie de l’état c’est renforcer. Cédric O. confirmant le soutien de la France mais vu les polémiques (utilisation majoritairement de bing, hébergement chez Microsoft, résultats du moteur décevant, histoire de financement lié à la sphère macroniste) a enfin lancé un audit sur l’indexation autonome et la non traçabilité. Retour fin Août. Pour les histoire de financement, l’un des fondateurs a été démissionné en réaction mais là pour démêler le tout on part sur des années d’autant qu’il y aurait des liens avec d’autres affaires en cours.
@byte_order
> >L’application souveraine peut avoir des avantages mais elle a aussi un pendant qui
> >est d’avoir plus de moyen pour la maintenir.
>Attention, pour comparer le prix, il faut pouvoir comparer sur la durée totale, pas seulement initial. Le prix de indépendance n'est évidement pas nul, mais le prix de la dépendance non plus.
Le vrai gros avantage d’une solution souveraine c’est de pouvoir vendre une récolte respectueuse de données limitées aux contacts de plus de 15min à moins d’1m et au final récolter tous les contacts dans la limite de portée du Bluetooth pour retraiter cette masse de données sur le serveur central.
@c0by
> Le vrai gros avantage d’une solution souveraine c’est de pouvoir vendre
> une récolte respectueuse de données limitées aux contacts de plus de 15min
> à moins d’1m et au final récolter tous les contacts dans la limite de portée
> du Bluetooth pour retraiter cette masse de données sur le serveur central.
Non, le gros avantage d'une solution souveraine c'est de pouvoir faire un peu plus ce que vous voulez sans être totalement dépendant de tiers étrangers.
Ce que vous avancez, c'est seulement votre spéculation de ce que vous pensez que certains pourraient vouloir faire.
Et par ailleurs, recolter des millions de pseudonymes randomisés toutes les 15 minutes, c'est pas très utile. Cela permet seulement de faire des statistiques sur les contacts entre individus lambdas, biaisées par le fait qu'il s'agit forcément d'invidus utilisant l'app, qui sont minoritaires en plus.
@byte_order
> Ce que vous avancez, c'est seulement votre spéculation de ce que vous pensez que certains pourraient vouloir faire.
Sincèrement pour le coup j’aurais aimé que cela soit ma propre spéculation, malheureusement vu l’article très documenté de Mediapart du 15 Juin c’est très factuel.
1) sur le fonctionnement de StopCovid, il a été très clairement indiqué que c’est lorsque 2 téléphones se croisent pendant 15min à moins d’un mètre, que chacun enregistre l’autre dans l’historique de son application de manière cryptée (cf faq mise en ligne par Bercy ou intervention Cédric O. 20h fr2 du 31 mai.
2) l’INRIA qui a mené des expériences constate que les données sont envoyées au serveur central sans notion de distance, ni durée lorsque l’on se déclare porteur du virus.
3) interrogé sur ce point le secrétaire d’etat confirme et indique que c’est bien dans ce cadre que la CNIL a donné sa validation. A voir ce qu’il en est côté CNIL qui est normalement en pleine campagne de contrôle.
Si cela concernait juste Bluetooth alors toutes les utilisations de Bluetooth seraient concernées et cette faille uniquement à Bluetooth aurait dû être révélée depuis longtemps. Du moins je le suppose.
@Inconnu-Soldat
Non. Car c’est une utilisation du Bluetooth qui en fait une sorte de réseau peer-to-peer. (Je grossis le trait, mais c’est ça)
Contrairement aux utilisations habituelles, l’impact d’une faille va au-delà du périmètre d’un seul utilisateur.
Ouahh! Ça fuse!
Au vu de vos commentaires, cela me confirme que j’installerai SwissCovid et ne m’inquiéterai pas trop!
Tiens un gros souci Apple/Google et aussi ce qui n’est pas très appuyé ici c’est que la France si en retard a son application qui tourne (bien et très bien quant à son usage même si 1,5 million ou plus n’est pas le Pérou), que ce fut fait avec des tests sans avoir besoin de 100.000 personnes (alors qu’ici on disait que c’était minable) depuis le 2 juin, qu’elle est encore en test en Suisse et même pas dispo encore en Allemagne et que si elle était inutile en France quelle serait donc son utilité en Suisse et surtout en Allemagne introduite bien plus tard et donc avec le virus encore moins présent ?
Qu’aurions-nous lu contre StopCovid si c’était son cas puisqu’il semble que la responsabilité majeure en est à l’API américano-américaine ? Nous en serions à 2.000 commentaires hurlants et haineux.
De quoi ont-ils l’air nos contempteurs de StopCovid et adorateurs de l’API transatlantique ? Et ce défaut s’ajoute à la non inter-opérabilité des applications avec l’API qui, de toutes façons, étant si peu nombreuses et si éclatées géographiquement que cela ne change pas grand chose.