Push-Benachrichtigung

- Lesezeit: 8 Minuten -

Bei Push-Benachrichtigungen geht es generell darum, inaktiven Apps über einen Umweg mitzuteilen, daß sie sich bei Ihrem Server melden sollen um neue Nachrichten abzuholen. Hierfür werden spezielle Server sowie Verteiler-Apps („Distributoren“) benötigt, die diese Aufgabe übernehmen.

Grundsätzlich kann bei Android-Systemen in „Firebase Cloud Messaging“ (FCM) von Google und das davon unabhängige „Unified Push“ (UP) unterschieden werden, die beide dafür das selbe Protokoll nutzen.

Die Vorteile von Stromsparpotentialen durch Apps, die nicht permanent aktiv sein müssen gehen aber auch mit Nachteilen im Datenschutz und der Sicherheit einher. Mehr dazu >> hier <<.

Unified Push

Mit „Unified Push“ (UP) ist es somit möglich, Push-Funktionalität unabhängig von Google und ohne Google-Server zu realisieren. Dazu müssen Apps jedoch „UP“ explizit unterstützen. Beispiele für Mastodon dafür sind die Apps „Tusky“ und „Fedilab“. Letztere App ist darüber hinaus auch noch für Pleroma, Friendica und Pixelfed.

Man kann sich dann sowohl den push-Server als auch die Verteiler-App („Distributor“) frei aussuchen.

Ausgangssituation

… am Beispiel von Mastodon und Conversations:
Die Mastodon-App ist auf Android nicht immer aktiv. Man will aber sofort informiert werden, wenn Nachrichten eingehen (push) - auch wenn „im Hintergrund ausführen“ deaktiviert ist.

Voraussetzung

Die Mastodon-App registriert sich bei einer Verteiler-App („Distributor app“), die sowieso eine dauerhafte Verbindung ins Internet offen hält. Diese App muss immer aktiv sein und kann somit immer mit dem push-Server verbunden sein. Da das Standardprotokoll XMPP hierfür sehr gut geeignet ist, kann diese Informations-/Verteil-Funktion aktuell z.B. durch Conversations erfüllt werden.

Ablauf

  1. Bei Mastodon geht eine Nachricht ein
  2. Mastodon sendet eine Information darüber an den eingerichteten push-Server
  3. Der push-Server sendet eine Nachricht an Conversations
  4. Conversations gibt ein Aufwachsignal an Android bzw. die Mastodon-App
  5. Die Mastodon-App startet und ruft die Nachrichten dann bei Mastodon ab
„Erklärung

Quelle der (ergänzten) Grafik: unifiedpush.org

Expertenwissen

Es gibt Push-Verteiler die verschiedene Technologien verwenden. So gibt es „Websockets“, „HTTP“ oder „XMPP“. Allerdings ist XMPP überlegen, wenn Verbindungen lange gehalten werden sollen und in der Effizienz.

Conversations-FAQ

In den häufig gestellten Fragen (HGF/FAQ) zu Conversations finden sich verschiedene Informationen zur Push-Benachrichtigung:

Wie funktionieren XEP-0357: Wie funktionieren Push-Benachrichtigungen?

Sie müssen die Play Store-Version von Conversations verwenden und Ihr Server muss Push-Benachrichtigungen unterstützen.¹ Da Googles Firebase Cloud Messaging (FCM) mit einem API-Schlüssel an eine bestimmte App gebunden ist, kann Ihr Server die Push-Nachricht nicht direkt initiieren. Stattdessen sendet Ihr Server die Push-Benachrichtigung an den (von uns betriebenen) Conversations-App-Server, der dann als Proxy fungiert und die Push-Nachricht für Sie initiiert. Die Push-Nachricht, die von unserem App-Server über FCM gesendet wird, enthält keine persönlichen Informationen. Es handelt sich lediglich um eine leere Nachricht, die Ihr Gerät aufweckt und Conversations auffordert, sich erneut mit Ihrem Server zu verbinden. Die Informationen, die von Ihrem Server an unseren App-Server gesendet werden, hängen von der Konfiguration Ihres Servers ab, können aber auf Ihren Kontonamen beschränkt sein. (In jedem Fall wird der Conversations App-Server keine Informationen über FCM weiterleiten, selbst wenn Ihr Server diese Informationen sendet.) Zusammenfassend lässt sich sagen, dass Google niemals in den Besitz von persönlichen Informationen kommt, außer dass etwas passiert ist. (Was nicht einmal eine Nachricht sein muss, sondern auch ein automatisiertes Ereignis sein kann.) Wir - als Betreiber des App-Servers - erhalten lediglich Ihren Kontonamen (ohne diesen mit Ihrem spezifischen Gerät in Verbindung bringen zu können). Wenn Sie das nicht wollen, wählen Sie einfach einen Server, der keine Push-Benachrichtigungen anbietet, oder bauen Sie selbst Konversationen ohne Unterstützung für Push-Benachrichtigungen. (Dies ist über ein gradle build flavor möglich.) Nicht-Playstore-Quellen von Conversations wie der Amazon App Store bieten auch eine Version ohne Push-Benachrichtigungen an. Conversations wird wie bisher funktionieren und seine eigene TCP-Verbindung im Hintergrund aufrechterhalten.

Übersetzt aus Quelle: github.com/iNPUTmice/Conversations (extern)

Aber warum brauche ich eine permanente Benachrichtigung, wenn ich Google Push verwende?

FCM (Google Push) ermöglicht es einer App, aus dem Ruhezustand aufzuwachen. Dies ist (wie der Name schon sagt) eine Ruhezustandsfunktion des Android-Betriebssystems, die die Netzwerkverbindung unterbricht und auch die Anzahl der Male reduziert, die die App aufwachen darf (z. B. um den Server anzupingen). Die App kann beantragen, vom Ruhezustand ausgeschlossen zu werden. Nicht-Push-Varianten der App (von F-Droid oder wenn der Server dies nicht unterstützt) werden dies beim ersten Start tun. Wenn Sie also von Doze ausgenommen werden oder wenn Sie regelmäßig Push-Ereignisse erhalten, sollte Doze keine Gefahr für die ordnungsgemäße Funktion von Conversatons darstellen. Aber auch mit Doze ist die App immer noch im Hintergrund geöffnet (im Speicher gehalten); sie ist nur in den Aktionen eingeschränkt, die sie ausführen kann. Conversations muss im Speicher bleiben, um bestimmte Sitzungszustände zu halten (Online-Status von Kontakten, Beitrittsstatus von Gruppenchats, …). Mit Android 8 hat Google dies jedoch wieder geändert und nun muss eine App, die im Speicher bleiben will, einen Vordergrunddienst haben, der für den Benutzer über die lästige Benachrichtigung sichtbar ist. Aber warum muss Conversations diesen Status halten? XMPP ist ein zustandsbehaftetes Protokoll, das viele Informationen pro Sitzung enthält; Pakete müssen gezählt werden, Präsenzinformationen müssen festgehalten werden, einige Funktionen wie Message Carbons werden nur einmal pro Sitzung aktiviert, MAM Catch-up geschieht nur einmal, Service Discovery geschieht nur einmal; die Liste geht weiter. Als Conversations Anfang 2014 entwickelt wurde, war dies alles kein Problem, da die Anwendungen einfach im Speicher bleiben durften. Im Grunde hält jeder XMPP-Client diese Informationen im Speicher, weil es viel komplizierter wäre, sie auf der Festplatte zu speichern. Ein komplettes Neuschreiben von Conversations im Jahr 2019 würde versuchen, dies zu tun und wäre wahrscheinlich erfolgreich, aber es würde genau das erfordern; ein komplettes Neuschreiben, das im Moment nicht machbar ist. Das ist übrigens auch der Grund, warum es schwierig ist, einen XMPP-Client auf iOS zu schreiben. Oder allgemeiner ausgedrückt ist dies auch der Grund, warum andere Protokolle als zustandslose Protokolle (oft auf der Grundlage von HTTP) konzipiert oder zu diesen migriert wurden; nehmen Sie zum Beispiel die Migration von IMAP zu JMAP.

Übersetzt aus Quelle: github.com/iNPUTmice/Conversations (extern)

Conversations Push-Proxy

Aufgrund von Einschränkungen in Firebase Cloud Messaging (und den meisten anderen Push-Diensten) kann nur der Entwickler Push-Benachrichtigungen für seine Anwendungen erstellen. Aus diesem Grund kann der Server eines Benutzers das Gerät des Benutzers nicht direkt aufwecken, sondern muss das Aufwecksignal über die Infrastruktur des App-Entwicklers weiterleiten. Hier ist eine kurze Beschreibung, wie diese Beziehung aufgebaut ist.
Alle Beispiele unten verwenden reale Werte von meinem persönlichen Gerät mit einem Testkonto. Die Tatsache, dass ich mich damit wohlfühle, diese Daten öffentlich zugänglich zu machen, kann als Hinweis darauf dienen, wie wenig datenschutzsensibel diese Daten sind …

Übersetzt aus Quelle: github.com/iNPUTmice/Conversations (extern)