Signal: porquê não recomendo mais

Por Sanders Venema, Tradução de Anders Bateva

Uma das coisas que faço é treinamento de criptografia e segurança da informação para jornalistas investigativos que têm precisam 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 extração de senhas por meio 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 de 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 ainda devem ser 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 (experimento que permite aos usuários buscarem GIFs engraçadinhas para usar como resposta, usando o Giphy, um servidor externo), que mostra uma direção para adotada o projeto que eu não adotaria. 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 costumava recomenda-lo para as pessoas era por ser fácil de usar, juntamente com a 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 o deixa mais lento para 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 um modelo de 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ários 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.

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


Kommentare

One comment for Signal: porquê não recomendo mais

  1. Pingback: Vulnerabilidade no WhatsApp permite a interceptação e leitura das mensagens | PIRATAS

Deixe uma resposta

Notice: Comments reflect the opionions of those who did wrote theme. Allowing people comment here, doenst mean, that we also agree with them.

Your email address won't be displayed. Required fields are marked with this sign: *

More information

Assine a petição!

 

158 signatures

Diga aos deputados: não censurem nossa Internet

Olá congressista!

O projeto de lei 5.204/16 propõe o bloqueio de acesso a sites "precipuamente dedicados ao crime" hospedados no exterior e sem representação no Brasil, excluindo, expressamente, a possibilidade de bloqueio de aplicativos de troca instantânea de mensagens (sim, o WhatsApp).

Em sua justificativa, anexa ao projeto, argumenta-se que hoje, para se retirar do ar sites criminosos - incluindo aqueles de ponografia infantil e de tráfico de drogas - tem que se expedir uma carta rogatória (documento que pede cumprimento de ordem judicial brasileira no exterior) para o servidor. Por ser demorada, não seria medida adequada de combate a esses crimes, devendo-se, então, bloquear o acesso de brasileiros a tais sites.

Contudo, há um grande problema nessa lógica de combate ao crime: sites que cometem crimes hediondos e torpes, como a pornografia infantil, NÃO estão na internet normal (surface web), e sim na internet não-indexada (deep web). O que isso quer dizer? Que não há como bloquear acesso a esses sites pelas medidas propostas pelo PL. E mesmo que essas trocas de material ilegal na internet esteja sendo feita em território brasileiro, a justiça já tem meios para combatê-las (a operação DarkWeb II da Polícia Federal,  de combate a pornografia infantil online, criminalizada no art. 241-A do Estatuto da Criança e Adolescente, estourou no dia 22/11/2016).

Ou seja, a título de combate a crimes graves, estão dando de um jeitinho de bloquear sites que desatendem aos interesses da indústria fonográfica, punindo a população ao dificultar acesso à informação, cultura e conhecimento.

Ainda que a primeira coisa que venha à mente nessas situações sejam os sites que disponibilizam filmes e séries inteiras para download ilegal, como o MegaFilmesHD e outros sites que já foram fechados, o PL não é nada claro com relação ao que seria considerado um provedor "precipuamente dedicado à pratica de crime", e as violações estabelecidas pela Lei de Direitos Autorais não se limitam ao compartilhamento ilegal de obras protegidas.

Na verdade, está bem longe disso.

A utilização derradeira de determinadas obras protegidas para produção de alguns tipos de obras derivadas –como remix de músicas, fotos para memes e vídeos que utilizam trechos de filmes para desenvolver críticas a eles (O Partido Pirata até já satirizou a #CPICIBER através de um vídeo) – não é permitida pela lei, consistindo em violação ao direito autoral, o que é abrangido pelo PL em questão. A utilização pode ter finalidade lucrativa ou não, o autor da obra derivada pode ser profissional ou amador - não importa, não pode! É possível que esse tipo de utilização bastasse para justificar o bloqueio de determinado provedor de aplicação.

Plataformas que viabilizam o compartilhamento desse tipo de conteúdo em massa e que poderiam eventualmente ser bloqueadas pelo PL são: o Vimeo (plataforma de vídeos); O YouTube (plataforma de vídeo); o SoundCloud (plataforma de músicas); o Flickr (plataforma de fotografia); o MemeGenerator (site que facilita a elaboração de memes) e até mesmo sites dedicados ao compartilhamento de FanFiction –outro tipo de manifestação cultural que é considerada ilegal pela Lei de Direitos Autorais. Nesse sentido, o bloqueio proposto pelo PL 5.204/16 é problemático sob quatro óticas distintas: para os provedores de aplicação, para os autores dos conteúdos, para os usuários e para o interesse público como um todo.

Para os provedores de aplicação, a medida é desproporcional, pois enseja no bloqueio de todos os seus serviços no país, independente de parte dele estar dentro da legalidade ou não. Por exemplo, o SoundCloud, caso bloqueado, o será por completo, apesar de servir também como plataforma para o compartilhamento de obras de forma legal. Já o YouTube poderá ser censurado por disponibilizar vídeos de paródias de músicas, trailers feito por usuários, etc.

Para os autores, o grande problema é a insegurança jurídica gerada pela medida. Como muitas das utilizações não são permitidas pela lei atual, não é possível saber até que ponto elas serão usadas para bloquear o acesso a suas obras. No mais, criadores de conteúdo que produzem obras completamente permitidas pela lei e disponibilizam-nas nessas plataformas serão penalizados por causa daqueles que compartilham obras de forma ilegal. Já para os usuários, a medida é problemática por prejudicar o livre acesso à internet e o acesso às demais obras (legais) hospedadas nessas plataformas –elementos essenciais do direito constitucional de acesso à cultura.

E, por último, para o interesse público, o PL é potencialmente ainda mais perigoso, já que o bloqueio a determinados serviços, com a justificativa de violação ao direito autoral, pode ser utilizado para cercear a liberdade de expressão. O exemplo dos vídeos que utilizam trechos de filmes para criticá-los é ilustrativo, mas grandes produtoras cinematográficas poderão solicitar o bloqueio de sites que hospedem esse tipo de vídeo com o argumento de que seus direitos autorais foram violados.

Este projeto de lei, portanto, se caracteriza como uma medida de combate direto à cultura de compartilhamento, já difundida na nossa geração. O objetivo explicitado no anexo fica em segundo plano, deixando margem para interpretá-lo apenas como um pretexto. Sendo assim, pode-se dizer que não é exagero especular que se trata de uma manobra movida pelo lobby da indústria audiovisual para esconder uma medida conhecidamente impopular.

Assine a petição, entre em contato com seu deputado: lute por uma Internet Livre e contra projetos de censura!

[signature]

Compartilhe com seus amigos:

Publicações