A Apple e o Google monitorizam todas as suas notificações push. Mas a Tuta protege-o disto desde 2017.

Permitir que todos abandonem o Gmail

O nosso objetivo com o Tuta é permitir que todos mudem 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 todos possam sair do Gmail completamente.

Assim, livrarmo-nos dos serviços de notificação push da Google foi a nossa principal prioridade quando reconstruímos a nossa aplicação de correio seguro a partir do zero. Estamos muito satisfeitos 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 do enorme ecossistema de seguimento de anúncios 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

A Reuters fez revelações surpreendentes 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 da 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 pela primeira vez trazida à atenção do público 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 os serviços secretos e as autoridades policiais associem os metadados já recolhidos às contas Google ou Apple.

O Tuta já estava ciente desse risco potencial há anos e, em 2017, substituímos totalmente os serviços de notificação do Google pelo nosso próprio serviço de notificação por push. Se estiver a usar o Tuta no Android, nenhum dado de notificação push é partilhado 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 a dica de que você o está usando. Ao instalar o Tuta através do F-Droid, as suas notificações push também não são susceptíveis a esta forma de recolha e vigilância de dados.

Nos dispositivos Apple, ainda não introduzimos o nosso próprio serviço de notificações push, mas isso está planeado para uma versão futura. Atualmente, todas as notificações push em dispositivos iOS apresentam apenas informações mínimas, informando-o de que chegou um novo e-mail, a fim de limitar os possíveis dados que poderiam ser recolhidos por tentativas de vigilância governamental.

Como substituímos o GCM

O GCM (ou, como se chama atualmente, FCM, Firebase Cloud Messaging) é um serviço propriedade da Google. Nós, na Tuta, usámos o FCM para a nossa antiga aplicação Android. Infelizmente, o FCM inclui o código de rastreio da Google para análise, que não queríamos ter na nossa aplicação segura.

E, ainda mais importante: Para poder utilizar o FCM, tem de enviar todos os seus dados de notificação para a Google. 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 por parte dos nossos utilizadores). Por conseguinte, a notificação push na aplicação antiga 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 fez alterações no Android que tornaram mais difícil não utilizar o seu serviço de notificações. Por outro lado, ao desistirmos do serviço de notificações da Google, deixávamos de exigir que os nossos utilizadores tivessem o Google Play Services nos seus telemóveis.

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
• ser rápido
• ser eficiente em termos energéticos

Fizemos uma pesquisa sobre como outros (Signal, Wire, Conversations, Riot, Facebook, 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árias aplicações de chat a tentar utilizar o WebSocket para notificações push e não nos pareceu eficiente em termos energéticos.

Já tínhamos alguma experiência com o WebSocket e sabíamos que as firewalls não gostam de ligações keepalive. 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 a partir do lado do servidor e aleatório para não sobrecarregar o servidor.

O suporte a várias contas apresenta 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 da 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 disso. 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.

Pensamento final: 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