Como o MindTheClub conecta você

No MindTheClub, o conteúdo das mensagens viaja diretamente entre dois dispositivos por um canal peer-to-peer criptografado. Nenhum servidor do MindTheClub, nem terceiros, armazena o conteúdo das suas mensagens.

Para estabelecer essa conexão direta, dois dispositivos precisam trocar uma pequena quantidade de informações de configuração e, se um deles estiver dormindo, um sinal para acordá-lo. Essas duas etapas de apoio são os únicos pontos em que um servidor participa, e abaixo descrevemos com precisão o que cada um pode e não pode ver.

Antes de tudo isso acontecer, os dois dispositivos precisam conhecer a identidade um do outro. Descrevemos isso primeiro, porque cada etapa posterior desta página se apoia nela.

Etapa 0: como dois pares se verificam mutuamente

Cada etapa criptografada a seguir depende de uma premissa: cada par usa a chave pública verdadeira do outro, não uma substituída por um provedor no meio do caminho. Conseguimos isso com uma única troca fora de banda e uma resposta lacrada, de modo que os dois lados ficam verificados após uma leitura de QR ou um toque num link de convite.

O código QR ou link de convite carrega uma impressão digital

Seu código QR contém seu identificador de usuário e uma impressão digital da sua chave pública, um hash criptográfico curto que a identifica de forma única. Seu link de convite carrega as mesmas duas coisas, embutidas no próprio link. Assim, quer alguém escaneie seu código ou toque no seu link, o dispositivo dessa pessoa recebe a mesma impressão digital para conferir. Mostrar o QR cara a cara é o canal mais forte, mas em ambos os casos a garantia abaixo vale: o provedor do diretório nunca consegue substituir sua chave sem ser detectado.

O destinatário verifica sua chave

Quando a outra pessoa escaneia ou toca, o dispositivo dela busca sua chave pública no diretório e calcula a impressão digital localmente. Se coincidir com a do QR ou do link, a chave é aceita; caso contrário, é rejeitada e não é armazenada. Uma chave substituída produz uma divergência, e o dispositivo a recusa.

Você é verificado em troca

O dispositivo dela então envia a você um pedido de contato com a própria impressão digital lacrada dentro, criptografada com a sua chave verificada. Só você pode decifrá-la. Seu dispositivo executa a mesma verificação no sentido inverso, aceitando o contato apenas se as impressões digitais coincidirem.

O que isso nos dá

Após uma leitura ou um toque, os dois pares verificaram de forma independente a chave um do outro, e um provedor que detenha o diretório não pode substituir nenhuma delas sem quebrar uma verificação que ele não tem poder de falsificar.

Etapa 1: o canal peer-to-peer (para onde vão seus dados)

O MindTheClub usa canais de dados WebRTC para transportar as mensagens. Um canal de dados WebRTC é uma conexão direta e criptografada entre dois dispositivos. Uma vez estabelecido entre dois pares:

Arquivos grandes são divididos em blocos e enviados pelo mesmo canal direto, com lógica de reenvio no dispositivo remetente para garantir a entrega final. Os blocos viajam peer-to-peer como tudo o mais.

E quando os pares não conseguem se conectar diretamente?

Às vezes dois dispositivos não conseguem abrir um caminho direto (NATs restritivos, firewalls de operadoras móveis). Nesse caso o WebRTC recorre a um relay TURN para fazer passar o fluxo criptografado. O MindTheClub usa o serviço TURN da Cloudflare para esse recurso. O relay encaminha pacotes criptografados; é uma parte padrão do funcionamento do WebRTC quando uma conexão direta não é possível. Esse recurso afeta apenas o caminho de rede do fluxo criptografado; não muda o fato de que o conteúdo permanece de ponta a ponta entre os dois dispositivos.

Etapa 2: sinalização (como os dois dispositivos se encontram)

Antes que um canal WebRTC possa abrir, os dois dispositivos precisam trocar informações de "sinalização": descrições de conexão e endereços de rede candidatos (em termos de WebRTC, a oferta/resposta SDP e os candidatos ICE). É um requisito universal do WebRTC — todo aplicativo WebRTC, incluindo sites de videochamada, faz isso. As informações são pequenas e servem apenas para estabelecer a conexão; não são o conteúdo das suas mensagens.

A questão é: quem transporta essa sinalização e o que consegue ver. No MindTheClub:

O que o relay de sinalização pode ver

Projetamos a sinalização para que o relay aprenda o mínimo possível:

Etapa 3: acordando um telefone adormecido (push)

Se o telefone do Bob está dormindo ou o app não está rodando, o dispositivo da Alice precisa de um jeito de acordá-lo para que ele entre na conexão. Para isso, o MindTheClub usa o Firebase Cloud Messaging (FCM), o serviço de push do Google, porque é o mecanismo que o Android fornece para acordar um app de forma confiável em segundo plano.

Como o sinal de despertar é enviado

Remetente lacrado ("sealed sender")

O conteúdo da carga de despertar é criptografado com a chave pública do destinatário antes de sair do remetente. Ponto crucial: a identidade do remetente está dentro dessa carga criptografada; ela não é visível para a infraestrutura de push. É um design de "remetente lacrado": quem entrega o push não consegue ver quem o enviou.

Para entregar um push, qualquer sistema de push precisa saber quem o recebe; é assim que a entrega funciona, e isso vale para todo mensageiro baseado em push. Então o endereço do destinatário é necessariamente visível à camada de push. O que não é visível é a identidade do remetente, que permanece lacrada dentro da carga criptografada.

Etapa 4: credenciais de conexão

Para estabelecer a conexão WebRTC, os dispositivos precisam de credenciais de curta duração para o serviço STUN/TURN (os componentes que ajudam dois dispositivos a encontrar um caminho de rede entre si). Essas credenciais são geradas usando uma chave secreta que deve ficar fora do dispositivo.

O MindTheClub busca essas credenciais num Cloudflare Worker que guarda o segredo do lado do servidor. Nenhum serviço do Google participa da obtenção das credenciais de conexão. Se essa busca falhar, a conexão recorre a servidores STUN públicos, que apenas ajudam um dispositivo a descobrir o próprio endereço público e não aprendem nada sobre quem ele vai contatar.

A forma do projeto, em um parágrafo

Juntando tudo: os pares verificam as chaves um do outro com uma leitura de QR ou um link, depois trocam pequenas quantidades de informações de configuração criptografadas por meio de um relay sem estado e um push de despertar lacrado. Uma vez aberto o canal direto, o conteúdo das mensagens flui apenas de dispositivo a dispositivo.