Privacy

An instance holds a little about each person: their account (name and email), their sessions and access tokens, what they published and reviewed, and the audit log of what they did. Most of it is the registry's record and stays. What identifies a person's connection rather than their work (an IP address, a browser's user agent, the email someone typed into a failed sign-in) is kept only as long as root says, as Quebec's Law 25, PIPEDA and the GDPR expect of retention limits. This page describes what the software does; it isn't legal advice.

Root sets two numbers on Admin › Settings › Privacy, each a whole number of days from 1 to 3,650, 90 by default, and each change is in the audit log:

• Keep IP addresses for: the client addresses kept with audit events, sessions and rmk login approvals, and the email typed in a failed sign-in.
• Keep expired sessions for: a session that has expired, and a finished rmk login approval.

A purge clears what is older than the number that covers it, and nothing else:

No audit event is ever deleted (Audit log), no account is touched, and no access token: a revoked token's row is the record of its revocation. Shortening a number clears more at the next run, down to a day.

When it runs. The server purges on its own, 5 minutes after it starts and every 6 hours after, under a lock in the database, so several servers on one database never purge at once. The Privacy tab shows the last run: when, and what it cleared; or that none has run yet; or the last error's name, with the reason in the logs (job.started, job.finished, job.failed).

From cron instead. rmk-server purge runs the same purge once, now, under the same lock (docker compose exec web pnpm run purge with Docker, sudo rmk-server purge with a service). --dry-run prints what a run would clear and changes nothing. It exits 0 when done, 1 when another purge holds the lock or the run failed, 2 on bad input. To leave the purge to cron, set RONNE_JOBS=off in the settings (the server then says so at start and the Privacy tab says "No run yet" naming the setting), and add a line such as:

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

Backups hold what the database held when they were made, personal data included: keep them no longer than the retention (Backups). Logs sent to a collector are kept by that collector's rules; Ronne writes no IP address or email into them.

A person can ask for their personal data to be erased, as Law 25, PIPEDA and the GDPR expect. They ask root: erasing is a decision someone accountable makes, and no session, stolen or not, can erase an account on its own. Root erases the account from Users: open the user and choose Erase, in the last section of their page (also for an account an identity provider deprovisioned, shown Deprovisioned by in the list). The dialog says what goes and what stays, and asks for the account's email typed before Erase is on. It can't be undone.

What goes: the email, the name and the picture (the account becomes deleted-user-<id>), the password, the identity-provider links and two-factor sign-in, every session, access token and rmk login approval, the SCIM links, the workspace memberships, open requests to join and open scope moves, the drafts, the person's IP address on every audit event, and their email wherever an event's details held it. The old email is free for a new account at once.

What stays, under the pseudonym: the items and versions they published (shown as published by deleted-user-<id>), their submitted, approved and rejected submissions and every review comment, the audit events they appear in, and their personal workspace when it holds a published item or a submission, renamed from the pseudonym (an empty one is deleted with its scopes). The registry's record stays whole: other people's installs and lockfiles depend on it. To stop someone without erasing, Disable them instead.

Afterwards the page and the list's row show Erased on <date>, its status is erased (the Status filter finds them), and nothing can change it again: no enable, no password reset, no sign-in by any route, and no provisioning. The audit log records user.erased with the counts of what went, never the email or the name. Nothing of the person's can be read back afterwards, so give them what they asked for first (root can make the file from the user's page: Your data). You can't erase your own account, or the last enabled root.

• SCIM: unassign the person at the identity provider first (What the provider does to accounts). Erasing deletes the account's SCIM links, so a provider that still lists the person gets 404 for the old id and creates a new, empty account at its next sync.
• Backups made before the erasure still hold the person's data, and a restore brings it back (Restoring): keep backups within the retention, and erase again after a restore.
• MySQL and MariaDB: the audit log is rewritten in batches right after the account is erased. If the server stops in between, the Privacy tab shows An erasure wasn't completed with Retry, and the purge finishes it on its next run; the account is already the pseudonym.

Anyone can see what an instance holds about them, as Law 25, PIPEDA and the GDPR expect. On Your account, in the Password tab, Download my data saves one JSON file named ronne-data-<id>-<date>.json. It is a record of you, not a backup, and Ronne sends no email.

What the file holds:

• Your account: id, name, email, role, dates, whether two-factor is on, how you sign in (the password, or the identity providers you are linked to) and your SCIM link.
• Sessions (dates, IP address and browser), access tokens (name, the prefix shown, dates; never the token) and rmk login approvals.
• Workspaces you belong to, your requests to join, and the scopes you created.
• Items you own or published a version of, with those versions.
• Submissions (name, status, dates, number of revisions and file names) and the comments you wrote.
• Audit events you acted in or were the target of.

What it never holds: a password hash, the value or hash of a token, a two-factor secret or backup code, an identity provider's tokens, the contents of files, tarballs, and other people's data. Another person's email in one of your events is replaced by [other], and the IP address of something someone else did to your account is left out.

Limits: one download per account every 10 minutes (the next one says how long to wait, and root's downloads for you count), only from the web app, signed in: a token or rmk can't download it. A list is cut at 10,000 rows, keeping the oldest, and a comment at 10,000 characters; the file names what was cut in truncated at its top. If you need more, ask root for a database export.

Root can make the same file for someone who asked and can't sign in (disabled, or two-factor lost), and before erasing them: Download their data on their page in Users. The audit log records user.data_exported with root as who. An erased account has nothing left to give, so its action is greyed.