Dans un produit digital, la sécurité des données ne se résume pas seulement à la robustesse technique du code. Une phase de conception qui prend en compte ces enjeux est cruciale afin de préserver l’anonymat des utilisateurs.
Même anonymes, lorsque beaucoup de données sont produites par une application elles courent le risque d’être désanonymisées par regroupement et corrélations. Ce billet explore des cas de désanonymisation des données personnelles pour réfléchir aux choix que les designers peuvent faire – dès les premières ébauches – pour prévenir ces risques.
Anonymiser des datas, c’est quoi ?
En me replongeant dans mes notes je suis retombé sur ce podcast de Stack Overflow. Nous sommes au printemps 2020 et les applications pour tracer le virus commencent à faire leur apparition. Pour la plupart, elles collectent en masse des données sensibles de géolocalisation. La problématique est claire : » comment éviter une brèche qui verrait un acteur mal intentionné mettre la main sur la géolocalisation de millions d’utilisateurs ? «
Une principale réponse à cette problématique est : l’anonymisation des données. Un processus qui consiste à modifier le contenu ou la structure des datas afin de les exploiter tout en rendant difficile l’identification des personnes concernées.
Mais voilà, anonymiser des données, c’est déjà un acte de conception en soi. On doit arbitrer : de quoi ai-je besoin pour le bon fonctionnement de mon système et de quoi puis-je me passer ? Pour les applications de traçage du virus se pose également la question des informations que je vais délivrer aux utilisateurs : bien qu’anonyme dans quelle mesure est-ce qu’informer l’utilisateur qu’il a été en contact durant sa journée avec une personne malade ne peut pas être deanonymisé ?
Les risques de désanonymisation, c’est exactement le type de sujet qui peut être abordé par les designers dès l’acte de conception de l’expérience. Alors, face à ces questions j’ai décidé de mener des recherches sur des cas qui pourraient nous inspirer des bonnes pratiques, comme nous prévenir des mauvaises.
L’application Strava à produit deux cas intéressant à étudier, chacun représentatifs de ce qu’il faut faire et de ce qu’il faut éviter. C’est ceux-ci qui seront développés dans la suite de ce billet.
Analyser les usages pour protéger les utilisateurs
Récemment Strava, l’application de tracking et partage d’itinéraires pour sportifs, a proposé aux utilisateurs d’anonymiser une partie de leurs données.
En Août 2021 Strava a mis à jour ses paramètres de confidentialité pour permettre aux utilisateurs de mieux contrôler ce que les autres peuvent voir de leurs parcours. Auparavant, les utilisateurs ne pouvaient définir des zones de confidentialité qu’autour des adresses qu’ils avaient saisies dans l’application afin de les garder secrète.
Désormais, les utilisateurs peuvent masquer jusqu’à un kilomètre des points de départ et d’arrivée de leurs activités, et par défaut quelques mètres seront retirés des itinéraires partagés. La review de ces fonctionnalités est faite en détail sur ce blog.
Ce n’est pas une sécurisation technique à proprement parler. C’est la prise en compte de l’anonymat des utilisateurs tout en livrant l’expérience promise. L’utilisateur est ici acteur de ce qu’il souhaite dévoiler publiquement en plus d’être, par défaut, protégé.
La question de la sécurité des données est d’autant plus un acte de conception dans ce cas que l’application est centrée sur la question du “trajet”. Historiquement, on imagine Strava plutôt destiné à une population de sportifs aguerris qui partagent des tracés de trail ou autres longues distances. A l’époque l’intérêt est tout trouvé : Strava devient un répertoire de tracés dans la nature que l’on peut reproduire.
C’est un shift dans l’usage de l’application qui a rendu les données confidentielles plus accessibles et plus faciles à désanonymiser. Lorsque Strava entre dans le mainstream, l’application n’est plus uniquement peuplée de sportifs aventuriers, elle compte aussi des amateurs qui enregistrent leurs performances quotidiennement près de leur domicile ou travail. La mise en ligne de son footing autour de chez soi devient donc bien plus sensible et pousse Strava à adapter des fonctionnalités pour protéger cette donnée.
Désanonymiser dans la masse
Et c’est justement ce shift dans l’usage de l’app qui verra Strava devenir un des exemples tristement fameux lorsque l’on parle de désanonymisation de datas.
En novembre 2017, Strava publie une « heat map » mondiale basée sur les données des utilisateurs. Les données ont été recueillies au cours des années 2015 et 2017 et consistaient en 16 milliards de km de courses enregistrées.
L’année suivante, Nathan Ruser, un étudiant australien, a publié sur Twitter que les emplacements de bases militaires du monde entier étaient révélés par la carte thermique produite par Strava.
La faille n’est pas technique, mais bien dans l’acte de conception. En 2017 Strava est déjà mainstream, et les usages ont déjà shiftés. Comme le tout venant, les militaires de tous pays trackent leurs footings quotidiens sur leurs bases, lesquelles deviennent identifiables sur la heat map comme l’a révélé le travail de Nathan Ruser. Ici on ne desanonymise pas la donnée à l’échelle d’un utilisateur, mais plutôt de groupes – et pas n’importe lesquels – dont on localise les bases et routines d’entraînement.
L’ambition était pourtant intéressante de la part de Strava. En suivant son identité “tracé centric” historique, cette heat map aurait révélé les spots de trail, vtt et autres les plus prisés par leur utilisateurs. C’était sans compter le shift dans l’usage de l’application qui devient un outil de tracking du quotidien.
Autres cas de désanonymisation de masses de données
Au-delà de Strava, bien des exemples nous guident dans les « choses à ne pas faire » quand il en va d’usage de datas anonymisées. Toujours dans l’épisode 232 du podcast de stack-overflow les chroniqueurs citent le très fameux AOL Search Data Leak.
En 2006, une équipe de la branche recherche d’AOL publie volontairement des données qui comprennent 20 millions de requêtes web provenant de 650 000 utilisateurs, sans leur permission. Bien que les noms aient été remplacés par un numéro d’identification aléatoire, l’analyse de toutes les recherches effectuées ont permis de remonter la trace de certains utilisateurs, et donc de désanonymiser la data. Au-delà de simples recherches en ligne, les données comprennent évidemment des noms, des adresses, des numéros de sécurité sociale qui ont rendu l’exercice d’identification d’autant plus simple pour certains profils.
Un autre exemple frappant est celui des Taxi New Yorkais. En 2014 la Commission des taxis et des limousines de New York a publié un ensemble de données concernant presque 200 millions de courses de taxi dans la ville de New York. Cet ensemble de données était censé être utilisé pour améliorer l’efficacité du système de taxi, mais son analyse a permis de révéler bon nombre d’informations personnelles, notamment les adresses et revenus de certains. La vidéo faite sur le sujet par le collectif Tactical Tech nous montre la “puissance” de la corrélation de plusieurs datasets à l’heure de désanonymiser la data.
Dans cet article, nous avons exploré des cas où la désanonymisation des données a eu lieu malgré des efforts d’anonymisation. Ces exemples soulignent l’importance d’aller au-delà de la simple anonymisation, car les comportements et les usages des utilisateurs peuvent changer, rendant les données vulnérables.
Les designers, en utilisant leur expertise en analyse des usages des utilisateurs, peuvent anticiper les risques et concevoir, avec les développeurs et les experts en sécurité, des mécanismes de protection des données par défaut.