O Signal conseguiu ganhar um grande número de usuários ativos após o tweet de Elon Musk e várias outras recomendações de personalidades importantes que também incluem Edward Snowden, que geralmente recomenda o uso do Signal.
Sem dúvida, o Signal é uma das alternativas de WhatsApp mais privadas disponíveis lá fora.
No entanto, alguns eventos recentes que envolveram alguns pesquisadores de segurança da comunidade anticensura relatando uma falha crítica na técnica de evasão da censura da Signal para o Irã me levaram a pensar como o Signal, como empresa, responde e se apresenta à comunidade de código aberto em geral.
Eles estão fazendo algo errado? Eles devem trabalhar para melhorar sua comunicação com a comunidade? O que exatamente está acontecendo?
Neste artigo, tentarei compartilhar minha opinião (limitada ao meu ponto de vista e pesquisa) sobre como o Signal abordou a questão e como eu acho que eles deveriam ter feito.
Observação: Claro, entendo que eles têm uma equipe pequena e não são obrigados a responder a tudo, considerando seu brilhante trabalho no aplicativo. Eu tentei entrar em contato com eles no passado para criar conteúdo que pudesse ter ajudado nossos leitores a saber mais sobre o Signal enquanto era um usuário desde 2014 e não obtive uma resposta. Então, isso não é surpresa para mim.
Observação adicional: *Esta é totalmente minha opinião e foi levantada como uma preocupação para obter uma resposta oficial adequada da equipe do Signal.
Aqui está o que aconteceu: a situação
Tomando um thread do GitHub por database64128 como referência, aqui estão algumas coisas que você deve saber para começar:
- Signal anunciou a implementação de um proxy TLS simples para que os usuários no Irã possam se reconectar ao Signal contornando a censura.
- Um pesquisador, DuckSoft, notou imediatamente uma falha com o proxy simples (o que basicamente significava que o proxy pode ser detectado e bloqueado - o que poderia expor os usuários a censores) e relatou problemas via GitHub no repositório do Signal
- Outro pesquisador studentmain escreveu e testou um PoC (Proof of Concept) que foi postado posteriormente no mesmo tópico.
- O problema do GitHub foi supostamente encerrado por Moxie (co-fundador da Signal), mencionando que eles não discutem tais questões aqui no GitHub e sugeriu que postassem a discussão no fórum da comunidade do Signal .
- Frustrados com a resposta, os pesquisadores tentaram furiosamente repassar o problema e enviar uma solicitação de pull para adicionar o PoC ao repositório de proxy TLS do Signal.
- O thread original do GitHub foi excluído e os pesquisadores foram supostamente banidos do repositório GitHub do Signal.
- Uma preocupação de segurança para consultas de DNS com vazamento de aplicativo Signal também foi postada no Fórum da comunidade Signal.
Agora, você pode encontrar o problema publicado novamente em uma página separada do GitHub pela DuckSoft, que também está sendo confirmada e apoiada por vários outros pesquisadores no tópico.
No entanto, Moxie acredita que não é tecnicamente uma falha, mas sim como a técnica é projetada:
Sim, um proxy sempre será detectável como um proxy, pelo menos quando alguém descobrir o link do proxy - o que é inevitável quando milhões de pessoas o usam. Felizmente, não é segredo!
- Moxie Marlinspike (@moxie) 8 de fevereiro de 2021
Aqui está o que eu penso sobre isso
Sim, eu percebi que os pesquisadores que relataram a falha de usar essa técnica de proxy eram tóxicos em algum momento que o problema inicial do GitHub foi fechado, deixando-os frustrados.
Qualquer tipo de toxicidade não deve ser tolerado e isso é certo.
Mas, não vejo um motivo para excluir o problema do GitHub que foi relatado originalmente. Moxie menciona em alguns de seus tweets que fechou o problema para manter a seção de problemas do GitHub limpa porque esse não é o lugar para discussão e a discussão começou uma montanha-russa de PRs falsos e jargões em geral:
Desligamos os problemas quase imediatamente, porque estava começando a atrair muitos pedidos de suporte técnico genérico e tópicos de discussão. Não achamos os problemas do GH úteis para isso, então postamos uma nota redirecionando as pessoas nos problemas e os desativamos. Não estava "mirando" em ninguém.
- Moxie Marlinspike (@moxie) 8 de fevereiro de 2021
No entanto, desabilitar a seção “Issues” completamente ou possivelmente excluir todo o tópico não é um bom sinal para mim.
Além disso, considerando que expor os usuários à censura pode ser perigoso no futuro (mesmo com uma chance de 0,01%), redirecionar uma preocupação séria de um tópico de problema do GitHub para o tópico da comunidade do Signal? Sério?
Especialmente, quando alguém se esforça para preparar uma PoC junto com possíveis soluções para ajudar a Signal a implementar uma técnica de contenção de censura melhor?
O thread da comunidade é destinado a discussões de usuários ou solicitações de recursos, não para discutir questões imediatas de segurança. Não esqueça, esse não é um lugar para obter uma resposta oficial.
Como meu colega, Avimanyu Bandyopadhyay menciona a filosofia de código aberto, que foi fundada com humildade, amor e compaixão.
Honestamente, não vejo isso nesta situação. A situação poderia ter sido tratada melhor e provavelmente Moxie também sabe disso.
Até conversei com um profissional de segurança cibernética (Roshan Raj Mishra) que acredita que, mesmo se considerarmos que a falha de segurança não foi relatada educadamente, não reconhecer uma falha relatada com uma PoC torna o comportamento do Signal anti-profissional. Então, é isso.
Além disso, não vejo alguém levantando uma preocupação nos problemas do GitHub como um problema? Isso poderia ter sido discutido lá como uma exceção. Há uma primeira vez para tudo.
Qual é o ponto de manter os problemas do GitHub completamente limpos sem discutir ou encerrar a preocupação de maneira adequada?
Citando o tópico de referência da comunidade Anti-Censura, eles exigem:
Instamos a Signal a emitir uma declaração que informe seus usuários sobre os riscos potenciais causados pelas falhas de sua implementação de proxy. A Signal deve parar de aconselhar as pessoas no Irã a usar sua solução frágil e temporária. Em vez disso, o povo iraniano deve buscar outras soluções bem estabelecidas, como as de nossa comunidade.
Reflexões finais
Claro, alguém poderia argumentar que a Signal mencionou a implementação do proxy como uma “solução provisória “.
Mas, mesmo assim, por que eles não podem abordar adequadamente uma preocupação dos pesquisadores de segurança? Um tweet oficial sobre a preocupação? Uma postagem no blog para esclarecer (com uma isenção de responsabilidade) que a implementação do proxy não é a melhor solução e é potencialmente arriscada para o futuro ou um sistema de censura mais difícil?
Especialmente, quando não é apenas um único cara ficando paranóico sobre algo, mas muitos pesquisadores da comunidade anticensura.
Sem descartar o fato de que outro pesquisador de segurança Sergey Frolovalso relatou algumas preocupações com o aplicativo da Signal no passado, mas também não recebeu nenhuma resposta. Isso não me parece excelente.
Como dizemos, nada nunca é perfeito neste mundo. Então, certamente pode haver algo errado com a Signal como uma empresa de código aberto também? Talvez eles precisem trabalhar em uma comunicação rápida e transparente?
Profissionalmente, acho que eles deveriam definitivamente trabalhar em apresentar, abordar ou responder às preocupações levantadas pela comunidade de forma eficiente. Não importa o quão pequena seja a equipe, considerando a crescente base de usuários do Signal (por todas as razões certas, e é por isso que eu também o uso), responder às preocupações da comunidade deve ser uma prioridade agora.
A comunidade FOSS merece discutir isso de uma maneira civilizada, em vez de apenas descartar os problemas de forma não profissional, sou apenas eu e não falo por todos.
Mas, o que você acha disso? Deixe-me saber o que você pensa sobre isso.
Via itsfoss.com. Você pode conferir o post original em inglês:
Signal Needs to do Better For its Response to the Anti-Censorship Community
Última atualização deste artigo: 17 de february de 2021
