Pegue uma frase da política — a que o fez considerar o fornecedor — e siga-a por todo o sistema. Uma promessa sobre o túnel não descreve automaticamente o portal da conta, o resolvedor, a caixa de suporte ou o processador de pagamentos. A maioria das comparações ruins nasce de ler uma afirmação sobre um componente e aplicá-la a outro. O roteiro abaixo transforma esse hábito numa folha de trabalho curta.

Siga os dados, não o adjetivo

Um título como «sem registos de atividade» é uma afirmação sobre uma categoria, e a pergunta útil é qual componente poderia produzir essa categoria em primeiro lugar. O extremo do túnel pode ver endereços de origem e marcas temporais; um resolvedor pode ver os nomes consultados; o sistema de contas pode ver a identidade e o histórico de pagamentos; o suporte pode ver tudo o que colar num pedido. Dois deles podem ser operados pela mesma empresa e um pode ser um subcontratado.

A cifragem em trânsito não diz nada sobre retenção, porque o extremo decifra antes de reencaminhar.

Primeiro, construa um mapa de componentes

Escreva seis linhas: aplicação de cliente, operador do extremo do túnel, resolvedor de DNS, sistema de contas e faturação, canal de suporte e qualquer destinatário de diagnósticos ou relatórios de falhas. Em cada linha, anote quem o opera e se essa parte é a mesma empresa sobre a qual está a ler. Serviços de marca branca, equipas de suporte subcontratadas e analítica de terceiros tornam a resposta interessante mais vezes do que parece.

Depois, enumere aquilo a que cada componente tem acesso técnico: endereço de origem, identificador de conta, nome consultado, hora de ligação, volume transferido, detalhes do dispositivo, relatório submetido. A disponibilidade não é retenção, mas identifica que parte da política tem de responder a que pergunta.

Compare categorias, finalidade, retenção e partilha

Uma afirmação de que os destinos de navegação não são armazenados não abrange as marcas temporais da sessão, e uma afirmação sobre estatísticas agregadas não descreve os registos em bruto que as alimentaram. Procure a categoria exata, a finalidade declarada, o prazo de retenção e a redação sobre partilha, por esta ordem. Onde a política diz «anónimo», verifique que identificadores e que granularidade temporal foram removidos em vez de aceitar a palavra como explicação.

Atenção às secções que se aplicam por linha de produto. Uma extensão de navegador, um cliente móvel e um router da mesma marca podem ter caminhos de dados diferentes, e a política pode cobrir os três com uma página de generalidades.

O guia de considerações de privacidade do IETF é aqui uma estrutura útil, porque obriga a analisar por componente e não por frase de marketing.

Avalie as provas que aceita

O código de cliente aberto descreve o que o cliente faz com os seus dados e diz pouco sobre o backend que termina o túnel. Uma auditoria cobre um sistema declarado durante um período declarado, o que é útil e mais estreito do que uma garantia permanente. Uma afirmação sobre jurisdição é uma afirmação sobre o processo legal, não sobre o registo técnico. Cada uma destas é uma prova de um tipo específico, e misturá-las produz conclusões seguras que ninguém consegue defender um ano depois.

A cifragem em repouso protege registos que ainda existem, por isso responde a uma pergunta diferente da de saber se os registos existem de todo.

Registe o que ficou sem resposta

Onde falta um componente na política ou uma categoria não é abordada, escreva «por explicar» ao lado. Esse é o resultado honesto, e é mais útil do que transformar o silêncio numa garantia ou numa acusação. Guarde a versão e a data da política junto das suas notas, porque estes documentos mudam em silêncio e uma comparação sem versão envelhece mal.

Por último, seja claro sobre o que o seu próprio teste demonstrou. Uma saída funcional e um endereço público alterado demonstram encaminhamento. Não dizem nada sobre retenção do lado do servidor, e a folha de trabalho é o lugar onde essa distinção vive.

Artigos relacionados