Im Web werden wir getrackt – das sind wir uns gewohnt. Weniger bekannt ist, dass auch Apps jede Regung von uns Nutzerinnen und Nutzern aufzeichnen, auswerten, speichern und – vermutlich – auch in personalisierter oder anonymisierter Form weiterverkaufen: App Tracking: Es ist noch viel, viel schlimmer, war mein Fazit, nachdem ich mir Exodus angeschaut hatte: Das ist eine Website, die aufzeigt, welche Tracker in welcher App enthalten sind. Die Erkenntnis damals: Es gibt kaum eine App, die nicht trackt. Und manche Apps haben Dutzende solcher Komponenten von verschiedenen Datensammlern eingebaut.
Nun hat mich @kiki auf Mastodon auf ein spannendes Projekt in diesem Zusammenhang hingewiesen: Warden ist eine Erweiterung der Exodus-Datenbank. Es handelt sich um eine App, die unter Android die installierten Apps auf Tracker und Logger hin untersucht. Sie zeigt an, welche Module vorhanden sind und welche Berechtigungen eine App anfordert. Und es gibt die Möglichkeit, die Apps zu «debloaten» und zu «nuken». Dazu gleich mehr.
Installation am Play-Store vorbei
Die Warden-App findet sich auf Gitlab.com, und zwar im Quellcode und als APK, d.h. als ausführbare Android-App. Denn – wen wundert es? – diese App geht nicht mit den Anforderungen konform, die Google an die Apps hat, die in den Play Store dürfen.
Die Installation des APK ist trotzdem einfach: Man lädt die Datei herunter und betätigt (z.B. in Firefox) den Öffnen-Befehl. Daraufhin erhält man den Bescheid, dass dieser Dateitypus nicht geöffnet werden könne. Man darf jedoch die Berechtigung dazu erteilen.
Randbemerkung: Das Sideloading, d.h. die direkte Installation von Apps ohne den Store, ist auch über die Einstellungen zugänglich. Bei meinem Nokia-Telefon tut man das über die Option Installieren unbekannter Apps, die sich in Apps & Benachrichtigungen unter Erweitert bei Spezieller App-Zugriff findet.
Es ist sinnvoll, diese Option standardmässig abgeschaltet zu lassen und nur bei Bedarf temporär zu aktivieren.
Eine aufschlussreiche App-Analyse
Nun ist die App einsatzbereit. In der Rubrik Scanner startet man den Suchvorgang, bei dem alle Apps auf ihre Tracker hin analysiert werden. Sobald der Vorgang abgeschlossen ist, tippt man auf View Report:
In einer Übersicht wird aufgeführt, wie viele Apps untersucht worden sind und welche Tracker dabei gefunden wurden. In einer Grafik werden die wichtigsten Tracker angezeigt.
Wie schon seinerzeit erkannt, ist Google Firebase omnipräsent und fast in jeder App vorhanden. Wenn man in der Grafik das grüne Ring-Segement antippt, das für Firebase steht, sieht man alle Apps, die dieses Modul verwenden. Viele davon überraschen nicht, denn wer hätte ernsthaft damit gerechnet, dass Tiktok oder Onedrive keine Tracker enthalten?
Auch du, Firefox?
Bei anderen Apps wundert man sich hingegen schon: Warum baut Mozilla einen solchen Tracker in seinen Firefox-Browser ein, wo die Stiftung sonst bei jeder Gelegenheit mit dem Datenschutz wirbt? Warum steckt Firebase in der Nextcloud-App – wo diese App doch von Leuten verwendet wird, die einigen Aufwand betreiben, damit ihre Daten nicht in einer öffentlichen Cloud landen, sondern in einer eigenen, selbst betriebenen Online-Ablage?
Tippt man eine App an, sieht man eine Übersicht der Tracker und Logger, die die App verwendet, ebenso die Berechtigungen. Warden erlaubt es nun, die nach Activities, Providers, Services, Receivers und Permission gruppierten Module anzutippen und einzusehen. Und nicht nur das: Es ist auch möglich, Module abzuknipsen.
Fürs Löschen der Tracker ist Root-Zugriff nötig
Für letzteres ist es allerdings notwendig, die App mit Root-Zugriff zu starten: Nur so hat sie die Möglichkeit, an anderen Apps herumzudoktern. Für Uneingeweihte: Der Root-Zugriff gibt der App volle Rechte, die sie normalerweise aus Sicherheitgründen nicht habe.
Und ja, das ist ein Risiko, weswegen ich bei meinem Telefon darauf verzichtet habe: Ich nutze es dafür, Android-Apps unter jenen Umständen zu testen, unter denen sie von den allermeisten Anwendern benutzt werden – und da gehört das Rooten nicht dazu. Falls sich jemand anders entscheidet, würde ich Kingo empfehlen; Details gibt es in einem Beitrag von Cnet.
Warden liefert auch eine Übersicht mit allen Apps, in der jeweils auch die Versionsnummer und die UID angezeigt, was uns daran erinnert, dass Android ein Linux-, bzw. Unix-Abkömmlung ist. Ausserdem erfährt man die Application ID (z.B. org.mozilla.firefox oder com.google.android.apps.docs.editors.docs), die die App eindeutig identifiziert und uns wiederum an den Package name aus Java erinnert. Aber das ist an dieser Stelle nicht sonderlich wichtig, ausser für Leute, die immer auch gerne etwas über die Vorgänge hinter den Kulissen erfahren.
Die harten Bandagen
Die App hält über das Menü links oben einige weitere Funktionen bereit. Bei Monitor sieht man die App-Verwendung pro Tag, Woche und Monat. Bei All Trackers und All Loggers gibt es eine Übersicht der in der Exodus-Datenbank erfassten Module. Über Hidden Apps darf man auch die versteckten Anwendungen untersuchen.
Und unter Lab gibt es die zwei Funktionen, die explizit als experimentell gekennzeichnet sind: Debloat und Nuke it!. Soweit ich es verstanden habe, ist der erste Befehl (Debloat) dazu da, Ballast aus den Apps zu entfernen – ich nehme an, indem überflüssige Module entfernt werden. Der zweite Befehl Nuke it! löscht (gemäss dieser Information) alle Tracker aus den Apps. Ob das funktioniert, kann ich nicht beurteilen, da dafür wiederum Root-Zugriff notwendig wäre.
Ich würde empfehlen, diese beiden Befehle nur zurückhaltend anzuwenden: Erstens wegen der Gefahren, die das Rooten des Geräts mit sich bringt. Es ist beispielsweise damit zu rechnen, dass manche Apps, namentlich fürs E-Banking, nicht mehr funktionieren. Generell wird die Sicherheit des Geräts geschwächt, sodass man sich fragen kann, ob das ein legitimer Preis für den verbesserten Datenschutz ist.
Besser nicht!
Zweitens würde es mich wundern, wenn nach dem «nuken» alle Apps noch problemlos funktionieren würden. Ich glaube nicht, dass die Entwickler sich allesamt die Mühe machen, ihre Apps so zu schreiben, dass sie auch ohne das Tracking klaglos funktionieren – darum scheinen mir unerwünschte Nebenwirkungen wahrscheinlich.
Beitragsbild: Um den Trackern gepflegt den Mittelfinger zu zeigen, ist leider Root-Zugriff erforderlich (Nicolas Postiglioni, Pexels-Lizenz).
Wenn man sein Smartphone nicht rooten will und viel Geduld mitbringt, kann man das APK auf den Rechner laden, dekompilieren, die Tracker entfernen (meist lassen sie sich durch eine Anpassung der Konfiguration deaktivieren), die App kompilieren und dann manuell installieren. Und das dann natürlich bei jedem Update… Ein Beispiel gibt es hier: https://www.silur.me/posts/Modding-an-apk-to-disable-tracking/
Sowohl Google als auch Apple tun leider viel dafür, dass man nicht auf „dumme“ Ideen kommt. So lässt sich weder bei Android noch bei iOS der DNS-Server für Mobilfunkverbindungen festlegen. Technisch gibt es keinen Grund für die Einschränkung.
Weshalb so viele Apps Firebase Analytics integriert haben, ist klar: Man kommt sonst kaum an Absturzberichte. Die Benutzer können keine Logdatei anschauen und einsenden, sondern abstürzende Apps werden einfach kommentarlos geschlossen.
Google hat das erkannt und bietet Crashlytics an. Das läuft auf Android und iOS und ist innert Minuten integriert. Man hängt es am zentralen Try-Catch-Punkt ein und immer, wenn die App auf einen Fehler stösst, der nicht abgefangen wird (sie also abstürzt), wird ein Bericht übermittelt mit OS, Gerät, was der Benutzer gemacht hat, Inhalt von Variablen etc. Diese Meldungen kann man dann auswerten und so auch hartnäckige Fehler finden.
„Leider“ stehen nur wenige Funktionen zur Verfügung, wenn man Crashlytics ohne Analytics verwendet. Deshalb werden häufig beide Tools integriert. Da beide Tools kostenlos sind, bezahlt man mit den Analytics-Daten.
Ein eingebundenes Analytics kann vieles heissen. Von „wird nur für Crashlytics verwendet“ bis zu „jeder Touch wird getrackt“.
Das Tracking hat auch zwei Seiten: einerseits werden die Benutzer überwacht, andererseits ist es die beste Möglichkeit für Benutzer, um zu sehen, welche Funktionen der App wie häufig verwendet werden. So können auch Open-Source-Projekte ihre Ressourcen auf die meistverwendeten Features konzentrieren.
Aber ja, ich hätte auch gerne eine grössere Diskussion darüber, was Hersteller von Apps, die man verwenden muss, alles dürfen sollen. Ich denke da hauptsächlich an die SBB-App. Das wäre vielleicht mal was für den Tagi. In Deutschland steht die App der DB in der Kritik: https://digitalcourage.de/blog/2022/db-tracking-brief.