Données personnelles minimales

Pour fonctionner, un système de communication n’a pas besoin de connaître le nom d’un utilisateur : un identifiant « aléatoire » suffit. Pour le mail, par exemple, tout fonctionnerait aussi bien avec des adresses composées de caractères tirés au hasard (même si ce serait probablement moins pratique).

Qu’entendons-nous ici par identifiant « aléatoire » ? C’est un identifiant qui protège son détenteur en garantissant deux propriétés :

• il est dédié, c’est-à-dire qu’il ne sert qu’à ce service de communication et à rien d’autre ;
• et il n’est lié à aucune donnée personnelle préexistante, ni dérivé d’un nom, d’une adresse email ou d’un numéro de téléphone.

Un identifiant tiré au hasard, spécifiquement pour le service, possède ces deux propriétés par construction : il ne révèle rien, et ne permet aucun recoupement.

Le numéro de téléphone : un identifiant rigide, impossible à multiplier, et recyclé

Dans cette optique, le numéro de téléphone échoue doublement. Il peut sembler « aléatoire » (une suite de chiffres sans signification apparente), mais il n’est ni dédié, ni délié : il sert à passer des appels, il est exigé par d’innombrables sites et services, et il est attribué par un opérateur qui connaît l’identité civile de son titulaire. Quiconque connaît votre numéro peut donc vous relier à vos autres comptes, et souvent à votre identité réelle. Loin d’être un identifiant anonyme, le numéro de téléphone est un pivot de recoupement.

Le numéro de téléphone présente un dernier défaut : on ne le choisit pas, et l’on ne s’en défait pas librement. Un identifiant aléatoire se crée, se multiplie et s’abandonne sans frais ; un numéro de téléphone, non. Comment maintenir deux comptes de messagerie parfaitement séparés, l’un personnel, l’autre professionnel, quand l’identifiant est un numéro de téléphone ? Il faut deux lignes téléphoniques. Comment conserver son compte quand on change de numéro, par exemple en s’installant à l’étranger ? Et que devient un numéro abandonné ? Il est réattribué : la carte SIM résiliée en quittant un pays, ou la ligne professionnelle rendue avec le téléphone en quittant une entreprise, finissent entre les mains d’un inconnu au bout de quelques semaines. Les contacts qui écrivent encore à ce numéro s’adressent alors à un étranger, et ce nouveau titulaire peut réenregistrer le compte de messagerie qui y était attaché. Nous expliquons d’ailleurs dans le critère sur la substitution d’identité, que cette nécessité de laisser un numéro réattribué changer de mains est précisément ce qui empêche Signal et WhatsApp de verrouiller durablement les comptes de leurs utilisateurs.

Un nom pour les contacts, pas pour le serveur

Si un identifiant aléatoire suffit, pourquoi nos adresses email contiennent-elles souvent nos noms ? Pour une raison purement pratique : retrouver un correspondant dans son carnet d’adresses est plus facile avec « marie.durand » qu’avec une suite de caractères sans signification. Mais cette commodité n’exige pas d’exposer le nom au serveur. Il suffit que le nom soit connu des contacts, qui l’associent, chacun dans leur carnet d’adresses, à l’identifiant aléatoire. Le nom est une information destinée aux humains ; l’identifiant, une information destinée aux machines. Rien n’impose que l’opérateur du service connaisse le premier.

Que doit réellement connaître le serveur ?

Dans une messagerie instantanée, le serveur a besoin d’un identifiant pour jouer son rôle de relais : savoir quels messages remettre quand un appareil vient les chercher, et quel appareil notifier quand un message arrive. Comme pour tout service en ligne, il voit par ailleurs nécessairement l’adresse IP depuis laquelle les requêtes lui parviennent. Enfin, en pratique, il conserve le plus souvent un jeton de notification par appareil, sur lequel nous revenons ci-dessous. L’inventaire s’arrête là : un identifiant, une adresse IP, un jeton. Rien d’autre n’est nécessaire pour opérer le service, c’est-à-dire faire transiter des messages. Toute donnée supplémentaire (nom, numéro de téléphone, adresse email, carnet d’adresses) est collectée pour d’autres raisons : faciliter la découverte des utilisateurs, ou lutter contre les faux comptes et le spam. Nous verrons dans le critère suivant que ce besoin découle lui-même d’un choix de conception : celui de permettre à n’importe qui de contacter n’importe qui.

Ce que tout serveur de relais observe : le graphe social

Aussi réduit soit-il, cet inventaire suffit à construire une information sensible : le graphe social. Pour distribuer les messages, le serveur connaît nécessairement, pour chaque utilisateur, la clé publique par laquelle celui-ci s’authentifie afin de récupérer les messages qui lui sont destinés, et l’adresse IP depuis laquelle il se connecte. L’envoi, en revanche, peut rester anonyme du point de vue du serveur : comme pour une lettre envoyée par la poste, rien n’impose d’identifier le déposant d’un message, et certaines solutions, comme Olvid, s’abstiennent effectivement de le faire. Cet anonymat applicatif ne protège pourtant pas le graphe : en corrélant les adresses IP et les horaires des dépôts et des relèves, le serveur peut reconstituer quel identifiant communique avec lequel, à quelle fréquence et à quels moments, quelle que soit la qualité du chiffrement.

La minimisation des données personnelles ne fait pas disparaître ce graphe ; elle détermine ce que l’opérateur peut attacher à chacun de ses nœuds. Sans aucune donnée personnelle, les nœuds restent pseudonymes : une clé publique, une adresse IP. Quand l’application exige un numéro de téléphone, comme Signal ou WhatsApp, chaque nœud est au contraire relié d’emblée à une identité civile : le graphe de pseudonymes devient un annuaire nominatif des relations de chacun. Entre les deux, chaque donnée fournie, même optionnelle, enrichit le nœud correspondant. Notons que SimpleX fait exception par construction : les identifiants y sont propres à chaque conversation, sans identifiant global qui les relie, ce qui fragmente les nœuds mêmes du graphe.

Le cas des jetons de notification push

Pour notifier l’arrivée d’un message, la plupart des messageries s’appuient sur les services de notification d’Apple et de Google. Le serveur de la messagerie conserve pour cela un « jeton push » par appareil. De son point de vue, ce jeton est un identifiant opaque de plus, qui ne révèle rien sur son détenteur. Mais il n’est opaque que pour lui : chez Apple et Google, ce même jeton est rattaché au compte de l’utilisateur, donc à son nom et à son adresse email. Fin 2023, une lettre^archivé du sénateur américain Ron Wyden a révélé que des gouvernements exigeaient d’Apple et de Google les données associées à ces jetons, précisément pour relier des utilisateurs anonymes de messageries à leur compte Apple ou Google ; Apple indique d’ailleurs, dans ses lignes directrices destinées aux forces de l’ordre, que l’identité associée à un jeton pouvait initialement être obtenue sur simple réquisition ; depuis la révélation, Apple exige^archivé une décision de justice. Autrement dit, même si la messagerie ne sait rien de vous, un tiers peut faire le pont entre votre identité de messagerie et votre identité réelle. C’est ce qui a conduit plusieurs messageries à proposer, sur Android, des mécanismes de notification alternatifs, sans jeton, reposant sur une connexion permanente au serveur : Threema avec Threema Push^archivé, Signal, dont l’application installée sans les services de Google^archivé bascule d’elle-même sur ce mode, et Olvid, où il suffit d’un réglage^archivé. Le prix en est une consommation de batterie légèrement accrue ; sur iOS, cette approche se heurte aux fortes limitations^archivé que le système impose aux connexions permanentes.

Moins de données, moins de risques

Chaque donnée que le serveur ne détient pas est une donnée qui ne peut être ni piratée, ni revendue, ni réquisitionnée. La minimisation des données n’est donc pas qu’une affaire de principe : c’est une réduction directe de la surface d’attaque. Elle a aussi une conséquence réglementaire appréciable pour les organisations : déployer une messagerie qui ne collecte pas de données personnelles réduit d’autant les traitements à justifier au titre du RGPD, et simplifie la mise en conformité.

Application de ce critère

Une messagerie obtient un ✅Bon si elle peut être utilisée sans fournir aucune donnée personnelle à l’opérateur : ni nom, ni adresse email, ni numéro de téléphone, et ne propose aucun moyen de lui en fournir. Un nom communiqué aux seuls contacts, et jamais au serveur, n’entre pas dans ce périmètre, comme expliqué plus haut. Les solutions où la fourniture de telles données à l’opérateur est possible mais optionnelle obtiennent un 🟠Partiel. Ces deux niveaux supposent en outre que la collecte s’arrête à l’inventaire décrit plus haut : un identifiant, une adresse IP, un jeton de notification. Une solution dont les serveurs conservent durablement les métadonnées des conversations (membres, expéditeurs, horaires), voire les disséminent vers d’autres serveurs, obtient un ❌Mauvais, indépendamment des identifiants demandés à l’inscription.