Toute exposition de données n'est pas forcément un défaut. Une messagerie peut choisir de révéler une information pour préserver une propriété qu'elle juge plus importante. Olvid, dont la conception repose sur la protection de la vie privée, fait ce choix dans deux cas que j'ai examinés. Voici ce qui se passe et pourquoi l'éditeur estime ces comportements acceptables.
IP du destinataireLes appels Olvid passent par un serveur relais TURN. Sur Android, l'appelant peut désigner ce serveur. S'il choisit un serveur qu'il contrôle, l'appareil de son interlocuteur s'y connecte dès que celui-ci accepte l'appel. Son adresse IP devient alors visible pour ce relais.
La position d'Olvid. L'éditeur a cessé d'imposer son propre relais en prévision d'une future fonctionnalité. Il souligne aussi que toute prise de contact dans Olvid exige déjà de connaître des informations sur la personne, comme son nom ou son numéro, qu'il juge plus identifiantes que la seule donnée exposée ici : l'IP publique du téléphone. Olvid estime donc cette exposition peu significative et ne la considère pas comme une vulnérabilité.
Mon point de vue. Une IP publique n'est pas de même nature que des coordonnées : elle renseigne sur une localisation approximative et peut évoluer dans le temps. Être déjà en contact ne revient donc pas à connaître cette IP. Il s'agit toutefois d'une appréciation liée au modèle de menace, et j'accepte la conclusion d'Olvid selon laquelle le risque résiduel est acceptable dans son modèle.
iOS — relais fixesAndroid — relais de l'appelantLe client iOS utilise des adresses de relais fixes et ignore celles de l'appelant ; le client Android les accepte. Olvid présente ce retour en arrière sur Android comme un choix délibéré pour préparer une fonctionnalité, et non comme un oubli.
Aperçus de liens : l'expéditeur,
pas le destinataire.
Olvid génère l'aperçu sur l'appareil de l'expéditeur et l'intègre au message chiffré. Le destinataire l'affiche sans rien télécharger. Contrairement à de nombreuses messageries, il n'y a donc pas de fuite sans clic du côté de la réception. En revanche, l'appareil de l'expéditeur consulte directement l'URL, sans proxy, et expose sa propre IP au serveur qui l'héberge.
La position d'Olvid. Un proxy côté serveur, comme celui de Signal, permettrait à Olvid de voir tous les liens partagés par ses utilisateurs, ce que l'éditeur juge contraire à son objectif de protection de la vie privée dès la conception. Il rappelle aussi que l'expéditeur a généralement déjà ouvert le lien. Le fonctionnement actuel est donc conservé tant qu'aucune solution ne protège l'IP de l'expéditeur sans permettre à un intermédiaire central de voir tous les liens.
J'accepte ce raisonnement. Deux dimensions de la vie privée sont ici en tension, et Olvid a choisi celle qui correspond à son modèle.
Un désaccord bien traité.
Les deux comportements sont réels et délibérés. Signalés via l'ANSSI / CERT-FR, ils ont été examinés avec l'éditeur. Après étude des arguments, je les ai acceptés comme des compromis de conception, pas comme des défauts. J'ai également retiré plusieurs observations initiales au cours du processus. C'est le principe de la divulgation coordonnée : tout constat ne débouche pas sur un correctif, et une explication claire du modèle de sécurité est aussi un résultat utile.