Immuni : l'Italie lance une des premières apps de traçage des contacts avec l'API d'Apple et Google
Une des premières applications à tirer partie de l'API Exposure Notification développée par Apple et Google est italienne1. Immuni, fraîchement disponible sur l'App Store, est éditée par le ministère de la Santé du pays. On peut la télécharger sur l'App Store français, et si on regrette que le mode sombre ne soit pas supporté, saluons la localisation dans la langue de Molière. On n'ira cependant pas bien loin avec Immuni, en tout cas je n'ai pas pu dépasser l'activation des notifications.
L'application explique son fonctionnement dans un langage facile à comprendre. Chaque smartphone est associé à un code généré aléatoirement qui ne contient aucune information à propos de l'utilisateur ou de son appareil. Ce code change plusieurs fois par heure. Lors d'un contact, les smartphones s'échangent leurs codes via Bluetooth, mais l'application ne connait l'identité de personne et ne sait pas où la rencontre a eu lieu (pas de géolocalisation GPS).
Quand une personne est testée positive, elle est libre de partager ses codes téléchargés depuis un serveur qui contient les codes aléatoires transmis par les utilisateurs les jours précédents pour les mettre à disposition des autres personnes. L'application vérifie périodiquement les codes présents sur le serveur et les compare avec ceux enregistrés sur le smartphone. Cela permet à Immuni de déterminer si on a été exposé à une potentielle infection.
En cas de contact avec une personne contaminée, l'app avertira l'utilisateur et indiquera la marche à suivre pour éviter de propager le virus (test, quarantaine). Les données restent confidentielles, assure l'application.
L'Italie n'est pas le seul pays à utiliser l'API d'Apple et de Google. La Suisse, la Lettonie et l'Allemagne s'en serviront également pour leurs propres applications. StopCovid, l'app française qui utilise une toute autre méthode pour le suivi des contacts, sera disponible ce mardi à midi.
-
L'Italie a été battue sur le fil par la Lettonie, qui a mis en ligne il y a quelques jours Apturi Covid. ↩︎
Alors que l’épidémie est finie..
@marveyhumus
Je ne serais pas aussi optimiste
@marveyhumus
On sait pas encore et puis ça pourra servir pour la saison 2 ou la prochaine pandémie. #ToujoursOptimiste 😅
@marveyhumus
Rendez-vous cet automne !
@marveyhumus
Oui enfin les Chinois ont mis tout récemment 100 millions de personnes en confinement dans les provinces du Nord, ce dont on ne parle jamais ici.
Temps d’incubation beaucoup plus long (jusqu’à 25 jours sans symptômes), pas de fièvre et le virus attaque uniquement les poumons. Je ne dirais donc pas que c’est fini... Aurons-nous quelque chose de similaire en France ? Je n’en sais rien mais prudence avant de chanter victoire.
@Zoupinou
Merci de nous indiquer des sources...
@Paul Position
https://www.japantimes.co.jp/news/2020/05/20/asia-pacific/science-health-asia-pacific/china-new-coronavirus-outbreak/ par exemple
@marveyhumus
Quand l’épidémie battait son plein, il y avait d’autres priorités.
D’autres pays se sont mis en consortium et s’appuient sur les travaux autrichiens et suisses, comme la Belgique représentée par Bart Preneel (https://www.esat.kuleuven.be/cosic/news/bart-preneel-on-contact-tracing-corona-app-in-de-afspraak-on-belgian-television/).
Si on installe tous cette app, pas besoin de stop covid 😅
beaucoup de gens ne savent pas comment installer une app. ou ils ne seront jamais au courant qu'une app pour le covid existe.
on est très peu nous qu'on suit des sites technologiques.
Je ne comprends plus rien... je croyais que la solution Google/Apple était décentralisée et là on nous parle d'un serveur contenant les codes des smartphones dont le propriétaire s' est déclaré positif "L'application vérifie périodiquement les codes présents sur le serveur et les compare avec ceux enregistrés sur le smartphone. Cela permet à Immuni de déterminer si on a été exposé à une potentielle infection."
C'est exactement le même comportement que celui décrit pour StopCovid en France:
Lorsqu'un utilisateur installe l'application, un serveur central lui crée une clé cryptographique aléatoire. Tous les jours, l'application va diffuser autour d'elle via le Bluetooth des clés temporaires, dérivées de la clé principale et changées régulièrement. Dans le même temps, elle va stocker les clés temporaires émises par les autres applications installées sur des téléphones se trouvant à moins d'un mètre et pendant quinze minutes.
Lorsque l'utilisateur de l'application est diagnostiqué positif au Sars-Cov-2, on lui remet un code unique à insérer dans l'application. Cette dernière envoie alors au serveur central la liste des clés temporaires qu'elle a enregistrées (c'est-à-dire les « pseudos » des personnes avec qui le malade a été en contact). Le serveur avertit ensuite ces personnes par une notification.
Quelque chose m'échappe? C'est quoi la différence entre les 2 approches?
mais sans un serveur je vois pas comment une app peut partager les données. ce qui change dans cette app italienne est que le décideur final (de partager ou pas l'info) est l'utilisateur et pas celui qui gère le serveur.
et puis celui qui sera touché il va avoir besoin d'un médecin de tout façon et son identité sera déclaré même en utilisant aucun app.
@marenostrum
Probablement ! Mais alors pourquoi tout ce débat centralisé / décentralisé si dans les 2 cas on a un serveur central qui assure exactement les mêmes fonctions ...
y a surement des différences, pas encore claires pour le moment. il faut les utiliser pour les comparer. peut-être que la solution française n'a pas besoin de donner la confirmation, elle peut te considérer malades (ou personne à risque) si seulement t'as été en contact prolongé avec un malade. tandis que l'app italienne non, parce que ils ne le savent pas si on confirme pas.
"Quand une personne est testée positive, elle est libre de partager ses codes téléchargés depuis un serveur qui contient les codes aléatoires transmis par les utilisateurs les jours précédents pour les mettre à disposition des autres personnes. "
@r e m y
Dans le cas de StopCovid, il y a un serveur qui effectue des traitements sur les données personnelles. Ces données sont sécurisées sur des serveurs Microsoft. Les traitements sont donc centralisés. L’avantage est qu’on peut faire des traitements d’intelligence artificielle plus facilement a priori.
Dans le cas de l’API Apple / Google, le serveur ne fait que fournir des fichiers de manière sécurisée.
Les fichiers en question sont des clés de chiffrement et des périodes de validité pour ces clés. L’information sensible est le pseudonyme chiffré qui reste sur le smartphone. Et le diagnostic effectué sur le smartphone. Les traitements sont donc décentralisés.
@FloMo
> Et le diagnostic effectué sur le smartphone.
Et dans les mains d'Apple et Google (et liés à leurs produits), puisque l'implémentation, propriétaire, de ce traitement fait partie de l'API.
> Les traitements sont donc décentralisés.
Les données le sont, le traitement, lui, est délégué à Apple et Google. Il se fait sur le smartphone (bien qu'en absence de transparence sur son implementation, on ne peut pas être certain), mais il est sous leur contrôle.
Si l'on veut prendre en compte une donnée comme, par exemple, le nombre moyen, médian, max, min de contacts (sains ou pas) durant les N derniers jours pour pondérer le risque d'exposition, ce n'est plus possible sans qu'ils soient d'accord.
Si l'on veut utiliser une autre plateforme qu'un smartphone, ce n'est plus possible.
Des points que vous avez rapidement ballayé, comme si c'était sans risque qu'un algo de diagnostic sanitaire, qui pourrait être utilisé pour d'autres épidémies, soit sous le contrôle d'entreprises étrangères...
@byte_order
Si on veut glisser là-dessus, les API utilisées par StopCovid côté smartphone sont celles d’Apple et Google.
Quel est l’intérêt des constructeurs d’exploiter ces données puisqu’ils ont déjà potentiellement accès a beaucoup plus d’informations nous concernant ? Ce sont eux qui conçoivent les systèmes des smartphones. Ils ont déjà tout.
Le fait d’effectuer le traitement dans un cloud permet de personnaliser. Mais personnaliser avec des données peu fiables, ça n’a pas d’intérêt. Enfin, je vois pas le truc.
Pour que ce soit efficace, et je crois que c’est ce qui est prévu, il faudrait que les citoyens volontaires acceptent de donner plus d’infos. Du genre, traitement médicamenteux, âge, etc. Mais ça nécessiterait une infrastructure bien plus sécurisée, chiffrée de bout en bout. Et pseudonymisée.
Sinon, la doc pour la diagnostic semble assez complète niveau paramétrages, dans la mesure ce qui est techniquement réalisable :
https://developer.apple.com/documentation/exposurenotification/enexposureconfiguration
Sachant que ce sont les autorités qui ont demandé ce paramétrage du fait du manque de consensus scientifique.
En l’état, ça fait le job et surtout sa préserve la vie privée vis-à-vis des dangers extérieurs. Si ça fonctionne (encore à vérifier), nul doute qu’il faudra aller plus loin. Mais déjà, il faut que ça fonctionne ailleurs que sur le papier.
Je suis sûr que d’ici là, si le procédé s’avère efficace, la France aura trouvé une excuse bidon pour rendre compatible l’app avec l’API fournie par défaut. Et je pense que c’est le jour où les autres pays auront un moyen sécurisé d’accéder à des données détaillées que la France voudra le mettre dans son propre cloud.
Si la France se bloque là-dessus, on fera de l’IA avec de la donnée non fiable du fait du signal Bluetooth moins bien géré. Et donc les résultats seront moins fiables que ceux de nos voisins.
Et avec de la bonne donnée (via API Bluetooth optimisée), une app bien conçue (comme elle l’est aujourd’hui) et notre savoir-faire... là, on pourra faire rayonner le talent français.
Talent qui a déjà été mis à l’épreuve au sein des équipes de l’API Google / Apple, ironiquement.
L’information recueillie est valable 14 jours avant d’être supprimée. Il a fallu 7 semaines pour concevoir toute l’app et son environnement. C’est ce qu’il a fallu pour les autres pays également. Donc c’est jouable.
@FloMo
> Si on veut glisser là-dessus, les API utilisées par StopCovid côté smartphone sont
> celles d’Apple et Google.
Mais elles n'ont rien d'exclusif. On trouve des API similaires sur d'autres plateformes. Y'a parfaitement moyen de faire une app StopCovid pour ordinateur ultramobile sous Windows, par exemple. Ou Linux. Ou pour Tyzen.
Y'a une différence entre s'appuyer sur des API techniques pour faire votre fonctionnalité et dépendre d'une API "métier". Hors, ici, l'API d'Apple/Google n'est pas une API technique, c'est une API qui réalise le coeur de la fonctionnalité : tracer les contacts et évaluer le risque d'exposition.
C'est comme de développeur un jeu en utilisant spécifiquement l'API Metal : votre jeu est de facto lié à Apple. Si à la place vous l'écrivez en Vulkan et le transposez sur les plateformes d'Apple via MoltenVK (ou utilisez un moteur de jeu multiplateformes - aucun n'est que Metal, sont pas fous !), le coeur de métier de votre travail n'est plus aussi dépendant d'une entreprise.
> Quel est l’intérêt des constructeurs d’exploiter ces données puisqu’ils ont déjà
> potentiellement accès a beaucoup plus d’informations nous concernant ?
Pas exploiter les données.
Exploiter la captivité d'un outil sur leurs plateformes.
Le fait qu'un outil de lutte contre les pandémies soit lié à une API propriétaire leur permettrait, par exemple, de refourguer une ancienne AppleWatch, largement amortie mais rebrandée pour l'occasion, et compatible avec l'API proprio.
Vous n'êtes pas assez naïf pour ne pas y voir un intérêt pour un constructeur...
> Ce sont eux qui conçoivent les systèmes des smartphones. Ils ont déjà tout.
Non. Bon nombre d'algo au coeur de la fonctionnalité des apps qui tournent sur leurs plateformes ne dépendent pas de la disponibilité d'une API "métier".
Elles dépendent d'API techniques, comme le réseau IP, BT, l'entrée/sortie audio, mais pas d'une API métier qui est au coeur de la fonctionnalité.
@byte_order
D’ailleurs, à propos d’ultra-mobilité et de GNU/Linux, les premiers prototypes compatibles avec les API Apple / Google sont de sortie et sont compatibles Raspberry Pi Zero W. J’ai fait un billet sur le sujet : ça me donne l’occasion de sortir l’anecdote. Ils se sont appuyé sur les spécifications techniques et ça fonctionne plutôt bien. Sauf le manque de précision du signal qui est à déplorer pour le moment.
La version StopCovid ne saurait tarder connaissant la communauté.
Ces solutions permettent d’offrir une alternative à bas coût (10 € le RPi, 30 € avec boîtier) qui ne nécessite pas de connexion à Internet vu que les diagnostics sont faits hors ligne : juste un serveur relai qui stocke les clés. Et encore, les smartphones pourraient faire office de relais. Idéal en zone blanche.
Le sujet autour de tout ça est passionnant.
Sinon, du reste, je pense que la conversation tourne en rond. Wait and see.
Si ça se trouve, aucune des solutions ne sera efficace. ^^
@FloMo
> Mais personnaliser avec des données peu fiables, ça n’a pas d’intérêt
Qu'est-ce qui vous permet de dire qu'elles sont peu fiables hors utilisation de l'API de Apple/Google !? Leur API n'améliore nullement la qualité d'estimation de la distance !
Compter le nombre de contacts min, moyen, median, max ne necessite que d'avoir pu capter le message, ce que l'usage de l'API n'augmente pas, c'est totalement lié à l'environnement radio.
Et l'intérêt pour améliorer les modèles statistiques d'exposition et de diffusion lors d'une pandémie me semble assez évident, à moi.
> Je suis sûr que d’ici là,
Vous étiez également sûr que l'app française ne serait pas dispo à la date annoncée...
> Il a fallu 7 semaines pour concevoir toute l’app et son environnement.
> C’est ce qu’il a fallu pour les autres pays également.
Euh, l'app Suisse n'est pas dispo officiellement, c'est en phase de test jusqu'à la fin du mois, le parlement n'ayant pas voté encore.
Celle de l'Italie est également en phase de tests dans 4 provinces uniquement, pas tout le pays.
Y'a que celle de la Létonie qui soit vraiment officiellement déployée en version finale à cette date.
@byte_order
On verra. Aujourd’hui, on ne peut être que dans la spéculation.
@FloMo
Alors n'affirmez pas que les données sont plus fiables avec l'API, comme ça, dans le vent.
@byte_order
Ceux qui implémentent les API côté Raspberry Pi le confirment.
Avec l’API d’Apple/Google, la partie serveur ne contient qu’en les clés anonymes des cas positifs, pas les contacts qui ne sortent jamais du téléphone.
Ensuite, avec cette API, la partie serveur peut être codée comme on veut, et donc il est parfaitement possible de faire une partie serveur sous forme décentralisée, par exemple avec une blockchain.
@r e m y
Avec la solution Apple/Google, le serveur central connaît uniquement les identifiants des personnes s’étant déclarées positives.
Avec StopCovid, le serveur central connaît l’ensemble des identifiants, positifs et non positifs.
La solution Apple/Google à la réputation d’être moins intrusive dans la vie privée. Si on fait confiance à ces sociétés.
La solution StopCovid a l’avantage de ne pas s’appuyer sur un intermédiaire privé. Et offre plus d’information au monde médical pour essayer d’y appuyer des modèles de propagation du virus.
Google ou Apple n'ont pas besoin de cette API pour nous surveiller. ils savent tout de nous, en fait ce que la technologie bourré de bugs leur permet.
on a des appareils localisé et connecté ce qui sert d'ailleurs de leur protection (en cas de vol, perte, etc), plus gps, et tout ça. comment l'ont tué le général iranien. il était géolocalisé depuis toujours. il suffisait qu'il sorte juste un petit peu de son trou.
C’est surtout :
1/ compatible avec toutes les autres app utilisant ces API.
2/ possible de faire tourner l’app en tache de fond sur iOS, car cela fait appel à des mécanismes au niveau de l’OS, alors que le failware français StopCovid oblige à laisser l’app active pour qu’elle fonctionne.
> 1/ compatible avec toutes les autres app utilisant ces API.
C'est faux.
C'est pas compatible, cela permet de rendre plus facilement interopérable les autres solutions utilisant cette même API, nuance.
Cela ne signifie nullement que l'app de l'Italie, de la Suisse et de la Létonie sont interchangeables. Il suffit qu'ils n'aient pas mis en place de mécanisme d'échange entre leurs serveurs pour que votre app Immuni italienne ne reçoive jamais l'info comme quoi vous avez croisé un Suisse qui depuis a été testé positif.
> possible de faire tourner l’app en tache de fond sur iOS, car cela fait appel
> à des mécanismes au niveau de l’OS, alors que le failware français StopCovid oblige
> à laisser l’app active pour qu’elle fonctionne.
C'est également faux.
L'app française fonctionne également en tâche de fond.
Le seul cas où elle fonctionnera mal, c'est quand y'aura *que* des iPhones à portée et que *aucun* n'est actif pendant 15 minutes ou plus.
@byte_order
1. le protocole côté serveur prévoie l’interopérabilité entre serveurs (cf code open-source de Google) et côté client, c’est forcément mis en commun vu que c’est l’API qui stocke.
2. Côté Bluetooth, on ne perd pas les connexions en tache de fond s’il n’y a pas d’Android « ancien ».
Mais surtout, on profite de l’accès bas niveau pour avoir une précision optimale.
Un aspect que Cédric O lui-même déplore en demandant aux constructeurs de leur donner accès au protocole Bluetooth complet.
@FloMo
> le protocole côté serveur prévoie l’interopérabilité entre serveurs
> (cf code open-source de Google) et côté client, c’est forcément mis en commun vu
> que c’est l’API qui stocke.
C'est ce que je dis : l'usage de l'API facilite l'implémentation de l'interopérabilité entre les solutions, car les données à échanger suivent le même protocole, mais elle ne l'apporte pas comme ça, par magie. Si un pays n’implémente aucune passerelle d'interopérabilité entre leur solution et une autre, API ou pas coté smartphone, y'a pas d'interopérabilité.
> Côté Bluetooth, on ne perd pas les connexions en tache de fond s’il n’y a pas d’Android
> « ancien ».
Ancien !?
Ce n'est qu'à partir d'Android 10. Hors la fragmentation - dont iGen se sert régulièrement comme point négatif d'Android - est telle que Android 10 c'est moins de 9% du parc installé, tandis que Android 9 et 8, plus "anciennes" comme vous dites, c'est un smartphone android sur 2 !
Et que dire des iPhones qui n'ont pas accès à iOS 13 !?
> Mais surtout, on profite de l’accès bas niveau pour avoir une précision optimale.
Foutaises. BT ne permet nullement d'avoir une estimation de distance fiable. C'est pas une histoire d'API, c'est juste que les perturbations radio sont d'autant plus perturbantes pour cette estimation que le niveau d'énergie est faible.
> Un aspect que Cédric O lui-même déplore en demandant aux constructeurs de leur
> donner accès au protocole Bluetooth complet.
Pour ne pas dépendre d'une API métier proprio qui s'interpose, liant de facto la solution aux plateformes des promoteurs de cette API. Nuance.
C'est comme si pour accéder à Internet de manière sécurisée, on était contraint d'utiliser un protocole proprio de haut niveau existant uniquement sur les smartphones sous le contrôle d'entreprises privées étrangères, alors que tout ce que l'on veut c'est de pouvoir faire du TLS tranquillou...
@byte_order
> Et que dire des iPhones qui n'ont pas accès à iOS 13 !?
À date, ils sont environ 10 % selon Mixpanel. Et potentiellement 4 % en France.
@FloMo
Donc dans les deux cas, l’occurrence est assez faible. Pourquoi alors le présenter comme un frein plus important !? D'autant que la cause réelle, c'est une décision arbitraire d'Apple, qui refuse d'accorder à l'utilisateur le droit de décider librement s'il accorde ou pas ce droit à telle app.
Ce problème est purement artificiel, il n'est pas technique, il est stratégique pour Apple parce que sans son verrou cela menacerait son monopole avec ApplePay, par exemple, mais aussi AirDrop, ses futurs AirTags.
@byte_order
> Donc dans les deux cas, l’occurrence est assez faible.
Au détail près que le nombre d’appareils non compatibles iOS 13 va en décroissant. Et le nombre d’appareils Android 10 va en croissant.
> Pourquoi alors le présenter comme un frein plus important !?
Voir ci-dessus.
> D'autant que la cause réelle, c'est une décision arbitraire d'Apple, qui refuse d'accorder à l'utilisateur le droit de décider librement s'il accorde ou pas ce droit à telle app.
En fait, par défaut, pour des raisons de sécurité, l’utilisation des beacons en tâche de fond est bloquée.
D’ailleurs, depuis iOS 13.4 (et probablement les dernières versions correctives des autres versions), il est impossible d’utiliser le protocole de communication Bluetooth utilisé par l’API EN. On ne peut donc pas concevoir une app mobile qui irait sniffer et géolocaliser / partager les pseudonymes de l’API EN.
> Ce problème est purement artificiel, il n'est pas technique, il est stratégique pour Apple parce que sans son verrou cela menacerait son monopole avec ApplePay, par exemple, mais aussi AirDrop, ses futurs AirTags.
Non. Raisons de sécurité. Pour maintenir le niveau de sécurité existant.
Les apps qui réveillent artificiellement l’app en background exposent la sécurité de leurs utilisateurs et en prennent la responsabilité. Apple n’aime pas trop ce genre de mauvaise presse et s’en prémunit.
L’ouverture des protocoles côté Apple se fait uniquement quand on est sûr que cela ne mets pas en péril la sécurité et que cela n’implique pas des données constructeurs confidentielles.
Quelques exemples connus de protocoles mis en open-source par Apple :
- HealthKit (partage de données directement de l’iPhone aux labos en chiffrement de bout en bout)
- HomeKit (domotique avec chiffrement de bout en bout)
- fichiers CoreML (Machine Learning, s’appuie sur Protocol Buffer de Google)
- l’infrastructure iCloud (via FoundationDB + Layers).
AirDrop et AirPlay le sont par contre pour des raisons commerciales je suppose.
@byte_order
> C'est comme si pour accéder à Internet de manière sécurisée, on était contraint d'utiliser un protocole proprio de haut niveau existant uniquement sur les smartphones sous le contrôle d'entreprises privées étrangères, alors que tout ce que l'on veut c'est de pouvoir faire du TLS tranquillou
TLS 1.3 a été mis au point majoritairement par Apple et Google. Ils ont été les premiers à l’implémenter en beta. Et ils ont fourni en parallèle les specs pour les autres constructeurs.
C’est la même démarche pour l’API COVID.
@FloMo
> C’est la même démarche pour l’API COVID.
Non. On ne peut pas implémenter soit même le protocole BT de l'API d'Apple/Google dans une app iOS (et p'tet Android).
L'API pour faire des communications BT depuis une app iOS l'empêche, on est obligé d'utiliser l'implémentation fournie par le constructeur.
Alors qu'on peut parfaitement implémenter soit même le protocole TLS dans une app iOS. l'API pour faire des communications TCP depuis une app iOS ne l'empêche nullement.
@byte_order
C’est pour garder le même niveau de sécurité.
Implémenter son propre TLS ne mets pas en péril la sécurité.
Ce n’est pas pour rien que toute app utilisant l’API EN voit son accès au GPS bloqué.
@Benoît42
> La solution StopCovid a l’avantage de ne pas s’appuyer sur un intermédiaire privé
Côté StopCovid, les données sensibles sont stockées chez Microsoft Health. C’est un intermédiaire privé.
Côté API Apple / Google, les données sensibles sont stockées sur le smartphone. Donc chez l’utilisateur.
Le seul avantage de StopCovid est qu’il est potentiellement possible d’exploiter un système d’intelligence artificielle en s’appuyant sur les données collectées.
Pour le moment, car Apple et Google ont leurs propres solutions open-source de partage de données de santé avec les cliniques. L’ajout de la compatibilité HealthKit / CareKit / ResearchKit dans un second temps ne me surprendrait pas.
@FloMo
C’est tout à fait possible mais ça reste un choix. Ui plus est réversible. Et le contrat stipule certainenement que l'état est le propriétaire des données.
Par contre Apple a le contrôle de son API et peut en désactiver l’utilisation à tout moment à sa convenance. Et là ce n’est pas un choix.
@scanmb
Peut-être... ou pas... Votre question est floue. Une application fait ce que l'on y code, dans la limite de ce qui est autorisé par le système. Mais StopCovid est (en partie au moins, je n'ai pas le détail exact) open source.
@Benoît42
En effet, mais cela ne s’est jamais produit.
Et, dans le pire des cas, les protocoles de chiffrement, de Bluetooth et de fonctionnement de l’API sont publics.
D’où les versions open-source qui émergent sur Raspberry Pi.
@FloMo
Je vois mal tout le monde se balader dans la rue avec un Raspberry dans la poche. Et non, Apple/Google n'a jamais désactivé son API encore, pour la bonne raison que les toutes premières appli l'utilisant viennent juste de sortir.
La FAQ Apple dit clairement "Google and Apple will disable the exposure notification system on a regional basis when it is no longer needed." (https://blog.google/documents/73/Exposure_Notification_-_FAQ_v1.1.pdf)
C'est assez clair, il n'est pas dit que ça doivent se faire en accord avec les autorités de la région concernée. Quelques soit les qualités de cette API, ça donne quand même un pouvoir non négligeable (et elles en ont déjà beaucoup) à ces sociétés.
@Benoît42
La démo sur Raspberry Pi montre les possibilités en IoT.
Pour la désactivation, c’est surtout par protection de la vie privée. Pour que les utilisateurs ne se sentent pas postés en permanence.
Il me semble que, dans les conditions d’utilisation, ce sont les organisations de santé qui demandent à Apple de désactiver ou activer le procédé. Mais c’est à clarifier.
Après, avoir le pouvoir d’activer / désactiver à distance un procédé reste bien inférieur à la dépendance actuelle à Microsoft qui possède les données de santé du fait de la centralisation des traitements.
@FloMo
« la dépendance actuelle à Microsoft qui possède les données de santé du fait de la centralisation des traitements. »
L’hébergement et la propriété des données sont deux notions qui n’ont rien à voir. Quand on héberge chez un prestataire, on a toujours la possibilité de migrer les données ailleurs.
@Benoît42
Si on reste dans la logique du procédé.
Les représentants du gouvernement ont choisi d’héberger les données sur un cloud souverain car Apple et Google n’offraient pas de garanties suffisantes concernant la vie privée en laissant les données sur les smartphones.
Déjà, l’approche est surprenante. Car, au final, les données vont transiter par les infrastructures Apple et Google. Puisque ce sont les smartphones qui sont, dans cette logique, considérés comme des infrastructures Apple / Google.
Et en plus, défendre ça comme un projet européen alors que le Parlement Européen a justement voté pour une approche décentralisée au nom du respect de la vie privée le 17 avril, c’est un peu gonflé.
Là-dessus, on attend de voir ce fameux cloud souverain qui nous protège des GAFAM. C’est ce qui est écrit dans le communiqué : « La solution Apple Google n’est pas jugée apporter, à date, des garanties suffisantes en matière de respect de la vie privée et de protection des données de santé. »
Dans la logique gouvernementale, « Les solutions proposées par Apple et Google reposent sur la transmission à tous les smartphones des pseudonymes des personnes diagnostiquées positives. »
C’est faux à plusieurs niveaux. En premier lieux, ce ne sont que certaines clés de chiffrement qui transitent. Les clés ne sont pas les pseudonymes. Et les diagnostics sont faits sur les smartphones, à partir des paramètres fournis par les organisations de santé.
Et au final, dans le cloud souverain, les données qui auraient pu rester sur les smartphones vont chez Microsoft.
La logique de vie privée n’y est plus du tout. Ça pourrait difficilement être pire.
Alors c’est vrai qu’après ça on va nous dire : « oui, mais on a besoin de concevoir ça pour faire une IA »...
Mais si c’est du même niveau que le reste, on peut s’attendre au pire.
Le plus dingue, c’est que l’excellente conception de l’app par Lunabee associée à la puissance de l’outil Apple / Google aurait permis d’avoir une app des plus abouties.
@FloMo
Je vois bien que vous avez plein d'arguments contre StopCovid. Mais vous ne tenez aucun compte des arguments contre l'API Apple/Google.
Les deux approches ont des avantages et des inconvénients, mais beaucoup ici se mettent des oeillères...
@Benoît42
Le seul et unique argument qui tient pour l’app StopCovid est le projet d’une IA.
Tout le reste ne tient pas.
Enfin, ce qui pose soucis ce n’est pas l’app. C’est une excellente initiative saluée par des études scientifiques.
Ce qui pose soucis, c’est le protocole ROBERT qui a été rejeté pour raisons de respect de la vie privée par le Parlement Européen.
Et ce rejet s’appuie sur la mise en garde de centaines de chercheurs en sécurité au niveau mondial.
@FloMo
Ça fait un paquet de fois que tu leur expliques ces points...en vain.
Le déni, l’endoctrinement politique, tout ça ...
@Steve Molle
En même temps, il faut comprendre les tenants et aboutissants techniques.
C’est un devoir de vulgariser et expliquer quand on le peut.
Pages