Je vois toujours pas de réponse de la part de Signal. Il est possible qu'ils ne considèrent pas la suppression de messages (automatiques ou manuels) comme une fonctionnalité de sécurité mais plutôt comme un truc permettant juste d'économiser du stockage. C'est un peu ce qui est suggéré par leur page d'aide sur le sujet. Mais c'est quand même dommage qu'ils ne prennent pas la peine de répondre du tout.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Si j'ai bien suivi, ce n'est pas la suppression des messages qui ne fonctionnerait pas comme attendu, mais les messages éphémères: quand le délais d'affichage est dépassé, l'application Signal n'affiche plus le message, mais elle le conserve en base de donnée d'après cette analyse.
If a user deletes a message in the Signal app (or uses its “disappearing messages” feature), the corresponding database entry is hidden from the app and marked for deletion in the Write-Ahead Log. According to Sintonen, it can take days, or even weeks for infrequently used Signal instances, until this deletion is executed and the message thus disappears from the device.
(Interprétation sur la base du même document ou échange avec l'auteur du document ?)
Le message est supprimé de la base de données (un SELECT ne le retournera plus) mais au niveau du fichier, la suppression est d'abord notée dans un fichier annexe (le fameux WAL) avant d'être "appliquée" sur le fichier principal en différé.
Ce n'est pas particulièrement surprenant quand on sait comment fonctionne sqlite, mais du coup le message n'est pas "supprimé" du fichier tant que le fichier principal n'est pas modifié.
Par ailleurs il existe un problème similaire pour tous les systèmes de fichiers, il n'y a pas de garantie que les changements soient appliqués sur le disque tant qu'on n'a pas appelé fsync(), ce que beaucoup de programmes ne font pas pour des raisons de performance.
Pour revenir à sqlite par contre, je ne comprends pas bien pourquoi ils utilisent le mode WAL vu qu'a priori il n'y a pas de soucis de performance particuliers (base petite, une seule connexion).
Je pense qu'il y a le même problème avec PostgreSQL, quand les données sont supprimées par requête SQL elles restent encore longtemps quelque part sur le disque.
Je ne crois pas que ce soit un problème du point de vue du RGPD.
C'est comme quand tu as ton nom comme auteur dans un truc comme git.
C'est un processus technique qui implique cette rétention, parfois plusieurs années, le RGPD n'a pas grand chose à dire là-dessus.
Ce qui doit être fait est d'expliciter dans le registre des traitements l'existence de ces sauvegardes/archives/journaux, pour quelle durée (qui pourrait être infinie dans le cas d'un historique git) et pour quelle raison.
Juste parce que c'est un processus techniques ne veut pas dire que ça n'est pas quelque chose qui doit être pris en compte d'un point de vue RGPD. Techniquement, tu peux tout à fait supprimer un nom d'un historique git : il suffit de réécrire l'historique. Je comprend que ça entre en conflit avec le workflow de beaucoup de gens/organisations mais je connais des organisations qui utilisent un tel mécanisme pour remplir leurs obligations de protection des données.
Donc, oui, quand tu utilises PostgreSQL, SQLite, git, ext4 ou tout autre système de stockage dans un cadre où tu as des « obligations » de supprimer les données (que ça soit RGPD ou feature d'auto-deletion de messages), il convient de comprendre comment ce stockage fonctionne pour pouvoir remplir ces obligations.
Selon le cas d'utilisation, un autre mécanisme de « suppression » de données qui sont répliquées à plein d'endroits (backups, journaux de filesystem,…) est de chiffrer ces données, de stocker la clé de manière plus contrôlée et de supprimer juste la clé. Les copies ne sont techniquement pas supprimées mais à partir du moment où plus personne n'a la clé (et que le chiffrement est suffisamment fort), c'est fonctionnellement équivalent.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
je connais des organisations qui utilisent un tel mécanisme pour remplir leurs obligations de protection des données
Et bien, quel courage ! Tu aurais un exemple d'une telle organisation qui s'est donné les moyens pour le cas d'un gestionnaire de version de code comme git ? J'avais l'impression - fausse semble-t-il - que c'est tellement disproportionné, que ça n'en devient pas applicable en pratique.
Pour les sauvegardes et les journaux, ces données ont en général une durée de vie limitée (de quelques jours à quelques années le plus souvent), donc attendre la rotation naturelle est une bonne manière de régler la question, du moment que c'est documenté comme tel.
Pour des archives (rétention potentielle de plusieurs décennies), je vois mal comment régler la question sans altérer l'intégrité de l'archive. Une bonne méthode serait de ne pas archiver les données personnelles dans l'archive mais à côté, par personne. Ça pourrait être tenable dans le cas où ces infos sont secondaires, mais pas si elles sont primaires. Dans ce dernier cas, déclarer l'intérêt légitime de conserver la donnée est une réponse.
Tiens, ça me rappelle un truc rigolo. Un jour une prestataire qui préparait un devis pour un service d'archivage me demandait avec quel logiciel on supprimait les données des disques durs en fin de vie ou hors service. Je lui ai dit qu'on perçait les plateaux à plusieurs endroits. Ce a quoi elle m'a répondu "mais, ce n'est pas conforme au RGPD ça". Ça m'a surpris :).
Tu aurais un exemple d'une telle organisation qui s'est donné les moyens pour le cas d'un gestionnaire de version de code comme git
Quand j'étais chez Google, l'équipe qui s'occupe du gestionnaire de version de code (Piper) recevait régulièrement des requêtes internes pour censurer l'historique qui contenait des informations personnelles (e.g. numéro de téléphone d'(ex)employés). Ils avaient une procédure pour cela et l'exécutaient au besoin.
On a aussi discuté ici d'autres entreprises qui ont tenté de se défiler devant leurs obligations vis à vis de la RGPD pour des raisons techniques avec un succès mitigé.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
avec quel logiciel on supprimait les données des disques durs en fin de vie ou hors service. Je lui ai dit qu'on perçait les plateaux à plusieurs endroits. Ce a quoi elle m'a répondu "mais, ce n'est pas conforme au RGPD ça".
Il a expliqué en quoi ça serait pas conforme ?
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# Silence surprenant
Posté par raphj (site web personnel) . Évalué à 2 (+0/-0).
Curieux que Signal n'ait pas répondu en quasi 6 mois.
[^] # Re: Silence surprenant
Posté par Krunch (courriel, site web personnel) . Évalué à 2 (+0/-0).
Je vois toujours pas de réponse de la part de Signal. Il est possible qu'ils ne considèrent pas la suppression de messages (automatiques ou manuels) comme une fonctionnalité de sécurité mais plutôt comme un truc permettant juste d'économiser du stockage. C'est un peu ce qui est suggéré par leur page d'aide sur le sujet. Mais c'est quand même dommage qu'ils ne prennent pas la peine de répondre du tout.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# Messages éphémères
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
Si j'ai bien suivi, ce n'est pas la suppression des messages qui ne fonctionnerait pas comme attendu, mais les messages éphémères: quand le délais d'affichage est dépassé, l'application Signal n'affiche plus le message, mais elle le conserve en base de donnée d'après cette analyse.
[^] # Re: Messages éphémères ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 3 (+0/-0). Dernière modification le 23 mai 2026 à 09:25.
Pas clair.
A priori on efface pas à la main les éphémères. En tout cas, il n'y a pas "disappearing messages" ici.
Contrairement à plus loin.
[^] # Re: Messages éphémères ou pas
Posté par Benoît Sibaud (site web personnel) . Évalué à 3 (+0/-0). Dernière modification le 23 mai 2026 à 09:25.
https://www.heise.de/en/news/Deleted-and-yet-not-gone-Signal-stores-messages-longer-than-expected-11304678.html
(Interprétation sur la base du même document ou échange avec l'auteur du document ?)
[^] # Re: Messages éphémères
Posté par nud . Évalué à 3 (+1/-0).
Le message est supprimé de la base de données (un SELECT ne le retournera plus) mais au niveau du fichier, la suppression est d'abord notée dans un fichier annexe (le fameux WAL) avant d'être "appliquée" sur le fichier principal en différé.
Ce n'est pas particulièrement surprenant quand on sait comment fonctionne sqlite, mais du coup le message n'est pas "supprimé" du fichier tant que le fichier principal n'est pas modifié.
Par ailleurs il existe un problème similaire pour tous les systèmes de fichiers, il n'y a pas de garantie que les changements soient appliqués sur le disque tant qu'on n'a pas appelé fsync(), ce que beaucoup de programmes ne font pas pour des raisons de performance.
Pour revenir à sqlite par contre, je ne comprends pas bien pourquoi ils utilisent le mode WAL vu qu'a priori il n'y a pas de soucis de performance particuliers (base petite, une seule connexion).
[^] # Re: Messages éphémères
Posté par Krunch (courriel, site web personnel) . Évalué à 2 (+0/-0).
J'y connais rien mais si ça permet de limiter le nombre d'écritures, ça peut faire durer la SSD plus longtemps.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# Postgresql et RGPD
Posté par wilk . Évalué à 2 (+0/-0).
Je pense qu'il y a le même problème avec PostgreSQL, quand les données sont supprimées par requête SQL elles restent encore longtemps quelque part sur le disque.
[^] # Re: Postgresql et RGPD
Posté par Pol' uX (site web personnel) . Évalué à 2 (+0/-0).
Et dans les backups. :)
Adhérer à l'April, ça vous tente ?
[^] # Re: Postgresql et RGPD
Posté par cg . Évalué à 2 (+0/-0).
Je ne crois pas que ce soit un problème du point de vue du RGPD.
C'est comme quand tu as ton nom comme auteur dans un truc comme git.
C'est un processus technique qui implique cette rétention, parfois plusieurs années, le RGPD n'a pas grand chose à dire là-dessus.
Ce qui doit être fait est d'expliciter dans le registre des traitements l'existence de ces sauvegardes/archives/journaux, pour quelle durée (qui pourrait être infinie dans le cas d'un historique git) et pour quelle raison.
[^] # Re: Postgresql et RGPD
Posté par Krunch (courriel, site web personnel) . Évalué à 3 (+1/-0). Dernière modification le 25 mai 2026 à 13:45.
Juste parce que c'est un processus techniques ne veut pas dire que ça n'est pas quelque chose qui doit être pris en compte d'un point de vue RGPD. Techniquement, tu peux tout à fait supprimer un nom d'un historique git : il suffit de réécrire l'historique. Je comprend que ça entre en conflit avec le workflow de beaucoup de gens/organisations mais je connais des organisations qui utilisent un tel mécanisme pour remplir leurs obligations de protection des données.
Donc, oui, quand tu utilises PostgreSQL, SQLite, git, ext4 ou tout autre système de stockage dans un cadre où tu as des « obligations » de supprimer les données (que ça soit RGPD ou feature d'auto-deletion de messages), il convient de comprendre comment ce stockage fonctionne pour pouvoir remplir ces obligations.
Selon le cas d'utilisation, un autre mécanisme de « suppression » de données qui sont répliquées à plein d'endroits (backups, journaux de filesystem,…) est de chiffrer ces données, de stocker la clé de manière plus contrôlée et de supprimer juste la clé. Les copies ne sont techniquement pas supprimées mais à partir du moment où plus personne n'a la clé (et que le chiffrement est suffisamment fort), c'est fonctionnellement équivalent.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Postgresql et RGPD
Posté par cg . Évalué à 2 (+0/-0).
Et bien, quel courage ! Tu aurais un exemple d'une telle organisation qui s'est donné les moyens pour le cas d'un gestionnaire de version de code comme git ? J'avais l'impression - fausse semble-t-il - que c'est tellement disproportionné, que ça n'en devient pas applicable en pratique.
Pour les sauvegardes et les journaux, ces données ont en général une durée de vie limitée (de quelques jours à quelques années le plus souvent), donc attendre la rotation naturelle est une bonne manière de régler la question, du moment que c'est documenté comme tel.
Pour des archives (rétention potentielle de plusieurs décennies), je vois mal comment régler la question sans altérer l'intégrité de l'archive. Une bonne méthode serait de ne pas archiver les données personnelles dans l'archive mais à côté, par personne. Ça pourrait être tenable dans le cas où ces infos sont secondaires, mais pas si elles sont primaires. Dans ce dernier cas, déclarer l'intérêt légitime de conserver la donnée est une réponse.
Tiens, ça me rappelle un truc rigolo. Un jour une prestataire qui préparait un devis pour un service d'archivage me demandait avec quel logiciel on supprimait les données des disques durs en fin de vie ou hors service. Je lui ai dit qu'on perçait les plateaux à plusieurs endroits. Ce a quoi elle m'a répondu "mais, ce n'est pas conforme au RGPD ça". Ça m'a surpris :).
[^] # Re: Postgresql et RGPD
Posté par Krunch (courriel, site web personnel) . Évalué à 3 (+1/-0). Dernière modification le 26 mai 2026 à 11:29.
Quand j'étais chez Google, l'équipe qui s'occupe du gestionnaire de version de code (Piper) recevait régulièrement des requêtes internes pour censurer l'historique qui contenait des informations personnelles (e.g. numéro de téléphone d'(ex)employés). Ils avaient une procédure pour cela et l'exécutaient au besoin.
On a aussi discuté ici d'autres entreprises qui ont tenté de se défiler devant leurs obligations vis à vis de la RGPD pour des raisons techniques avec un succès mitigé.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Postgresql et RGPD
Posté par cg . Évalué à 2 (+0/-0).
Merci !
[^] # Re: Postgresql et RGPD
Posté par Krunch (courriel, site web personnel) . Évalué à 2 (+0/-0).
Il a expliqué en quoi ça serait pas conforme ?
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.