Métadonnées
Quelles métadonnées peuvent encore exister autour d’un message chiffré ?
Ce que le chiffrement protège et ce qui peut rester visible autour d’un lien Collogue.
Publié le: 27 avril 2026
Limites de l’implémentation actuelle
Le client actuel chiffre le texte dans le navigateur et place le contenu chiffré dans l’URL. Le mot de passe transmis séparément ne fait pas partie du lien. Aucun serveur applicatif ne stocke, ne récupère, ne supprime ou ne consomme les messages une seule fois.
Contexte complémentaire
Réponse directe : Le chiffrement peut protéger le contenu d’un message sans masquer tous les événements qui l’entourent. Dans l’implémentation actuelle côté client, l’application ne crée ni identifiants de message, ni paramètres d’expiration, ni événements d’accès. L’infrastructure réseau située en dehors de ce code peut néanmoins traiter les métadonnées ordinaires de connexion. La confidentialité du contenu et l’anonymat sont deux propriétés différentes.
Un message chiffré peut être illisible tout en restant visible en silhouette.
Un observateur ne saura peut-être pas ce qu’Alice a envoyé à Bob. Il pourra toutefois savoir qu’un message a été créé à 14 h 03, que sa charge utile chiffrée faisait 840 octets, qu’une requête provenait d’un réseau donné et que le lien a été consulté dix minutes plus tard.
L’importance de ces faits dépend du modèle de menace.
Le contenu est le message lui-même.
Tous les systèmes ne collectent pas tous ces éléments.
Un chiffrement correct doit rendre le texte chiffré inutilisable, sur le plan du calcul, pour retrouver le texte en clair sans la clé.
- les mots exacts ;
- les mots de passe ;
- les valeurs de jetons ;
- les notes personnelles ;
- le contenu structuré.
- l’existence du texte chiffré ;
- sa taille approximative ;
- le moment de son envoi ;
- le moment où il a été demandé ;
- les points du réseau à l’origine des requêtes.
Les systèmes cryptographiques protègent souvent plus facilement le sens que les circonstances.
- la connexion de l’utilisateur ;
- un VPN ;
- une passerelle d’entreprise ;
- un opérateur mobile ;
- un proxy inverse ;
- un analyseur de sécurité ;
- un réseau partagé.
Ce n’est pas une identité parfaite, mais cela reste potentiellement une métadonnée sensible.
Déterminez si Collogue ou son infrastructure la conserve, pendant combien de temps et dans quel but.
Ne dites pas que Collogue est anonyme simplement parce qu’aucun compte n’est requis.
Un identifiant opaque est préférable à un identifiant contenant des informations sur l’utilisateur ou le contenu. Il reste un marqueur d’événement corrélable s’il apparaît dans plusieurs journaux.
Le chiffrement ne masque généralement pas la longueur approximative du texte en clair, sauf si un remplissage est ajouté.
Pour la plupart des secrets courts, ce n’est pas le risque principal. Dans certains contextes, des motifs de taille peuvent révéler le type de message ou une activité.
Ne prétendez pas que Collogue masque la taille tant que le remplissage n’a pas été vérifié.
Les horodatages de création et d’expiration peuvent être nécessaires pour faire respecter le cycle de vie.
Ils peuvent aussi révéler un schéma d’activité.
Les outils d’analyse, de signalement d’erreurs, les CDN, les polices, les intégrations et les widgets d’assistance peuvent recevoir des métadonnées de requête.
- la page de création ;
- la page de résultat ;
- la page de révélation ;
- l’état où le message est déchiffré ;
- les pages « Comment fonctionne la confidentialité ».
Les routes sensibles à la confidentialité doivent éviter les requêtes externes superflues.
Si des identifiants ou des clés sensibles figurent dans les URL, la navigation et le chargement des ressources exigent une politique de référent soigneuse.
- la clé se trouve-t-elle dans un fragment, une requête ou un chemin ? ;
- des ressources tierces sont-elles chargées sur les pages de message ? ;
- quelle est la valeur de l’en-tête
Referrer-Policy? ; - quels attributs sont utilisés pour les liens externes ? ;
- les outils d’analyse capturent-ils les URL ?
Les fragments ne sont normalement pas envoyés dans les requêtes HTTP, mais les scripts de la page et les actions de l’utilisateur peuvent tout de même les exposer.
Aucun mot isolé comme « privé » ne répond à toutes ces questions.
Un service transparent indique quelle couche il protège.
- Utilisez un appareil de confiance.
- Évitez les environnements publics ou surveillés pour les échanges très sensibles.
- Utilisez des identifiants temporaires.
- N’ajoutez pas de contexte inutile.
- Demandez-vous si l’existence et le moment de l’échange sont eux-mêmes sensibles.
- Utilisez un système d’anonymat approuvé lorsque l’anonymat – et pas seulement la confidentialité du contenu – est requis.
- Respectez la politique de l’organisation pour les données réglementées.
Collogue ne doit pas se présenter comme un réseau d’anonymat s’il n’offre pas réellement ces propriétés.
Il ne devrait pas révéler le texte en clair exact avec un chiffrement correct, mais peut révéler une longueur approximative ou un motif de message.
Collogue peut protéger le contenu des messages selon son modèle vérifié, mais il ne faut pas le confondre avec un réseau d’anonymat.