Permettre à chacun de quitter complètement Google

Notre objectif avec Tuta est de permettre à chacun de passer à un service de messagerie sécurisé qui respecte vos données et votre droit à la vie privée. Il est très important pour nous que tout le monde puisse quitter Gmail, également connu sous le nom de “déGoogle”, complètement.

C’est pourquoi notre priorité absolue a été de nous débarrasser des services de notification push de Google lorsque nous avons reconstruit notre application de messagerie sécurisée à partir de zéro. Nous sommes très heureux d’avoir réussi à remplacer le GCM de Google pour les notifications push, de sorte que l’application Tuta n’a aucune connexion avec Google. Cela vous protège de la collecte massive de données de Google ainsi que de l’espionnage gouvernemental sans mandat.

De nouvelles preuves montrent aujourd’hui que ce changement préventif constituait une étape importante dans la protection de votre vie privée. Tuta est le seul fournisseur de messagerie cryptée à offrir ce niveau de confidentialité, même l’alternative sécurisée Protonmail ne prend pas cette mesure supplémentaire.

Apple et Google surveillent toutes vos notifications push

Des révélations surprenantes ont été faites par Reuters le 7 décembre 2023, avec des preuves que les gouvernements du monde entier espionnent les utilisateurs d’Apple et de Google en surveillant les notifications push qui sont envoyées à leurs appareils. Cette autre forme de surveillance a été portée à l’attention du public après la publication d’une lettre ouverte adressée par le sénateur américain Ron Wyden au ministère américain de la justice.

Ces notifications permettent aux services de renseignement et aux forces de l’ordre de relier les métadonnées déjà collectées aux comptes Google ou Apple.

L’équipe Tuta était déjà consciente de ce risque potentiel il y a des années et, en 2017, nous avons remplacé les services de notification de Google par notre propre service de notification push. Si vous utilisez Tuta sur Android, aucune donnée de notification push n’est partagée avec Google. Votre vie privée est en sécurité avec nous.

Nous prenons également en charge l’installation de l’application Tuta sur les appareils Android via F-Droid, ce qui vous permet d’utiliser le logiciel sans fournir à Google l’information que vous l’utilisez. Mais que vous installiez l’application Android via F-Droid ou Google Play, vos notifications push sont en sécurité chez nous et ne sont pas susceptibles d’être collectées et surveillées par Google.

Pour une protection maximale de la vie privée, toutes les notifications push sur les appareils iOS n’affichaient jusqu’à présent que des informations minimales, vous informant simplement de la réception d’un nouvel e-mail. Nous limitons ainsi les données susceptibles d’être collectées par Apple et les tentatives de surveillance des gouvernements. Lorsque nous avons ajouté un aperçu de notification pour afficher l’expéditeur et l’objet dans les notifications, nous nous sommes assurés que ces informations sont cryptées de manière sécurisée pour vous protéger de la surveillance d’Apple ! Désormais, vous pouvez même utiliser des actions rapides sur les notifications depuis l’application Tuta, tout en protégeant au maximum votre vie privée.

Comment nous avons remplacé GCM

GCM (ou, comme on l’appelle maintenant, FCM, Firebase Cloud Messaging) est un service appartenant à Google. Chez Tuta, nous utilisions FCM pour notre ancienne application Android, jusqu’en 2017. Malheureusement, FCM inclut le code de suivi de Google pour l’analyse, que nous ne voulions pas avoir dans notre application de messagerie sécurisée.

Et, plus important encore : Pour pouvoir utiliser FCM, vous devez envoyer toutes vos données de notification à Google - ce qui devrait être interdit pour tout service de messagerie sécurisée. Vous devez également utiliser leurs bibliothèques propriétaires. En raison des problèmes de confidentialité et de sécurité qui en découlent, nous n’avons pas envoyé d’informations avec les messages de notification dans l’ancienne application (ce qui, naturellement, a suscité des plaintes de la part de nos utilisateurs). Par conséquent, la notification push de l’ancienne application Android indiquait seulement que vous aviez reçu un nouveau message, sans aucune référence à l’e-mail lui-même ou à la boîte aux lettres dans laquelle le message avait été placé.

FCM est très pratique à utiliser, mais au fil des ans, Google a apporté des modifications à Android qui ont rendu plus difficile le fait de ne pas utiliser leur service pour les notifications. D’un autre côté, l’abandon du service de notification de Google nous permettrait de ne pas exiger de nos utilisateurs qu’ils aient Google Play Services sur leur téléphone. C’est donc exactement ce que nous avons fait !

Le défi de remplacer le FCM de Google

Les applications Tuta sont des logiciels libres, et nous voulons fournir une véritable alternative open source à Gmail, ce qui pour nous inclut la publication de notre application Android sur F-Droid. Nous voulions que nos utilisateurs puissent utiliser Tuta sur toutes les ROM et tous les appareils, sans l’interférence d’un service tiers comme Google.

Nous avons décidé de relever le défi et de créer notre propre service de notification push.

Lorsque nous avons commencé à concevoir notre système de notification push, nous avions plusieurs objectifs en tête :

• Il doit être sécurisé
• Il doit être rapide
• Il doit être économe en énergie

Nous avons fait des recherches sur la manière dont d’autres applications sécurisées et privées (Signal, Wire, Conversations, Riot, Mastodon) ont résolu des problèmes similaires. Nous avions plusieurs options en tête, notamment WebSockets, MQTT, Server Sent Events et HTTP/2 Server Push.

Remplacer FCM par SSE

Nous avons opté pour SSE (Server Sent Events) parce qu’il semblait s’agir d’une solution simple. J’entends par là “facile à mettre en œuvre, facile à déboguer”. Le débogage de ce type de choses peut être un véritable casse-tête, il ne faut donc pas sous-estimer ce facteur. Un autre argument en faveur du SSE était l’efficacité énergétique relative : Nous n’avions pas besoin de messages en amont et une connexion constante au serveur n’était pas notre objectif.

Qu’est-ce que l’ESS ?

L’ESS est une API web qui permet à un serveur d’envoyer des événements aux clients connectés. Il s’agit d’une API relativement ancienne qui est, à mon avis, sous-utilisée. Je n’avais jamais entendu parler de l’ESS avant d’étudier le réseau fédéré Mastodon: Ils utilisent SSE pour les mises à jour en temps réel de la ligne de temps, et cela fonctionne très bien.

Le protocole lui-même est très simple et ressemble au bon vieux polling : Le client ouvre une connexion et le serveur la maintient ouverte. La différence avec le polling classique est que nous gardons cette connexion ouverte pour plusieurs événements. Le serveur peut envoyer des événements et des messages de données ; ils sont simplement séparés par de nouvelles lignes. La seule chose que le client doit faire est donc d’ouvrir une connexion avec un délai d’attente important et de lire le flux en boucle.

SSE répond mieux à nos besoins que WebSocket (il est moins cher et converge plus rapidement, car il n’est pas duplex). Nous avons vu plusieurs applications de chat essayer d’utiliser WebSocket pour les notifications push, et cela ne semblait pas efficace en termes de consommation d’énergie.

Nous avions déjà une certaine expérience de WebSocket, et nous savions que les pare-feu n’aiment pas les connexions keep-alive. Pour résoudre ce problème, nous avons utilisé la même solution pour SSE que pour WebSocket : Nous envoyons des messages vides “heartbeat” toutes les quelques minutes. Cet intervalle est réglable du côté du serveur et aléatoire afin de ne pas le surcharger.

La prise en charge de comptes multiples pose des problèmes supplémentaires

Il convient de noter que l’application Tuta prend en charge plusieurs comptes, ce qui nous a posé un problème : Nous voulions qu’il n’y ait qu’une seule connexion ouverte par appareil. Après quelques itérations, nous avons trouvé une solution qui nous satisfait. Chaque appareil n’a qu’un seul identifiant. Lors de l’ouverture de la connexion, le client envoie la liste des utilisateurs pour lesquels il souhaite recevoir des notifications. Le serveur valide cette liste par rapport aux enregistrements des utilisateurs et filtre ceux qui ne sont pas valides.

Les utilisateurs peuvent supprimer un jeton de notification de leurs paramètres, mais cela n’affectera pas les autres connexions sur cet appareil. En outre, nous avons dû mettre en place un mécanisme de suivi de la livraison lorsqu’une notification est reçue. Malheureusement, nous avons découvert que notre serveur n’est pas en mesure de détecter la rupture d’une connexion et nous avons donc dû envoyer des confirmations du côté client.

Pour recevoir des notifications, nous nous appuyons sur les capacités d’Android. Nous exécutons un service en arrière-plan qui maintient la connexion au serveur ouverte, comme le fait le processus FCM. Une autre difficulté a été causée par le mode Doze, introduit dans Android M. Le mode Doze, qui est activé après une période d’inactivité, empêche notamment les processus d’arrière-plan d’accéder au réseau. Comme vous pouvez l’imaginer, cela empêche notre application de recevoir des notifications.

Nous atténuons ce problème en demandant aux utilisateurs de faire une dérogation aux optimisations de la batterie pour notre app. Cela a assez bien fonctionné. Un problème similaire, mais sans rapport avec Doze, est celui des optimisations de la batterie spécifiques à un fournisseur. Afin de prolonger la durée de vie de la batterie de leurs appareils, les fabricants de téléphones, comme Xiaomi, activent par défaut des optimisations strictes de la batterie. Heureusement, les utilisateurs peuvent les désactiver, mais nous devons mieux communiquer à ce sujet.

Un autre problème a été causé par les changements d’Android O. L’un d’entre eux est la restriction des processus en arrière-plan : À moins que votre application ne soit visible par l’utilisateur, vos processus d’arrière-plan vont être arrêtés, et vous ne pourrez pas en lancer de nouveaux.

Initialement, nous pensions pouvoir résoudre ce problème en affichant une notification persistante avec une priorité minimale, qui est visible dans la gouttière de notification, mais pas dans la barre d’état. Cela n’a pas fonctionné pour Oreo : Si vous essayez de lancer un service en arrière-plan et d’utiliser la priorité minimale pour sa notification, la priorité de la notification passe à une priorité plus élevée (visible en permanence) et, en plus, le système affiche une autre notification persistante : “L’application X consomme de la batterie”.

Nous avions initialement prévu d’expliquer aux utilisateurs comment masquer ces notifications persistantes, mais cela n’était pas très agréable pour l’utilisateur, et nous avons donc dû trouver une meilleure solution. Nous nous sommes appuyés sur le mécanisme Android Job pour lancer notre service périodiquement (au moins toutes les 15 minutes), et nous essayons également de le maintenir en vie par la suite. Nous ne maintenons pas les WakeLocks manuellement - le système le fait pour nous. Nous avons pu nous débarrasser complètement des notifications persistantes. Même si les notifications ont parfois un léger retard, elles sont toujours reçues et les courriels sont là instantanément.

En fin de compte, nous avons dû faire un peu de travail, mais cela en valait vraiment la peine. Nous avons libéré nos utilisateurs de l’obligation d’utiliser Google Play Services. Enfin, tout le monde peut obtenir l’application Tuta sur F-Droid. Le système combine maintenant les deux : une bonne efficacité énergétique et la vitesse.

La nouvelle application Calendrier Tuta est également disponible sur F-Droid, notre boutique d’applications préférée.

Dernière réflexion : Chaque utilisateur devrait pouvoir choisir un “fournisseur de notifications” pour chaque application.

Ne serait-ce pas génial si l’utilisateur pouvait simplement choisir un “fournisseur de notifications push” dans les paramètres du téléphone et si le système d’exploitation gérait lui-même tous ces détails difficiles ? Ainsi, chaque application qui ne veut pas être contrôlée par le propriétaire de la plateforme n’aurait pas à inventer le système à nouveau ? Il pourrait être crypté de bout en bout entre l’application et le serveur d’application. Il n’y a pas de réelle difficulté technique à cela, mais tant que nos systèmes sont contrôlés par de grands acteurs qui ne le permettent pas, nous devons résoudre le problème par nous-mêmes.

Pour un web libre et ouvert, nous devons cesser de donner toutes nos données privées aux grandes entreprises. C’est pourquoi nous disons : #NoMoreGoogle.