Como funciona
Chat peer-to-peer com WebRTC, explicado
Depois do handshake não existe servidor no caminho, então não há nada para guardar nem para entregar. Veja exatamente o que o backend enxerga, e as três coisas que o peer-to-peer não garante.
Abrir sala P2P
Abrir sala P2PO único trabalho do servidor é a apresentação
Todo app de chat que você já usou funciona do mesmo jeito por baixo dos panos: sua mensagem sobe até o servidor de uma empresa, o servidor guarda ela, e o servidor entrega para a outra pessoa. As discussões sobre criptografia são sobre quem pode ler essa cópia. A cópia continua existindo.
Um DataChannel do WebRTC pula essa etapa do meio. Dois navegadores negociam uma conexão direta criptografada, e depois que ela abre, sua mensagem vai da sua máquina para a do outro sem nada no caminho. O FadeChats até roda um servidor, mas ele funciona como uma telefonista de mesa: passa os dados que os dois navegadores precisam para se encontrar, e depois sai da conversa.
Esse é todo o truque, e é por isso que este site não tem um botão de "apagar meus dados". Não existe uma tabela de mensagens para apagar.
O que acontece entre abrir a página e digitar
- Seu navegador escreve uma oferta
Ele monta uma oferta SDP descrevendo o transporte que suporta, mais a impressão digital de um certificado gerado para esta sessão. A oferta vai para o servidor do FadeChats, estacionada sob um id de sala aleatório.
- O outro navegador responde
Seu convidado abre o link de convite de uso único, pega a oferta e devolve uma resposta. Os dois lados também trocam candidatos ICE: os endereços de rede em que cada um pode estar acessível, descobertos com a ajuda de um servidor STUN.
- As duas pontas apertam as mãos direto
O ICE testa pares de candidatos até um conectar, e então os navegadores fazem um handshake DTLS sobre essa conexão. Eles mesmos derivam as chaves e conferem um ao outro contra as impressões digitais combinadas no primeiro passo.
- O canal abre, o servidor termina seu papel
Texto, imagens, GIFs e figurinhas viajam em um fluxo SCTP dentro dessa sessão DTLS, de navegador para navegador. Os registros de configuração expiram em um TTL de 10 minutos que a atividade renova.
Quem consegue ver o quê
| A pessoa que você convidou | O servidor do FadeChats | Um relay TURN, quando necessário | |
|---|---|---|---|
| Mensagens, imagens, GIFs | Sim, essa é a ideia | Nunca | Só bytes criptografados |
| O id da sala | Sim | Sim | Sim |
| Seu endereço IP | Sim, numa conexão direta | Sim, durante a configuração | Sim, enquanto faz o relay |
| Que a sala esteve ativa | Sim | Até o TTL expirar | Enquanto faz o relay |
| Qualquer coisa depois que a sala desaparece | Só o que a pessoa capturou | Nada foi escrito, nunca | Nada |
Cada lado descobrir o endereço do outro é uma propriedade do transporte, não uma configuração que dá para desligar.
Três coisas que o peer-to-peer não garante
- Seu par vê seu endereço IP
Uma conexão direta tem duas pontas reais, então a pessoa que você convidou descobre mais ou menos sua cidade e seu provedor de internet. O Signal esconde isso fazendo o relay de tudo pelos próprios servidores. O FadeChats não pode, porque fazer o relay de tudo é justamente o que ele se recusa a fazer.
- Às vezes existe um relay de qualquer jeito
NAT simétrico, redes corporativas e algumas operadoras de celular bloqueiam um caminho direto. Aí o WebRTC recorre a um relay TURN, que repassa bytes criptografados por DTLS sem ter a chave para eles. Ainda assim é uma terceira máquina no caminho, e vale dizer isso em voz alta.
- O handshake confia no canal de sinalização
Cada lado verifica a impressão digital do certificado do outro, mas essa impressão digital chegou através do servidor. Um servidor de sinalização comprometido poderia, em princípio, trocá-la e ficar no meio. O Signal resolve isso com números de segurança que você compara por fora; o FadeChats não tem essa verificação.
Onde esse formato encaixa
Peer-to-peer é certo quando duas pessoas precisam dizer algo uma vez e não querem nenhuma cópia disso em lugar nenhum: uma senha com uma pergunta de acompanhamento, um endereço, um diagnóstico, um número. É o formato errado para um grupo, para qualquer coisa que precise sobreviver a uma aba fechada, e para uma situação em que errar sobre quem é o adversário tem consequências reais.
Perguntas frequentes
Um chat com WebRTC precisa de servidor?
Precisa, mas só para apresentar os dois navegadores. Um servidor de sinalização carrega a oferta, a resposta e os candidatos de rede; um servidor STUN diz a cada navegador qual é o seu endereço público. Depois que o DataChannel abre, nenhum dos dois fica no caminho de uma única mensagem.
O servidor de sinalização consegue ler minhas mensagens?
Não, ele nunca recebe elas. O canal é negociado entre os navegadores e as chaves são deles. O servidor do FadeChats guarda só os registros de configuração, que expiram em um TTL de 10 minutos renovado pela atividade.
A outra pessoa vê meu endereço IP?
Numa conexão direta, sim, e você também vê o dela. É isso que torna a conexão direta. Se você precisa esconder isso da pessoa com quem está falando, use uma VPN, ou use uma ferramenta que faz o relay de tudo, como o Signal.
Um DataChannel do WebRTC é criptografado de ponta a ponta?
O transporte é: SCTP dentro de DTLS, com chaves que os dois navegadores derivam sozinhos. A ressalva é a troca de impressões digitais explicada acima. A criptografia de ponta a ponta no WebRTC só é tão confiável quanto o canal que carregou essas impressões digitais.
Preciso instalar alguma coisa para experimentar?
Não. O WebRTC já vem em todo navegador atual, então o FadeChats é só uma página que você abre. Sem conta, sem número de telefone, sem aplicativo. A sala existe assim que a página carrega e cabem duas pessoas nela.