TousAntiCovid intègre l'attestation de déplacement et dépasse les 7 millions d'activations
L'application TousAntiCovid continue de s'enrichir pour être plus attractive et être adoptée plus largement, la condition sine qua non de son efficacité. Après des statistiques et des informations sur l'épidémie de coronavirus, l'app accueille dans sa version 2.1 un générateur d'attestation de déplacement.
La fonctionnalité est à chercher en bas de l'app, dans la section Plus. La création d'une attestation, réalisée entièrement en local, est on ne peut plus simple : on remplit tous les champs nécessaires (prénom, nom, date de naissance…), on sélectionne le motif de déplacement et on génère l'attestation.
Avant que l'attestation soit générée, il est nécessaire de certifier que son déplacement est lié au motif sélectionné. Cette étape consiste simplement à appuyer sur le bouton « Je certifie » de la boîte de dialogue.
Une fois que c'est fait, on obtient l'attestation sous la forme d'un code QR intégré à l'application. En touchant ce code QR on l'affiche en grand à l'écran et on obtient des détails.
Vous pouvez stocker plusieurs attestations en même temps dans l'application. Les attestations expirées sont mises de côté et supprimées automatiquement au bout de 24h minimum. Mais attention, TousAntiCovid semble faire une erreur en appliquant une expiration d'une heure pour l'intégralité des motifs, et pas seulement pour la balade autour de son domicile. De plus, il n'y a pas la possibilité de sélectionner plusieurs motifs simultanément.
Par ailleurs, vous avez la possibilité d'exporter les attestations dans une autre app ou de les partager à une autre personne. Pour cela, il faut appuyer sur le bouton « Plus d'options » (les trois points dans un cercle), ce qui aura pour effet d'ouvrir le menu de partage d'iOS.
Si vous choisissez de partager votre attestation par email, par exemple parce que vous l'avez remplie pour quelqu'un d'autre, l'email contiendra les informations personnelles et le code QR.
À noter aussi que TousAntiCovid permet d'enregistrer ses données personnelles pour générer plus rapidement les attestations suivantes. Si on coche la case « Sauvegarder mes données » à la fin du formulaire, les données personnelles (prénom, nom, date de naissance, lieu de naissance et adresse) sont stockées dans le téléphone. La prochaine fois que l'on créera une attestation, toutes ces données seront préremplies, il ne restera plus qu'à choisir le motif. La date et l'heure de sortie sont pour leur part définies automatiquement (mais on peut les modifier manuellement si besoin).
Enfin, même si cela va à l'inverse de l'objectif recherché, il est possible d'utiliser le générateur d'attestation sans activer le traçage des contacts dans TousAntiCovid, ce sont deux fonctionnalités indépendantes. Une autre nouveauté plus discrète de cette mise à jour est la possibilité de désactiver les notifications des actualités quotidiennes.
Une application qui décolle enfin
Ce générateur d'attestation fort pratique devrait contribuer à augmenter la popularité de l'application, qui décolle enfin depuis le rebranding de StopCovid en TousAntiCovid. Cédric O a annoncé ce matin que l'application avait dépassé les 7 millions d'activation, contre 3,3 millions le 23 octobre. L'ancienne version était restée sous la barre des 3 millions en cinq mois d'existence.
Toujours selon le secrétaire d’État chargé de la Transition numérique, TousAntiCovid notifie désormais 500 personnes par jour d'un risque d'exposition au virus. Au dernier pointage lundi soir, environ 30 000 personnes se sont déclarées positives au Covid-19 dans l'application et 4 200 ont été averties qu'elles se sont trouvées à proximité d'un cas positif.
Le ratio entre les cas déclarés et les personnes notifiées est faible, mais il « s'améliore considérablement », a soutenu Cédric O à l'AFP. Pour rappel, l'application ne fonctionne toujours pas en tâche de fond sur les iPhone quand il n'y a pas de smartphones Android à proximité.
Le gouvernement vise maintenant « entre 15 et 20 millions de téléchargements le plus vite possible. » Au Royaume-Uni, l'application de traçage des contacts équivalente a été téléchargée par 19 millions de personnes.
Tiens on dit un peu de bien de cette app ...
@lkaritoo
Ce qui fait un peu du bien... Elle a besoin de publicité en ce moment cette application :/
@Link1993
🐑 🐑🐑🐑🐑🐑🐑🐑
Heureusement, que tu sois un berger, ouf je me sens moins perdu !
Et oui, belle initiative que cette application !
@lkaritoo
Le seul soucis de l’app, c’est son traçage des contacts.
L’app offre malgré tout des informations et fonctionnalités utiles.
@FloMo
Si tous les Français commençaient par l’installer et après on fera les comptes.
Ce sujet de api reste un sujet geek pour moi.
Dans ma famille ils sont loin très loin de ce genre de détail.
@lkaritoo
Imaginons un instant que plusieurs millions d’utilisateurs (15-20 millions) aient installé l’app.
Et que par une malicieuse astuce le système est dupé et envoie des centaines de milliers voir des millions de fausses notifications.
Quelles seraient les conséquences au niveau des hôpitaux, des entreprises et des centres de tests ? Ce serait plus puissant que n’importe quelle armée. Et là, ça ne serait pas un sujet geek mais une catastrophe nationale.
Si des centaines de chercheurs en sécurité dans le monde se sont alarmés de l’usage d’un protocole centralisé, ce n’est pas pour rien.
Et si ça arrive un jour, ce qui n’est pas souhaitable, on entendra « on ne pouvait pas savoir ». Comme toute attaque informatique.
@FloMo
Merci pour ta réponse Florian.
Je pense que je dois lire un peu plus sur le sujet.
Je me disais juste, est ce que y’a pas aussi le risque de piratage dans les api Apple Google aussi ?
Si on arrive à exploiter ces données, ça serait encore plus grave, car l’impact est mondiale.
@lkaritoo
nan lui c’est Florent
en fait ca lui a fait perdre une tournée de biere cet été, une ancienne histoire trop longue à raconter...
@raoolito
Merci.
Désolé Flo ( je m’en sors bien là)
@lkaritoo
C’est un métier. ^^
Concernant l’API Apple / Google, le diagnostic est effectué sur chaque appareil. Et les pseudonymes reçus en Bluetooth restent sur l’appareil.
Et surtout ils sont « verrouillés » par l’API. Pour remonter les pseudonymes à risque, l’utilisateur doit manuellement valider l’opération.
Et, en protection supplémentaire, l’API n’est accessible qu’à un nombre limité d’apps. Et donc uniquement les apps officielles.
Le seul moyen de duper le système serait d’utiliser une implémentation sur Raspberry Pi par exemple. Mais c’est beaucoup plus difficile à diffuser qu’un smartphone.
Et, en général, les serveurs utilisent des protections supplémentaires pour s’assurer que c’est bien un smarphone qui leur parle. (Un procédé refusé par ROBERT car ça fait appel aux outils de Google et Apple...)
@FloMo
> Et que par une malicieuse astuce le système est dupé et envoie des centaines de
> milliers voir des millions de fausses notifications.
> Quelles seraient les conséquences au niveau des hôpitaux, des entreprises et des
> centres de tests ? Ce serait plus puissant que n’importe quelle armée. Et là, ça ne
> serait pas un sujet geek mais une catastrophe nationale.
2 entreprises américaines, donc sous contrôle d'un pays étranger, sont tout autant dans la possibilité de générer des fausses notifications.
Si vous voulez aller dans le catastrophisme, je ne vois pas pourquoi vous focalisez uniquement sur une attaque "malicieuse" que sur l'approche centralisée.
Côté architecture centralisé, cela impliquerait de monter une armée d'appareils BT qui "répandraient" massivement partout des pseudonymes taggés comme contaminé par un diagnostique authentique contrôlé côté serveur afin que tout le monde ayant activé TousAntiCovid (une minorité pour l'instant) les croise, générant des cas contacts avec des appareils plutôt que des gens.
Côté API, Apple et Google dispose déjà de cette armée d'appareils BT, il suffit juste d'y injecter le code produisant un faux diagnostique de cas contact, sans avoir besoin de balader quoi que ce soit. Une faille exploitée par un hacker ou une maj d'OS avec une modification contenant une génération de faux diagnostics (mais limitée à des pays ciblées par exemple) est tout autant possible.
Qui ici, dès lors qu'on part dans le _catastrophisme_, peut garantir que jamais un président américain n'utiliserait tout ce qu'il peut pour déstabiliser économiquement un pays ou un bloc économique qu'il juge contraire aux intérêts des américains !?
Ironiquement, la panique sur notifications a eu lieu au début du lancement de l'app utilisant l'API chez les britanniques : ils ont pris peur de la notification "l'app de notification d'exposition au covid est activé", l'interprétant comme "vous avez été exposé au covid" !
@byte_order
> 2 entreprises américaines, donc sous contrôle d'un pays étranger, sont tout autant dans la possibilité de générer des fausses notifications.
Les notifications sont locales. Donc non.
Le seul moyen est de duper le serveur. Et il y a une technique pour ça.
> Côté architecture centralisé, cela impliquerait de monter une armée d'appareils BT...
C’est beaucoup plus simple que ça et avec moins d’appareils. N’importe quel smartphone serait compatible. En plus des raspberry pi qui sont beaucoup plus complexes à déployer.
> Côté API, Apple et Google dispose déjà de cette armée d'appareils BT, il suffit juste d'y injecter le code produisant un faux diagnostique de cas contact, sans avoir besoin de balader quoi que ce soit.
C’est possible avec ROBERT, en effet. Via un framework XSSET par exemple. Ou une app bidon qui en sous-main se ferait passer pour TousAntiCovid. (Je ne détaillerai pas le procédé évidemment)
D’où le blocage du protocole EN par Apple. Il est impossible de « simuler » EN via l’API Bluetooth par défaut. Pour limiter les attaques de ce type.
Et l’API n’est accessible qu’aux apps autorisées.
Et le tout nécessite intervention manuelle de l’utilisateur pour récupérer les pseudonymes à risque, limité à une fréquence de 24h je crois.
D’autant que la plupart des serveurs EN utilisent les API Apple / Google pour s’assurer que c’est bien l’app officielle qui envoie la requête. Rejeté par ROBERT car ça utilise des technologies des GAFAM. (Sérieux..)
Sécurité VS « ça n’arrivera jamais »
> Ironiquement, c'est quasiment ce qui a eu lieu au début du lancement de l'app utilisant l'API chez les britanniques : ils ont pris peur de la notification "l'app de notification d'exposition au covid est activé", l'interprétant comme "vous avez été exposé au covid" !
Ha ça !
@FLoMo
> Les notifications sont locales. Donc non.
Émises sur la base d'un code d'une API qui retourne un booléen "exposé/ pas exposé", API dont la distribution est dans les mains exclusives d'Apple et Google.
Donc, techniquement : si, si !
Ces 2 entreprises ont bien techniquement la possibilité d'injecter du code qui générerait à grande échelle de fausses notifications d'exposition. Et donc d'enclencher une panique sur un système de santé.
Je note que dans votre théorie catastrophique, vous balayez totalement l'argument du risque "jamais aucun président américain ne pourrait utiliser tous les moyens en son pouvoir, dont le contrôle d'entreprises américaines sur l'ensemble du parc mondial d'équipements, pour générer dans certains pays des paniques dans l'intérêt des américains, économiques, politiques peu importe".
Le fait est que si Apple et/ou Google injecte une modification du code dans l'API distribuée dans leurs OS qui générerait des faux diagnostiques d'exposition, y'a absolument rien qui l'empêche, et les conséquences seraient exactement les mêmes pourtant.
Marrant comment votre "Sécurité VS ça n'arrivera jamais" est à géométrie variable.
Ca n'arrivera jamais qu'un pays étranger utilise son contrôle à distance de plateformes utilisées partout dans le monde à son avantage !?
Vous théorisez sur du catastrophisme mais vous balayez ça d'un revers de main !?
C'est pourtant une position tout autant "ça n'arrivera jamais", je ne comprends pas que vous ne le voyez pas.
Ironiquement, le risque que vous évoquez sur l'app Française, dans le cas où il aurait lieu, ne pourra pas toucher plein de pays en même temps - avantage typique de la diversité des solutions.
@byte_order
>> Les notifications sont locales. Donc non.
> Émises sur la base d'un code d'une API qui retourne un booléen "exposé/ pas exposé", API dont la distribution est dans les mains exclusives d'Apple et Google.
> Donc, techniquement : si, si !
> Ces 2 entreprises ont bien techniquement la possibilité d'injecter du code qui générerait à grande échelle de fausses notifications d'exposition. Et donc d'enclencher une panique sur un système de santé.
En même temps, si on parle de modifications d’API, ce qui est quand même super vicieux, cela ne change rien que ce soit ROBERT ou EN.
Dans un cas, c’est le framework EN qui le déclenche.
Dans l’autre, c’est le framework ROBERT qui demande au framework Notifications de le déclencher.
À la fin, c’est la même chose. Les deux sont des frameworks Apple / Google.
> Je note que dans votre théorie catastrophique
Théorie, comme toute mesure de sécurité.
Un mot de passe « 1234 » ne sera cracké qu’en théorie.
Le ver Tuxnet ne pouvait nuire au programme nucléaire iranien qu’en théorie.
> Le fait est que si Apple et/ou Google injecte une modification du code dans l'API distribuée dans leurs OS qui générerait des faux diagnostiques d'exposition, y'a absolument rien qui l'empêche, et les conséquences seraient exactement les mêmes pourtant.
C’est justement la grosse nuance.
Côté Apple / Google, il y a au moins 2 interrupteurs en cas de problème :
- côté serveur gouvernemental (serveurs différenciés de surcroît)
- côté Apple / Google, le framework peut aussi être coupé à distance.
Encore une fois, c’est le principe de précaution qui est appliqué. L’hypothèse d’une attaque informatique n’est pas balayée.
Et clairement, ROBERT n’a pas été conçu pour être sécurisé. On se rappelle tous de Stéphane Richard affirmant que c’était le système le plus sécurisé de France. Avant le bug bounty.
> Vous théorisez sur du catastrophisme mais vous balayez ça d'un revers de main !?
Si on n’a pas confiance dans la technologie d’un pays, on ne l’utilise pas.
L’utiliser en disant « on n’a pas confiance en eux » est risible.
Le principe Nº1 de la sécurité mobile est : sortez le moins d’informations possibles du smartphone. Là, on fait l’inverse.
@FloMo
> Dans un cas, c’est le framework EN qui le déclenche.
> Dans l’autre, c’est le framework ROBERT qui demande au framework Notifications
> de le déclencher.
> À la fin, c’est la même chose. Les deux sont des frameworks Apple / Google.
Et donc ? C'est techniquement un vecteur d'injection de fausses notifications dans les deux cas.
> Le ver Tuxnet ne pouvait nuire au programme nucléaire iranien qu’en théorie.
Intéressant que vous utilisiez justement ce parfait exemple d'utilisation par les gouvernements américains et israéliens de leur contrôle sur Windows pour générer une attaque informatique servant leurs intérêts...
> Côté Apple / Google, il y a au moins 2 interrupteurs en cas de problème :
> - côté serveur gouvernemental (serveurs différenciés de surcroît)
C'est faux.
Nul besoin d'intervenir sur le serveur, l'API peut parfaitement générer une réponse "exposition détectée" fausse, que les apps remonteront à l'utilisateur via une notification, sans aucune aide côté serveur gouvernemental.
> - côté Apple / Google, le framework peut aussi être coupé à distance.
Et le serveur de StopCovid, lui, ne peut pas l'être peut-être !?
> Encore une fois, c’est le principe de précaution qui est appliqué.
> L’hypothèse d’une attaque informatique n’est pas balayée.
Vous balayez bien celle d'un usage par une puissance étrangère d'un code ou d'une faille présent dans un OS... Tout en soulignant la jurisprudence de Tuxnet. Sacré paradoxe.
@byte_order
> Et donc ? C'est techniquement un vecteur d'injection de fausses notifications dans les deux cas.
Dans un cas, seuls Apple / Google peuvent exploiter ce vecteur.
Dans l’autre, n’importe quel hacker.
Énorme nuance.
> Intéressant que vous utilisiez justement ce parfait exemple d'utilisation par les gouvernements américains et israéliens de leur contrôle sur Windows pour générer une attaque informatique servant leurs intérêts...
Stuxnet n’était pas installé avec Windows.
Il a été créé par la NSA.
> C'est faux.
> Nul besoin d'intervenir sur le serveur, l'API peut parfaitement générer une réponse "exposition détectée" fausse, que les apps remonteront à l'utilisateur via une notification, sans aucune aide côté serveur gouvernemental.
Ça nécessite un accès physique à l’appareil de l’utilisateur.
Contrairement à la solution centralisée qui offre une attaque « cross-platforms ».
Le serveur central serait incapable de détecter le dysfonctionnement dans un délai raisonnable. C’est exactement ce qui a été fait pour Stuxnet.
> Et le serveur de StopCovid, lui, ne peut pas l'être peut-être !?
C’est le seul interrupteur. Si le serveur est détourné, l’app continue sa vie.
Comme dans tout système sécurisé, un seul interrupteur ne suffit pas. Mieux vaut en avoir plusieurs.
> Vous balayez bien celle d'un usage par une puissance étrangère d'un code ou d'une faille présent dans un OS... Tout en soulignant la jurisprudence de Tuxnet. Sacré paradoxe.
Stuxnet n’a pas été fourni par Microsoft avec Windows. Il a été injecté par la NSA.
Les failles CONNUES de ROBERT peuvent être exploitées par n’importe quel pays qui en voudrait à la France. Il faut juste un niveau maximum d’adoption pour qu’il y ait un maximum de dégâts.
Si on n’a pas confiance en Apple / Google, on n’utilise pas leurs systèmes d’exploitation. C’est tout.
Avouez quand même l’ironie de la chose.
Le gouvernement utilise les API mises à disposition par les constructeurs afin d’ajouter le traçage des contacts via ROBERT.
Plutôt que d’utiliser les API génériques fournies par les constructeurs, ces derniers proposent une solution clés en main. Qui profite du calibrage spécifique à chaque appareil. De sorte à améliorer le procédé. Et qui a l’avantage d’être protégé par le système d’exploitation.
En gros, une API spécifique.
Pour l’histoire du calibrage, qui est essentiel pour une mesure fiable, ROBERT en a enregistré plusieurs dizaines.
Apple a calibré toute sa gamme. Google vient d’en ajouter plusieurs centaines, en plus de ceux déjà présents.
Rien que ça, ça en dit long.
Et la réponse qu’ils ont, c’est « non, on n’utilisera pas vos API optimisées, on utilisez vos API génériques car on veut rester souverains ».... OK. Génies.
C’est pas comme si la fiabilité était un pré-requis. En plus de la sécurité.
@FloMo
> Dans un cas, seuls Apple / Google peuvent exploiter ce vecteur.
Si y'a zéro faille qui permet d'injecter du code dans iOS.
Vous êtes près à parier qu'il n'y en a vraiment zéro ?
> Dans l’autre, n’importe quel hacker.
> Énorme nuance.
Non, pareil dans les deux cas.
Une faille est une faille.
La nuance, elle se situe sur la différence de surface d'attaque de iOS par rapport à celle d'un serveur.
Et contrairement à vous, je ne suis pas aussi certain qu'il y ait une si grosse différence que cela.
> Stuxnet n’était pas installé avec Windows.
> Il a été créé par la NSA.
En exploitant les failles zero-day de l'OS Windows.
Y'a vraiment aucun faille zero-day dans iOS, dans Android !?
> Ça nécessite un accès physique à l’appareil de l’utilisateur.
??? Pour exploiter une faille dans un OS, faut un accès physique à l'appareil !? Depuis quand ?
Les MAJ de iOS, Apple la pousse via un accès physique à l'appareil !?
> Le serveur central serait incapable de détecter le dysfonctionnement dans un délai
> raisonnable.
ouais, bien sûr, l'augmentation exponentielle du nombre de contacts avec les mêmes ID ne peuvent pas être détecté, impossible ! Un algo qui vérifie que aucun ID n'est remonté comme ayant rencontré plusieurs millions voire milliards d'autres ID, c'est absolument impossible à faire.
Bien sûr.
>Les failles CONNUES de ROBERT peuvent être exploitées par n’importe quel pays
> qui en voudrait à la France. Il faut juste un niveau maximum d’adoption
> pour qu’il y ait un maximum de dégâts.
Connues ou pas. Pareil pour le protocole EN.
La nuance, c'est l'échelle des dégâts. Dans le premier cas, la France serait victime de ses propres choix *et* implémentations. Dans le second, cela ne serait plus le cas, à une échelle bien plus grande potentiellement.
@byte_order
> Si y'a zéro faille qui permet d'injecter du code dans iOS.
> Vous êtes près à parier qu'il n'y en a vraiment zéro ?
Si on peut accéder à un tel niveau d’élévation des privilèges, on peut accéder à tout le contenu de tous les iPhone du monde.
> Non, pareil dans les deux cas.
> Une faille est une faille.
Sauf que la faille de ROBERT, elle est démontrable et son impact ne concerne pas un seul utilisateur.
> La nuance, elle se situe sur la différence de surface d'attaque de iOS par rapport à celle d'un serveur.
> Et contrairement à vous, je ne suis pas aussi certain qu'il y ait une si grosse différence que cela.
Peut-être parce que j’ai déjà éprouvé le système. La faille n’est pas technique à proprement parler. Elle est au niveau de l’architecture.
> En exploitant les failles zero-day de l'OS Windows.
> Y'a vraiment aucun faille zero-day dans iOS, dans Android !?
StopCovid s’appuie sur quel OS ? iOS et Android.
Il y a juste ROBERT qui offre une surface d’attaque supplémentaire.
> ??? Pour exploiter une faille dans un OS, faut un accès physique à l'appareil !? Depuis quand ?
> Les MAJ de iOS, Apple la pousse via un accès physique à l'appareil !?
Ça pourrait en effet se passer par une URL via une faille de Safari. Mais ça nécessite une activation de l’utilisateur.
Rien à voir avec les MAJ de iOS.
> ouais, bien sûr, l'augmentation exponentielle du nombre de contacts avec les mêmes ID ne peuvent pas être détecté, impossible ! Un algo qui vérifie que aucun ID n'est remonté comme ayant rencontré plusieurs millions voire milliards d'autres ID, c'est absolument impossible à faire.
Bien sûr.
Exactement comme Stuxnet : une incrémentation progressive est imperceptible.
Passé un seuil, c’est dangereux de l’ignorer.
L’algorithme va s’appuyer sur des informations réalistes.
La manifestation des lycées aujourd’hui a fait se coller les uns aux autres des centaines de lycéens. Il suffit d’un cas pour que tous les autres reçoivent la notification.
> Connues ou pas. Pareil pour le protocole EN.
Si une solution est utilisée dans la majorité des pays utilisant le traçage des contacts, il y a plus de chances pour que des hackers éthiques remontent les failles.
> La nuance, c'est l'échelle des dégâts. Dans le premier cas, la France serait victime de ses propres choix et implémentations. Dans le second, cela ne serait plus le cas, à une échelle bien plus grande potentiellement.
C’est un point de vue.
Tout démontre le contraire jusqu’à aujourd’hui :
- les principes de base de la sécurité mobile
- l’avis des 300 chercheurs en sécurité ayant tiré la sonnette d’alarme concernant les architectures centralisées
- le serveur qui ne tient pas la charge quand il y a trop de monde
- l’annonce du système le plus sécurisé de France suivi d’un bug bounty désastreux dont certains points ont été ignorés
- le fait qu’une faille potentielle exploitable immédiatement ait été démontré
- le fait qu’il y a un bug bounty permanent sur EN, avec des primes importantes.
Mais bon. Pourquoi pas.
@Florent Morin:
« Et clairement, ROBERT n’a pas été conçu pour être sécurisé. »
« Dans un cas, seuls Apple / Google peuvent exploiter ce vecteur. Dans l’autre, n’importe quel hacker. »
Ou comment perdre absolument toute crédibilité dans une discussion technique. ^_^
@FloMo
> Si on n’a pas confiance en Apple / Google, on n’utilise pas leurs systèmes
> d’exploitation. C’est tout.
Il se trouve que les particuliers l'utilisent, eux.
Le gouvernement a son propre OS pour smartphone pour ses propres besoins "sensibles", pour rappel. Mais les particuliers, de facto, imposent les plateformes à supporter.
Par ailleurs, la confiance, c'est pas tout ou rien, c'est pas aveugle.
Ce n'est pas j'ai confiance en tout et donc je peux déléguer tout.
On peut faire confiance à Apple et utiliser son API pour accéder à Internet sans pour autant faire confiance à Apple pour lui confier la gestion complete du suivi de la santé de l'utilisateur par exemple.
> Le gouvernement utilise les API mises à disposition par les constructeurs
> afin d’ajouter le traçage des contacts via ROBERT.
Et l'ironie c'est que Apple (et elle seule) conteste que l'on puisse utiliser les API qu'elle met a disposition pour faire cela. D'où son choix unilatéral de mettre en veille l'app sur iPhone.
> par les constructeurs, ces derniers proposent une solution clés en main.
Après le début du projet. Et impliquant un changement majeure d'architecture et de souveraineté du diagnostique. Vous aimez bien l'oublier, ce point.
Ce n'est pas parce que pour vous c'est pas un point qu'il n'existe pour personne.
L'approche est statistique côté serveur dans StopCovid
> Et qui a l’avantage d’être protégé par le système d’exploitation.
Parce que l'OS du serveur, il protège rien, lui ?
> Et la réponse qu’ils ont, c’est « non, on n’utilisera pas vos API optimisées,
> on utilisez vos API génériques car on veut rester souverains ».... OK. Génies.
ouais, tout comme il serait logique de ne pas utiliser iCloud pour faire du stockage souverain. Pourtant, API optimisées, clés en main etc.
> C’est pas comme si la fiabilité était un pré-requis. En plus de la sécurité.
Et l'API EN a démontré une fiabilité supérieure ? Une absence de faille ?
@byte_order
> On peut faire confiance à Apple et utiliser son API pour accéder à Internet sans pour autant faire confiance à Apple pour lui confier la gestion complete du suivi de la santé de l'utilisateur par exemple.
Dans un cas, l’API est utilisée pour faire un diagnostic local et informer l’utilisateur de son diagnostic.
Dans l’autre cas, l’API est utilisée pour demander un diagnostic distant et informer l’utilisateur de son diagnostic.
Les informations sont les mêmes.
Et pour le diagnostic, l’algorithme est déterminé par les organismes de santé gouvernementaux.
(À moins que le projet d’Apple soit de tous nous faire mourir)
> Et l'ironie c'est que Apple (et elle seule) conteste que l'on puisse utiliser les API qu'elle met a disposition pour faire cela. D'où son choix unilatéral de mettre en veille l'app sur iPhone.
Ce n’est pas la vérité.
Depuis toujours, l’API Bluetooth sur iPhone est limitée pour éviter le traçage des utilisateurs. Question de vie privée.
Le gouvernement a demandé à casser cette sécurité. Bah non.
> Après le début du projet.
Le 10 avril.
Avant le vote européen pour une action commune.
Avant que les premières lignes de code ROBERT n’apparaissent.
D’ailleurs, les ex-ROBERT ont utilisé l’API EN. Sauf la France.
> Et impliquant un changement majeure d'architecture et de souveraineté du diagnostique. Vous aimez bien l'oublier, ce point.
Le diagnostic en V1 s’appuyait sur les travaux initiaux de DP-3T.
Le diagnostic en V2 a été réalisé en collaboration avec les organisations de santé.
Et paramétrable sur les points de divergence.
Chacun étant libre d’utiliser la V1 ou la V2.
> Parce que l'OS du serveur, il protège rien, lui ?
Pas d’une mauvaise architecture.
> ouais, tout comme il serait logique de ne pas utiliser iCloud pour faire du stockage souverain. Pourtant, API optimisées, clés en main etc.
Justement non.
Le principe de sécurité recommandé par Apple et Google est de tout décentraliser.
En gros, Apple et Google ne doivent pas avoir accès aux données d’échanges de clés.
Mais ils recommandent aussi de séparer les serveurs et les intervenants entre le serveur qui échanges les clés et le serveur qui gère les codes au moment du diagnostic.
Comme ça, aucun prestataire douteux ne peut remonter la chaîne.
> Et l'API EN a démontré une fiabilité supérieure ?
Le système EN n’a pas connu d’interruption.
Logique car il fonctionne sur les appareils. Il a juste besoin de récupérer des clés toutes les 24h. Une interruption ponctuelle ne pénalise pas.
Le serveur ROBERT est tombé après trop de demandes d’activation.
Voilà.
@FloMo
> Dans l’autre cas, l’API est utilisée pour demander un diagnostic distant
> et informer l’utilisateur de son diagnostic.
C'est faux. L'API est utilisée pour transmettre des données en HTTPS. L'API ne voit pas "une demande de diagnostic", elle voit des octets, point. Qu'elle ne peut pas distinguer de tous les autres types de données qu'elle voit passer, sauf hack explicite de l'API.
> Et pour le diagnostic, l’algorithme est déterminé par les organismes
> de santé gouvernementaux.
C'est faux.
L'algorithme est derrière l'API, inaccessible sauf à Apple et à Google.
Ce sont les maigres paramètres de cet algorithme qui ont été déterminé avec les organismes, mais l'algo, lui, est bien implémenté et sous contrôle que de Apple et Google.
S'ils veulent modifier l'algo sans le dire, les organismes de santé ne pourront pas le voir.
> Les informations sont les mêmes.
Non, justement parce que l'API EN limite de facto aux seuls paramètres supportés en entrée de l'algo les informations utilisables.
> Depuis toujours, l’API Bluetooth sur iPhone est limitée pour éviter le traçage
> des utilisateurs. Question de vie privée.
Et jusqu'à iOS 14, *pourtant*, on pouvait utiliser l'API pour maintenir éveillé des apps sur appareils, y compris uniquement que des iPhones.
Question de contrôle, surtout. Derrière, y'a surtout le monopole de AirDrop et 2-3 autres protocoles proprio que Apple ne souhaite pas être exposé à la concurrence.
Quand il s'agit de protéger la vie privée des chinois ou ses intérêts financiers, elle choisi pas la vie privée, hein. Faut arrêter l'hypocrisie.
> Le 10 avril.
> Avant le vote européen pour une action commune.
> Avant que les premières lignes de code ROBERT n’apparaissent.
Apparaissent != existent.
> D’ailleurs, les ex-ROBERT ont utilisé l’API EN. Sauf la France.
Et ? En quoi cela prouve que le développement de StopCovid n'était pas démarré déjà ?
@byte_order
> C'est faux. L'API est utilisée pour transmettre des données en HTTPS.
Au final, c’est l’API « américaine » qui transmet les données en clair à l’app.
> C'est faux.
> L'algorithme est derrière l'API, inaccessible sauf à Apple et à Google.
Tous les algorithmes utilisés s’appuient sur des travaux scientifiques. Ce n’est pas de la magie.
Quel est l’interêt d’implémenter un algorithme qui fonctionne mal ???
> Les informations sont les mêmes.
Non, justement parce que l'API EN limite de facto aux seuls paramètres supportés en entrée de l'algo les informations utilisables.
> Et jusqu'à iOS 14, pourtant, on pouvait utiliser l'API pour maintenir éveillé des apps sur appareils, y compris uniquement que des iPhones.
C’est faux. On l’a vérifié sur iOS 12 et 13 avec les anciennes versions de StopCovid.
Ça n’a jamais fonctionné. Jamais.
> Apparaissent != existent.
Ça s’applique dans les deux cas.
Pour EN comme pour ROBERT.
Sauf qu’il y en a un qui a sorti les spécifications le 10 avril.
Et l’autre le 13. (Upload des specs le 18)
> Et ? En quoi cela prouve que le développement de StopCovid n'était pas démarré déjà ?
Les spécifications n’étaient pas terminées.
L’en-tête du code de StopCovid date du 7 avril.
(Specs terminées le 18 avril)
L’en-tête de la partie serveur date du 23 avril.
L’en-tête de la partie Bluetooth date du 30 avril.
Donc le 10 avril, à l’annonce de EN, il n’y avait pas grand-chose d’autres qu’une coquille vide.
@FloMo
> Au final, c’est l’API « américaine » qui transmet les données en clair à l’app.
Sans savoir ce qu'elles représentent.
Sans imposer ce qu'elles peuvent représenter, ni leurs évolutions.
Dans vos devs, vous accepteriez de devoir utiliser une API pour communiquer avec un serveur distant (ou un autre appareil quelconque) qui vous impose une format de données imposés !?
> Tous les algorithmes utilisés s’appuient sur des travaux scientifiques.
> Ce n’est pas de la magie.
Des algos qui font justement objet de travaux scientifiques en ce moment même !
Et qu'il faut pouvoir ajuster très rapidement sur un parc très important.
Hors vous ne contrôlez pas à quelle rapidité une MAJ s'installera sur les appareils.
Tandis que si l'algo sensible est côté serveur, sa correction ou amélioration est sous votre contrôle et s'applique à tout le monde d'un coup très rapidement.
> Quel est l’interêt d’implémenter un algorithme qui fonctionne mal ???
Quel est l'intérêt de pouvoir changer l'implémentation d'un algorithme !?
Sérieusement, vous posez la question ?!
Un exemple :
https://www.dailymail.co.uk/sciencetech/article-8904855/NHS-Covid-19-contact
> C’est faux. On l’a vérifié sur iOS 12 et 13 avec les anciennes versions de StopCovid.
> Ça n’a jamais fonctionné. Jamais.
Ah, ok. N'ayant voulu payé pour accéder à votre article, je l'ignorais.
La root cause reste Apple.
> Ça s’applique dans les deux cas.
> Pour EN comme pour ROBERT.
> Sauf qu’il y en a un qui a sorti les spécifications le 10 avril.
> Et l’autre le 13. (Upload des specs le 18)
Et ? Y'a violation de l'ordre d'arrivée par l'état français, c'est ça l'idée !?
> Les spécifications n’étaient pas terminées.
Le cycle en V c'est fini, hein.
> Donc le 10 avril, à l’annonce de EN, il n’y avait pas grand-chose d’autres
> qu’une coquille vide.
Y'avait pas non plus de version de Android et de iOS avec l'API EN disponible pour que des devs puissent avancer.
@byte_order
On va commencer par un « bonjour 🙂 »
> Sans savoir ce qu'elles représentent.
> Sans imposer ce qu'elles peuvent représenter, ni leurs évolutions.
Comment ils font pour bloquer le protocole EN depuis l’API Bluetooth générique ? Ils regardent le code service. Alors que le protocole Bluetooth est chiffré. CQFD.
> Dans vos devs, vous accepteriez de devoir utiliser une API pour communiquer avec un serveur distant (ou un autre appareil quelconque) qui vous impose une format de données imposés !?
C’est systématiquement le cas. Et ça me va bien.
C’est le protocole HTTP, sur une stack TCP/IP. En règle générale.
Les données sont soit en JSON, soit autre chose.
Et le schéma est imposé par le service web.
> Des algos qui font justement objet de travaux scientifiques en ce moment même !
> Et qu'il faut pouvoir ajuster très rapidement sur un parc très important.
> Hors vous ne contrôlez pas à quelle rapidité une MAJ s'installera sur les appareils.
La base de l’algorithme est intégrée au système. Déployée à grande vitesse.
Et le paramétrage peut être fait depuis un serveur.
Ils n’inventent pas un algorithme toutes les 2 semaines.
> Quel est l'intérêt de pouvoir changer l'implémentation d'un algorithme !?
> Sérieusement, vous posez la question ?!
NHS n’a pas changé l’algorithme du diagnostic vu que c’est EN qui est utilisé.
Et pourtant, le correctif a fonctionné.
>> C’est faux. On l’a vérifié sur iOS 12 et 13 avec les anciennes versions de StopCovid.
>> Ça n’a jamais fonctionné. Jamais.
> Ah, ok. N'ayant voulu payé pour accéder à votre article, je l'ignorais.
> La root cause reste Apple.
On est d’accord qu’on a entendu le contraire ici même. Dans les commentaires qui seraient venus des équipes d’Orange.
> Et ? Y'a violation de l'ordre d'arrivée par l'état français, c'est ça l'idée !?
Juste enième mensonge côté gouvernement en affirmant que les développements de StopCovid étaient bien trop avancés pour utiliser EN.
>> Les spécifications n’étaient pas terminées.
> Le cycle en V c'est fini, hein.
Si seulement. 😅
Ces spécifications là sont nécessaires au développement. Ce ne sont pas des spécifications d’interface utilisateur mais bien de la pure technique.
>> Donc le 10 avril, à l’annonce de EN, il n’y avait pas grand-chose d’autres
>> qu’une coquille vide.
> Y'avait pas non plus de version de Android et de iOS avec l'API EN disponible pour que des devs puissent avancer.
Oui et non.
La version alpha officielle du SDK DP-3T qui a servi de base à EN est sortie le 14 avril.
Dans le même temps, dès l’annonce d’Apple, les premières implémentations open-source sont apparues sur GitHub.
Par exemple, TracePrivately, sorti le 17 avril, est une app qui intégrait 100 % de l’implémentation EN, même la partie serveur. Une app complète en somme.
Il a juste fallu faire évoluer les appels d’API, mais la mécanique était en place.
StopCovid n’avait rien à ce moment-là.
Ils pouvaient s’appuyer sur ce projet sans soucis.
Ils avaient une solution fonctionnelle à disposition. Compatible avec les autres pays européens (voté le 17 avril). Approuvée par les chercheurs en sécurité du monde entier. Intégrée en natif par les constructeurs. Et donc optimisée sur tous les appareils. En plus de fonctionner sur iOS en tâche de fond.
Mais non. La souveraineté était le credo politique de Cédric O. 2-3 mensonges et ça passerait comme une lettre à la poste.
@FloMo
> Le principe de sécurité recommandé par Apple et Google est de tout décentraliser.
Ah ouais, donc iCloud est décentralisé ?
Ou Apple n'incite nullement à utiliser iCloud, ni l'AppleID ?
ApplePay, c'est décentralisé comme solution ?
L'AppStore, approche décentralisée ????
Et ne nous dites pas que jamais Apple n'a utilisé l'argument de la sécurité pour défendre ses solutions ApplePay, AppStore, Sign-in With Apple (parlez en aux joueurs de Fortnite, tiens...), toutes décentralisées hein, bien sur...
>> Et l'API EN a démontré une fiabilité supérieure ?
> Le système EN n’a pas connu d’interruption.
https://www.igen.fr/app-store/2020/07/lequivalent-allemand-de-stopcovid-cessait-de-fonctionner-en-tache-de-fond-116455
> Logique car il fonctionne sur les appareils.
Sauf que y'a bien eu des dysfonctionnements !
Y'a rien de logique, si ce n'est que c'est du code, des protocoles, et donc faillible. Votre biais "c'est sur l'iphone, c'est Apple donc c'est mieux" transpire ici plus qu'autre chose.
> Il a juste besoin de récupérer des clés toutes les 24h. Une interruption
> ponctuelle ne pénalise pas.
Ponctuelle, aka quelques heures, non. De plusieurs jours, dans le cadre d'une lutte contre un virus avec une période d'incubation d'une semaine, *si*.
L'absence de surveillance quand y'a *que* des iphones *tous* en veille a côté de vous ne pénalise pas beaucoup non plus, au passage : c'est rare à l'extérieur, tout comme il est rare que aucune personne ne soit en train d'utiliser son smartphone.
Et pourtant, cela vous semble plus grave que d'avoir aucun donnée pendant plusieurs jours pour faire des diagnostics d'exposition !
> Le serveur ROBERT est tombé après trop de demandes d’activation.
Et a été mis à l'échelle depuis. Combien de temps d'absence ? 24h, même pas, c'était corrigé dans la soirée. 24h c'est pas pénalisant quand c'est EN mais cela l'est quand c'est la solution que vous rejetez !?
Hypocrisie.
@byte_order
Je ne vais pas me fatiguer à ré-expliquer.
Vous êtes convaincu de votre truc.
Vérifiez vos sources quand même. Par principe.
Il y a eu pas mal de commentaires ici faisant croire que Orange avait mis au point un système interoperable avec EN.
Qu’ils avaient un algorithme Bluetooth que Apple voulait leur voler et qu’ils voulaient porter plainte contre Apple qui l’aurait utilisé dans iOS 14.
Et j’en passe.
Tout ceci a été démonté par les faits. L’histoire du Bluetooth étant un énorme gag : on n’aurait pas vérifié, on y croyait nous-mêmes tellement c’est énorme.
Votre temps sera mieux utilisé à vérifier vos sources qu’à argumenter.
Mais c’est bien aussi de débattre. 😁
Mais là, c’est plus de la foi que du factuel.
Bonne continuation.
@FloMo
Le gouvernement utilise les API mises à disposition par les constructeurs afin d’ajouter le traçage des contacts via ROBERT.
La réponse qu’ils ont, c’est « non, on n’utilisera pas vos API optimisées, on utilisez vos API génériques car on veut rester souverains ».... OK. Génies.
Eh oui ! C'est ce que je me dis depuis le début : la solution retenue par le gouvernement français n'est pas souveraine pour un sou. Pour qu'elle le fût, il eut fallu aller jusqu'au bout et développer une app qui ne fonctionne qu'avec les téléphones français. Là c'est cohérent !!!
Belle discussion technique en tout cas ce fil 😃
@FloMo
> Et clairement, ROBERT n’a pas été conçu pour être sécurisé.
Bien sûr que si.
On peut débattre des failles, on peut comparer avec d'autres protocoles, mais prétendre qu'à aucun moment la conception du protocole ROBERT n'a pris en compte la sécurité, c'est carrément mensongé, voir de la désinformation compte tenu de votre carte de "pigiste".
La sécurité n'est pas parfaite. Jamais.
L'API EN aussi a des défauts, par exemple : une faille a bien été découverte en septembre sur la traçabilité via le changement d'adresse MAC BT et la rotation des clés, non synchrones.
> Si on n’a pas confiance dans la technologie d’un pays, on ne l’utilise pas.
Tout à fait. C'est tout à fait valable pour StopCovid, donc.
Ou l'on revient, encore une fois, qu'à une simple question de confiance.
> L’utiliser en disant « on n’a pas confiance en eux » est risible.
Pas plus que de croire qu'on peut avoir plus confiance dans un pays étranger sur ce qu'il ne fera théoriquement jamais.
Encore une fois, cela débouche toujours sur une question de confiance.
En particulier, sur le nombre d'acteurs distincts en qui on choisi de faire confiance.
Et, moi, dans ce type de situation, je préfère *toujours* quand y'a plusieurs acteurs, car la diversité de facto limite l'échelle des conséquences.
Si StopCovid est piraté ou détourné par un gouvernement, les conséquences seraient que françaises. Si l'APi EN est piratée ou détournée par un gouvernement, les conséquences seraient multinationales.
> Le principe Nº1 de la sécurité mobile est :
> sortez le moins d’informations possibles du smartphone. Là, on fait l’inverse.
Vous évoquez le risque de panique. Nul besoin que des données fuitent pour engendrer une panique. Une maj d'OS ou d'app qui affiche des fausses notifications sur les évolutions de cours de bourses, sur un faux filtrage soit-disant gouvernemental de tels usages des smartphones et, ici, des fausses notifications d'exposition covid suffirait.
@byte_order
Ça suffit tu n’y connais rien. Aussi bien sur ce sujet que sur les sujets connexes comme l’état de la réglementation sur la surveillance des citoyens.
@FloMo
« Et que par une malicieuse astuce le système est dupé et envoie des centaines de milliers voir des millions de fausses notifications. Quelles seraient les conséquences au niveau des hôpitaux, des entreprises et des centres de tests ? »
En effet cela peut avoir des conséquences.
Exemple récent avec l’app anglaise : https://www.theguardian.com/world/2020/nov/02/fault-in-nhs-covid-app-meant-thousands-at-risk-did-not-quarantine?
@John McClane
En l’occurrence, c’est l’effet inverse qui s’est produit : des notifications pas assez alarmantes. Les conséquences sont différentes, mais pas forcément moindres. C’est comme s’ils n’avaient pas d’app.
Le problème a heureusement été réglé. Mais c’est dommage car cela aurait pu démontrer l’efficacité du procédé. Ou pas car personne ne se plaint quand ça fonctionne et les notifications ne peuvent être comptabilisées.
@FloMo
Oui en effet c’est l’effet inverse dans ce cas précis.
En tout cas j’ai ré-installé AntiCovid en lisant votre article, tout simplement car on peut à présent désactiver les infos anxiogènes quotidiennes qu’elle envoyait ! C’était le gros point négatif pour moi, je l’avais supprimée à cause de ça.
PS : et le nouveau générateur de dérogation est top aussi, donc oui c’est une belle mise à jour.
@FloMo
Imaginons un instant que...
Okay, d'accord. On peut tout imaginer quand on veut tuer son chien. Vous n'aimez pas cette application, parce qu'elle n'utilise pas les API des multinationales, parce qu'il y a un problème personnel avec quelqu'un, une histoire de famille ou d'héritage, ou une querelle de place de parking, bref, vous avez vos propres raisons. Ça nous regarde pas.
Mais alors faites un Site dédié contre l'application et qu'on en finisse.
@Ali Ibn Bachir Le Gros
J’ai une liste longue comme le bras de mensonges qu’on a entendu depuis le début.
2-3 qui me viennent :
- ca marche très bien sur iPhone : on a démontré le contraire et ça nous a été confirmé
- EN est anti-européen : il y a eu un vote le 17 avril qui favorisait la solution décentralisée
- EN est une boîte noire : il y a des specs open-source depuis le début, qui ont permis de concevoir les versions Raspberry Pi disponibles sur GitHub
- StopCovid a un prototype fonctionnel (ie en avril) : le code source à date démontre le contraire
- EN fait transiter un diagnostic médical entre les appareils : le diagnostic est effectué sur l’appareil
- ROBERT est interoperable avec les autres pays : en fait non
- etc.
Le sujet, c’est qu’on ne peut pas laisser passer des mensonges.
Après, c’est évident qu’il est trop tard pour revenir en arrière. Et qu’en termes d’image, ça ne le ferait pas. Il y a un électorat et une confiance à maintenir. On s’en fout qu’ils laissent une app dont la partie traçage ne fonctionne pas vraiment et est une passoire niveau sécurité. C’est leur responsabilité.
Mais le principe de liberté d’expression nous oblige. Quand il y a mensonge, la vérité doit être expliquée, preuves à l’appui.
Et ça n’a clairement aucun impact.
Le pouvoir gouvernemental aura toujours le dernier mot. Ils sont entraînés à la joute verbale et donc à l’exercice de mauvaise foi. C’est leur job de ne jamais admettre.
Ce n’est pas le sujet. Quand il y a un mensonge et qu’on peut le démontrer incontestablement, on doit. C’est tout.
@FloMo
> - EN est une boîte noire : il y a des specs open-source depuis le début,
Specifications != code binaire.
Le code binaire qui est embarqué dans iOS ou Android, c'est bien une boîte noire, et il est impossible de le remplacer par celui construit à partir des specs et du code source publié pour vérifier qu'il n'y a pas de différence.
Par contre, on peut installer une app TousAntiCovid reconstruite depuis les sources et l'utiliser à la place de celle dispo sur le PlayStore. Pour la version iOS, c'est possible mais moins facile mais ça c'est typique de iOS (on doit faire confiance aveugle à Apple, pas le choix d'un sideloading ou de canaux de distributions hors de son contrôle).
Côté serveur, là, de toute façon, c'est pareil : dans les 2 cas on ne peut pas vérifier ce qui est réellement déployer. Tout comme on ne peut pas vérifier si y'a une conservation discrete d'info dans l’implémentation de l'API EN
> - StopCovid a un prototype fonctionnel (ie en avril) : le code source à date
> démontre le contraire
La date d'un push dans git n'est pas une preuve de la date de conception d'un prototype.
> Quand il y a un mensonge et qu’on peut le démontrer incontestablement, on doit.
> C’est tout.
Très bien. La démontrastation que le code source publié de l'API est bien celui embarqué dans iOS, vous le démontrez quand ?
@byte_order
> Specifications != code binaire.
Si on réussit à communiquer avec un Raspberry Pi, c’est que ça fonctionne.
> Par contre, on peut installer une app TousAntiCovid reconstruite depuis les sources et l'utiliser à la place de celle dispo sur le PlayStore. Pour la version iOS, c'est possible mais moins facile mais ça c'est typique de iOS (on doit faire confiance aveugle à Apple, pas le choix d'un sideloading ou de canaux de distributions hors de son contrôle).
J’ai en effet buildé l’app. Et je l’ai fait communiquer avec une version App Store et une version PlayStore.
L’objectif était de comprendre ce fameux système Bluetooth que Apple voulait voler à Orange (J’ai lu ça dans les commentaires) : en fait, ça ne fonctionne pas entre iPhone en arrière-plan.
On a donc pu vérifier que ça ne fonctionne pas.
Et ça nous a été confirmé par les principaux intéressés qui pourtant affirmaient que ça fonctionnait très bien. Bref.
Et j’ai pu par la même occasion valider le fait qu’il y a une sacrée faille dans le protocole ROBERT.
Donc tout ça a été mis en open-source en se disant : « De toutes manières, personne n’ira vérifier. On peut dire ce qu’on veut. »
Et presque tout le monde a marché. Presque.
> Côté serveur, là, de toute façon, c'est pareil : dans les 2 cas on ne peut pas vérifier ce qui est réellement déployer.
Exact. Côté client aussi. Même en décompilant le code Android.
Mais je ne vois pas l’interêt.
> Tout comme on ne peut pas vérifier si y'a une conservation discrete d'info dans l’implémentation de l'API EN
Exact. Je ne vois pas l’interêt pour le constructeur qui a déjà accès à bien plus d’infos. À commencer par l’accès au GPS et la stack Bluetooth bas niveau. Et le GSM. Et le contenu affiché à l’écran. Etc.
> La date d'un push dans git n'est pas une preuve de la date de conception d'un prototype.
Si le prototype est fonctionnel, on envoie au moins du code fonctionnel. Même partiel.
Là, on avait juste 3 pauvres fichiers Swift.
> Très bien. La démontrastation que le code source publié de l'API est bien celui embarqué dans iOS, vous le démontrez quand ?
On ne peut pas. Tout comme on ne peut démontrer que le code de ROBERT n’est pas un code autre.
On pourrait se dire : « Mais pourquoi ROBERT fait-il du pinning SSL ? Qui a-t-il à cacher ? »
Et bien non : on sait que c’est une mesure de sécurité essentielle.
Et franchement, on a confiance sur ce point. On ne dit pas que le gouvernement veut nuire. On dit que ses chefaillons mentent sur le fonctionnement réel de ROBERT.
Peu importe qu’ils fassent des erreurs : tout le monde en fait.
Mais il ne faut pas les cacher sous le tapis. Pas dans une démocratie. Pas quand il y a un risque connu pour la sécurité nationale.
@FloMo
> Si on réussit à communiquer avec un Raspberry Pi, c’est que ça fonctionne.
Non. La communication, c'est pas l'implémentation de l'API..
On peut communiquer en TCP/IP entre 2 machines, cela ne signifie nullement que l'implémentation de la machine 1 est la même que celle de la machine 2, juste qu'elles sont interopérables.
> en fait, ça ne fonctionne pas entre iPhone en arrière-plan.
Fonctionne *plus*.
> On a donc pu vérifier que ça ne fonctionne pas.
Entre iPhone en arrière plan.
L'app existe aussi en version Android. Qui ne souffre pas de ce dysfonctionnement.
Y'a pas que iOS dans la vie. Vous vous servez du handicap de la version iOS, handicap qui est intégralement dû à la position de control freak d'Apple et rien d'autre (même l'utilisateur n' pas son mot à dire), pour dire que l'app en général est mal foutue.
Par ailleurs j'ai pas souvenir qu'il ait été dit que sans smartphone Android dans les parages cela marcherait quand même très bien. J'ai souvenir justement qu'il a été dit que cela marcherait suffisamment dans les cas d'usage identifiés comme utiles car il y aurait statistiquement très souvent un smartphone Android dans les parages également.
Joli nombrilisme.
> Côté client aussi. Même en décompilant le code Android.
Ben non.
Vous venez exactement de le faire : vous avez tester une version compilée par vos soins, qui fonctionne avec le serveur pourtant. Vous avez bien été en mesure de vérifier que le code publié fonctionnait avec le serveur et avec les autres apps officielles !
Mis à part le blocage d'Apple sur le mode en arrière plan qui ne concerne que iOS et que le fait d'avoir accepter depuis si/trop longtemps de tout déléguer à Apple, un choix que les utilisateurs iOS, minoritaires en France ne vous en déplaise, doivent assumer.
Perso, j'aurais été à leur place, j'aurais carrément annoncer zero support des iphones, faute de volontarisme d'Apple qui préfère protéger sa chasse gardée à tout prix.
@byte_order
>> en fait, ça ne fonctionne pas entre iPhone en arrière-plan.
> Fonctionne plus.
Ça n’a jamais fonctionné. On la vérifié avec toutes les versions de l’app, sur plusieurs versions de iOS.
>> Entre iPhone en arrière plan.
> L'app existe aussi en version Android. Qui ne souffre pas de ce dysfonctionnement.
Le problème d’Android est différent.
Le signal Bluetooth est bien calibré pour quelques dizaines de modèles côté ROBERT.
Google a de son côté des accords avec les constructeurs qui lui ont permis de calibrer au moins des centaines de modèles.
Ça change tout dans la fiabilité du procédé.
> Par ailleurs j'ai pas souvenir qu'il ait été dit que sans smartphone Android dans les parages cela marcherait quand même très bien.
Cedric O a affirmé que ca fonctionnait très bien sur iPhone.
> Ben non.
> Vous venez exactement de le faire : vous avez tester une version compilée par vos soins, qui fonctionne avec le serveur pourtant. Vous avez bien été en mesure de vérifier que le code publié fonctionnait avec le serveur et avec les autres apps officielles !
Je suis incapable de savoir quelles informations sont envoyées.
> Mis à part le blocage d'Apple sur le mode en arrière plan qui ne concerne que iOS et que le fait d'avoir accepter depuis si/trop longtemps de tout déléguer à Apple, un choix que les utilisateurs iOS, minoritaires en France ne vous en déplaise, doivent assumer.
Minoritaires à 45 % environ. Les chiffres des 20/80 correspondent au web.
Et surtout, pour un fonctionnement optimal, il faut au moins du Bluetooth 4.2. Donc cette ouverture aux vieux iOS / Android va juste amener du bruit.
> Perso, j'aurais été à leur place, j'aurais carrément annoncer zero support des iphones, faute de volontarisme d'Apple qui préfère protéger sa chasse gardée à tout prix.
Perso, j’aurais pas ré-inventé une roue. Surtout pour la faire carrée.
@FloMo
> Et j’ai pu par la même occasion valider le fait qu’il y a une sacrée faille
> dans le protocole ROBERT.
Publiée où ?
@FloMo
> Exact. Je ne vois pas l’interêt pour le constructeur qui a déjà accès à bien plus d’infos.
> À commencer par l’accès au GPS et la stack Bluetooth bas niveau. Et le GSM.
> Et le contenu affiché à l’écran. Etc.
Le constructeur, non.
Mais son gouvernement, lui...
Cf Stuxnet. Un gouvernement a parfaitement su exploiter des failles dans un OS pour avoir une action à distance sur des plateformes à distance afin d'engendrer des dysfonctionnements majeurs dans un pays étranger
Quelle différence ici ?
Le nom du constructeur et de l'OS change, mais c'est tout.
Vous parlez de sécurité, de risque. Ce risque à la Stuxnet est tout autant existant - l'histoire est là pour l'attester ! - que celui d'un sombre hacker isolé ayant un agenda individuel étrange. En pratique, les grosses cyber-attaques sont quasiment toutes pilotées par des groupes reliables à des états.
> Si le prototype est fonctionnel, on envoie au moins du code fonctionnel.
Qui ça "on" ? C'est une loi écrite où ?
La décision de rendre open source n'était pas encore actée à l'époque, il me semble.
On est plus dans un dépot servant de plateforme d'échange entre personnes déjà impliquées.
> On ne peut pas. Tout comme on ne peut démontrer que le code de ROBERT
> n’est pas un code autre.
Sauf qu'on *peut* utiliser une autre implémentation du protocole ROBERT, alors qu'on ne peut pas utiliser sur smartphone une autre implémentation du protocole EN que celle de l'OS.
> Et franchement, on a confiance sur ce point. On ne dit pas que le gouvernement
> veut nuire. On dit que ses chefaillons mentent sur le fonctionnement réel de ROBERT.
Le plus probable, c'est qu'ils y entravent que dalle, surtout.
> il ne faut pas les cacher sous le tapis. Pas dans une démocratie.
> Pas quand il y a un risque connu pour la sécurité nationale.
Le risque de dépendre d'une implémentation étrangère non contrôlable est aussi un risque connu. Vous auriez arbitré autrement, mais il existe.
@byte_order
> Le constructeur, non.
> Mais son gouvernement, lui...
Il fera comme pour Stuxnet : il demandera l’accès à tout. Pas seulement à des pseudonymes échangés.
>> Si le prototype est fonctionnel, on envoie au moins du code fonctionnel.
> Qui ça "on" ? C'est une loi écrite où ?
> La décision de rendre open source n'était pas encore actée à l'époque, il me semble.
> On est plus dans un dépot servant de plateforme d'échange entre personnes déjà impliquées.
J’ai vu le code : c’est juste du remplissage histoire de dire « on a quelque-chose ».
Il n’y avait même pas le projet Xcode !
> Sauf qu'on peut utiliser une autre implémentation du protocole ROBERT, alors qu'on ne peut pas utiliser sur smartphone une autre implémentation du protocole EN que celle de l'OS.
C’est en effet sur ça que s’appuie la faille de sécurité.
> Et franchement, on a confiance sur ce point. On ne dit pas que le gouvernement
> veut nuire. On dit que ses chefaillons mentent sur le fonctionnement réel de ROBERT.
Le plus probable, c'est qu'ils y entravent que dalle, surtout.
> Le risque de dépendre d'une implémentation étrangère non contrôlable est aussi un risque connu. Vous auriez arbitré autrement, mais il existe.
Alors qu’aujourd’hui, on dépend toujours de iOS et Android. Mais on a en plus des infos qui transitent un max via le web. Génial.
@FloMo
Tout comme le serveur qui centralise les cas positifs dans les stopcovid basés sur l’api de Google peut être dupé et envoyer des centaines de milliers de faux cas positifs 💁♀️
@Adodane
La remarque est bonne mais non.
Car le diagnostic est fait sur l’appareil. Il s’appuie donc uniquement sur les pseudonymes réellement reçus. Ils sont cloisonnés par le framework et ne sortent jamais. Seules les clés de signature transitent. Donc le seul transport autorisé est Bluetooth.
Alors que le serveur ROBERT considère que les pseudonymes qu’il reçoit ont été reçus en Bluetooth par un même appareil.
Même si c’est faux. Il ne peut pas le savoir.
@FloMo
Non le diagnostique est fait par un professionnel de santé, la personne positive doit ensuite se déclarer dans l’appli, et tout cela est centralisé dans un serveur central qui envoie ensuite le pseudo marqué comme positif ( enfin c’est l’appli qui récupère les pseudos positif ).
Ce serveur central peut aussi être piraté.
@Adodane
L’Allemagne par exemple injecte de fausses clés de diagnostic. Afin d’éviter de croiser les informations.
Puisque le pseudonyme correspondant à la clé n’existe pas sur l’appareil de l’utilisateur, il est ignoré.
Et le risque au niveau des codes est présents uniquement si les serveurs de code et de clés de diagnostic sont gérés par la même structure.
D’où la recommandation de bien les cloisonner.
@FloMo
Les pseudos sont fournis par le serveur Robert au moment de l’installation, donc si ils sont faux à un moment ça va coincer.
Les pseudos cas contact sont aussi déterminés par l’application Robert et ensuite envoyés sur le serveur pour prévenir les propriétaires des pseudos.
@Adodane
On peut tromper le système en utilisant uniquement des vrais pseudonymes.
C’est là tout le problème.
@FloMo
C’est à dire ?
Pages