Permitir que todos abandonem completamente o Google

O nosso objetivo com o Tuta é permitir que todos possam mudar para um serviço de correio eletrónico seguro que respeite os seus dados e o seu direito à privacidade. É muito importante para nós que toda a gente possa sair do Gmail, também conhecido como “deGoogle”, completamente.

Assim, livrarmo-nos dos serviços de notificação push da Google foi a nossa principal prioridade ao reconstruir a nossa aplicação de correio seguro a partir do zero. Estamos muito felizes por termos conseguido substituir o GCM do Google para push, de modo a que a aplicação Tuta não tenha qualquer ligação ao Google. Isto protege-o da recolha massiva de dados da Google, bem como da espionagem governamental sem mandado.

Agora, novas provas mostram que esta mudança preventiva foi um passo importante na proteção da sua privacidade. O Tuta é o único fornecedor de correio eletrónico encriptado que oferece este nível de privacidade, nem mesmo a alternativa segura Protonmail está a dar este passo extra.

A Apple e a Google monitorizam todas as suas notificações push

Revelações surpreendentes foram feitas pela Reuters a 7 de dezembro de 2023, com provas de que os governos de todo o mundo estão a espiar os utilizadores da Apple e do Google através da monitorização das notificações push que são enviadas para os seus dispositivos. Esta forma alternativa de vigilância foi trazida à atenção do público pela primeira vez após a divulgação de uma carta aberta enviada pelo senador norte-americano Ron Wyden ao Departamento de Justiça dos EUA.

Estas notificações permitem que as agências de inteligência e de aplicação da lei associem metadados já recolhidos a contas Google ou Apple.

A equipa do Tuta já estava ciente desse risco potencial há anos e, em 2017, substituímos os serviços de notificação do Google pelo nosso próprio serviço de notificação por push. Se você estiver usando o Tuta no Android, nenhum dado de notificação push será compartilhado com o Google. A sua privacidade está segura connosco.

Também apoiamos a instalação do aplicativo Tuta em dispositivos Android por meio do F-Droid, que permite usar o software sem fornecer ao Google as informações que você está usando. Mas independentemente de instalar a aplicação Android através do F-Droid ou do Google Play, as suas notificações push estão seguras connosco e não são susceptíveis à recolha de dados e vigilância da Google.

Para uma proteção máxima da privacidade, no passado todas as notificações push em dispositivos iOS apenas apresentavam informações mínimas, informando-o apenas de que tinha sido recebido um novo e-mail. Desta forma, limitamos os potenciais dados que poderiam ser recolhidos pela Apple e pelas tentativas de vigilância do governo. Quando adicionámos uma pré-visualização de notificação para mostrar o remetente e a linha de assunto nas notificações, certificámo-nos de que esta informação é encriptada de forma segura para o proteger da vigilância da Apple! Agora, pode até utilizar acções rápidas em notificações a partir da aplicação Tuta, enquanto protegemos ao máximo a sua privacidade.

Como substituímos o GCM

GCM (ou, como é chamado agora, FCM, Firebase Cloud Messaging) é um serviço de propriedade do Google. Nós da Tuta costumávamos usar o FCM para nosso antigo aplicativo Android, até 2017. Infelizmente, o FCM inclui o código de rastreamento do Google para análise, que não queríamos ter em nosso aplicativo de e-mail seguro.

E, ainda mais importante: Para poder utilizar o FCM, tem de enviar todos os seus dados de notificação para a Google - o que deveria ser proibido em qualquer serviço de correio eletrónico seguro. Também tem de utilizar as suas bibliotecas proprietárias. Devido às preocupações de privacidade e segurança que naturalmente acompanham esta situação, não enviámos qualquer informação juntamente com as mensagens de notificação com a aplicação antiga (o que, compreensivelmente, levou a queixas dos nossos utilizadores). Por conseguinte, a notificação push na antiga aplicação para Android apenas mencionava que tinha recebido uma nova mensagem, sem qualquer referência ao próprio correio eletrónico ou à caixa de correio em que a mensagem tinha sido colocada.

Ao longo dos anos, a Google introduziu alterações no Android que tornaram mais difícil não utilizar o seu serviço de notificações. Por outro lado, desistir do serviço de notificações da Google libertava-nos de exigir que os nossos utilizadores tivessem o Google Play Services nos seus telemóveis. Por isso, foi exatamente isso que fizemos!

O desafio de substituir o FCM do Google

As aplicações Tuta são software Libre, e queremos fornecer uma verdadeira alternativa de código aberto ao Gmail, o que para nós inclui publicar a nossa aplicação Android no F-Droid. Queríamos que os nossos utilizadores pudessem usar o Tuta em qualquer ROM e em qualquer dispositivo, sem a interferência de um serviço de terceiros como o Google.

Decidimos aceitar o desafio e construir o nosso próprio serviço de notificações push.

Quando começámos a desenhar o nosso sistema push, tínhamos vários objectivos em mente:

• Deve ser seguro
• Tem de ser rápido
• Tem de ser eficiente em termos energéticos

Pesquisámos a forma como outras aplicações seguras e privadas (Signal, Wire, Conversations, Riot, Mastodon) têm resolvido problemas semelhantes. Tínhamos várias opções em mente, incluindo WebSockets, MQTT, Server Sent Events e HTTP/2 Server Push.

Substituição do FCM pelo SSE

Escolhemos o SSE (Server Sent Events) porque parecia ser uma solução simples. Com isso quero dizer “fácil de implementar, fácil de depurar”. A depuração deste tipo de coisas pode ser uma grande dor de cabeça, pelo que não se deve subestimar este fator. Outro argumento a favor da SSE foi a relativa eficiência energética: Não precisávamos de mensagens upstream e uma ligação constante ao servidor não era o nosso objetivo.

Então, o que é o SSE?

SSE é uma API web que permite a um servidor enviar eventos para os clientes ligados. É uma API relativamente antiga que, na minha opinião, é subutilizada. Eu nunca tinha ouvido falar de SSE antes de olhar para a rede federada Mastodon: Eles usam SSE para actualizações em tempo real da linha de tempo e está a funcionar muito bem.

O protocolo em si é muito simples e assemelha-se ao bom e velho polling: O cliente abre uma conexão e o servidor a mantém aberta. A diferença em relação à sondagem clássica é que mantemos esta ligação aberta para múltiplos eventos. O servidor pode enviar eventos e mensagens de dados; eles são apenas separados por novas linhas. Assim, a única coisa que o cliente precisa de fazer é abrir uma ligação com um grande timeout e ler o fluxo num ciclo.

O SSE atende melhor às nossas necessidades do que o WebSocket (é mais barato e converge mais rápido, porque não é duplex). Vimos vários aplicativos de bate-papo tentando usar o WebSocket para notificações push, e ele não parecia eficiente em termos de energia.

Já tínhamos alguma experiência com o WebSocket e sabíamos que os firewalls não gostam de conexões keep-alive. Para resolver isso, usamos a mesma solução alternativa para o SSE que usamos para o WebSocket: Enviamos mensagens vazias de “heartbeat” a cada poucos minutos. Tornámos este intervalo ajustável do lado do servidor e aleatório para não sobrecarregar o servidor.

O suporte a várias contas coloca desafios adicionais

É de notar que a aplicação Tuta tem suporte para várias contas, o que constituiu um desafio para nós: Queríamos manter apenas uma ligação aberta por dispositivo. Após algumas iterações, encontrámos o design que nos satisfazia. Cada dispositivo tem apenas um identificador. Ao abrir a ligação, o cliente envia a lista de utilizadores para os quais pretende receber notificações. O servidor valida esta lista com os registos dos utilizadores e filtra os inválidos.

Os utilizadores podem eliminar um token de notificação das suas definições, mas isso não afectará outros inícios de sessão nesse dispositivo. Além disso, tivemos de criar um mecanismo de controlo de entrega quando uma notificação é recebida. Infelizmente, descobrimos que o nosso servidor não consegue detetar quando uma ligação é interrompida, pelo que tivemos de enviar confirmações do lado do cliente.

Para receber notificações, tiramos partido das capacidades do Android. Executamos um serviço em segundo plano que mantém a ligação ao servidor aberta, à semelhança do que faz o processo FCM. Outra dificuldade foi causada pelo modo Doze, introduzido no Android M. O Doze, que é ativado após um período de inatividade, impede, entre outras coisas, que os processos em segundo plano acedam à rede. Como pode imaginar, isto impede a nossa aplicação de receber notificações.

Atenuámos este problema pedindo aos utilizadores que isentassem a nossa aplicação das optimizações da bateria. Funcionou bastante bem. Um problema semelhante, mas não relacionado com o Doze, são as optimizações de bateria específicas do fornecedor. Para prolongar a vida útil da bateria dos seus dispositivos, os fabricantes de telemóveis, como a Xiaomi, activam, por defeito, optimizações rigorosas da bateria. Felizmente, os utilizadores podem desactivá-las, mas temos de comunicar isto melhor.

Outro problema foi causado pelas alterações do Android O. Uma delas é a restrição de processos em segundo plano: A menos que a aplicação esteja visível para o utilizador, os processos em segundo plano serão interrompidos e não será possível iniciar novos processos.

Inicialmente, pensámos que podíamos resolver isto mostrando uma notificação persistente com prioridade mínima, que é visível na calha de notificação, mas não na barra de estado. Isto não funcionou no Oreo: Se tentar iniciar um serviço em segundo plano e usar a prioridade mínima para a sua notificação, a prioridade da notificação é actualizada para uma prioridade mais elevada (visível o tempo todo) e, além disso, o sistema mostra outra notificação persistente: “A aplicação X está a consumir bateria”.

Inicialmente, planeámos explicar aos utilizadores como podem ocultar estas notificações persistentes, mas essa não era uma boa experiência para o utilizador, pelo que tivemos de encontrar uma solução melhor. Aproveitámos o mecanismo de Job do Android para lançar o nosso serviço periodicamente (pelo menos a cada 15 minutos), e também tentamos mantê-lo vivo depois. Não mantemos WakeLocks manualmente - o sistema faz isso por nós. Conseguimos eliminar completamente as notificações persistentes. Mesmo que, por vezes, as notificações tenham um pequeno atraso, serão sempre recebidas e as mensagens de correio eletrónico chegam instantaneamente.

No final, tivemos de fazer algum trabalho, mas valeu totalmente a pena. Libertámos os nossos utilizadores do requisito do Google Play Services. Finalmente, todos podem obter a aplicação Tuta no F-Droid. O sistema agora combina ambos: boa eficiência energética e velocidade.

O novo aplicativo Tuta Calendar também pode ser encontrado no F-Droid, nossa loja de aplicativos favorita.

Considerações finais: Cada utilizador deve poder escolher um “Fornecedor de notificações” para cada aplicação

Não seria ótimo se o utilizador pudesse escolher um “fornecedor de notificações push” nas definições do telefone e o sistema operativo gerisse sozinho todos estes detalhes difíceis? Assim, cada aplicação, que não quer ser policiada pelo proprietário da plataforma, não teria de inventar o sistema de novo? Poderia ser encriptado de ponta a ponta entre a aplicação e o servidor de aplicações. Não há nenhuma dificuldade técnica real nisso, mas enquanto os nossos sistemas forem controlados por grandes actores que não o permitem, temos de o resolver por nós próprios.

Para termos uma Web livre e aberta, temos de deixar de entregar todos os nossos dados privados às grandes empresas. É por isso que estamos a dizer: #NoMoreGoogle.