Apple et Google surveillent toutes vos notifications push. Mais Tuta vous protège de cela depuis 2017.

Permettre à chacun de quitter Gmail

Notre objectif avec Tuta est de permettre à tout le monde 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 complètement.

Ainsi, se débarrasser des services de notification push de Google était notre priorité absolue 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 l’énorme écosystème de suivi publicitaire de Google ainsi que de l’espionnage gouvernemental sans mandat.

De nouvelles preuves montrent aujourd’hui que ce changement préventif a constitué 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, prouvant 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 envoyé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 autorités chargées de l’application de la loi de relier les métadonnées déjà collectées aux comptes Google ou Apple.

Tuta était déjà conscient de ce risque potentiel il y a des années et, en 2017, nous avons entièrement 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 indiquer à Google que vous l’utilisez. En installant Tuta via F-Droid, vos notifications push ne sont pas non plus susceptibles de faire l’objet de cette forme de collecte de données et de surveillance.

Sur les appareils Apple, nous n’avons pas encore introduit notre propre service de notification push, mais cela est prévu pour une prochaine version. Actuellement, toutes les notifications push sur les appareils iOS n’affichent que des informations minimales, vous informant qu’un nouvel email est arrivé, afin de limiter les données qui pourraient être collectées par les tentatives de surveillance du gouvernement.

Comment nous avons remplacé GCM

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

Et, plus important encore : Pour pouvoir utiliser FCM, vous devez envoyer toutes vos données de notification à Google. 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 donné lieu à des plaintes de la part de nos utilisateurs). Par conséquent, la notification push de l’ancienne application mentionnait 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 font qu’il est plus difficile de ne pas utiliser leur service pour les notifications. Par ailleurs, l’abandon du service de notification de Google nous dispenserait d’exiger de nos utilisateurs qu’ils disposent de Google Play Services sur leur téléphone.

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 façon dont d’autres (Signal, Wire, Conversations, Riot, Facebook, 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 que cela semblait être 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 chronologie, 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 n’a pas semblé 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 keepalive. 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 pour 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 passer 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.

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 tous ces détails difficiles par lui-même ? 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