← Cuadernos Lacre

Análise · 16 de maio de 2026

Quando não há ninguém no meio

Cifrar o que passa por um servidor protege o conteúdo. Não ter um servidor no meio elimina a pergunta. Não são o mesmo.

Duas pessoas, uma conversa

Quando duas pessoas falam frente a frente numa sala, ninguém mais tem de prometer que não ouviu nada. Não ouviu porque não estava lá. Quando duas pessoas passam um papel de uma mão para a outra, ninguém no meio tem de jurar que não o leu. Não há ninguém no meio.

A maior parte das coisas na vida quotidiana funciona assim. Não assinamos acordos de confidencialidade com o ar que transmite a nossa voz, nem com o papel que seguramos. A privacidade da conversa não descansa sobre a promessa de um intermediário, porque não há intermediário. Essa é uma das formas mais fortes que existe de ser privado: não porque algo ou alguém se comporte bem, mas porque não há algo ou alguém.

Quando a conversa se translada para um canal digital, isto muda por defeito. O modelo habitual é o seguinte: duas pessoas ligam-se a um servidor, o servidor recebe a mensagem, cifra-a ou guarda-a cifrada, e entrega-a ao destinatário. O servidor está no meio. O servidor pode ser honesto. Pode ser auditado. Pode operar numa jurisdição favorável e sob uma política de privacidade estrita. Tudo isso pode ser verdade. Mas o servidor está no meio.

A diferença entre cifrar e não recolher (segunda parte)

Num artigo anterior desta mesma série, sustentamos que cifrar o conteúdo e não recolher metadados não são o mesmo. Há um passo mais além que convém formular com clareza: cifrar o que passa por um servidor e não ter servidor também não são o mesmo.

O primeiro modelo — servidor no meio, conteúdo cifrado — protege o conteúdo do operador do servidor, do seu pessoal de manutenção, e de um atacante externo que comprometa o sistema. E isso é importante. Mas não elimina o servidor: ele continua lá, a processar metadados, exposto a um pedido judicial, a uma intervenção legal, a uma pressão política ou a uma falha de segurança. Continua a ser, em suma, um ponto que requer depositar confiança em alguém.

O segundo modelo, sem servidor entre as duas pontas, não protege melhor o conteúdo cifrado: se a criptografia for sólida, o conteúdo está protegido em ambos os casos. O que muda é a própria questão: «o que acontece com o servidor?» deixa de ter sentido, porque não existe servidor sobre o qual perguntar.

Confiança, ausência, e a diferença entre ambas

A confiança pode estar bem depositada. Empresas honestas existem. Auditores rigorosos existem. Legislações favoráveis ao utilizador existem. Serviços sérios que cumprem escrupulosamente com tudo o anterior existem. A confiança, quando se concede a um operador que a merece, não é um mau acordo.

Mas a confiança, por mais sólida que seja, continua a ser confiança. É uma solução social, não uma solução técnica. Uma empresa pode mudar de mãos, uma jurisdição pode mudar de governo, uma ordem judicial pode chegar amanhã, uma nova vulnerabilidade pode ser descoberta no próximo mês. Nada disto acontece por má-fé: acontece porque o operador existe, e tudo o que existe está sujeito às contingências do mundo.

A ausência de um operador não está sujeita a essas mesmas contingências. Uma ordem judicial não pode pedir dados a um servidor que não existe. Um atacante não pode comprometer um servidor que não existe. Uma mudança na política de uma empresa não pode afetar dados que essa empresa nunca teve. A frase chave é simples: os dados que não existem não se podem perder.

Sobre o argumento legítimo do lado do servidor

Quem oferece um serviço de mensageiria profissional com servidor no meio costuma formular três argumentos perfeitamente válidos. Primeiro, que o servidor é necessário para garantir a entrega quando o destinatário está desligado. Segundo, que a cifragem do conteúdo é robusta e, portanto, o operador não pode lê-lo. Terceiro, que o serviço cumpre a legislação europeia e que os datos estão protegidos pela lei.

Os três argumentos são verdadeiros. Nenhum altera a natureza do assunto. É verdade que um servidor permite armazenar mensagens para entrega diferida; também é verdade que a entrega diferida pode ser resolvida de outra forma, através de protocolos de comunicação direta entre dispositivos refinados há décadas e operativos hoje. É verdade que a cifragem do conteúdo em trânsito é robusta nos serviços sérios. E é verdade que a legislação europeia protege os utilizadores mais do que a de muitos outros lugares.

A questão não é se os serviços com servidor no meio são legais, nem se são seguros, nem se protegem o conteúdo. Podem sê-lo, são legais, e costumam ser seguros. A questão é que ter um servidor no meio é uma escolha arquitetónica, não uma imposição técnica. E cada escolha tem consequências. Uma arquitetura com servidor no meio gera necessariamente um ator no qual é preciso confiar. Uma arquitetura sem servidor no meio não.

O que a lei diz, e o que a arquitetura faz

O RGPD não exige um modelo arquitetónico concreto. Exige resultados: minimização de dados, finalidade limitada, proteção desde o design e por defeito, capacidade de demonstrar o cumprimento. Um serviço com servidor no meio pode cumprir todos estes requisitos. Um serviço sem servidor no meio cumpre vários deles por construção, não por declaração. A minimização absoluta — não recolher nada que não seja estritamente necessário para entregar a mensagem — é trivial quando não existe um servidor que possa recolher algo.

Para os usos quotidianos não sensíveis, uma arquitetura com servidor é perfeitamente razoável, e a confiança num operador sério é um acordo válido. Para os outros usos — os que envolvem segredo profissional regulado, os que acarretam responsabilidade deontológica, os que tocam informação especialmente sensível — a ausência de um ponto de confiança não é um luxo, é uma vantagem estrutural.

A testemunha desnecessária

Voltar à sala do início ajuda a fixar a ideia. O fato de ninguém ter ouvido a conversa não depende de a testemunha ter se comportado bem: depende de não haver testemunha. Um servidor intermediário pode ser honesto, estar auditado, cumprir cada artigo do RGPD, e continuar sendo, precisamente, uma testemunha. Para quem lida com sigilo profissional, a pergunta que realmente importa não é se essa testemunha merece confiança: é se havia necessidade de que estivesse na sala.

A resposta, na maioria dos serviços de mensagens profissionais que existem hoje, é que não havia necessidade — e ela estava lá de qualquer forma.


Este artigo fecha o ciclo inicial de Cuadernos Lacre. Depois de falar da cifragem, dos metadados e do segredo profissional, completamos o quadro arquitetónico: cifrar o conteúdo e não ter servidor no meio são coisas distintas. As duas podem ser legais; apenas uma elimina o ponto de confiança.

Fontes e leitura adicional

  • Saltzer, J. H.; Reed, D. P.; Clark, D. D. — End-to-end arguments in system design, ACM TOCS, 1984. Texto fundacional do princípio segundo o qual as garantias de um sistema devem ser implementadas nas extremidades, não no canal intermédio.
  • Regulamento (UE) 2016/679, art. 25 — proteção de dados desde o design e por defeito.
  • Regulamento (UE) 2016/679, art. 5.1.c — princípio de minimização de datos.
  • Schneier, B. — Data and Goliath: the hidden battles to collect your data and control your world (2015), W. W. Norton. Capítulos sobre arquiteturas que minimizam a recolha por construção.

Leituras recentes