Como as pontes do Tor são distribuídas: BridgeDB, rdsys, Moat e a lógica da escassez
Uma ponte é um retransmissor do Tor não listado: não aparece na lista pública de relés, por isso um censor tem de a descobrir antes de poder bloqueá-la. Essa propriedade mantém-se apenas enquanto a ponte for difícil de obter, o que faz do próprio sistema de distribuição parte da resistência à censura do Tor. Em outubro de 2024, o Projeto Tor aposentou a BridgeDB, o sistema que distribuíra pontes durante mais de uma década, e concluiu a migração para o rdsys, o seu sistema de distribuição de nova geração. A forma como estes sistemas decidem quem recebe cada ponte explica muito sobre por que as pontes ainda funcionam em redes fortemente censuradas.
De BridgeDB a rdsys
A BridgeDB foi lançada há mais de onze anos como um protótipo e continuou a funcionar muito além da sua vida útil prevista. Segundo os engenheiros por trás da migração, oferecia pedidos pela web, pedidos por e-mail e uma API do navegador Tor chamada Moat, e os três canais acabaram sob pressão: os censores recolhiam dados dos sites de pedido de pontes, inundavam o sistema de e-mail para colher endereços e contornavam os captchas recorrendo a serviços humanos de resolução de CAPTCHAs. Anos de remendos contra essas táticas transformaram-se em dívida técnica, por isso o projeto começou por volta de 2020 a desenvolver um substituto: o rdsys. O rdsys, abreviatura de resource distribution system, é deliberadamente mais abrangente do que o seu antecessor. Distribui todo o tipo de recursos para contornar a censura: pontes do Tor, proxies Snowflake, pontos de VPN, até ligações de download de software de contorno. Em termos de arquitetura, é um processo de backend que recolhe recursos e vários processos distribuidores que os entregam. O backend mantém o inventário e mapeia cada recurso para exatamente um distribuidor; a tarefa do distribuidor, como diz a documentação do rdsys, é distribuir os recursos com juízo, oferecer uma interface utilizável e frustrar ataques Sybil. Os canais de distribuição
A documentação de suporte do Projeto Tor resume a premissa sem rodeios: "Como os endereços das pontes não são públicos, terá de os pedir você próprio." Hoje existem vários canais paralelos, cada um com o seu próprio controlo de acesso. - O Moat está integrado no navegador Tor: o utilizador clica em "Pedir pontes" nas definições de ligação, resolve um captcha e as pontes são adicionadas automaticamente.
- O distribuidor HTTPS gere o site das pontes, que oferece uma opção de um clique ("Just give me bridges!") ao lado de escolhas avançadas como o tipo de transporte ou endereços IPv6.
- O distribuidor de e-mail responde a mensagens enviadas para bridges@torproject.org a partir de um endereço Gmail ou Riseup, com "get transport obfs4" no corpo da mensagem.
- O distribuidor do Telegram entrega pontes através do @GetBridgesBot, com comandos como /obfs4 ou /webtunnel. Para distinguir utilizadores reais de contas criadas em massa, pondera o historial da conta, separando as antigas das recém-registadas; o Projeto Tor descreve isto como uma resposta à censura crescente na Rússia.
- O Lox, ainda em desenvolvimento, é um mecanismo que preserva a privacidade e se baseia na reputação: deteta pontes bloqueadas e recompensa os utilizadores cujas pontes permanecem desbloqueadas.
Há também dois não-canais que vale a pena conhecer. Um grupo reservado (Reserved) é guardado para distribuição manual a ONG e pessoas com necessidades especiais, e as pontes marcadas como None ficam ao cuidado dos seus operadores, que as distribuem por conta própria. Uma ponte recém-registada mostra None durante cerca de um dia antes de se juntar ao grupo que lhe foi atribuído. O Moat e o compromisso do captcha
O Moat merece um olhar mais atento porque é o caminho que a maioria dos novos utilizadores encontra primeiro. O captcha era a forma do sistema provar que um pedido vinha de um humano e não do rastreador de um censor, e resolver um continua a ser o fluxo documentado dentro do navegador Tor. Mas a própria avaliação do Projeto Tor é de que os captchas se tornaram um mau negócio: são frustrantemente inacessíveis para quem usa leitores de ecrã ou dispositivos antigos, por vezes impossíveis devido a barreiras linguísticas, e cada vez menos eficazes, porque os censores empregam ferramentas automatizadas ou serviços de resolução humana que os atravessam sem dificuldade. É por isso que o rdsys está a abandonar os captchas, e por que o Moat está a ser substituído pelo distribuidor Settings, uma API que configura automaticamente as definições de contorno, incluindo o tipo de ponte a experimentar, com base no país do utilizador. Por que a escassez é o ponto
Cada ponte entregue é uma ponte que um censor poderia aprender, por isso a distribuição é deliberadamente racionada em vez de publicada. O backend do rdsys só entrega recursos que se sabe funcionar: o serviço bridgestrap testa os transportes conectáveis de cada ponte e marca-os como funcionais ou defeituosos, um serviço separado mede a largura de banda, e cada ponte do Tor é testada novamente quando expira o seu temporizador de dezoito horas. Os operadores podem consultar o estado da sua própria ponte numa página de estado pública, por impressão digital. As pontes bloqueadas ou avariadas são retiradas de circulação em vez de serem empurradas para mais utilizadores na mesma região, e um mecanismo como o Lox foi concebido precisamente para detetar pontes bloqueadas e encaminhar pontes novas para quem ainda as precisa. Um problema de investigação em aberto
A tensão subjacente é antiga. Num artigo de 2016, os investigadores por trás do protocolo TorBricks disseram-no sem rodeios: os métodos atuais de distribuição de pontes são vulneráveis a utilizadores maliciosos que obtêm endereços de pontes para as bloquear. A sua proposta racionava um orçamento logarítmico de pontes por utilizador adversário, de modo que, mesmo com um número desconhecido de requerentes controlados pelo censor, os utilizadores honestos ainda conseguissem uma ponte funcional após algumas rondas de comunicação. Uma década depois, o problema geral continua por resolver; a resposta do rdsys é pragmática em vez de matemática: muitos canais pequenos, cada um com heurísticas diferentes, para que nenhum scraping ou inundação isolada esvazie o reservatório. Para a contraparte prática deste artigo, o nosso guia sobre pontes em regiões censuradas cobre como pedi-las e configurá-las hoje. A conclusão
A distribuição de pontes é um ato de equilíbrio entre alcançabilidade e escassez. Publicar demasiado livremente permite que os censores recolham a lista; filtrar de forma demasiado restrita deixa os utilizadores legítimos de fora. A passagem da BridgeDB ao rdsys não pôs fim a esse compromisso, mas tornou o sistema suficientemente modular para continuar a experimentar novos canais, do Telegram e do Lox às predefinições conforme a localização, à medida que os antigos se erodem. Para os utilizadores sob censura, o conselho não mudou: peça algumas pontes, teste-as e esteja pronto a pedir mais.
