Privacidade

Uma instância guarda pouco sobre cada pessoa: a conta (nome e e-mail), as sessões e os tokens de acesso, o que publicou e revisou, e o log de auditoria do que fez. A maior parte é o registro do marketplace e fica. O que identifica a conexão de uma pessoa, e não o seu trabalho (um endereço IP, o user agent de um navegador, o e-mail que alguém digitou num login que falhou), é guardado só pelo tempo que o root definir, como a Lei 25 do Quebec, a PIPEDA e o GDPR esperam de limites de retenção. Esta página descreve o que o software faz; não é aconselhamento jurídico.

O root define dois números em Admin › Settings › Privacy, cada um um número inteiro de dias de 1 a 3.650, 90 por padrão, e cada mudança fica no log de auditoria:

• Keep IP addresses for: os endereços dos clientes guardados com eventos de auditoria, sessões e aprovações de rmk login, e o e-mail digitado num login que falhou.
• Keep expired sessions for: uma sessão que expirou, e uma aprovação de rmk login concluída.

Uma limpeza apaga o que é mais antigo que o número que o cobre, e nada mais:

Nenhum evento de auditoria é excluído (Log de auditoria), nenhuma conta é tocada, e nenhum token de acesso: a linha de um token revogado é o registro da revogação. Encurtar um número apaga mais na próxima execução, até um dia.

Quando roda. O servidor faz a limpeza sozinho, 5 minutos depois de iniciar e a cada 6 horas depois disso, sob um bloqueio no banco de dados, de modo que vários servidores num mesmo banco nunca limpam ao mesmo tempo. A aba Privacy mostra a última execução: quando, e o que apagou; ou que nenhuma rodou ainda; ou o nome do último erro, com o motivo nos logs (job.started, job.finished, job.failed).

Pelo cron, em vez disso. rmk-server purge roda a mesma limpeza uma vez, agora, sob o mesmo bloqueio (docker compose exec web pnpm run purge com Docker, sudo rmk-server purge com um serviço). --dry-run imprime o que uma execução apagaria e não muda nada. Sai com 0 quando termina, 1 quando outra limpeza segura o bloqueio ou a execução falhou, 2 com entrada inválida. Para deixar a limpeza com o cron, defina RONNE_JOBS=off nas configurações (o servidor avisa ao iniciar e a aba Privacy diz "No run yet" nomeando a configuração), e adicione uma linha como:

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

Os backups guardam o que o banco de dados tinha quando foram feitos, dados pessoais incluídos: não os guarde por mais tempo que a retenção (Backups). Logs enviados a um coletor são guardados pelas regras desse coletor; o Ronne não escreve endereço IP nem e-mail neles.

Uma pessoa pode pedir que os seus dados pessoais sejam apagados, como a Lei 25, a PIPEDA e o GDPR esperam. Ela pede ao root: apagar é uma decisão que alguém responsável toma, e nenhuma sessão, roubada ou não, consegue apagar uma conta sozinha. O root apaga a conta em Usuários: abra o usuário e escolha Erase, na última seção da página dele (também para uma conta que um provedor de identidade desprovisionou, mostrada como Deprovisioned by na lista). O diálogo diz o que some e o que fica, e pede o e-mail da conta digitado antes de ligar o Erase. Não dá para desfazer.

O que some: o e-mail, o nome e a foto (a conta vira deleted-user-<id>), a senha, os vínculos com provedores de identidade e o login em duas etapas, todas as sessões, tokens de acesso e aprovações de rmk login, os vínculos SCIM, as participações em espaços de trabalho, os pedidos abertos para entrar e as mudanças de escopo abertas, os rascunhos, o endereço IP da pessoa em todos os eventos de auditoria, e o e-mail dela onde quer que os detalhes de um evento o guardassem. O e-mail antigo fica livre para uma conta nova na hora.

O que fica, sob o pseudônimo: os itens e versões que a pessoa publicou (mostrados como publicados por deleted-user-<id>), as submissões enviadas, aprovadas e rejeitadas e todos os comentários de revisão, os eventos de auditoria em que ela aparece, e o espaço de trabalho pessoal dela quando guarda um item publicado ou uma submissão, renomeado a partir do pseudônimo (um vazio é excluído com os escopos). O registro do registry fica inteiro: as instalações e os lockfiles de outras pessoas dependem dele. Para barrar alguém sem apagar, use o Disable.

Depois, a página e a linha da lista mostram Erased on <date>, o status dela é erased (o filtro Status as encontra), e nada mais a muda: sem ativar, sem redefinir senha, sem login por nenhum caminho, e sem provisionamento. O log de auditoria registra user.erased com as contagens do que sumiu, nunca o e-mail nem o nome. Nada da pessoa pode ser lido de volta depois, então entregue a ela antes o que ela pediu (root pode gerar o arquivo na página do usuário: Seus dados). Você não pode apagar a sua própria conta, nem o último root ativado.

• SCIM: desatribua a pessoa no provedor de identidade primeiro (O que o provedor faz com as contas). Apagar exclui os vínculos SCIM da conta, então um provedor que ainda lista a pessoa recebe 404 para o id antigo e cria uma conta nova, vazia, na próxima sincronização.
• Backups feitos antes de apagar ainda guardam os dados da pessoa, e uma restauração os traz de volta (Restaurar): guarde os backups dentro da retenção, e apague de novo depois de restaurar.
• MySQL e MariaDB: o log de auditoria é reescrito em lotes logo depois de a conta ser apagada. Se o servidor parar no meio, a aba Privacy mostra An erasure wasn't completed com Retry, e a limpeza termina o trabalho na próxima execução; a conta já é o pseudônimo.

Qualquer pessoa pode ver o que uma instância guarda sobre ela, como esperam a Lei 25, a PIPEDA e o GDPR. Em Sua conta, na aba Password, Download my data salva um arquivo JSON chamado ronne-data-<id>-<data>.json. É um registro de você, não um backup, e o Ronne não envia e-mail.

O que o arquivo contém:

• Sua conta: id, nome, e-mail, papel, datas, se o two-factor está ligado, como você entra (a senha, ou os provedores de identidade a que está vinculado) e o seu vínculo SCIM.
• Sessões (datas, endereço IP e navegador), tokens de acesso (nome, o prefixo mostrado, datas; nunca o token) e aprovações de rmk login.
• Workspaces de que você faz parte, seus pedidos para entrar e os escopos que você criou.
• Itens que você possui ou de que publicou uma versão, com essas versões.
• Submissões (nome, status, datas, número de revisões e nomes de arquivos) e os comentários que você escreveu.
• Eventos de auditoria em que você agiu ou foi o alvo.

O que nunca contém: hash de senha, o valor ou o hash de um token, segredo ou código de backup do two-factor, tokens de um provedor de identidade, o conteúdo dos arquivos, tarballs e dados de outras pessoas. O e-mail de outra pessoa em um dos seus eventos é trocado por [other], e o endereço IP de algo que outra pessoa fez na sua conta fica de fora.

Limites: um download por conta a cada 10 minutos (o seguinte diz quanto esperar, e os downloads de root para você contam), só pelo app web, com a sessão iniciada: um token ou o rmk não consegue baixá-lo. Uma lista é cortada em 10.000 linhas, mantendo as mais antigas, e um comentário em 10.000 caracteres; o arquivo diz o que foi cortado em truncated, no topo. Se precisar de mais, peça a root uma exportação do banco de dados.

Root pode gerar o mesmo arquivo para quem pediu e não consegue entrar (desativado, ou sem o two-factor), e antes de apagar a conta: Download their data na página da pessoa em Users. O log de auditoria registra user.data_exported com root como autor. Uma conta apagada não tem mais nada a entregar, então a ação fica desabilitada.