A maioria dos aplicativos de mensagens parece simples por fora. Você abre um chat, escolhe alguém e envia uma mensagem. Por trás dessa experiência simples, no entanto, os mensageiros podem ser construídos de formas muito diferentes.

Alguns funcionam como ambientes controlados, nos quais a comunicação permanece dentro de um único sistema. Outros permitem a conexão de servidores operados de forma independente, bots externos, aplicativos de terceiros, clientes de terceiros ou até mesmo outros serviços de mensagens.

Essas conexões podem oferecer recursos úteis. Elas podem permitir automação, aplicativos personalizados, ferramentas empresariais e comunicação entre diferentes plataformas. Mas cada nova conexão também cria outro caminho para dentro do sistema de comunicação, e esse caminho precisa ser protegido.

No nosso artigo anterior, analisamos como a limitação da busca por usuários protege as pessoas contra contatos indesejados. Aqui, estamos analisando outra camada da privacidade: os sistemas externos que um mensageiro permite conectar.

O que é um mensageiro de arquitetura aberta?

Neste artigo, um mensageiro de arquitetura aberta é aquele que permite que sistemas externos se conectem ao seu ambiente de comunicação.

Dependendo da plataforma, isso pode incluir: • servidores operados por outras organizações; • bots criados por desenvolvedores externos; • aplicativos de mensagens personalizados ou de terceiros; • pontes que conectam diferentes plataformas; • ferramentas empresariais e serviços automatizados; • comunicação direta com outros mensageiros.

Nem todo mensageiro aberto oferece suporte a todos esses recursos. Cada plataforma decide quais partes do sistema serão abertas e o que desenvolvedores ou serviços externos podem fazer.

Um mensageiro de arquitetura fechada adota uma abordagem diferente. A comunicação principal permanece dentro de um ecossistema controlado, usando aplicativos aprovados e um conjunto de regras de comunicação. A diferença está no controle.

Em um ambiente aberto, parte do processo de comunicação pode depender de softwares, servidores, desenvolvedores ou empresas fora do controle direto do provedor do mensageiro. Em um ambiente fechado, menos partes externas podem participar desse processo.

Cada conexão extra é mais uma porta

Todo mensageiro online precisa de uma conexão controlada entre seu aplicativo oficial e seu sistema de comunicação. Sem essa conexão, os usuários não poderiam entrar, enviar mensagens, compartilhar arquivos ou fazer chamadas.

A questão de segurança é quantas portas públicas adicionais o mensageiro cria para sistemas externos. Uma porta comum é uma Application Programming Interface (API). Uma API é um conjunto de regras que permite que um software se comunique com outro.

Um mensageiro pode oferecer uma API para que um desenvolvedor externo crie um bot, desenvolva um aplicativo personalizado, conecte um sistema de atendimento ao cliente ou automatize determinadas ações.

Uma API não é automaticamente uma falha de segurança. Mas é outro ponto de entrada que precisa de: • credenciais de acesso seguras; • limites claros de permissão; • proteção contra abuso automatizado; • monitoramento de atividades suspeitas; • atualizações regulares de segurança; • uma forma de remover o acesso rapidamente.

Profissionais de segurança chamam todos os pontos em que alguém pode interagir com um sistema de superfície de ataque. Quanto mais pontos públicos de conexão um sistema tem, mais lugares os invasores podem examinar em busca de controles de acesso fracos, erros de programação, credenciais roubadas ou permissões incorretas. (NIST Computer Security Resource Center)

A porta em si não é o exploit.

A fechadura fraca é a vulnerabilidade. O método usado para quebrá-la ou contorná-la é o exploit.

Isso leva a um princípio simples: uma porta pública que não existe não pode ter sua fechadura arrombada.

Cada conexão opcional que não é criada elimina mais um conjunto de credenciais, permissões, softwares externos e regras de segurança que, de outra forma, precisariam ser confiáveis e protegidos.

Federação: quando servidores externos se conectam

A federação permite que servidores operados de forma independente se comuniquem entre si. O e-mail é um exemplo conhecido. Um usuário do Gmail pode enviar um e-mail para um usuário do Outlook mesmo que Google e Microsoft operem sistemas diferentes.

Um mensageiro federado pode funcionar de maneira parecida. Uma organização opera seu próprio servidor de chat, outra organização opera um servidor diferente e os dois servidores trocam mensagens por meio de um sistema técnico compartilhado.

Isso dá mais independência às organizações. Elas podem operar seus próprios servidores e ainda se comunicar com uma rede mais ampla. Mas isso também significa que cada servidor conectado precisa processar informações vindas de sistemas que ele não controla.

Esses servidores externos podem usar software desatualizado, aplicar atualizações lentamente, ter configurações de segurança mais fracas ou processar informações de forma diferente. Um servidor também pode ser comprometido ou ser operado por alguém que esteja deliberadamente tentando prejudicar outras partes da rede.

O que aconteceu no Matrix

Matrix é uma rede aberta de mensagens que permite que pessoas e organizações operem servidores de chat separados e ainda se comuniquem com usuários em outros servidores Matrix.

Em 2025, uma vulnerabilidade grave foi encontrada no Synapse, software de servidor amplamente usado no Matrix. Um servidor conectado malicioso podia enviar dados especialmente preparados que impediam um servidor vulnerável de se comunicar corretamente com o restante da rede.

O aviso oficial de segurança confirmou que a vulnerabilidade havia sido explorada em ataques reais. Também afirmou que sistemas sem federação pública, assim como federações fechadas contendo apenas servidores confiáveis, não foram afetados.

A falha estava diretamente relacionada à federação. O servidor vulnerável precisava aceitar e processar dados vindos de outro servidor controlado de forma independente. Sem essa conexão pública entre servidores, essa rota específica de ataque não teria existido.

APIs e bots: quando softwares externos participam

APIs permitem que softwares externos executem determinadas ações dentro de um mensageiro. Um uso comum é o bot, uma conta automatizada controlada por software. Bots podem responder perguntas, oferecer atendimento ao cliente, enviar lembretes, processar pagamentos, gerenciar grupos ou fornecer informações.

Mas cada bot também introduz um operador externo e, em muitos casos, um servidor externo. O mensageiro passa a precisar confiar que: • o desenvolvedor do bot protege suas credenciais de acesso; • o bot solicita apenas as permissões de que precisa; • o servidor do desenvolvedor é seguro; • o bot não coleta informações de forma irresponsável; • a automação não é usada para spam ou fraude.

Se o token de acesso de um bot for roubado, um invasor poderá conseguir operar esse bot. Se o servidor do desenvolvedor for comprometido, o invasor poderá herdar a conexão legítima do bot com o mensageiro. A automação também pode aumentar a escala do abuso. Uma pessoa pode enviar mensagens prejudiciais uma por uma. Um software pode gerá-las e distribuí-las continuamente.

Aplicativos de mensagens de terceiros

Algumas plataformas também permitem que desenvolvedores externos criem seus próprios aplicativos conectados ao mensageiro. O aplicativo pode se conectar à rede real de mensagens, mas ainda é um software criado por alguém de fora do provedor principal do mensageiro.

Isso importa porque a criptografia protege uma mensagem enquanto ela trafega. O aplicativo ainda precisa ver a mensagem legível no dispositivo do usuário antes de ela ser criptografada e depois de ser descriptografada. Portanto, um cliente de terceiros pode lidar com: • credenciais da conta; • sessões de login; • mensagens; • arquivos baixados; • informações de contatos; • histórico local de mensagens; • chaves de criptografia ou outros dados confidenciais da conta.

Os usuários deixam de confiar apenas no mensageiro. Eles também passam a confiar no desenvolvedor externo que criou o aplicativo.

Mesmo que o sistema principal de comunicação continue protegido, um cliente mal projetado ou malicioso pode expor informações diretamente no dispositivo. Para um mensageiro focado em comunicação privada, controlar quais softwares podem se conectar é, portanto, tão importante quanto proteger a própria conexão.

Interoperabilidade: quando diferentes mensageiros se conectam

A interoperabilidade permite que usuários de serviços de mensagens diferentes se comuniquem diretamente. Por exemplo, uma pessoa que usa um mensageiro pode conseguir enviar uma mensagem para alguém que usa outro mensageiro sem que nenhum dos dois precise trocar de aplicativo.

Do ponto de vista do usuário, pode parecer uma conversa normal. Tecnicamente, no entanto, dois sistemas diferentes agora estão envolvidos. Os serviços precisam coordenar: • identidades dos usuários; • entrega de mensagens; • criptografia; • arquivos e mídia; • participação em grupos; • bloqueio; • denúncias de spam; • mensagens temporárias; • diferenças entre configurações de privacidade.

Cada mensageiro pode ter seus próprios aplicativos, servidores, processos de segurança, cronograma de atualizações e regras para lidar com dados dos usuários. Isso significa que um único provedor deixa de controlar todo o caminho da comunicação.

Por que o Zangi mantém a comunicação privada fechada

No Zangi, fizemos uma escolha arquitetônica deliberada. Não projetamos nosso mensageiro privado principal como uma plataforma pública para bots externos, clientes de mensagens de terceiros, servidores federados ou redes externas de mensagens. Os usuários do Zangi se comunicam dentro de um único ambiente controlado por meio dos aplicativos oficiais do Zangi. Nós controlamos as regras de comunicação, os softwares compatíveis e a forma como as informações trafegam pelo sistema.

Isso remove várias dependências externas da comunicação privada. Sem uma plataforma pública de bots, não existe um token público de acesso de bot que possa ser roubado e usado para operar dentro de chats privados.

Sem uma plataforma aberta para clientes de terceiros, os usuários não precisam confiar em um desenvolvedor externo para lidar com suas mensagens legíveis, sessões de conta ou dados locais de comunicação. Sem federação pública, o Zangi não precisa aceitar instruções de comunicação ou dados de servidor especialmente criados por operadores desconhecidos. Sem interoperabilidade entre mensageiros, outra empresa de mensagens não passa a fazer parte da conversa privada de um usuário do Zangi.

Essa arquitetura controlada funciona em conjunto com o modelo mais amplo de privacidade do Zangi. A comunicação é protegida com criptografia de ponta a ponta, os usuários se comunicam por meio de números privados Zangi e o histórico de comunicação permanece no dispositivo do usuário, em vez de se tornar um histórico permanente de chat armazenado em servidor. (Zangi) Algumas plataformas de mensagens são projetadas para se tornar grandes ecossistemas para desenvolvedores, bots, aplicativos personalizados e conexões com outras redes.

O Zangi foi criado com outro propósito: comunicação privada dentro de uma comunidade controlada. Isso não é um recurso ausente. É a arquitetura funcionando exatamente como foi planejada.

Cada porta pública opcional que deixamos de incluir é uma porta a menos que precisa de fechadura, uma chave a menos que pode ser roubada e uma parte externa a menos em quem os usuários precisam confiar.