Après avoir collé un lien à lecture unique dans un chat qui génère un aperçu, pourquoi le nombre de lectures n'est pas forcément déjà consommé

Quand vous collez une adresse du type https://…/s.html?id=…#… dans Slack, Discord, Microsoft Teams ou WhatsApp, une petite carte s'affiche souvent sous le champ de saisie ou sous le message : un titre, une phrase d'extrait, parfois une icône. Beaucoup la lisent comme « le lien a déjà été ouvert ». L'ordre est l'inverse. L'outil envoie d'abord un GET HTTP à cette adresse, extrait du HTML og:title, og:description ou un simple <title>, puis dessine la carte. Le destinataire n'a encore rien cliqué.

Slack le décrit en français et en anglais. La page d'aide Partager des liens et définir vos préférences pour les aperçus dit qu'un aperçu du contenu s'affiche sous le message, et que la plupart des URL sont « automatiquement développées ». Côté technique, Slack appelle cela le classic link unfurling dans Unfurling links in messages : quand un lien est détecté, Slack le parcourt et fournit un aperçu. Le robot qui récupère la page se nomme Slackbot-LinkExpanding 1.0 (+https://api.slack.com/robots). Sur Slack Robots, Slack écrit qu'il prend le moins possible de la page (en-têtes HTTP Range) pour extraire les balises oEmbed, Twitter Card et Open Graph. Il ne récupère une image, une vidéo ou un fichier audio que si une balise y pointe, pour en vérifier la validité. Les réponses sont mises en cache côté service pendant environ 30 minutes. La page ne dit pas que le JavaScript de la page est exécuté, ni qu'un bouton est cliqué à la place de l'utilisateur.

Quand un navigateur — ou un robot d'aperçu qui se comporte comme un navigateur — envoie ce GET, le texte après # n'entre pas dans la ligne de requête. L'IETF définit le fragment, dans RFC 3986 §3.5, comme un identifiant côté client : le serveur ne s'en sert pas pour traiter l'URI. Même si le robot recopie toute la chaîne vue dans le champ de saisie, la requête qui atteint UsePwd s'arrête en général à s.html?id={id}. Pourquoi la clé n'apparaît pas dans les journaux d'accès, c'est l'objet de Pourquoi le fragment # d'une URL n'apparaît pas dans les journaux serveur. Ici, il s'agit de la couche suivante : un GET qui n'a jamais porté la clé compte-t-il comme « une lecture ».

Beaucoup de liens à usage unique accrochent le secret à exactement l'URL que le robot d'aperçu interroge en GET. Le robot demande une fois ; le serveur renvoie le corps et efface l'enregistrement. Le destinataire ouvre ensuite « déjà lu » ou une 404. Cet échec est fréquent. Slack ne « brûle » pas le secret par malveillance. L'implémentation traite un GET pouvant être mis en cache — méthode que la RFC 9110 continue de décrire comme sûre — comme l'action qui détruit le texte chiffré.

Le lien unique UsePwd sépare le travail en trois étapes. À la création, l'onglet actuel chiffre avec Web Crypto et AES-256-GCM. Texte en clair : 32 KB au plus. Les seuls champs envoyés sont le texte chiffré, une expiration et un nombre de lectures. L'expiration peut être 1 heure, 24 heures, 7 jours, ou « détruit après lecture seulement » sans TTL horaire. Les lectures vont de 1 à 10, 1 par défaut. L'URL partagée a la forme s.html?id={id}#{key}. Création et lecture s'utilisent dès l'ouverture : aucun des deux côtés ne s'inscrit. Le serveur ne stocke que le texte chiffré. Il ne voit pas le texte en clair, et il n'existe pas de compte qui permettrait de le retrouver par utilisateur.

Quand le destinataire ouvre la page de lecture, l'onglet demande d'abord à /api/secrets/{id}/status si le texte chiffré est encore là. La réponse est active, burned ou expired. Le compteur n'augmente pas, l'enregistrement reste. Ce n'est qu'après Ouvrir et afficher que le navigateur appelle /api/secrets/{id}, récupère le texte chiffré et le déchiffre en local avec la clé après #. Une fois le nombre fixé à la création atteint, le serveur supprime le texte chiffré ; un nouvel appel renvoie 410. Un robot d'aperçu qui s'arrête au HTML de la page de lecture n'a, dans le cas courant, ni la clé ni l'intention de cliquer sur ce bouton.

Le robot d'expansion de liens Slack, le collecteur d'embeds Discord et la requête côté serveur dont Microsoft Teams se sert pour construire une carte appartiennent à la même famille : GET de la page, puis recherche d'un titre et d'un extrait dans le HTML. Discord s'identifie comme Mozilla/5.0 (compatible; Discordbot/2.0; +https://discordapp.com). Les descriptions publiques de Discordbot s'accordent sur une limite que vous pouvez traiter comme hypothèse de travail : il analyse le HTML renvoyé par le serveur et n'exécute pas le JavaScript. Slack est explicite sur une autre limite. Après avoir expérimenté robots.txt, Slack a cessé de le respecter comme le ferait un crawler de recherche, parce que le développement d'un lien « agit pour le compte d'un humain » et ne parcourt pas le site. Mettre noindex sur la page de lecture peut empêcher les moteurs de l'indexer. Cela n'empêchera pas la carte dans le canal.

La page de lecture UsePwd est une vue temporaire de texte chiffré. Elle porte noindex, nofollow et n'entre pas dans le plan du site. Le titre du document est fixé à « Ouvrir un lien unique ». La description dit seulement que le déchiffrement se termine dans cet onglet et que la clé se trouve après #. Si une carte d'aperçu apparaît, le canal voit cette phrase générique — pas le mot de passe, le jeton ou le texte de ticket que vous avez saisi. Cela peut être vrai en même temps que « le journal d'accès n'a pas le fragment ». La carte prouve qu'un GET a touché la page d'atterrissage. Le journal n'a toujours pas la clé après #.

Slack indique que le résultat d'expansion d'une même URL est mis en cache pendant environ 30 minutes. Coller deux fois le même lien de test dans un canal, dans un intervalle court, ne produit pas forcément une seconde récupération. Pour vérifier « un robot est-il passé », cherchez un User-Agent du type Slackbot-LinkExpanding ou Discordbot dans vos propres journaux d'accès. Ne vous fiez pas au nombre de rafraîchissements de la carte. Un GET vers s.html ne permet toujours pas de conclure que /api/secrets/{id} a été appelé.

Le consommateur le plus courant est le destinataire lui-même : il ouvre le lien complet, voit « Le texte chiffré est encore là », puis clique sur « Ouvrir et afficher ». Le nombre par défaut est 1. Après cet appel réussi, le serveur supprime le texte chiffré ; la même URL rouverte indique « Déjà détruit ». Si vous avez fixé 2 lectures ou plus à la création, le texte chiffré reste après les premiers appels, jusqu'à ce que le compteur atteigne la limite. L'expiration le supprime aussi : 24 heures par défaut, ou 1 heure, ou 7 jours ; « détruit après lecture seulement » ne coupe que sur le nombre, pas sur l'horloge.

La deuxième classe, ce sont les environnements qui exécutent les scripts et simulent un clic. Certaines passerelles de sécurité messagerie et certains bacs à sable de liens ouvrent l'URL dans un navigateur isolé ; quelques-uns cliquent aussi le bouton principal de la page. Ce n'est plus « dessiner une carte », c'est une autre visite complète, comme celle d'une personne. Si le bac à sable clique sur « Ouvrir et afficher », la lecture est consommée et le destinataire verra ensuite l'état détruit. Cette couche se vérifie dans le rapport de la passerelle, pas en déduisant depuis la carte du chat.

La troisième classe, c'est d'envoyer directement l'adresse de l'API qui délivre le texte chiffré. L'adresse de lecture est s.html?id= ; celle qui consomme une lecture est /api/secrets/{id}. Un utilisateur ordinaire ne copie pas la seconde. Si quelqu'un colle l'URL de l'API dans un canal qui génère un aperçu, et que cet outil traite le premier GET comme une récupération de texte chiffré, la lecture sera consommée dès l'aperçu. La forme de partage UsePwd n'emprunte pas cette adresse : la page de création copie le lien de lecture, avec #.

L'outil de messagerie conserve l'adresse entière que vous avez collée. Quiconque peut chercher l'historique, exporter l'espace de travail ou ouvrir une sauvegarde peut rouvrir la page de lecture. Tant que des lectures restent, une personne qui ouvre plus tard peut encore cliquer sur « Ouvrir et afficher » et lire le texte en clair. Une fois le nombre épuisé, l'historique garde un lien déjà détruit, plus le titre de la carte d'alors. L'export d'un administrateur ne ressuscite pas un texte chiffré déjà supprimé sur le serveur ; il n'efface pas non plus le fait que l'URL complète a figuré dans le canal.

Capture d'écran et transfert sont une autre copie. Dès que quelqu'un photographie le texte en clair après une lecture réussie, ou renvoie le lien vers un autre groupe qui génère un aperçu, la frontière n'est plus « ce GET-ci » mais « par qui passe le saut suivant ». Un lien unique limite la durée de vie et le nombre de lectures du texte chiffré sur le serveur ; il ne limite pas les captures côté destinataire. UsePwd n'a ni compte ni coffre, et ne peut pas retrouver un lien perdu par utilisateur. Pour une conservation durable ou une synchro entre appareils, il faut un gestionnaire de mots de passe dédié. L'identité du produit est dans À propos.

Les fichiers sont un troisième chemin. Une sauvegarde locale d'un fichier unique de 5 GB au plus passe par Chiffrer un fichier, au format .lock / .enc ; le fichier n'est pas envoyé par défaut. Le mot de passe lui-même se génère entre 6 et 128 caractères, puis se vérifie dans Tester un mot de passe. Ces pages, comme celle-ci, s'utilisent dès l'ouverture. Ne lisez pas « l'aperçu n'a pas consommé de lecture » comme « coller dans n'importe quel canal est sûr » : l'historique du canal et la récupération d'aperçu ne sont pas la même couche.