Signal: porquê não recomendo mais

Fonte: blog pessoal do Sander Venema, 5 de novembro de 2016. Licença CC-BY-NC 4.0. Tradução por Anders Bateva.

Uma das coisas que faço é treinamento de criptografia e segurança da informação para jornalistas investigativos que têm uma necessidade de manter suas fontes e comunicações confidenciais, de formas que possam mais seguramente fazer seus trabalhos de interesse público. Frequentemente, eles trabalham em locais que são pesadamente vigiados, como Europa, ou Estados Unidos. Os documentos do Edward Snowden explicam uma ou outra coisa sobre como o aparato de inteligência dos EUA faz seu trabalho diário. Os jornalistas também às vezes trabalham em locais no mundo onde a cripto-análise de mangueira de borracha [nota do tradutor: extração de senhas através de tortura] é mais comum do quê nos EUA ou Europa. E é por essas coisas que a ferramentas de criptografia sozinhas não são o Alfa e Ômega de segurança pessoal. Isto requer consideração cuidadosa do quê usar quando, e em qual situação. Uma das coisas que eu recomendei no passado para vários casos é o aplicativo do OpenWhisperSystems chamado Signal, disponível para Android e iOS. Neste artigo, eu quero explicar minhas razões sobre porquê eu não irei recomendar Signal no futuro.

Para ser claro: a razão para isto não é segurança. Até onde sei, o protocolo Signal é criptograficamente sólido, e suas comunicações devem ainda estar seguras. A razão tem muito mais a ver com a forma na qual o projeto é executado, o foco, e algumas dependências do aplicativo Signal oficial para Android, bem como o futuro da Internet, e que futuro nós gostaríamos de construir e viver. Este post foi principalmente desencadeado pelo experimento Giphy do Signal [nota do tradutor: refere-se ao Signal permitir aos usuários buscarem GIFs engraçadinhas para usar como resposta, usando o Giphy, um servidor externo], que mostra uma direção para o projeto que eu não tomaria. Há outros, e maiores, problemas que merecem nossa atenção.

O que é Signal?

Signal é um aplicativo publicado pela OpenWhisperSystems, uma companhia dirigida por Moxie Marlinspike. Ela publicou um aplicativo oficial Signal para Google Android, e Apple iOS. O Signal têm sido central em prover um aplicativo de troca de texto e ligações fácil de usar, e criptograficamente seguro. É uma combinação dos aplicativos separados prévios TextSecure e Redphone, que foram combinados em um aplicativo chamado Signal.

Uma das principais razões do porquê eu recomendava-o anteriormente às pessoas era ele ser fácil de usar, juntamente da segurança criptográfica. Esta é uma coisa boa que o Signal tem a seu favor. As pessoas poderiam simplesmente instalá-lo, e então comunicarem-se seguramente. Software criptográfico necessita ser muito mais simples de usar, e usar seguramente, e o Signal está fazendo sua parte em plataformas móveis, para criar uma plataforma segura de mensagens, e fácil de usar. Eu os aprecio por isto. Eu queria já deixar isso claro.

Múltiplos problemas com o Signal

Há, porém, múltiplos problemas com o Signal, especialmente:

  • Ausência de federação;
  • Dependência do Google Cloud Messaging;
  • Sua lista de contatos não é privada;
  • O servidor RedPhone não é código-aberto.

Tratarei destes um de cada vez.

Falta de federação

Há uma versão modificada do Signal, chamada LibreSignal, que removeu a dependência do Google que o aplicativo Signal tem, permitindo ao Signal ser executado em outros dispositivos (Android), como CopperheadOS, ou telefones Jolla (com a camada de compatibilidade do Android). Em maio deste ano, porém, Moxie deixou claro que ele não quer que o LibreSignal use os servidores do Signal, e que ele não aprova o nome. O nome é algo que pode mudar, não é um problema. O que é um problema, porém, é o fato de que ele não quer o LibreSignal usando os servidores Signal. O que estaria OK, se ele permitisse ao LibreSignal federar entre seus próprios servidores. Isto foi tentado uma vez (com o Telegram, mais que todos os outros), mas a seguir abandonado, porquê o Moxie crê que isto lerdeia mudanças para o aplicativo e/ou protocolo.

Todo o problema com sua posição, porém, é que eu não vejo o ponto de fazer qualquer destas coisas de mensagens seguras, sem ter federação. A internet foi construída sobre federação. Múltiplos provedores de e-mail e servidores, por exemplo, podem comunicar-se sem esforço uns com os outros, de formas que posso mandar um e-mail para alguém que tem um endereço do Gmail, ou um endereço corporativo, etc sem esforço, e tudo funciona. Isto funciona devido à federação, porquê os protocolos são todos padrões abertos e há múltiplas implementações dos padrões, que podem cooperar e comunicarem-se juntos. Outro exemplo seria o protocolo Jabber/XMPP, que também tem múltiplos clientes em múltiplas plataformas, que podem comunicar-se seguramente uns com os outros, apesar de um ter uma conta Jabber num servidor diferente do outro.

Se não federarmos, se não cooperarmos, o que irá prevenir que a internet torne-se um monte de jardins murados novamente? Seria a internet nada mais que apenas uma plataforma para escolhermos certos serviços-silos proprietários? O Signal então, apenas é um silo (parcialmente proprietário) no qual suas mensagens são transmitidas seguramente.

Dependência do Google Cloud Messaging

Atualmente, o cliente oficial Signal depende da Google Cloud Messaging para operar corretamente. A alternativa que foi desenvolvida pelas pessoas do LibreSignal removeu esta dependência, de formas que as pessoas rodando outros softwares, como Jolla ou CopperheadOS podem rodar Signal. Infelizmente, as decisões de políticas do OpenWhisperSystems e Moxie Marlinspike tornaram impossível confiavelmente rodar clientes Signal não-oficiais que usam a mesma infraestrutura de servidor, para que as pessoas possam comunicar-se. Também, a federação, como explicado na seção anterior, é expressamente atrapalhada e proibida por OpenWhisperSystems, então não é uma opção para o LibreSignal simplesmente rodar seus próprios servidores e então federar com a rede Signal maior, permitindo às pessoas contactar umas às outras através de clientes.

O que é Google Cloud Messaging?

O serviço Google Cloud Messaging basicamente é responsável por manejar mensagens de/para os dispositivos do usuário e os servidores do Signal. O serviço GCM então maneja todos os aspectos de enfileirar mensagens e transmitir de/para usuários.

Há uma forma de usar o Signal sem depender do GCM, mas isto usa microg, o que basicmente requer das pessoas que re-compilem seus kernels. Isto não é algo que possa-se pedir a usuáros não-técnicos.

prism_logo

Logotipo do programa PRISM, da NSA.
Fonte: Wikimedia Commons.

Também, há o problema da integridade. O Google ainda está cooperando com a NSA e outras agências de inteligência. O PRISM ainda é um problema. Eu tenho bastante certeza de que o Google poderia servir uma atualização especialmente modificada ou versão do Signal para alvos específicos de vigilância, e eles não saberiam que foi instalado malware em seus telefones.

Sua lista de contatos não é privada

Aqui está a lista de permissões do Signal, incluindo a explicação do OpenWhisperSystems sobre a necessidade para elas. Como podes ver, o Signal tem permissão (se você instalá-lo), de ler e modificar seus contatos. O Signal associa números de telefone com nomes em uma maneira similar com a qual o WhatsApp está fazendo, e isto é uma grande razão do porquê eles sentem que precisam ler sua lista de contatos. Também, há a questão de usabilidade, onde eles mostram os nomes dos contatos e fotos no aplicativo Signal.

Isto poderia, claro, ter sido feito todo diferente, ao utilizar nomes de usuários para conectar os usuários, ao invés de seus números de telefone (colateralmente, isto iria também permitir às pessoas que usam múltiplos números no mesmo dispositivo a poderem usar o Signal confiavelmente). E, da última vez que chequei, se você usa o mesmo número de telefone em um dispositivo diferente, o Signal será des-registrado no dispositivo antigo.

Outro problema, e um plus para empregar nomes de usuários, é que você pode querer usar Signal com pessoas as quais você não necessariamente quer dar seu número de telefone. E a federação seria também mais fácil com nomes de usuários, e servidores, separados por um símbolo, como a @. Tal qual no caso do Jabber/XMPP. Eu também não vejo nenhum problema de usabilidade aqui, dado que mesmo pessoas não-técnicas geralmente entendem o conceito de um endereço, ou um endereço de e-mail, e isto seria bem similar.

RedPhone não é código-aberto

O componente de telefonia do Signal é chamado RedPhone. O componente do servidor disto é, infortunamente, não-código aberto (então as pessoas são impedidas de rodar seus próprios servidores de telefonia, e isto também é provavelmente a razão pela qual chamadas telefônicas criptografadas seguramente não funcionam, por exemplo, no LibreSignal).

Eu não sei exatamente o quê previne o código do servidor do RedPhone de ser liberado (sejam problemas legais, ou simples falta de vontade), mas eu penso que é estranho que não haja movimento também para mudar para uma solução diferente/alternativa, que respeite os direitos dos usuários.

Seguindo adiante

A grande questão agora, como também dita por @shiromarieke no Twitter, é qual ferramenta pós-Signal nós queremos usar. Eu não sei a resposta para essa questão ainda, mas eu irei apontar meus requerimentos mínimos para tal peça de software aqui. Nós, como uma comunidade, precisamos encontrar uma solução viável e alternativa ao Signal, que seja fácil de usar e que de fato respeite as escolhas das pessoas, tanto no hardware quanto no software que elas decidam usar.

A meu ver, deveria haver uma ferramenta que seja totalmente software livre (segundo a definição da GNU GPL), que respeite as liberdades dos usuários de livremente inspecionar, usar, modificar o software e distribuir cópias modificadas do software. Também, esta ferramenta não deveria ter dependência de infraestrutura corporativa como a do Google (basicamente qualquer colaborador do PRIM), que permita a estes colaboradores controlar o funcionamento correto do software. O fato de que o Signal depende do Google Cloud Messaging, e da tecnologia Google em geral, é algo que deve ser evitado.

No fim, eu penso que precisamos seguir para uma Internet onde há mais serviços federados, não menos; onde a informação é abertamente compartilhada; e os serviços publicamente executados por múltiplas pessoas em todo o mundo. De outra maneira, nós estaremos em risco de terminar em uma Internet neo-90s, com jardins murados e paywalls por todo lado. Você já vi esta tendência ocorrendo no jornalismo.

Precisamos lembrar que nós estamos lutando não apenas contra a vigilância governamental, mas também contra vigilância corporativa. Nós precisamos de maneiras de defender-nos contra isto, e usar soluções corporativas que criem dependência nestas soluções, mesmo se as comunicações em si não sejam legíveis para eles, ainda há o problema dos metadados, e claro, a disponibilidade geral dos serviços Google para o Signal.

É realmente lamentável que o OpenWhisperSystems não seja mais amigável com iniciativas tal qual LibreSignal, uma vez que estas pessoas tiveram bastante trabalho, que agora está basicamente para ser jogado fora porquê a pessoa no comando do Signal não é amigável a essas iniciativas.

Nós precisamos cooperar mais como uma comunidade, ao invés de criar estas ilhotas, do contrário, não iremos ter sucesso em derrotar, ou mesmo significativamente deifender-nos, do Grande Irmão. Lembre-se, nosso inimigo sabe como dividir e conquistar. Divide et impera. Têm sido uma tática governamental de subjugação desde os tempos de Roma. Nós não deveríamos permitir nossos próprios egos mesquinhos, e a busca por fama hacker eterna, de entrar no caminho de nosso objetivo real: desmantelar os Estados de vigilância globalmente.

Deixe uma resposta

O seu endereço de e-mail não será publicado.

*