Après avoir fermé un onglet à lecture unique, pourquoi la clé après # revient encore depuis les onglets récemment fermés

Dès que vous ouvrez https://…/s.html?id=…#…, la barre d'adresse tient deux morceaux à la fois : l'identifiant du texte chiffré après le point d'interrogation, et la clé de déchiffrement après #. Fermer cet onglet se lit facilement comme « la clé n'est plus sur cet ordinateur ». Le navigateur fait exactement l'inverse. Pour le retour arrière, l'avant, la reprise après plantage et les onglets récemment fermés, il doit garder l'URL entière de cette navigation. Chromium appelle cet enregistrement par onglet l'historique de session (session history) : une entrée de navigation stocke l'URL du moment, la position de défilement et les données de formulaire non envoyées. Après la fermeture d'un onglet ou un redémarrage du navigateur, ces entrées sont sérialisées pour que l'onglet revienne tel quel. Voir le document Chromium Session History.

Firefox range la même famille de fonctions sous Session Restore. Il suit les fenêtres, les onglets et les onglets récemment fermés, et écrit sur le disque l'historique de chaque onglet, la position de défilement et les formulaires, pour que le démarrage ou « Annuler la fermeture » puisse les relire. Voir Firefox Source Docs : Session Restore. Microsoft Edge est bâti sur Chromium : rouvrir un onglet fermé emprunte le même historique de session — pas une règle à part qui « garderait le titre et jetterait le fragment ».

Cette couche n'est pas la requête HTTP. L'IETF, dans la RFC 3986 §3.5, définit le fragment comme une identification côté client. Le serveur ne s'en sert pas pour traiter l'URI. Les journaux d'accès UsePwd ne contiennent donc pas la clé après #. Cette frontière est déjà détaillée dans Pourquoi le fragment # d'une URL n'apparaît pas dans les journaux serveur. Cet article complète la couche suivante : un fragment qui n'entre jamais dans la requête peut tout de même entrer dans votre propre historique de navigateur. Fermer l'onglet arrête cet affichage. Cela n'efface pas automatiquement l'URL entière assise dans l'historique de session.

Dans Chrome ou Edge, appuyez sur Ctrl+Maj+T, ou ouvrez Historique → Onglets récemment fermés. Le navigateur prend cet enregistrement de session et ouvre l'URL qu'il contient. La liste officielle des raccourcis Chrome nomme cette action « Rouvrir les onglets précédemment fermés dans l'ordre où ils ont été fermés » ; voir Raccourcis clavier dans Chrome. La liste Firefox des onglets récemment fermés fait de même depuis le Session Store : l'URL de l'entrée d'historique active devient la cible de la restauration. Le fragment fait partie de l'URL, ce n'est pas un ornement à côté du titre. La restauration n'a pas d'étape supplémentaire pour l'enlever.

L'historique long terme et l'historique de session ne sont pas non plus le même magasin. Quand Chromium écrit une URL dans la base d'historique, il retire le nom d'utilisateur et le mot de passe. La conversion ne vide pas le fragment. La fonction est Chromium GurlToDatabaseUrl. Une adresse à lecture unique qui montre encore # dans chrome://history ne contredit donc pas « la requête n'avait pas de fragment » : la base d'historique stocke la chaîne entière que vous avez visitée ; la ligne de requête reste seulement s.html?id={id}.

Le clic droit « Dupliquer l'onglet » est un chemin plus court. Chromium documente que dupliquer un onglet — ou exécuter Précédent, Suivant ou Actualiser dans un nouvel onglet — clone les entrées de navigation directement, au lieu de les écrire dans un fichier puis de les relire. La barre d'adresse de l'onglet cloné est en général la même chaîne qu'avant, y compris # et la clé. Sur un ordinateur partagé, c'est plus rapide que de fouiller l'historique : la personne à côté n'a pas besoin de savoir chercher dans l'historique. Dupliquer l'onglet suffit.

Quand vous ajoutez la page de lecture aux favoris, le navigateur enregistre la chaîne affichée dans la barre d'adresse. L'étoile ne demande pas d'abord « le texte après # est-il une clé ? » pour ne stocker que le chemin. Plus tard, n'importe quel appareil qui synchronise les favoris peut ouvrir cette entrée et réafficher le lien entier. Le guide iCloud d'Apple indique qu'après avoir activé Safari dans iCloud, les signets et les onglets ouverts sont stockés dans iCloud et restent à jour sur iPhone, iPad et Mac ; les signets se synchronisent aussi vers un PC qui exécute iCloud pour Windows. Voir Synchroniser Safari sur tous ses appareils avec iCloud.

Chrome liste « Historique et onglets » comme un élément de synchro que vous pouvez activer. Une fois activé, les onglets ouverts apparaissent sous Historique → Onglets d'autres appareils. La page d'aide est Accéder à vos favoris, à vos mots de passe et plus encore sur tous vos appareils. Le chemin « Envoyer l'onglet vers vos appareils » écrit le spec() entier du GURL dans l'enregistrement de synchro. Un fragment # ordinaire est sérialisé avec le reste de l'URL ; il n'est pas retiré d'abord. L'implémentation est Chromium SendTabToSelfEntry.

Ne traitez pas la feuille de partage système comme un favori. Dans Safari sur iPad, partager une URL qui contient un fragment vers Mail ne laisse parfois que la partie avant #. Sélectionner toute la barre d'adresse et copier conserve en général le fragment. C'est précisément le point : ne concluez pas « la clé a disparu » parce que vous avez touché Partager. Décidez d'après les caractères qui apparaissent réellement dans la barre d'adresse du destinataire — ou de l'autre appareil. Un robot d'aperçu de chat qui s'arrête au titre est un autre article. Une fois le lien entier dans un favori ou un enregistrement de synchro, ce n'est plus un robot d'aperçu.

Le Burn-Link UsePwd place la clé après # dans s.html?id={id}#{key}. Création et lecture s'ouvrent tout de suite — aucun des deux côtés ne s'inscrit. L'onglet actuel chiffre ou déchiffre avec Web Crypto et AES-256-GCM. Le texte en clair fait au plus 32 Ko. Les seuls champs envoyés sont le texte chiffré, une durée de vie et un nombre de lectures. L'expiration peut être 1 heure, 24 heures, 7 jours, ou « détruit après lecture seulement ». Les lectures vont de 1 à 10, 1 par défaut. Le serveur ne stocke que le texte chiffré. Il ne voit pas le texte en clair, et il n'existe pas de compte qui pourrait retrouver le secret par utilisateur.

Quand le destinataire ouvre la page de lecture, l'onglet demande d'abord si le texte chiffré est encore là. Cette vérification ne consomme pas de lecture. Ce n'est qu'après Ouvrir et afficher que le navigateur récupère le texte chiffré et le déchiffre en local avec la clé après #. Après un déchiffrement réussi, le fragment reste par défaut dans la barre d'adresse. Fermer l'onglet ou quitter la page vide la zone de texte en clair — la page de lecture écoute pagehide — mais ne réécrit pas l'adresse. Seul Effacer cette page appelle history.replaceState et ramène l'URL actuelle au chemin plus la requête, en retirant # et la clé qui suit. WHATWG définit replaceState comme le remplacement de l'entrée d'historique de session actuelle, pas l'ajout d'une nouvelle ; voir l'API History. Fermez l'onglet après cela, et les onglets récemment fermés restaurent une adresse qui n'a plus la clé.

Que le texte chiffré soit déjà parti du serveur dépend toujours uniquement du nombre et de la durée fixés à la création. Effacer cette page ne consomme pas une lecture de plus, et n'en économise pas une. Tant qu'il reste des lectures, quiconque a le lien entier peut encore cliquer sur Ouvrir et afficher. Une fois le nombre épuisé, le lien entier n'ouvre plus que l'état détruit — et l'adresse peut encore rester dans l'historique de session, les favoris et le chat. Pourquoi coller le même lien dans un chat qui génère un aperçu ne consomme pas toujours une lecture est expliqué dans 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é. Cet article couvre l'historique du navigateur du destinataire, pas la carte dans le canal.

La personne qui peut appuyer sur le raccourci est celle qui peut utiliser ce profil de navigateur. Un PC partagé, un bureau non verrouillé, ou un navigateur prêté et jamais déconnecté, transforment les onglets récemment fermés en un second moyen d'obtenir le lien. Vider la liste des onglets récemment fermés ou vider l'historique bloque ce raccourci. Cela ne bloque pas une URL entière déjà copiée dans un chat, un ticket ou une capture. Burn-Link limite la durée de vie du texte chiffré sur le serveur, et le nombre de lectures. Il ne décide pas qui peut encore voir l'adresse dans un enregistrement local.

Une fois le nombre de lectures épuisé, ouvrir le lien depuis l'historique n'affiche en général que l'état détruit. Ce n'est pas « l'historique est désormais sûr ». Un administrateur, un collègue ou vous-même pouvez encore lire dans cette chaîne qu'un identifiant a existé et que quelqu'un a utilisé un fragment comme clé. Un stockage long terme ou une synchro multi-appareils appartient à un gestionnaire de mots de passe dédié. UsePwd n'a ni compte ni coffre, et ne peut pas retrouver un lien perdu par utilisateur. L'identité est expliquée 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, écrit .lock / .enc, et n'envoie pas le fichier par défaut. Générez la phrase secrète elle-même dans le Générateur de mot de passe entre 6 et 128 caractères, puis contrôlez la force dans Tester un mot de passe. Ces pages, comme cet article, s'ouvrent tout de suite. Ne lisez pas « le fragment n'entre pas dans les journaux serveur » comme « fermer l'onglet détruit la clé ». Journaux, historique de session et historique de chat ne sont pas la même couche.