Apple und Google überwachen alle Push-Benachrichtigungen, außer bei Tuta!

Jedem die Möglichkeit geben, Google vollständig zu verlassen

Unser Ziel mit Tuta ist es, jedem den Wechsel zu einem sicheren E-Mail-Dienst zu ermöglichen, der Ihre Daten und Ihr Recht auf Privatsphäre respektiert. Es ist für uns sehr wichtig, dass jeder Gmail vollständig verlassen kann.

Daher war es unsere oberste Priorität, die Push-Benachrichtigungsdienste von Google loszuwerden, als wir unsere sichere E-Mail-App im Jahr 2017 von Grund auf neu entwickelten. Wir sind sehr froh, dass es uns gelungen ist, Googles GCM für Push zu ersetzen, so dass die Tuta-App keinerlei Verbindung zu Google hat. Dies schützt Sie vor Googles massivem Tracking-Ökosystem sowie vor dem Schnüffeln durch die Regierung ohne richterlichen Beschluss.

Jetzt zeigen neue Beweise, dass diese präventive Umstellung ein wichtiger Schritt zum Schutz Ihrer Privatsphäre war. Tuta ist der einzige verschlüsselte E-Mail-Anbieter, der dieses Maß an Datenschutz bietet. Nicht einmal die sichere Alternative Protonmail geht so weit beim Schutz Ihrer Privatsphäre.

Apple und Google überwachen alle Ihre Push-Benachrichtigungen

Die Nachrichtenagentur Reuters hat am 7. Dezember 2023 verblüffende Enthüllungen gemacht, die belegen, dass Regierungen auf der ganzen Welt Apple- und Google-Nutzer ausspionieren, indem sie Push-Benachrichtigungen überwachen, die an ihre Geräte gesendet werden. Diese alternative Form der Überwachung wurde erstmals der Öffentlichkeit bekannt, nachdem ein offener Brief des US-Senators Ron Wyden an das US-Justizministerium veröffentlicht wurde.

Diese Benachrichtigungen ermöglichen es Geheimdiensten und Strafverfolgungsbehörden, bereits gesammelte Metadaten mit Google- oder Apple-Konten zu verknüpfen.

Tuta war sich dieses potenziellen Risikos bereits vor Jahren bewusst und hat 2017 die Benachrichtigungsdienste von Google vollständig durch unseren eigenen Push-Benachrichtigungsdienst ersetzt. Wenn Sie Tuta auf Android nutzen, werden keine Push-Benachrichtigungsdaten mit Google geteilt. Ihre Privatsphäre ist bei uns sicher.

Wir unterstützen auch die Installation der Tuta-App auf Android-Geräten über F-Droid, was es Ihnen ermöglicht, die Software zu nutzen, ohne dass Google davon erfährt. Aber egal, ob Sie Tuta über F-Droid oder Google Play installieren, Ihre Push-Benachrichtigungen können von Google nicht überwacht werden..

Für den maximalen Schutz der Privatsphäre zeigen alle Push-Benachrichtigungen auf iOS-Geräten nur minimale Informationen an, die Sie lediglich darüber informieren, dass eine neue E-Mail eingegangen ist. So begrenzen wir die möglichen Daten, die durch Apple sowie staatliche Überwachungsversuche gesammelt werden könnten. Wir planen auch bei Apple mehr Informationen in den Push-Benachrichtigungen anzuzeigen - diese werden dann aber sicher verschlüsselt sein, um sie vor dem Überwachen durch Apple zu schützen!

Wie wir GCM ersetzt haben

GCM (oder, wie es jetzt heißt, FCM, Firebase Cloud Messaging) ist ein Dienst im Besitz von Google. Wir bei Tuta haben FCM für unsere alte Android-App verwendet. Leider enthält FCM Googles Tracking-Code für Analysen, den wir nicht in unserer sicheren App haben wollten.

Und, was noch wichtiger ist: Um FCM nutzen zu können, müssen Sie alle Ihre Benachrichtigungsdaten an Google senden. Dies sollte ein absolutes No-Go für jeden sicheren E-Mail-Service sein! Außerdem hätten wir Googles proprietäre Bibliotheken verwenden müssen. Wegen der damit verbundenen Datenschutz- und Sicherheitsbedenken haben wir in der alten App keine Informationen mit den Benachrichtigungen mitgeschickt (was verständlicherweise zu Beschwerden unserer Nutzer geführt hat). Daher wurde in der Push-Benachrichtigung der alten Android-App nur erwähnt, dass Sie eine neue Nachricht erhalten haben, ohne Hinweis auf die E-Mail selbst oder auf das Postfach, in dem die Nachricht abgelegt wurde.

FCM ist recht bequem zu verwenden, und im Laufe der Jahre hat Google Änderungen an Android vorgenommen, die es schwieriger machten, ihren Dienst für Benachrichtigungen nicht zu verwenden. Andererseits würde der Verzicht auf den Benachrichtigungsdienst von Google uns davon befreien, dass unsere Nutzer Google Play Services auf ihren Telefonen haben müssen.

Die Herausforderung, Googles FCM zu ersetzen

Die Tuta-Apps sind Libre-Software, und wir wollen eine echte Open-Source-Alternative zu Gmail bieten, was für uns die Veröffentlichung unserer Android-App auf F-Droid einschließt. Wir wollten, dass unsere Nutzer Tuta auf jedem ROM und jedem Gerät nutzen können, ohne die Einmischung eines Drittanbieterdienstes wie Google.

Wir beschlossen, die Herausforderung anzunehmen und unseren eigenen Push-Benachrichtigungsdienst zu entwickeln.

Als wir mit der Entwicklung unseres Push-Systems begannen, hatten wir mehrere Ziele vor Augen:

• es muss sicher sein
• es muss schnell sein
• es muss energieeffizient sein

Wir haben recherchiert, wie andere (Signal, Wire, Conversations, Riot, Facebook, Mastodon) ähnliche Probleme gelöst haben. Wir hatten mehrere Optionen im Sinn, darunter WebSockets, MQTT, Server Sent Events und HTTP/2 Server Push.

Ersetzen von FCM durch SSE

Wir entschieden uns für SSE (Server Sent Events), weil es eine einfache Lösung zu sein schien. Damit meine ich "einfach zu implementieren, einfach zu debuggen". Die Fehlersuche bei dieser Art von Dingen kann viel Kopfzerbrechen bereiten, daher sollte man diesen Faktor nicht unterschätzen. Ein weiteres Argument, das für SSE sprach, war die relative Leistungseffizienz: Wir brauchten keine Upstream-Nachrichten und eine ständige Verbindung zum Server war nicht unser Ziel.

Was also ist SSE?

SSE ist eine Web-API, die es einem Server ermöglicht, Ereignisse an die angeschlossenen Clients zu senden. Es handelt sich um eine relativ alte API, die meiner Meinung nach zu wenig genutzt wird. Ich habe noch nie etwas von SSE gehört, bevor ich mir das föderierte Netzwerk Mastodon angeschaut habe: Sie verwenden SSE für Echtzeit-Aktualisierungen der Zeitleiste, und es funktioniert hervorragend.

Das Protokoll selbst ist sehr einfach und ähnelt dem guten alten Polling: Der Client öffnet eine Verbindung, und der Server hält sie offen. Der Unterschied zum klassischen Polling besteht darin, dass wir diese Verbindung für mehrere Ereignisse offen halten. Der Server kann Ereignisse und Datennachrichten senden; sie werden einfach durch neue Zeilen getrennt. Das Einzige, was der Client tun muss, ist also, eine Verbindung mit großem Timeout zu öffnen und den Stream in einer Schleife zu lesen.

SSE passt besser zu unseren Bedürfnissen als WebSocket (es ist billiger und konvergiert schneller, weil es nicht duplex ist). Wir haben mehrere Chat-Anwendungen gesehen, die versucht haben, WebSocket für Push-Benachrichtigungen zu verwenden, und es schien nicht energieeffizient zu sein.

Wir hatten bereits einige Erfahrung mit WebSocket und wussten, dass Firewalls keine Keepalive-Verbindungen mögen. Um dieses Problem zu lösen, haben wir für SSE denselben Workaround verwendet wie für WebSocket: Wir senden alle paar Minuten leere "Heartbeat"-Nachrichten. Dieses Intervall ist serverseitig einstellbar und zufällig gewählt, um den Server nicht zu überfordern.

Die Unterstützung mehrerer Konten bringt zusätzliche Herausforderungen mit sich

Es ist anzumerken, dass die Tuta-App mehrere Konten unterstützt, was für uns eine Herausforderung darstellte: Wir wollten nur eine Verbindung pro Gerät offen halten. Nach ein paar Iterationen haben wir ein Design gefunden, das uns zufrieden stellt. Jedes Gerät hat nur eine Kennung. Beim Öffnen der Verbindung sendet der Client die Liste der Benutzer, für die er Benachrichtigungen erhalten möchte. Der Server gleicht diese Liste mit den Benutzerdatensätzen ab und filtert ungültige aus.

Benutzer können ein Benachrichtigungstoken aus ihren Einstellungen löschen, was sich jedoch nicht auf andere Anmeldungen auf diesem Gerät auswirkt. Darüber hinaus mussten wir einen Mechanismus zur Verfolgung der Zustellung von Benachrichtigungen entwickeln. Leider mussten wir feststellen, dass unser Server nicht in der Lage ist, zu erkennen, wenn eine Verbindung unterbrochen wurde, so dass wir Bestätigungen von der Client-Seite aus senden mussten.

Um Benachrichtigungen zu erhalten, nutzen wir die Möglichkeiten von Android. Wir lassen einen Hintergrunddienst laufen, der die Verbindung zum Server offen hält, ähnlich wie es der FCM-Prozess tut. Eine weitere Schwierigkeit war der Doze-Modus, der mit Android M eingeführt wurde. Der Doze-Modus, der nach einer gewissen Zeit der Inaktivität eingeschaltet wird, verhindert unter anderem, dass Hintergrundprozesse auf das Netzwerk zugreifen können. Wie Sie sich vorstellen können, hindert dies unsere App daran, Benachrichtigungen zu erhalten.

Wir haben dieses Problem entschärft, indem wir die Benutzer gebeten haben, unsere App von den Akku-Optimierungen auszunehmen. Das hat recht gut funktioniert. Ein ähnliches Problem, das jedoch nichts mit Doze zu tun hat, sind herstellerspezifische Akku-Optimierungen. Um die Akkulaufzeit ihrer Geräte zu verlängern, aktivieren Telefonhersteller wie Xiaomi standardmäßig strenge Akku-Optimierungen. Glücklicherweise können Nutzer diese deaktivieren, aber wir müssen dies besser kommunizieren.

Ein weiteres Problem wurde durch die Änderungen von Android O verursacht. Eines davon ist die Einschränkung von Hintergrundprozessen: Wenn Ihre App für den Nutzer nicht sichtbar ist, werden Ihre Hintergrundprozesse gestoppt und Sie können keine neuen Prozesse starten.

Ursprünglich dachten wir, dass wir dieses Problem lösen können, indem wir eine dauerhafte Benachrichtigung mit minimaler Priorität anzeigen, die in der Benachrichtigungsrinne sichtbar ist, aber nicht in der Statusleiste. Das hat bei Oreo nicht funktioniert: Wenn Sie versuchen, einen Hintergrunddienst zu starten und die minimale Priorität für seine Benachrichtigung zu verwenden, wird die Benachrichtigungspriorität auf eine höhere Priorität hochgestuft (die die ganze Zeit sichtbar ist) und zusätzlich zeigt das System eine weitere dauerhafte Benachrichtigung an: "Anwendung X verbraucht Akku".

Ursprünglich hatten wir geplant, den Benutzern zu erklären, wie sie diese ständigen Benachrichtigungen ausblenden können, aber das war keine gute Benutzererfahrung, also mussten wir eine bessere Lösung finden. Wir haben den Android-Job-Mechanismus genutzt, um unseren Dienst regelmäßig (mindestens alle 15 Minuten) zu starten, und wir versuchen auch, ihn danach am Leben zu erhalten. Wir halten die WakeLocks nicht manuell - das System erledigt das für uns. Wir konnten die permanenten Benachrichtigungen ganz abschaffen. Auch wenn die Benachrichtigungen manchmal eine kleine Verzögerung haben, werden sie immer empfangen und die E-Mails sind sofort da.

Am Ende mussten wir etwas Arbeit investieren, aber das war es wert. Wir haben unsere Nutzer von der Anforderung der Google Play Services befreit. Endlich kann jeder die Tuta-App auf F-Droid bekommen. Das System kombiniert nun beides: gute Energieeffizienz und Geschwindigkeit.

Letzter Gedanke: Jeder Nutzer sollte einen "Notification Provider" für jede App wählen können

Wäre es nicht toll, wenn der Benutzer in den Telefoneinstellungen einfach einen "Push-Benachrichtigungsanbieter" auswählen könnte und das Betriebssystem all diese schwierigen Details selbst verwalten würde? So müsste nicht jede App, die nicht vom Plattformbetreiber überwacht werden möchte, das System neu erfinden? Es könnte Ende-zu-Ende zwischen der App und dem App-Server verschlüsselt werden. Das ist technisch nicht wirklich schwierig, aber solange unsere Systeme von großen Unternehmen kontrolliert werden, die das nicht zulassen, müssen wir das Problem selbst lösen.

Für ein freies und offenes Web müssen wir aufhören, all unsere privaten Daten an große Konzerne zu geben. Deshalb sagen wir: #NoMoreGoogle!