Un slogan ne se vérifie pas. Le trafic, si.
Beaucoup jugent une page de « chiffrement en ligne » à une phrase : calcul local, zéro envoi, bout en bout. Ces phrases peuvent figurer sur n’importe quel site, y compris celui qui envoie le fichier en POST au serveur pour le chiffrer là-bas. Ce n’est pas une preuve.
Ce que vous pouvez vraiment voir sur place, ce sont les requêtes émises par cet onglet. Le panneau Network des outils de développement liste la méthode, l’adresse, la query, le corps, et une partie des statistiques. Si le nom du fichier que vous venez de choisir, la phrase secrète, ou un clair « canari » que vous seul connaissez apparaît à ces endroits, le chiffrement local ne tient pas.
À l’inverse, l’absence de clair dans Network ne dit que ceci : cette opération n’a pas envoyé ces champs comme données métier. Elle ne prouve pas qu’il n’y a pas de clair en mémoire, qu’une extension n’a pas lu le presse-papiers, ni que la prochaine version se comportera pareil. L’intérêt de la vérification : transformer une promesse incontrôlable en observation reproductible.
« Local » : à quelle couche de calcul cela correspond
« Navigateur local » ne veut pas dire « ce nom de domaine a l’air sûr », mais « le chiffrement a lieu dans l’onglet que vous regardez ». Pour AES-256-GCM, le chemin correct habituel est l’appel à l’API Web Crypto : dérivation de clé, chiffrement et étiquette d’authentification se font dans l’interface cryptographique du navigateur, pas en envoyant le clair à une API distante.
Le déroulement typique d’un chiffrement de fichier : vous choisissez un fichier local, le script le lit en blocs binaires en mémoire, chiffre bloc par bloc, puis déclenche le téléchargement du chiffré. Le .lock ou .enc téléchargé est le fichier résultat, pas un accusé d’upload. Si la limite est écrite à 5 Go par fichier, c’est la capacité de traitement en flux sur cet appareil, pas 5 Go de clair reçus par un serveur.
Il faut aussi séparer « envoi métier » et « requêtes que la page émet de toute façon ». Un site d’outils prêt à l’emploi charge encore styles et scripts, et peut envoyer des statistiques sans le corps du texte. Ces requêtes ne suffisent pas à accuser un « fichier envoyé » ; mais si la query ou le body d’une stat contient la phrase secrète ou le mot de passe que vous venez de saisir, c’est une autre affaire.
Écrire la frontière de calcul en phrases vérifiables vaut mieux que des adjectifs : pour le générateur, le test de force, la suppression des UTM et le chiffrement de fichiers, texte en clair et clés restent par défaut dans le navigateur ; le lien auto-destructible n’autorise que le texte chiffré à partir, la clé de déchiffrement étant derrière #. MakePwd implémente les outils selon cette frontière, tous sans compte. Une promesse reste une promesse. Ci-dessous, Network la transforme en points de contrôle.
N’utilisez pas de vraies clés, pièces d’identité ou tableaux non masqués pour l’essai. Préparez un petit fichier jetable, et une phrase secrète à usage unique. On vérifie le trafic, on ne réexpose pas une vie privée.
Faire avec Network un contrôle reproductible
Préparez d’abord une marque qui n’apparaît pas dans un vrai flux métier. Le fichier peut s’appeler canary-local-2026.xlsx, la phrase secrète une longue phrase aléatoire, le corps une phrase unique à cet essai. Le canari sert à chercher : collez-le dans le filtre Network ; un hit = échec.
Ouvrez les outils de développement, allez dans Network, cochez Preserve log, filtrez XHR / Fetch. Ne regardez pas seulement les « requêtes réussies » : une requête annulée ou en 4xx a pu déjà emporter du clair.
Puis faites une opération complète : choisir le fichier, saisir la phrase secrète, lancer le chiffrement ou la génération. Ensuite, ne fermez pas le panneau ; regardez les trois endroits ci-dessous.
- Collez la chaîne canari dans le filtre et cherchez d’abord un hit en rouge. S’il y en a un, arrêtez-vous et lisez cette requête : inutile de continuer à « sentir » que c’est local.
- Sans hit, ouvrez ensuite chaque XHR / Fetch et comparez la ligne de requête, la query et le corps. Les ressources statiques, polices et scripts peuvent être ignorés.
- Filtrez à part les chemins de statistiques, puis ouvrez query et body. Le titre de page et le chemin peuvent apparaître ; la phrase secrète, le mot de passe testé, le texte avant nettoyage et le contenu du fichier ne doivent pas.
Regarder la ligne de requête
Le path et la query après ? dans l’URL complète méritent une lecture mot à mot. Un champ de localisation comme id peut apparaître ; le nom de fichier, la phrase secrète, le mot de passe testé et la clé après # ne doivent pas. Comparez toute la barre d’adresse à la ligne de requête : si ce qui suit le dièse y entre, l’implémentation a traité le fragment comme une query, ou un script l’a lu puis réécrit dans la requête.
Regarder le corps de requête
Le payload POST / PUT est le deuxième endroit. Si le chiffrement de fichier est annoncé comme local, le corps ne doit contenir ni le binaire du fichier d’origine, ni la phrase secrète. Un lien auto-destructible peut avoir un champ chiffré : c’est la donnée prévue à l’envoi ; vérifiez qu’il ne ressemble pas au clair que vous venez de saisir. Si la page de test de mot de passe envoie le mot de passe en POST, que le motif soit « chercher une fuite » ou « calculer la force », il a déjà quitté l’appareil.
Regarder à part les envois d’analyse
Les statistiques d’audience sont souvent oubliées. Une API métier propre avec un envoi qui porte tout le champ de saisie : l’opération ne compte toujours pas comme « clair resté dans le navigateur ». En filtrant les chemins de stats, ne supposez pas qu’« un script d’analyse est forcément inoffensif » : c’est une autre requête sortante, à contrôler comme une API métier.
Cochez Preserve log. Après chiffrement, si la page redirige ou se recharge, la première requête portant du clair peut déjà avoir disparu sans cette case : vous obtiendriez un faux « panneau vide ».
Le point d’interrogation entre dans HTTP ; le dièse, en principe, non
L’URL a deux parties souvent mélangées. La query après le point d’interrogation entre dans la ligne de requête HTTP : serveur, reverse proxy et journaux d’accès la voient. Le fragment après le dièse reste par défaut dans le navigateur, pour le script de la page courante, et n’est pas envoyé avec cette requête de document.
Donc, si un lien chiffré à usage unique met la clé dans #, quand le destinataire ouvre s.html?id=...#clé, le serveur ne doit voir que id, pas la clé. Ce n’est pas un protocole de chiffrement supplémentaire, c’est le comportement par défaut du fragment. Il a une limite : si vous collez l’adresse complète dans un ticket, un chat ou une page de redirection qui jette le hash, la clé passe de « hors HTTP » à « visible sur l’écran et dans les journaux d’autrui ».
La méthode de contrôle est tout aussi concrète : créez un lien de test et voyez si le body de création ne contient que du chiffré ; à l’ouverture de la page de lecture, voyez si l’URL de la requête document et des appels suivants ne contient que id. Ce qui suit # dans la barre d’adresse ne doit pas apparaître dans ces requêtes. La page de lecture est publique pour le destinataire, sans connexion.
| Où regarder | Entre-t-il dans HTTP ? | Critère de réussite |
|---|---|---|
| Slogan de la page | Sans objet | Pas une preuve, seulement un point de comparaison |
| Ligne de requête / query | Oui | Pas de canari, pas de phrase secrète, pas de clé de fragment |
| Corps POST | Oui | Pas de clair ; le lien auto-destructible n’autorise que le chiffré |
Fragment URL # |
Par défaut, non | Présent dans la barre d’adresse, absent de la ligne de requête |
| Statistiques d’audience | Selon l’implémentation | Pas le clair des champs de saisie |
Ce que vous pouvez prouver, et ce que vous ne pouvez pas
La conclusion que ce contrôle soutient est étroite ; l’écrire clairement la rend plus utile.
Cela peut soutenir : dans ce navigateur, cette version et cette opération, le clair, les phrases secrètes et la clé de fragment n’ont pas quitté l’onglet comme données HTTP métier observées ni comme texte d’analyse.
Cela ne peut pas soutenir : aucun autre onglet ou extension ne lit le presse-papiers ; le dossier Téléchargements est sûr ; le destinataire ne fera pas de capture après déchiffrement ; le test de mot de passe couvre toutes les bases de fuites. Si le testeur ne fait qu’une entropie locale plus une liste publique Top de mots de passe faibles, il répond à « cela ressemble-t-il à un mot de passe faible courant », pas à « il n’est jamais apparu dans une fuite ». Ce n’est pas un contrôle HIBP mondial.
Ne le prenez pas non plus pour un test d’intrusion. Vous n’avez pas inspecté les WebSocket ni le cache des Service Workers, ni inversé un script obfusqué. L’objectif : pouvoir dire à un collègue que vous avez ouvert Network, cherché le canari, et que la ligne de requête et le body étaient propres. C’est plus proche d’une discussion d’ingénierie que de relayer « le site dit que rien n’est envoyé ».
Appliquer les mêmes étapes aux outils MakePwd
Si vous voulez une page qui écrit clairement la frontière de calcul, commencez par le chiffrement de fichiers MakePwd. Ouverture immédiate, sans inscription. Prenez un petit fichier sans vraie vie privée, une phrase secrète canari, chiffrez et téléchargez un .lock. Surveillez Network : vous devez voir des ressources statiques et éventuellement des statistiques, pas le fichier d’origine ni la phrase secrète comme champs métier. L’algorithme indiqué sur le site est AES-256-GCM, calculé dans Web Crypto, un fichier jusqu’à 5 Go.
Le lien auto-destructible convient au second exercice : créez un texte de test inoffensif et confirmez que ce qui part est du chiffré. La page de lecture est publique pour le destinataire ; la forme du lien est s.html?id={id}#{key}. Le test de mot de passe convient à « le contenu du champ entre-t-il dans les stats » : le mot de passe testé n’est pas envoyé, la comparaison se fait sur une liste locale.
Ces exercices ne prouvent pas qu’un site est « absolument sûr ». Ils familiarisent avec la même checklist. Sur toute page qui affirme un chiffrement local, les étapes restent : canari, Preserve log, ligne de requête, corps, envois d’analyse.
Trois points à retenir la prochaine fois
Premier : regarder le trafic, pas le slogan. Deuxième : un chiffré sortant peut être acceptable ; clé et clair, non. Troisième : refaire la recherche canari après un changement de navigateur, de version ou de fonction. Seule une observation reproductible mérite d’entrer dans vos propres notes de sécurité.
Si la question suivante est « pourquoi la clé peut-elle rester après le dièse », lisez Pourquoi le fragment après # d’une URL convient pour une clé, et quand cette protection lâche. Ici, on ne fait que transformer « le clair a-t-il quitté cet onglet » en contrôle faisable sur place.