Confidentialité

Une instance garde peu de choses sur chaque personne : son compte (nom et courriel), ses sessions et ses jetons d'accès, ce qu'elle a publié et révisé, et le journal d'audit de ce qu'elle a fait. L'essentiel est le registre du marketplace et reste. Ce qui identifie la connexion d'une personne plutôt que son travail (une adresse IP, le user agent d'un navigateur, le courriel saisi dans une connexion échouée) n'est gardé que le temps fixé par root, comme la Loi 25 du Québec, la LPRPDE et le RGPD l'attendent des limites de rétention. Cette page décrit ce que fait le logiciel; ce n'est pas un avis juridique.

Root fixe deux nombres dans Admin › Settings › Privacy, chacun un nombre entier de jours de 1 à 3 650, 90 par défaut, et chaque changement figure dans le journal d'audit :

• Keep IP addresses for : les adresses des clients gardées avec les événements d'audit, les sessions et les approbations rmk login, et le courriel saisi dans une connexion échouée.
• Keep expired sessions for : une session expirée, et une approbation rmk login terminée.

Une purge efface ce qui est plus ancien que le nombre qui le couvre, et rien d'autre :

Aucun événement d'audit n'est jamais supprimé (Journal d'audit), aucun compte n'est touché, ni aucun jeton d'accès : la ligne d'un jeton révoqué est la trace de sa révocation. Raccourcir un nombre efface davantage à la prochaine exécution, jusqu'à un jour.

Quand elle s'exécute. Le serveur purge de lui-même, 5 minutes après son démarrage puis toutes les 6 heures, sous un verrou dans la base de données, de sorte que plusieurs serveurs sur une même base ne purgent jamais en même temps. L'onglet Privacy montre la dernière exécution : quand, et ce qu'elle a effacé; ou qu'aucune n'a encore eu lieu; ou le nom de la dernière erreur, avec la raison dans les journaux (job.started, job.finished, job.failed).

Par cron plutôt. rmk-server purge exécute la même purge une fois, maintenant, sous le même verrou (docker compose exec web pnpm run purge avec Docker, sudo rmk-server purge avec un service). --dry-run affiche ce qu'une exécution effacerait et ne change rien. Le code de sortie est 0 quand c'est fait, 1 quand une autre purge tient le verrou ou que l'exécution a échoué, 2 pour une entrée invalide. Pour laisser la purge à cron, mettez RONNE_JOBS=off dans les réglages (le serveur le dit au démarrage et l'onglet Privacy affiche « No run yet » en nommant le réglage), et ajoutez une ligne comme :

30 4 * * * /usr/bin/rmk-server purge >> /var/log/rmk-server-purge.log 2>&1
30 4 * * * cd /opt/ronne-marketplace && docker compose exec -T web pnpm run purge >> /var/log/ronne-purge.log 2>&1   # Docker

Les sauvegardes contiennent ce que la base de données contenait au moment où elles ont été faites, données personnelles comprises : ne les gardez pas plus longtemps que la rétention (Sauvegardes). Les journaux envoyés à un collecteur sont gardés selon les règles de ce collecteur; Ronne n'y écrit ni adresse IP ni courriel.

Une personne peut demander que ses données personnelles soient effacées, comme la Loi 25, la LPRPDE et le RGPD l'attendent. Elle le demande à root : effacer est une décision qu'une personne responsable prend, et aucune session, volée ou non, ne peut effacer un compte à elle seule. Root efface le compte depuis Utilisateurs: ouvrez l'utilisateur et choisissez Erase, dans la dernière section de sa page (aussi pour un compte qu'un fournisseur d'identité a déprovisionné, affiché Deprovisioned by dans la liste). La boîte de dialogue dit ce qui disparaît et ce qui reste, et demande le courriel du compte, saisi, avant d'activer Erase. C'est irréversible.

Ce qui disparaît : le courriel, le nom et la photo (le compte devient deleted-user-<id>), le mot de passe, les liens avec les fournisseurs d'identité et la connexion à deux facteurs, chaque session, jeton d'accès et approbation de rmk login, les liens SCIM, les adhésions aux espaces de travail, les demandes d'adhésion et les déplacements de portée en attente, les brouillons, l'adresse IP de la personne sur chaque événement d'audit, et son courriel partout où les détails d'un événement le contenaient. L'ancien courriel est libre pour un nouveau compte aussitôt.

Ce qui reste, sous le pseudonyme : les éléments et versions publiés (affichés comme publiés par deleted-user-<id>), les soumissions envoyées, approuvées et rejetées et chaque commentaire de revue, les événements d'audit où la personne apparaît, et son espace de travail personnel quand il contient un élément publié ou une soumission, renommé d'après le pseudonyme (un espace vide est supprimé avec ses portées). Le registre reste entier : les installations et les fichiers de verrouillage des autres en dépendent. Pour arrêter quelqu'un sans effacer, utilisez Disable.

Ensuite la page et la ligne de la liste affichent Erased on <date>, son statut est erased (le filtre Status les trouve), et plus rien ne la change : ni activation, ni réinitialisation du mot de passe, ni connexion par aucune voie, ni provisionnement. Le journal d'audit enregistre user.erased avec le compte de ce qui a disparu, jamais le courriel ni le nom. Rien de la personne ne peut être relu ensuite : remettez-lui d'abord ce qu'elle a demandé (root peut produire le fichier depuis la page de l'utilisateur : Vos données). Vous ne pouvez pas effacer votre propre compte, ni le dernier root activé.

• SCIM : retirez d'abord la personne chez le fournisseur d'identité (Ce que le fournisseur fait aux comptes). Effacer supprime les liens SCIM du compte : un fournisseur qui liste encore la personne reçoit 404 pour l'ancien id et crée un nouveau compte, vide, à sa prochaine synchronisation.
• Les sauvegardes faites avant l'effacement contiennent encore les données de la personne, et une restauration les ramène (Restaurer) : gardez les sauvegardes dans la rétention, et effacez de nouveau après une restauration.
• MySQL et MariaDB : le journal d'audit est réécrit par lots juste après l'effacement du compte. Si le serveur s'arrête entre les deux, l'onglet Privacy affiche An erasure wasn't completed avec Retry, et la purge termine le travail à sa prochaine exécution ; le compte est déjà le pseudonyme.

Chacun peut voir ce qu'une instance conserve à son sujet, comme l'attendent la Loi 25, la LPRPDE et le RGPD. Dans Votre compte, onglet Password, Download my data enregistre un fichier JSON nommé ronne-data-<id>-<date>.json. C'est un relevé de vous, pas une sauvegarde, et Ronne n'envoie aucun courriel.

Ce que contient le fichier :

• Votre compte : id, nom, courriel, rôle, dates, si le two-factor est activé, comment vous vous connectez (le mot de passe, ou les fournisseurs d'identité auxquels vous êtes lié) et votre lien SCIM.
• Sessions (dates, adresse IP et navigateur), jetons d'accès (nom, préfixe affiché, dates ; jamais le jeton) et approbations de rmk login.
• Espaces de travail dont vous faites partie, vos demandes d'adhésion et les portées que vous avez créées.
• Éléments que vous possédez ou dont vous avez publié une version, avec ces versions.
• Soumissions (nom, statut, dates, nombre de révisions et noms de fichiers) et les commentaires que vous avez écrits.
• Événements d'audit où vous avez agi ou étiez la cible.

Ce qu'il ne contient jamais : un hachage de mot de passe, la valeur ou le hachage d'un jeton, un secret ou un code de secours du two-factor, les jetons d'un fournisseur d'identité, le contenu des fichiers, les tarballs et les données des autres. Le courriel d'une autre personne dans l'un de vos événements est remplacé par [other], et l'adresse IP de ce qu'une autre personne a fait sur votre compte est omise.

Limites : un téléchargement par compte toutes les 10 minutes (le suivant dit combien attendre, et ceux de root pour vous comptent), seulement depuis l'application web, connecté : un jeton ou rmk ne peut pas le télécharger. Une liste est coupée à 10 000 lignes, en gardant les plus anciennes, et un commentaire à 10 000 caractères ; le fichier dit ce qui a été coupé dans truncated, en haut. S'il vous en faut plus, demandez à root un export de la base de données.

Root peut produire le même fichier pour qui l'a demandé et ne peut pas se connecter (désactivé, ou two-factor perdu), et avant d' effacer le compte : Download their data sur sa page dans Users. Le journal d'audit enregistre user.data_exported avec root comme auteur. Un compte effacé n'a plus rien à donner : son action est grisée.