SHARE THE PERSPECTIVE

L’aperçu d’un lien peut déclencher une requête réseau avant même votre clic ; mais l’émetteur de cette requête et les informations visibles par le site de destination dépendent de la conception de la messagerie. La présence d’une miniature dans une conversation ne permet pas de conclure que les adresses IP de l’expéditeur et du destinataire ont toutes deux été exposées.

Le chiffrement de bout en bout protège le message sur son trajet entre les participants à la conversation. La récupération du titre et de l’image d’un site web emprunte un trajet distinct, qui doit être évalué séparément.

Trois façons différentes de créer un aperçu

Méthode Que voit le site de destination ? Question importante
Récupération directe par l’appareil L’IP de la connexion à l’origine de la requête et les informations qui l’accompagnent La requête a-t-elle lieu pendant la saisie, l’envoi ou la réception ?
Récupération via un intermédiaire ou un proxy Généralement l’IP de l’intermédiaire, plutôt que l’IP directe de l’utilisateur Que voit et conserve l’intermédiaire lui-même ?
Création de l’aperçu par l’expéditeur, puis envoi dans le message Le destinataire peut ne pas avoir à se connecter au site de destination pour afficher la carte Les images de la carte sont-elles locales ou récupérées à nouveau sur le Web ?

Ces méthodes peuvent être combinées. Signal a par exemple décrit l’utilisation d’un proxy pour les aperçus dans son explication technique de 2019. Ce document constitue un exemple de conception ; il ne faut pas l’étendre sans vérification à toutes les versions ni à toutes les applications. Le guide actuel de Signal explique comment désactiver la création des aperçus et supprimer une carte avant l’envoi.

IP, identifiant de lien et identité ne sont pas la même chose

Le site de destination voit l’IP de l’entité qui établit la connexion réseau : il peut s’agir de l’appareil, d’un VPN ou d’un proxy. Une IP seule n’est généralement ni le nom d’une personne ni l’adresse précise de son domicile. Toutefois, associée à l’heure de la requête et à d’autres données, elle peut servir à relier des événements.

Un lien comportant un identifiant unique peut également indiquer que cette URL précise a été demandée. Cette observation ne prouve pas à elle seule qui l’a lue : la requête peut provenir d’un aperçu, d’un outil de sécurité, de l’expéditeur, du destinataire ou d’une personne à qui le lien a été transféré.

De plus, l’adresse IP n’est pas nécessairement un champ dans HTTP ; elle fait partie de la communication réseau. Le type et la valeur des en-têtes, tels que User-Agent, dépendent du logiciel à l’origine de la requête.

Récupérer le titre d’une page n’équivaut pas à l’exécuter entièrement

Certains aperçus se contentent de récupérer et de traiter le HTML et les images. Cela ne signifie pas nécessairement exécuter JavaScript ou ouvrir la page dans un navigateur. À l’inverse, le préchargement ou l’affichage d’une page dans un environnement web peut se comporter autrement.

Posez donc deux questions distinctes : « Une requête est-elle envoyée au site ? » et « Le contenu actif de la page est-il exécuté ? » La réponse à l’une ne détermine pas celle à l’autre.

Réglages pratiques pour les conversations sensibles

  • Si vous n’avez pas besoin de carte d’aperçu, vérifiez l’option de génération automatique de l’application. Supprimer une carte après sa création n’annule pas la requête déjà effectuée.
  • Traitez les liens inconnus et les liens personnalisés de connexion, de récupération ou de partage de fichiers comme des données sensibles. Ne les soumettez pas à des services publics d’analyse d’URL pour les tester.
  • Ne supprimez pas arbitrairement les paramètres d’un lien signé : cela pourrait compromettre l’accès ou sa validité. Si possible, obtenez une version publique et non personnalisée de la page auprès de la source d’origine.
  • Ne confondez pas la désactivation des aperçus avec le blocage de toutes les connexions réseau. L’ouverture des liens, les images externes et les autres fonctions ont chacune leurs propres trajets.
  • Pour une évaluation en organisation, utilisez une URL inoffensive sous votre contrôle et un appareil de test afin de vérifier quand les requêtes sont créées ; ne généralisez pas les résultats d’une version à tous les appareils.

Que peut-on dire de Livara ?

Le modèle de menace de Livara explique les limites de la protection du contenu privé ainsi que celles des appareils et du réseau. Cette explication générale ne permet pas de conclure que chaque aperçu, dans chaque version, utilise obligatoirement une connexion directe ou un proxy. Une telle affirmation nécessite une documentation de la fonctionnalité ou un examen de la version concernée.

Pour la confidentialité des liens, le trajet de la requête compte davantage que l’apparence de la carte d’aperçu.

Explorer l’architecture de sécurité de Livara
CONTINUE THE THREADPrivate messaging ↗
YOU’VE REACHED THE ENDBack to the reading room ↗