La Quadrature du Net et la Ligue des Droits de l’Homme viennent de déposer un recours en urgence contre le déploiement de drones par la préfecture de police de Paris. Depuis le début du confinement et un peu partout en France, la police prétend se faire assister de drones pour lutter contre les infractions. Pourtant, puisqu’ils sont déployés en l’absence de tout cadre légal spécifique et adapté, ce sont eux qui violent la loi et nos libertés. Nous espérons qu’une victoire à Paris aura des effets dans tout le pays..

Depuis le début du confinement, la police et la gendarmerie utilisent de façon massive et inédite les drones pour surveiller la population et faire appliquer les règles du confinement : diffusion des consignes par haut-parleurs ainsi que surveillance par vidéo pour repérer les contrevenants, guider les patrouilles au sol et filmer les personnes échappant à la police pour mieux les sanctionner après.

Le déploiement de ces drones, déjà utilisés notamment pour la surveillance des manifestations, ne fait que s’amplifier avec la crise sanitaire. En avril, le ministère de l’Intérieur a par ailleurs publié un appel d’offres portant sur l’acquisition de plus de 650 nouveaux drones pour plus que doubler sa flotte. Selon un rapport sénatorial, entre le 24 mars et le 24 avril, la police nationale a déclenché 535 vols de drones dont 251 de surveillance.

Ce déploiement, en plus d’augmenter de manière inédite les capacités de surveillance de la police, se fait en l’absence de tout cadre légal spécifique quant à l’utilisation des images filmées. Aucun texte ne prévoit un délai de suppression pour ces images ou n’en limite l’accès aux seuls agents de la préfecture pour une mission de police identifiée. D’ailleurs, dans un premier temps, cette absence de texte nous a empêchés d’attaquer les drones.

Heureusement, la publication par Mediapart le 25 avril dernier, dans un article de Clément Le Foll et Clément Pouré, de deux documents issus du service de communication de la préfecture de police de Paris a apporté plusieurs éléments concrets nous permettant d’agir en justice. La préfecture y reconnait notamment qu’il n’existe aucun cadre juridique spécifique pour les images captées par les drones, et cela alors qu’ils sont équipés de caméras haute-résolution permettant « la captation, la transmission et l’enregistrement des images » ainsi que « l’identification d’un individu ».

Nous avons déposé samedi un référé-liberté devant le tribunal administratif de Paris pour lui demander de faire cesser immédiatement ce dispositif illégal. Notre recours est notamment fondé sur l’absence de cadre légal spécifique, qui implique de multiples atteintes au droit à la vie privée (absence d’information des personnes filmées ou de délai de conservation de ces images…), et la disproportion de ce dispositif. Il est enfin évident qu’en cas de victoire, les principes d’une telle décision devront être respectés par l’ensemble de la police et de la gendarmerie, partout en France, et pas seulement par la préfecture de police de Paris.

Si la police comptait profiter de la crise sanitaire pour tester ses nouveaux gadgets, elle s’est trompée. Nous sommes là pour la ramener à la froide réalité des choses : ce n’est pas elle qui fait la loi.

Dans le contexte de la pandémie, le gouvernement recommande officiellement aux établissements d’enseignement supérieur la télésurveillance des examens à l’aide de dispositifs invasifs, discriminants et manifestement illégaux : reconnaissance faciale, vidéosurveillance par webcam et smartphone, détection de bruits suspects… Ou quand la Technopolice envahit l’enseignement. Ces dispositifs doivent être rejetés dès maintenant

En mars 2020, le ministère de l’Enseignement supérieur a publié un « plan de continuité pédagogique » composé de plusieurs fiches visant à accompagner les établissements dans le contexte de la pandémie (et depuis régulièrement mis à jour). La fiche n°6 « Évaluer et surveiller à distance » indique que « les examens écrits nécessitent une télé-surveillance particulière qui permet de vérifier l’identité de l’étudiant et d’éviter les fraudes. Ils nécessitent donc un recours à des services de télésurveillance ». Le document recommande ensuite aux établissements une liste de fournisseurs de services « qui ont l’habitude de travailler avec des établissements d’enseignement supérieur ».

Cette liste, qui est donc une recommandation officielle du gouvernement, fait la promotion d’outils de surveillance extrêmement invasifs, dangereux et profondément discriminants. Au programme : reconnaissance faciale, vidéosurveillance continue avec analyse comportementale (par utilisation simultanée de la webcam et du smartphone), voire détection sonore de bruits suspects.

Enseignement technopolisé

Commençons par une rapide présentation des pires solutions envisagées :

– Managexam propose des solutions de surveillance audio et vidéo, avec « prise de photos fréquentes, régulières ou aléatoires » ou « vidéo captée en continue ». Sur son site, l’entreprise promet de repérer « automatiquement les anomalies pouvant survenir dans la session d’évaluation grâce à une recherche et une classification visuelle de l’environnement des candidats » ;

– C’est le cas également pour Proctorexam, qui propose une « technologie avec deux prises de vues simultanées sur l’étudiant (webcam+appli smartphone) » et Evalbox, qui propose « des algorithmes d’analyse comportementale pour détecter les comportements suspicieux » ;

– TestWe, solution qui revient souvent dans les média, offre un système de photographie de la carte d’étudiant ou d’identité par webcam « pour vérifier que la bonne personne est en face de l’écran ». Son PDG, Benoît Sillard, se vante également de mettre « en place actuellement un système à double caméras, celle de l’ordinateur qui filme par l’avant, et celle de votre smartphone qui filme l’ensemble de la pièce, pour vérifier qu’il n’y a pas un deuxième ordinateur ou quelqu’un en train de vous souffler » ;

– et enfin Smowl qui « utilise un algorithme de reconnaissance automatique des visages pour vérifier l’identité de l’utilisateur en ligne et un système qui détecte les comportements incorrects ».

Ces services ne sont malheureusement pas nouveaux et sont déjà utilisés par plusieurs établissements. Selon le document du ministère, c’est notamment le cas de l’Université de Caen-Normandie depuis 2017 et de Sorbonne Université (même s’il est difficile de connaître exactement la solution mise en place). Le contexte de la pandémie provoque une démultiplication leur utilisation et plus de 50 universités et écoles seraient en train d’envisager ce type de procédés.

Surveillance et discrimination

Ces dispositifs sont pourtant profondément intrusifs : ces logiciels bloquent les ordinateur des étudiant.es, déclenchent une double surveillance obligatoire de la webcam et de la caméra du téléphone et nécessitent quelquefois un enregistrement sonore. Mais il est également nécessaire de prendre en compte les profondes discriminations que ces outils risquent d’entraîner, notamment pour les étudiant·es n’ayant pas l’équipement adapté, ou un environnement propice à ce genre d’examens (la surveillance visuelle et sonore nécessite un lieu à soi, sans bruits, etc.).

Ce sont bien ces mêmes arguments qui ont déjà été soulevés par le journal Le Poing (à ne pas confondre avec Le Point) qui souligne le « protocole aussi kafkaïen qu’orwellien, intrusif pour sa vie privée, et lourd de contrainte, en particulier pour les étudiants précaires » et le SNESUP-FSU (syndicat d’enseignement supérieur) qui dénonce ces dispositifs en considérant justement que « la plus grande liberté laissée aux établissements d’une dématérialisation complète des examens pouvant faire appel à de la télésurveillance, outre qu’elle se heurte à des problèmes techniques souvent insurmontables, facilite la réalisation par les établissements d’un suivi individualisé des enseignant·es, au mépris de leur liberté pédagogique, et accentue potentiellement l’inégalité des étudiant·es ».

Illégalités manifestes

Il est encore plus étonnant de voir le gouvernement recommander des solutions aussi manifestement illégales. Car en ce qui concerne le système de reconnaissance faciale ou d’enregistrement sonore d’une voix en particulier, l’article 9 du règlement général sur la protection des données (RGPD) interdit tout traitement de données biométriques « aux fins d’identifier une personne physique de manière unique » – ce qui est bien le cas ici. Et si cette interdiction de principe souffre quelques exceptions, aucune d’elle ne permet d’autoriser ce type d’outils (et sûrement pas le « consentement » de l’élève, qui doit être libre, c’est-à-dire non contraint…).

De manière générale, outre que personne ne devrait être forcé à une surveillance constante par sa webcam ou son téléphone, les solutions décrites ci-dessus ne sont en aucun cas « adéquates, pertinentes et limitées à ce qui est nécessaire » comme le recommande pourtant le RGPD (article 5) – Nous ne voyons pas ici quel objectif rendrait licite une surveillance d’une telle intensité. Ce qui rend la plupart de ces dispositifs simplement illégaux.

Voir le gouvernement recommander de telles solutions illustre sa fuite systématique vers la surveillance numérique. Fuite que nous appelons les établissements d’enseignement à ne pas suivre en renonçant à ces dispositifs invasifs

Recommander ces méthodes est d’autant plus dommageable que des alternatives existent, comme l’annulation ou le report des examens, ou plus simplement le passage d’une évaluation en contrôle terminal à une évaluation en contrôle continu. Mieux encore : cette situation inédite peut être l’occasion de préférer de véritables innovations pédagogiques à de pseudo-innovations techniques. Plutôt que de fonder l’évaluation sur la crainte de la triche, il serait ainsi possible d’évaluer élèves et étudiant·e·s sur leurs compétences, d’aménager individuellement les évaluations, ou de recourir à l’auto-évaluation supervisée.

<style>.space{margin-bottom: 1em;}

Tribune de Guinness, doctorante en informatique et membre de La Quadrature du Net

À l’heure où toutes les puissances de la planète se mettent à réfléchir à des solutions de traçage de contact (contact tracing), les GAFAM sautent sur l’occasion et Apple et Google proposent leur propre protocole.
On peut donc se poser quelques minutes et regarder, analyser, chercher, et trouver les avantages et les inconvénients de ce protocole par rapport à ses deux grands concurrents, NTC et DP-3T, qui sont similaires.

Commençons par résumer le fonctionnement de ce protocole. Je me base sur les documents publiés sur le site de la grande pomme. Comme ses concurrents, il utilise le Bluetooth ainsi qu’un serveur dont le rôle est de recevoir les signalements de personnes infecté·es, et de communiquer aux utilisateurices de l’application les listes des personnes infectées par SARS-Cov2 qu’elles auraient pu croiser.

Mais commençons par le début.

Le protocole utilisant de nombreux protocoles et fonctions cryptographiques, et étant assez long, je ne vais pas l’expliquer en détail, et si vous voulez plus d’informations, vous pouvez vous référer à la note en bas de page.¹L’application commence par générer un identifiant unique de 256 bits. Suffisamment long pour qu’il n’y ait pas de risque de collisions (deux personnes qui génèrent par hasard – ou non – le même identifiant), et ce même si toute la population terrestre utilisait l’application. Cet identifiant est appelé Tracing Key.
Puis, chaque jour, un identifiant pour la journée (appelé Daily Tracing Key) est calculé à partir de la Tracing Key. Pour ce faire, on utilise la fonction à sens unique HKDF, qui permet à partir de paramètres d’entrée de générer une clef unique et à partir de laquelle il est impossible en pratique de remonter aux informations d’origine. Dans notre cas, les paramètres d’entrée sont la Tracing Key et le numéro du jour courant, ce qui nous permet de calculer une clef journalière de 128 bits.
Pour la dernière étape, le protocole dérive un nouvel identifiant, celui qui sera communiqué via Bluetooth aux autres utilisateurices de l’application: le Rolling Proximity Identifier (RPI) un « identifiant de proximité continu » au sens où celui-ci change constamment. Il est recalculé toutes les 15 minutes, chaque fois que l’adresse physique de la puce Bluetooth change et on stocke un nombre appelé TIN_j qui augmente de 1 toutes les 15 minutes de même que j ; à la différence que j est réinitialisé chaque jour. On utilise pour calculer la RPI la fonction HMAC, une autre fonction à sens unique, qui utilise comme paramètres la Daily Tracing Key du jour courant ainsi que le TIN_j du quart d’heure en cours.
Finalement, la partie intéressante : que se passe-t-il lorsqu’une personne est déclarée infectée ?
L’application crée une clef de diagnostic, qui n’a ici aucune fonction cryptographique : on envoie les dernières 14 Daily Tracing Keys, ainsi que les numéros des jours associés, puis on continue chaque jour d’envoyer les 14 dernières Daily Tracing Keys ainsi que le jour associé (voir ce PDF au paragraphe §CTSelfTracingInfoRequest) . Cette clef est ensuite envoyée sur un serveur qui stocke toutes les clefs de diagnostic.
Par ailleurs, de manière fréquente, les client·es récupèrent la liste des clefs de diagnostic, utilisent ces clefs pour recalculer tous les RPI, et voir si dans la liste des personnes croisées, on retrouve un de ces RPI. Si c’est le cas, on prévient l’utilisateurice.<script type="text/javascript"> jQuery("#footnote_plugin_tooltip_6574_1").tooltip({ tip: "#footnote_plugin_tooltip_text_6574_1", tipClass: "footnote_tooltip", effect: "fade", fadeOutSpeed: 100, predelay: 400, position: "top right", relative: true, offset: [10, 10] });

Pour faire simple, on génère initialement une clef (Tracing Key ou TK), qu’on utilise chaque jour pour calculer une nouvelle clef (Daily Tracing Key ou DTK), qu’on utilise elle-même toutes les 15 minutes pour calculer une troisième clef (Rolling Proximity Identifier ou RPI), qu’on va appeler la «clef roulante de proximité», qui sera diffusée avec le Bluetooth.
Ce qu’il faut retenir, c’est que l’identifiant qui est diffusé via le Bluetooth change toutes les 15 minutes, et qu’il est impossible en pratique de déduire l’identité d’une personne en ne connaissant que cet identifiant ou plusieurs de ces identifiants.

Par ailleurs, si on se déclare comme malade, on envoie au serveur central la liste des paires (DTK, jour de création de la DTK) des 14 derniers jours, et de même pendant les 14 jours suivants. Cet ensemble forme ce qu’on appelle la clef de diagnostic.

Cryptographie

D’un point de vue cryptographique, tous les spécialistes du domaine (Anne Canteaut, Leo Colisson et d’autres personnes, chercheureuses au LIP6, Sorbonne Université) avec lesquels j’ai eu l’occasion de parler sont d’accord : les algorithmes utilisés sont bien connus et éprouvés. Pour les spécialistes du domaine, la documentation sur la partie cryptographique explique l’utilisation des méthodes HMAC et HKDF avec l’algorithme de hashage SHA256. Les clefs sont toutes de taille suffisante pour qu’on ne puisse pas toutes les générer en les pré-calculant en créant une table de correspondance également appelée « Rainbow table » qui permettrait de remonter aux Tracing Keys . L’attaque envisagée ici consiste à générer le plus de TK possibles, leurs DTK correspondantes et lorsque des DTK sont révélées sur quelques jours, utiliser la table de correspondance pré-calculée pour remonter à la TK.

On peut faire un gros reproche cependant : la non-utilisation de sel (une chaîne de caractères aléatoires, différente pour chaque personne et définie une fois pour toutes, qu’on ajoute aux données qu’on hashe) lors de l’appel à HMAC pour générer les DTK, ce qui est une aberration, et pire encore, aucune justification n’est donnée par Apple et Google.

Respect de la vie privée et traçage

Quand on écrit un protocole cryptographique, selon Apple et Google « with user privacy and security central to the design » (Traduction : « avec le respect de la vie privée de l’utilisateurice et la sécurité au centre de la conception »), on est en droit de chercher tous les moyens possibles de récupérer un peu d’information, de tracer les utilisateurices, de savoir qui iels sont.

Premier problème : La quantité de calcul demandée aux clients

À chaque fois que le téléphone du client récupère la liste des clefs de diagnostic des personnes déclarées malades, il doit calculer tous les RPI (144 par jour, faites moi confiance c’est dans le protocole, 144 * 15 min = 24 h) de toutes les clefs pour tous les jours. On peut imaginer ne récupérer que les nouvelles données chaque jour, mais ce n’est pas spécifié dans le protocole. Ainsi, au vu de la quantité de personnes infectées chaque jour, on va vite se retrouver à court de puissance de calcul dans le téléphone. On peut même s’imaginer faire des attaques par DoS (déni de service) en insérant de très nombreuses clefs de diagnostic dans le serveur pour bloquer les téléphones des utilisateurices.

En effet, quand on se déclare positif, il n’y a pas d’information ajoutée, pas d’autorité qui assure que la personne a bien été infectée, ce qui permet à tout le monde de se déclarer positif, en faisant l’hypothèse que la population jouera le jeu et ne se déclarera positive que si elle l’est vraiment.

Deuxième problème : Le serveur principal

Un design utilisant un serveur centralisé (possédé ici par Apple et Google), qui a donc accès aux adresses IP et d’autres informations de la part du client gagne beaucoup d’informations : il sait retrouver quel client est infecté, avoir son nom, ses informations personnelles, c’est-à-dire connaître parfaitement la personne infectée, quitte à revendre les données ou de l’espace publicitaire ciblé pour cette personne. Comment cela se passe-t-il ? Avec ses pisteurs embarqués dans plus de 45% des applications testées par Exodus Privacy, pisteurs qui partagent des informations privées, et qui vont utiliser la même adresse IP, Google va pouvoir par exemple recouper toutes ces informations avec l’adresse IP pour savoir à qui appartient quelle adresse IP à ce moment.

Troisième problème : Traçage et publicité

Lorsqu’on est infecté⋅e, on révèle ses DTK, donc tous les RPI passés. On peut donc corréler les partages de RPI passés avec d’autres informations qu’on a.

Pour aller plus loin, nous avons besoin d’introduire deux notions : celle d’adversaire actif, et celle d’adversaire passif. L’adversaire actif tente de gagner activement de l’information, en essayant de casser de la cryptographie, de récupérer des clefs, des identifiants. Nous avons vu précédemment qu’il a fort peu de chance d’y arriver.
L’adversaire passif quant à lui se contente de récupérer des RPIs, des adresses physiques de puces Bluetooth, et d’essayer de corréler ces informations.

Ce dernier type d’adversaire a existé et existe encore . Par exemple, la ville de Londres a longtemps équipé ses poubelles de puces WiFi, permettant de suivre à la trace les smartphones dans la ville. En France, l’entreprise Retency, ou encore les Aéroports de Paris font la même chose avec le Bluetooth. Ces entreprises ont donc des réseaux de capture de données, et se révéler comme positif à SARS-Cov2 permet alors à ces entreprises, qui auront capté les RPIs envoyés, de pister la personne, de corréler avec les données de la publicité ciblée afin d’identifier les personnes infectées et donc revendre des listes de personnes infectées.
On peut aussi imaginer des implémentations du protocole qui stockent des données en plus de celles demandées par le protocole, telles que la localisation GPS, ou qui envoient des données sensibles à un serveur tiers.

D’autres attaques existent, dans le cadre d’un adversaire malveillant, mais nous ne nous attarderons pas dessus ; un article publié il y a quelques jours (en anglais) les décrit très bien : https://eprint.iacr.org/2020/399.pdf.

Nous pouvons ainsi voir que, même si le protocole est annoncé comme ayant la sécurité et le respect de la vie privée en son centre, il n’est pas exempt de défauts, et il y a même, à mon avis, des choix techniques qui ont été faits qui peuvent permettre le traçage publicitaire même si on ne peut en prouver la volonté. Alors même que tous les pays du monde sont en crise, et devraient investir dans du matériel médical, dans du personnel, dans les hôpitaux, dans la recherche de traitements contre SARS-Cov2, ils préfèrent se tourner vers un solutionnisme technologique qui non seulement n’a aucune assurance de fonctionner, mais qui également demande que plus de 60 % de la population utilise l’application pour être efficace (voir cet article pour plus d’informations).
D’autant plus qu’une telle application ne peut être efficace qu’avec un dépistage massif de la population, ce que le gouvernement n’est actuellement pas en état de fournir (à raison de 700k tests par semaine, tel qu’annoncé par Édouard Philippe dans son allocution du 28 avril, il faudrait environ 2 ans pour dépister toute la population).

Pour plus d’informations sur les possibles attaques des protocoles de contact tracing, en particulier par des adversaires malveillants, je vous conseille l’excellent site risques-tracage.fr écrit par des chercheureuses INRIA spécialistes du domaine.

<script type="text/javascript"> function footnote_expand_reference_container() { jQuery("#footnote_references_container").show(); jQuery("#footnote_reference_container_collapse_button").text("-"); } function footnote_collapse_reference_container() { jQuery("#footnote_references_container").hide(); jQuery("#footnote_reference_container_collapse_button").text("+"); } function footnote_expand_collapse_reference_container() { if (jQuery("#footnote_references_container").is(":hidden")) { footnote_expand_reference_container(); } else { footnote_collapse_reference_container(); } } function footnote_moveToAnchor(p_str_TargetID) { footnote_expand_reference_container(); var l_obj_Target = jQuery("#" + p_str_TargetID); if(l_obj_Target.length) { jQuery('html, body').animate({ scrollTop: l_obj_Target.offset().top - window.innerHeight/2 }, 1000); } }

L’application StopCovid ne fera finalement pas l’objet d’un vote à l’Assemblée nationale, le gouvernement se refusant à tout risque de vote contraire à sa volonté. Pourtant, les prises de position s’accumulent contre elle et son avenir semble chaque jour plus incertain.

Hier, la CNIL a rendu son avis à son sujet. Contrairement au Conseil national du numérique (CNNum) qui s’est prononcé vendredi en faveur de l’application, la CNIL n’a pas entièrement fui le débat : elle exige que le gouvernement démontre l’utilité concrète de StopCovid, ce qu’aucune étude ou analyse ne soutient actuellement. Hélas, alors que la CNIL aurait dû s’arrêter à ce simple constat pour demander l’arrêt de ce dangereux et inutile projet, elle s’est égarée dans le faux-débat tendu par le gouvernement : rechercher des « garanties », forcément illusoires, pour encadrer l’application.

Une nécessité non démontrée

L’idée au cœur du droit des libertés fondamentales est que, par principe, il est interdit de limiter nos libertés. Elles ne peuvent l’être que par exception, et uniquement en démontrant qu’une telle limitation est utile à un intérêt supérieur, telle que la santé publique dans notre cas. Hier, la CNIL a rappelé ce principe cardinal, qu’elle applique naturellement de longue date. Par exemple, dans son avis sur les portiques de reconnaissance faciale dans des lycées de la région Sud, elle avait bien rappelé qu’il revenait au responsable de traitement de données« d’évaluer la nécessité et la proportionnalité du traitement envisagé ». Un tel raisonnement l’avait conduit à considérer que le projet de reconnaissance faciale était contraire au RGPD, car la région n’avait pas démontré cette nécessité.

Il ne fait pas de doute que StopCovid est une mesure limitant les libertés fondamentales, ce que la CNIL reconnaît facilement : risques d’attaques malveillantes, de discriminations, d’accoutumance à la surveillance constante, de dévoiement par le gouvernement. La CNIL exige donc que les prétendus bienfaits sanitaires de l’application soient démontrés avant que celle-ci ne soit déployée, ce qui fait jusqu’ici défaut. La rigueur du raisonnement de la CNIL tranche nettement avec l’avis du CNNum, qui conclut en faveur de StopCovid hors de toute méthode d’analyse sérieuse.

Toutefois, il faut regretter que la CNIL se soit arrêtée là, sans conclure et répondre elle-même à la question qu’elle a si justement posée. Si aucun élément factuel ne prouve l’efficacité d’une technique qu’elle reconnaît pourtant comme attentatoire aux libertés fondamentales, la mission de la CNIL est de déclarer celle-ci illégale. Déclarer illégaux des traitements de données injustifiés est une des missions centrales qui justifient l’existence de la CNIL.

Mais, refusant de tenir son rôle, la CNIL s’est ensuite perdue dans le débat vain souhaité par le gouvernement : chercher à tâtons les garanties pouvant encadrer cette pratique. Pourtant, les conditions pour que StopCovid respecte nos libertés sont impossibles à remplir. L’essence même du « traçage de contact », automatique comme manuel, rend impossible l’anonymat, et le contexte de crise sanitaire rend irréaliste la garantie d’un consentement libre.

Un anonymat impossible

Cédric O affirme que les données traitées par StopCovid « seraient anonymes ». De même, Bruno Sportisse, directeur de l’INRIA chargé du protocole ROBERT sur lequel reposera l’application, affirme que celle-ci serait « totalement anonyme ».

En pratique, une application anonyme n’aurait aucun intérêt : l’application doit envoyer à des personnes ciblées des alertes du type « vous avez été au contact de personnes malades, mettez-vous en quarantaine ». Du moment que chaque alerte est envoyée à des personnes ciblées, le système n’est plus anonyme : trivialement, il suffit qu’un tiers (un patron, un conjoint, etc.) puisse consulter votre téléphone pour constater que vous avez reçu une alerte. Des chercheu·ses de l’INRIA ont produit une excellente liste de quinze scénarios de ce type, démontrant à quel point il était simple de lever ce prétendu « anonymat ».

Hélas, le CNNum s’enfonce dans le déni de réalité et continue de prétendre que « les utilisateurs de l’application ne peuvent pas se réidentifier entre eux ». Dans une étrange note de bas de page, l’avis du CNNum admet que cette affirmation est peut-être fausse puis renvoie vers les scénarios de l’INRIA. Voilà la triste posture du CNNum : mentir dans le corps du texte et s’excuser en pied de page, en petits caractères.

De son côté, heureusement, la CNIL est plus honnête et ne cache pas ces failles : les données traitées par StopCovid sont des pseudonymes ré-identifiables. Mais elle refuse d’en tirer la moindre conséquence effective. Après avoir exigé quelques mesures de sécurité nécessaires qui ne changeront pas le fond du problème, elle semble se bercer dans l’illusion que le droit serait une garantie suffisante pour empêcher que ce pseudonymat si fragile ne soit levé. Au final, sa seule « garantie » n’est rien d’autre que ce cher RGPD que la CNIL échoue à faire respecter depuis deux ans, quand elle ne s’y refuse pas carrément (lire notre article sur les cookies publicitaires).

Un consentement impossible

Tout comme l’utilisation faussée de la notion de données « anonymes », le gouvernement fonde la création de StopCovid sur le fait que l’application serait installée « volontairement ». Une telle présentation est encore mensongère : matériellement, l’État ne pourra pas s’assurer que l’application ne soit pas imposée par des tiers.

Si des employeurs, des restaurants ou des centres d’hébergement exigent que leurs salariés ou usagers utilisent StopCovid, que va faire Cédric O ? Leur envoyer la police pour forcer le passage ? Si la pression vient de la famille ou des amis, que va faire la CNIL ? Leur imposer des amendes en violation du RGPD – qu’encore une fois elle ne fait déjà pas respecter avec énormément de sites internet ?

L’urgence est partout ailleurs

Comme nous ne cessons de le répéter, il est urgent que ce débat prenne fin, par le rejet de ce projet. L’attention du public, du Parlement et de la recherche doit se rediriger vers les nombreuses autres solutions proposées : production de masques, de tests, traçage de contacts réalisé par des humains, sans avoir à réinventer la roue. Leur efficacité semble tellement moins hasardeuse. Surtout, contrairement à StopCovid, ces solutions ne risquent pas de légitimer sur le long terme l’ensemble de la Technopolice, qui cherche depuis des années à rendre acceptable la surveillance constante de nos corps dans l’espace public par la reconnaissance faciale, les drones ou la vidéo automatisée.

Les 28 et 29 avril, dans le cadre des mesures de déconfinement, l’Assemblée nationale débattra de StopCovid, sans toutefois voter spécifiquement à son sujet. L’Assemblée doit exiger la fin de cette application. Rendez-vous sur cette page pour contacter les député·es.