Apple et l’API de notification d’exposition COVID-19 de Google: questions et réponses

Apple et Google entreprennent un effort d'équipe sans précédent pour construire un système permettant aux androïdes et aux iPhones d'interagir au nom du suivi des contacts COVID-19 assisté par la technologie.

Le plan des entreprises fait partie d'un torrent de propositions visant à utiliser la force du signal Bluetooth pour améliorer la recherche manuelle des contacts avec des applications mobiles basées sur la proximité . Comme Apple et Google sont un duopole efficace dans l'espace du système d'exploitation mobile, leur plan a un poids particulier. La technologie d'Apple et de Google serait largement décentralisée, gardant la plupart des données sur les téléphones des utilisateurs et à l'écart des bases de données centrales. Ce type d'application présente des compromis inévitables en matière de confidentialité, comme nous le verrons ci-dessous, et Apple et Google pourraient faire plus pour éviter les fuites de confidentialité. Pourtant, leur modèle est conçu pour réduire les risques de confidentialité du suivi de proximité Bluetooth, et il est préférable à d'autres stratégies qui dépendent d'un serveur central.

Les applications de suivi de proximité pourraient être, tout au plus, une petite partie d'une réponse de santé publique plus large à COVID-19. Cette utilisation de la technologie Bluetooth n'est pas prouvée et n'a pas été testée, et elle est conçue pour être utilisée dans des applications pour smartphone qui n'atteindront pas tout le monde . Les applications construites au-dessus d'Apple et du nouveau système de Google ne seront pas une technosolution «magique» pour l'état actuel du refuge en place. Leur efficacité dépendra de nombreux compromis et d'une confiance suffisante pour une large adoption par le public. Des protections insuffisantes de la vie privée réduiront cette confiance et mineront ainsi l'efficacité des applications.

Comment ça va fonctionner?

Dès aujourd'hui , Apple et Google commencent à déployer des parties de l'infrastructure iPhone et Android dont les développeurs ont besoin pour pouvoir créer des applications de suivi de proximité basées sur Bluetooth. Si vous téléchargez l'une de ces applications, il utilisera la puce Bluetooth de votre téléphone pour faire ce que fait Bluetooth: émettre de petits pings radio pour trouver d'autres appareils. Habituellement, ces pings recherchent vos haut-parleurs externes ou votre souris sans fil. Dans le cas des applications de suivi de proximité COVID-19, elles contacteront les personnes à proximité qui ont également choisi d'utiliser Bluetooth à cette fin. Leurs téléphones émettront et écouteront également ces pings. Les applications utiliseront la force du signal Bluetooth pour estimer la distance entre les deux téléphones. S'ils sont suffisamment proches – 6 pieds ou plus, selon les directives actuelles du CDC – les deux enregistreront un événement de contact.

Il existe maintenant de nombreuses propositions différentes pour faire essentiellement la même chose , avec des considérations légèrement différentes pour l'efficacité, la sécurité et la confidentialité. Le reste de cet article examine en particulier la proposition d'Apple et de Google ( version 1.1 ).

Chaque téléphone générera chaque jour une nouvelle clé privée à usage spécial, appelée «clé d'exposition temporaire». Il utilisera ensuite cette clé pour générer des numéros d'identification aléatoires appelés «identifiants de proximité roulants» (RPID). Les pings sortiront au moins une fois toutes les cinq minutes lorsque le Bluetooth est activé. Chaque ping contiendra le RPID actuel du téléphone, qui changera toutes les 10 à 20 minutes. Ceci est destiné à réduire le risque que des trackers tiers puissent utiliser les pings pour suivre passivement les emplacements des personnes . Le système d'exploitation enregistrera toutes ses clés d'exposition temporaires et enregistrera tous les RPID avec lesquels il entre en contact au cours des 2 dernières semaines.

Les applications de suivi de proximité pourraient être, tout au plus, une petite partie d'une réponse de santé publique plus large à COVID-19.

Si un utilisateur de l'application apprend qu'il est infecté, il peut accorder à une autorité de santé publique l'autorisation de partager publiquement ses clés d'exposition temporaires. Afin d'empêcher les gens d'inonder le système de fausses alarmes, les autorités sanitaires doivent vérifier que l'utilisateur est réellement infecté avant de pouvoir télécharger leurs clés. Une fois téléchargées, les clés d'exposition temporaire d'un utilisateur sont appelées «clés de diagnostic». Les clés de diagnostic sont stockées dans un registre public et disponibles pour tous les autres utilisateurs de l'application.

Les clés de diagnostic contiennent toutes les informations nécessaires pour recréer l'ensemble complet des RPID associés à l'appareil de chaque utilisateur infecté. Les applications participantes peuvent utiliser le registre pour comparer les RPID avec lesquels un utilisateur a été en contact avec les RPID des opérateurs COVID-19 confirmés. Si l'application trouve une correspondance, l'utilisateur reçoit une notification de son risque d'infection.

Le programme se déroulera en deux phases. Dans la phase 1, Google et Apple construisent une nouvelle API dans leurs plates-formes respectives. Cette API contiendra les fonctionnalités de base nécessaires pour faire fonctionner leur schéma de suivi de proximité sur les iPhones et les Androïdes. Les autres développeurs devront créer des applications qui exécutent réellement la nouvelle API. Des projets de spécifications pour l'API ont déjà été publiés et pourraient être disponibles pour les développeurs cette semaine . Dans la phase 2, les entreprises déclarent que le suivi de proximité " sera introduit au niveau du système d'exploitation pour garantir une large adoption ". Nous en savons beaucoup moins sur cette deuxième phase.

Est-ce que ça marchera?

Plusieurs défis techniques et sociaux entravent le suivi de proximité automatisé. Tout d'abord, ces applications supposent que «téléphone portable = humain». Mais même aux États-Unis, l'adoption du téléphone portable est loin d'être universelle . Les personnes âgées et les ménages à faible revenu sont moins susceptibles de posséder des smartphones, ce qui pourrait exclure de nombreuses personnes les plus exposées au COVID-19. De nombreux téléphones plus anciens ne disposent pas de la technologie nécessaire pour le suivi de proximité Bluetooth. Les téléphones peuvent être éteints, laissés à la maison, à court de batterie ou réglés en mode avion. Ainsi, même un système de suivi de proximité avec une adoption quasi universelle va manquer des millions de contacts chaque jour.

Ces applications supposent que «téléphone portable = humain», mais l'adoption du téléphone portable est loin d'être universelle.

Deuxièmement, les applications de suivi de proximité doivent faire le grand saut entre «il y a un signal Bluetooth puissant près de moi» et «deux humains connaissent un contact épidémiologiquement pertinent». La technologie Bluetooth n'a pas été conçue pour cela. Une application peut enregistrer une connexion lorsque deux personnes portant des masques se croisent brièvement sur un trottoir venteux, ou lorsque deux voitures avec des fenêtres s'asseyent l'une à côté de l'autre dans la circulation. La proximité d'un patient avec une infirmière en EPI complet peut ressembler à Bluetooth comme la proximité de deux personnes qui s'embrassent. De plus, Bluetooth peut être perturbé par de grandes concentrations d'eau, comme le corps humain. Dans certaines situations, bien que deux personnes puissent être suffisamment proches pour se toucher, leur téléphone peut ne pas être en mesure d'établir un contact radio. Il est encore plus difficile d'estimer avec précision la distance entre deux appareils.

Troisièmement, Apple et Google proposent actuellement que les téléphones diffusent des signaux aussi rarement qu'une fois toutes les cinq minutes. Ainsi, même dans des conditions optimales, deux téléphones ne peuvent pas enregistrer de contact tant qu'ils ne sont pas proches l'un de l'autre pendant la durée requise.

Quatrièmement, une partie importante de la population doit réellement utiliser les applications. À Singapour, une application développée par le gouvernement n'a atteint environ 20% d'adoption qu'après plusieurs semaines. En tant que duopole des plates-formes mobiles, Apple et Google sont peut-être les mieux placés pour encourager le déploiement d'un nouveau logiciel à grande échelle. Même ainsi, l'adoption peut être lente et elle ne sera jamais universelle .

Sera-t-il privé et sécurisé?

La vérité est que personne ne sait vraiment à quel point les applications de suivi de proximité seront efficaces. En outre, nous devons peser les avantages potentiels par rapport aux risques très réels pour la confidentialité et la sécurité.

Premièrement, tout système de suivi de proximité qui vérifie une base de données publique de clés de diagnostic par rapport aux RPID sur l'appareil d'un utilisateur – comme le fait la proposition Apple-Google – laisse ouverte la possibilité que les contacts d'une personne infectée déterminent laquelle des personnes rencontrées est infecté. Par exemple, si vous avez un contact avec un ami et que votre ami signale qu'il est infecté, vous pouvez utiliser le journal des contacts de votre propre appareil pour savoir qu'il est malade. Poussés à l'extrême, les mauvais acteurs pourraient collecter des RPID en masse, les connecter à des identités à l'aide de la reconnaissance faciale ou d'autres technologies, et créer une base de données sur les personnes infectées. D'autres propositions, comme le PEPP-PT de l'UE et le ROBERT de la France et de l'Allemagne , visent à empêcher ce type d'attaque, ou du moins à le rendre plus difficile, en effectuant une correspondance sur un serveur central; mais cela introduit des risques plus graves pour la vie privée.

Deuxièmement, le choix d'Apple et de Google pour que les utilisateurs infectés partagent publiquement leurs clés de diagnostic une fois par jour – au lieu de leurs RPID de quelques minutes – expose ces personnes à des attaques de liaison . Un adversaire disposant de ressources suffisantes pourrait collecter des RPID à de nombreux endroits différents à la fois en installant des balises Bluetooth statiques dans des lieux publics ou en convaincant des milliers d'utilisateurs d'installer une application. Le tracker recevra un tuyau d'incendie de RPID à différents moments et endroits. Avec juste les RPID, le tracker n'a aucun moyen de relier ses observations entre elles.

Mais une fois qu'un utilisateur a téléchargé ses clés de diagnostic quotidiennes dans le registre public, le tracker peut les utiliser pour relier tous les RPID de cette personne en une seule journée.

Cela peut créer une carte de la routine quotidienne de l'utilisateur, y compris où il travaille, vit et passe du temps. Ces cartes sont très uniques à chaque personne, elles pourraient donc être utilisées pour identifier la personne derrière la clé de diagnostic téléchargée. De plus, ils peuvent révéler l'adresse personnelle d'une personne, son lieu de travail et ses déplacements dans des endroits sensibles comme une église, une clinique d'avortement, un bar gay ou un groupe de soutien pour toxicomanes. Le risque de suivi de localisation n'est pas unique aux applications Bluetooth, et les acteurs disposant des ressources pour mener une attaque comme celle-ci ont probablement d'autres moyens d'obtenir des informations similaires à partir de tours de téléphonie cellulaire ou de courtiers de données tiers. Mais les risques associés au suivi de proximité Bluetooth en particulier devraient être réduits autant que possible.

Ce risque peut être atténué en raccourcissant la durée d'utilisation d'une seule clé de diagnostic pour générer des RPID, au prix d'une augmentation de la taille de téléchargement de la base de données d'exposition. Des projets similaires, comme le PACT du MIT , proposent d'utiliser des clés horaires au lieu de clés quotidiennes.

Troisièmement, la police peut rechercher des données créées par des applications de proximité. Le téléphone de chaque utilisateur stockera pendant plusieurs semaines un journal de sa proximité physique avec les téléphones d'autres personnes, et donc de leurs associations intimes et expressives avec certaines de ces personnes. Quiconque a accès aux données de l'application de proximité à partir des téléphones de deux utilisateurs pourra voir si, et à quels jours, ils ont enregistré des contacts les uns avec les autres. Ce risque est probablement inhérent à tout protocole de suivi de proximité. Elle devrait être atténuée en donnant aux utilisateurs la possibilité de désactiver sélectivement l'application et de supprimer les données de proximité de certaines périodes. Comme de nombreuses autres menaces à la vie privée, elle devrait également être atténuée par un cryptage et des mots de passe solides.

Le protocole d'Apple et de Google peut être sensible à d'autres types d'attaques. Par exemple, il n'y a actuellement aucun moyen de vérifier que le périphérique envoyant un RPID est bien celui qui l'a généré, afin que les trolls puissent collecter les RPID des autres et les rediffuser comme les leurs. Imaginez un réseau de balises Bluetooth installé aux coins des rues animées qui rediffusent tous les RPID qu'ils observent. Quiconque passe devant une «mauvaise» balise enregistre les RPID de toutes les autres personnes qui se trouvent à proximité de l'une des balises. Cela conduirait à de nombreux faux positifs, ce qui pourrait saper la confiance du public dans les applications de traçage de proximité – ou pire, dans le système de santé public dans son ensemble.

Que doivent faire les développeurs d'applications?

La phase 1 d'Apple et de Google est une API, qui laisse le reste du monde pour développer les applications réelles qui utilisent la nouvelle API. Google et Apple ont déclaré qu'ils avaient l'intention que les «autorités de santé publique» créent des applications. Mais la plupart des autorités sanitaires n'auront pas les ressources techniques internes pour le faire, il est donc probable qu'elles s'associeront avec des entreprises privées. Quiconque construit une application au-dessus de l'interface devra faire beaucoup de choses correctement pour s'assurer qu'elle est privée et sécurisée.

Les développeurs d'applications de mauvaise foi peuvent essayer de briser les garanties de confidentialité soigneusement élaborées des géants de la technologie. Par exemple, bien que les données d'un utilisateur soient censées rester sur son appareil, une application avec accès à l'API peut être en mesure de tout télécharger sur un serveur distant. Il pourrait ensuite associer des clés privées quotidiennes à un identifiant d'annonce mobile ou à un autre identifiant, et exploiter l'historique des associations d'utilisateurs pour les profiler. Il pourrait également utiliser l'application comme un « cheval de Troie » pour convaincre les utilisateurs d'accepter toute une suite de suivi plus invasive.

Alors, que doit faire un développeur d'applications responsable? Pour commencer, ils doivent respecter le protocole sur lequel ils s'appuient. Les développeurs ne devraient pas essayer de greffer un protocole plus «centralisé», qui partage plus de données avec une autorité centrale, en plus d'Apple et du modèle plus «décentralisé» de Google qui conserve les données des utilisateurs sur leurs appareils. De plus, les développeurs ne devraient pas partager de données sur Internet au-delà de ce qui est absolument nécessaire: il suffit de télécharger des clés de diagnostic lorsqu'un utilisateur infecté choisit de le faire.

Les développeurs doivent être extrêmement francs avec leurs utilisateurs sur les données que l'application collecte et comment les arrêter. Les utilisateurs doivent pouvoir arrêter et commencer à partager des RPID à tout moment. Ils devraient également pouvoir voir la liste des RPID qu'ils ont reçus et supprimer tout ou partie de cet historique de contacts.

Tout le système dépend de la confiance.

Ce qu'il ne faut pas faire est tout aussi important. Il s'agit d'une crise de santé publique, pas une chance de développer une startup. Les développeurs ne doivent pas forcer les utilisateurs à ouvrir un compte pour quoi que ce soit. En outre, ils ne devraient pas expédier une application de suivi des contacts avec des fonctionnalités supplémentaires inutiles. L'application doit faire son travail et s'éloigner, pas essayer d'intégrer les utilisateurs à un nouveau service.

De toute évidence, les applications de traçage de proximité ne devraient rien avoir à voir avec les publicités (et le désordre d'exploitation et de succion de données qui les accompagne). De même, ils ne devraient pas utiliser de bibliothèques d'analyse qui partagent des données avec des tiers. En général, les développeurs doivent utiliser des protections techniques et politiques solides et transparentes pour isoler ces données aux fins de COVID-19 et uniquement à des fins de COVID-19.

Tout le système dépend de la confiance. Si les utilisateurs ne croient pas qu'une application fonctionne dans leur meilleur intérêt, ils ne l'utiliseront pas. Les développeurs doivent donc être aussi transparents que possible sur le fonctionnement de leurs applications et les risques encourus. Ils devraient publier le code source et la documentation afin que les utilisateurs avertis et les technologues indépendants puissent vérifier leur travail. Et ils devraient inviter des audits de sécurité et des tests de pénétration de professionnels à être aussi confiants que possible que leurs applications font réellement ce qu'ils disent qu'ils feront.

Tout cela prendra du temps. Il y a beaucoup de choses qui peuvent mal tourner, et trop sont en jeu pour se permettre des logiciels précipités et bâclés. Les autorités de santé publique et les développeurs devraient prendre du recul et s'assurer qu'ils font bien les choses. Et les utilisateurs doivent se méfier de toutes les applications qui seront livrées dans les jours suivant la première version d'API d'Apple et de Google.

Que devraient faire Apple et Google?

Apple et Google devraient être transparents quant à leurs critères.

Au cours de la première phase, Apple et Google ont déclaré que l'API ne peut «[être] utilisée que pour le suivi des contacts par les applications des autorités de santé publique», qui «recevront une approbation en fonction d'un ensemble spécifique de critères conçus pour garantir qu'elles ne sont administrées que dans en collaboration avec les autorités de santé publique, répondre à nos exigences de confidentialité et protéger les données des utilisateurs. " Apple et Google doivent être transparents et précis sur ce que sont exactement ces critères. Grâce à ces critères, les entreprises peuvent contrôler les autres autorisations des applications. Par exemple, ils pourraient empêcher les applications de suivi de proximité COVID-19 d'accéder aux ID d'annonces mobiles ou à d'autres identifiants d'appareil. Ils pourraient également faire des prescriptions de politique plus détaillées, comme exiger que toute application utilisant l'API dispose d'un mécanisme clair pour que les utilisateurs puissent revenir en arrière et supprimer des parties de leur journal de contacts. Les critères d'approbation d'App Store d'Apple et de Google et les restrictions associées doivent également être appliqués de manière uniforme; si Apple et Google font des exceptions pour les gouvernements ou les entreprises avec lesquels ils sont amicaux, cela saperait la confiance nécessaire pour un consentement éclairé.

Dans la deuxième phase, les entreprises intégreront la technologie de suivi de proximité directement dans Android et iOS. Cela signifie qu'aucune application ne sera nécessaire au départ, bien qu'Apple et Google proposent que l'utilisateur soit invité à télécharger une application de santé publique si une correspondance d'exposition est détectée. Toutes les recommandations ci-dessus pour les développeurs d'applications s'appliquent également à Apple et Google ici. De manière critique, l'opt-in promis doit obtenir le consentement spécifique et éclairé de chaque utilisateur avant d'activer tout type de suivi de proximité. Ils doivent permettre aux utilisateurs qui acceptent de se retirer plus tard et d'afficher et de supprimer les données que l'appareil a collectées. Ils devraient créer de fortes barrières techniques entre les données collectées pour le suivi de proximité et tout le reste. Et ils devraient open-source leurs implémentations afin que les analystes de sécurité indépendants puissent vérifier leur travail.

Ce programme doit prendre fin lorsque la crise du COVID-19 est terminée.

Enfin, ce programme doit prendre fin lorsque la crise du COVID-19 est terminée. Les applications de suivi de proximité ne doivent pas être utilisées à d'autres fins, comme le suivi d'épidémies de grippe saisonnière plus légères ou la recherche de témoins d'un crime. Google et Apple ont déclaré qu'ils "peuvent désactiver le système de notification d'exposition sur une base régionale lorsqu'il n'est plus nécessaire". Il s'agit d'une capacité importante, et Apple et Google devraient établir un plan clair et concret pour savoir quand mettre fin à ce programme et supprimer les API de leurs systèmes d'exploitation. Ils devraient déclarer publiquement comment ils définiront «la fin de la crise», y compris les critères qu'ils rechercheront et les autorités de santé publique qui les guideront.

Il n'y aura pas de solution technique rapide à COVID-19. Aucune application ne nous permettra de reprendre nos activités comme d'habitude. Le suivi des contacts assisté par application aura de sérieuses limitations, et nous ne connaissons pas encore l'étendue des avantages. Si Apple et Google vont mener cette grande expérience sociale, ils doivent le faire de manière à réduire au minimum les risques pour la vie privée. Et s'ils veulent que cela réussisse, ils doivent gagner et conserver la confiance du public.