Confidentialité des messages
Collogue peut-il lire mes messages privés ?
Ce que le code actuel exécuté dans le navigateur peut et ne peut pas consulter lorsqu’il chiffre un message Collogue.
Publié le: 14 janvier 2026
Limites de l’implémentation actuelle
Les liens Collogue actuels portent la charge utile chiffrée dans l’URL. Le navigateur utilise l’API Web Crypto : PBKDF2-SHA-256 avec 310 000 itérations dérive une clé AES-GCM de 256 bits à partir du mot de passe saisi séparément, avec un sel aléatoire de 16 octets et un IV de 12 octets. Le client actuel n’envoie aucune requête à une API applicative pour créer, récupérer ou stocker des messages.
Le mot de passe n’est pas encodé dans le lien. L’implémentation ne fournit ni affichage à usage unique, ni suppression côté serveur, ni minuteur d’expiration. Considérez le lien complet comme sensible et transmettez le mot de passe par un autre canal.
Contexte complémentaire
« Le service peut-il lire mon message ? » semble appeler une réponse par oui ou par non. Techniquement, plusieurs questions se cachent derrière cette phrase.
Une réponse utile sépare ces questions au lieu de les dissimuler derrière un seul adjectif.
Le message lisible s’appelle le texte en clair. Le résultat chiffré est le texte chiffré. Un bon chiffrement doit rendre le texte chiffré inutilisable sans la clé nécessaire.
La question suivante est de savoir d’où vient la clé et qui peut l’obtenir.
Si Collogue utilise un mécanisme différent, l’explication publique doit décrire ce mécanisme plutôt que d’emprunter à un autre produit l’histoire du fragment d’URL.
Supposons qu’un site chiffre les messages dans le navigateur. Vous inspectez aujourd’hui la requête réseau et confirmez qu’aucun texte en clair n’est envoyé. Très bien.
Cela ne rend pas le chiffrement dans le navigateur inutile. Cela précise ce que cette protection signifie.
Un dépôt consultable publiquement peut améliorer la transparence. Il ne prouve pas que la version déployée correspond exactement au dépôt sans processus de publication vérifiable. Un audit indépendant peut renforcer la confiance. Il ne transforme pas une application web qui évolue en théorème mathématique.
La sécurité reste une affirmation technique étayée par des éléments vérifiables.
Ces protections sont utiles précisément parce qu’elles sont limitées.
- l’appareil de l’expéditeur est compromis ;
- l’appareil du destinataire est compromis ;
- une extension de navigateur malveillante lit la page ;
- l’expéditeur donne le lien à la mauvaise personne ;
- quelqu’un transmet le lien complet avant son ouverture ;
- le destinataire copie ou enregistre le message ;
- l’application web envoyée au navigateur est malveillante ;
- le secret lui-même est faible, réutilisé ou trop privilégié.
Le chiffrement contrôle l’accès aux informations selon les hypothèses annoncées. Il n’abolit pas les comportements humains.
N’employez ce terme que si l’architecture, la gestion des clés, le code déployé et le modèle opérationnel le justifient. Une charge utile chiffrée dans le navigateur ne suffit pas à trancher toutes les interprétations de « zero knowledge ».
La réponse dépend de la présence de texte en clair, de texte chiffré, de clés ou de données suffisantes pour dériver les clés. Publiez le schéma vérifié et le chemin des clés plutôt qu’un slogan.
Oui. Le destinataire doit finalement reconstruire le texte en clair pour le voir. À ce moment, l’environnement du navigateur et l’appareil font partie du modèle de confiance.
Créez un lien privé Collogue pour envoyer un mot de passe, un jeton, un code de récupération ou une autre valeur sensible courte.