Uma etiqueta de privacidade é uma declaração a investigar, não uma medição de tudo o que uma aplicação sabe.
Não há um vencedor universal defensável como «a aplicação de mensagens que recolhe menos dados» sem definir o que conta: identificadores de registo, dados da lista de contactos, registos de ligação conservados, utilização publicitária ou conteúdo das mensagens. Uma etiqueta de privacidade é um ponto de partida útil, não uma medição de tudo o que uma aplicação processa.
Este guia explica como comparar as declarações. Não é uma auditoria independente concluída de todos os serviços de mensagens e não atribui à Livara nem a qualquer concorrente um selo de menor recolha de dados.
Leia a etiqueta antes de contar as categorias
A secção Privacidade da aplicação da Apple e a secção Segurança dos dados do Google Play baseiam-se em declarações dos programadores, mas as suas definições diferem. As orientações da Apple distinguem dados associados a um utilizador, rastreio e finalidades da recolha. O processamento que permanece no dispositivo não é considerado recolha, e alguns processamentos transitórios e declarações opcionais têm exceções específicas.
As orientações da Google também têm exceções: dados com encriptação ponta a ponta que cumpram os requisitos e não possam ser lidos pelos intermediários ficam fora da declaração de dados recolhidos, e algumas transferências para prestadores de serviços não contam como partilha. «Encriptado em trânsito» numa ficha da loja não é uma promessa de encriptação ponta a ponta. Uma categoria vazia, portanto, não prova que não existam pedidos de rede ou relações com prestadores de serviços.
Não compare o número de caixas da Apple com o da Google para declarar um vencedor. Compare a mesma loja, data, região e pressupostos sobre as funcionalidades utilizadas.
Uma comparação de privacidade em cinco camadas
| Evidência | Pergunta útil | O que não consegue estabelecer por si só |
|---|---|---|
| Etiqueta da loja | Que tipos de dados e utilizações são declarados? | Exatidão completa ou conservação real |
| Política de privacidade | Quem recebe os dados, para quê e durante quanto tempo? | Se a implementação corresponde à política |
| Permissões do dispositivo | A aplicação pode aceder a contactos, localização, microfone ou fotografias? | O que aconteceu aos dados já enviados |
| Documentação do protocolo | Que áreas e chaves protegem o conteúdo? | Proteção de todos os dispositivos ou compilações do software |
| Avaliação independente | Que versão e componentes foram testados e o que foi corrigido? | Segurança permanente de versões futuras |
Estas camadas respondem a perguntas diferentes. Um cliente de código aberto pode ser inspecionado; isso não revela, por si só, a conservação efetiva no servidor. Uma auditoria pode abranger criptografia sem examinar a análise de utilização. Leia o âmbito antes de usar qualquer uma como pontuação de privacidade.
Utilize esta ficha de comparação
Para cada aplicação que estiver a considerar, registe em privado o seguinte. Um registo curto e datado é mais útil do que uma classificação sem fundamento.
| Campo | O que anotar |
|---|---|
| Produto e plataforma | Aplicação exata, ligação da loja, sistema operativo e versão |
| Data de observação | Quando a etiqueta e a política foram consultadas |
| Registo | Identificadores de telefone, correio eletrónico ou pagamento obrigatórios e opcionais |
| Descoberta | Lista de contactos, nome de utilizador, código QR, ligação de convite ou ID de conta |
| Registos técnicos | Dados declarados de IP, dispositivo, diagnóstico e utilização |
| Conservação | Duração indicada, condições de eliminação ou «não especificada» |
| Exceções por funcionalidade | Cópias de segurança, bots, interações comerciais, pagamentos, canais públicos e chamadas |
| Lacunas de evidência | O que os documentos não esclarecem |
Se uma política apenas disser que os dados são conservados «conforme necessário», indique que a duração exata é desconhecida em vez de a inventar. Se uma etiqueta mudar após uma atualização, mantenha a data anterior nas notas para que a comparação continue a ser interpretável.
Não exigir número de telefone é uma dimensão, não o resultado completo
O Session e o SimpleX oferecem formas de comunicar sem uma identidade baseada num número de telefone. O Threema torna opcional a associação de telefone ou correio eletrónico. A documentação pública da Livara descreve o registo sem número de telefone nem correio eletrónico, mas também descreve metadados de encaminhamento e pertença a grupos. Estas arquiteturas não devem ser tratadas como equivalentes.
O Signal documenta agora uma opção de registo sem número de telefone na sua versão beta para Android. Isso não significa que todas as versões do Signal ou as contas existentes dispensem número. Um nome de utilizador numa conta baseada num número e a criação de uma conta sem número são funcionalidades diferentes.
Mesmo sem número, uma fotografia de perfil reutilizada, conta de pagamento, ficheiro partilhado, endereço IP ou contexto da conversa podem ligar uma conta a uma pessoa. «Não exige telefone» não demonstra anonimato completo. Sobre a questão distinta das informações de encaminhamento, consulte a explicação dos metadados de mensagens.
Como testar o acesso aos contactos sem expor a sua lista
- Instale a aplicação oficial e recuse inicialmente a permissão de contactos.
- Adicione um contacto de teste que tenha dado consentimento, usando um identificador, convite ou código QR suportado.
- Confirme se as mensagens habituais funcionam sem acesso à lista de contactos.
- Inspecione a definição de sincronização de contactos da aplicação e a permissão do sistema operativo. Nem sempre são o mesmo controlo.
- Se os contactos já tiverem sido sincronizados, procure uma opção separada de eliminação ou um processo documentado de pedido. Revogar a permissão limita o acesso futuro ao dispositivo; não remove necessariamente a cópia do servidor.
Não envie uma lista de contactos só para ver se a aplicação a envia. Um pedido de permissão revela o acesso solicitado, não é uma auditoria completa do fluxo de dados. Uma inspeção de rede pode revelar destinos e tempos, mas a encriptação pode impedir a compreensão dos campos transmitidos.
O que a E2EE deixa fora da comparação
A encriptação ponta a ponta protege o conteúdo abrangido entre os dispositivos participantes. Não elimina automaticamente identificadores de conta, horários de ligação, registos de pertença a grupos ou dados de tokens de notificações push. Também não protege uma cópia enviada deliberadamente a um bot, ferramenta empresarial ou serviço de apoio fora dessa conversa encriptada.
No caso específico da Livara, a documentação de segurança distingue mensagens diretas encriptadas e grupos privados compatíveis de canais públicos legíveis pelo servidor. O seu acordo híbrido de chaves é uma alegação de proteção de conteúdo, não uma prova de que recolhe menos metadados do que todos os outros serviços. Este artigo não mediu de forma independente o comportamento dos seus servidores.
Escolha os dados mínimos necessários para a sua utilização
Comece pela informação que mais precisa de resguardar. Se for um número de telefone, teste o registo sem número. Se for a lista de contactos, verifique a descoberta manual. Se for o histórico de conversas legível na nuvem, investigue a cópia de segurança separadamente. Se forem metadados de ligação, leia o desenho do encaminhamento e da conservação, em vez da lista de cifras.
Uma pergunta final útil é: O que fica este serviço a saber quando uso exatamente as funcionalidades de que preciso, e quais dessas divulgações posso evitar? Isso produz uma decisão mais honesta do que um único troféu de «menos dados».
