Wer Wert auf ein nicht-spionierendes Handy legt, ist mit den Android Custom ROMs, die in Mikes kürzlich durchgeführter Analyse gut abschnitten, sicher am besten bedient:
https://www.kuketz-blog.de/android-grapheneos-calyxos-und-co-unter-der-lupe-custom-roms-teil1/
Allerdings ist dieser Weg nicht immer praktikabel. Diese Custom ROMs sind nur für wenige Android Smartphones verfügbar. Im wesentlichen sind dies die Google Pixel, das Fairphone und wenige ältere Geräte anderer Hersteller. Für die meisten Android Smartphones gibt es entweder gar kein Custom ROM oder nur ein unsicheres, bei dem z.B. der Bootloader nach der Installation nicht mehr geschlossen werden kann oder Sicherheitsupdates nicht automatisch eingespielt werden. Darüber hinaus läuft Android auf vielen weiteren Gerätetypen, wie Tablets und Smart-TVs für die fast immer nur das installierte Stock-ROM des Herstellers verfügbar ist.
Ich wollte daher hier zeigen, wie mit Hilfe der Android Debug Bridge (ADB) und weniger Apps zur Geräteadministration auch ein vorinstalliertes Stock-ROM mehr oder weniger datenschutzfreundlich umgebaut werden kann. Im Idealfall kann fast das Datenschutzniveau eines guten Custom ROMs erreicht werden. Diesen Idealfall habe ich bei einem Samsung Tablet vom Typ SM-T225 mit SIM-Karte unter Android 14 verwirklicht. Daher wollte ich im folgenden den Ansatz an Hand dieses Geräts demonstrieren. Das Vorgehen lässt sich direkt auf andere aktuelle Samsung Smartphones und Tablets übertragen, auf denen dasselbe Android Stock-ROM von Samsung läuft. Am Ende gehe ich auf wenige Geräte weiterer Hersteller ein, bei denen ich diesen Ansatz auch verfolgt hatte, mal mit mehr, mal mit weniger Erfolg.
Das Vorgehen ist relativ einfach: Unter Einstellungen / Verbindungen / Datennutzung und mit einer installierten Firewall wie RethinkDNS wird das Datensendeverhalten der vorinstallierten (System-) Apps von Google und des Geräteherstellers, in diesem Fall also Samsung beobachtet. Apps die „nach Hause funken“ werden darauf geprüft, ob sie essentiell sind oder deaktiviert, deinstalliert werden können. Nicht deinstalliert werden sollen Apps, die für System- und Sicherheitsupdates sorgen. Alles andere steht grundsätzlich zur Disposition. Mit Hilfe von veröffentlichten Bloatlisten wird vor der Deinstallation abgeglichen, ob damit ein Risiko verbunden ist, also ob andere Nutzer eine App bereits ohne negative Nebenwirkungen deinstallieren konnten. Da bei Systemapps meistens die Deinstallation und selbst die Deaktivierung unter Einstellungen blockiert ist, wird die ADB benötigt. Mit dieser lässt sich diese Sperre umgehen und praktisch alle vorinstallierten Apps lassen sich entweder Deaktivieren oder Deinstallieren. Dafür sind keine Root-Rechte notwendig, die hier auch nicht verwendet werden sollen. Das Ziel ist, die Sicherheitsarchitektur in Form des Rechte- und Zugriffsmanagements und der Sicherheits- und Systemupdates nicht anzutasten. Die ADB ist darüber hinaus ein mächtiges Debug-Tool um weitere Optimierungen am System vorzunehmen.
Der Ansatz ist nicht völlig ohne Risiko. Mit der ADB können auch essentielle Systemapps deinstalliert werden, wie z.B. der Launcher. Im schlimmsten Fall wird ein System „gebrickt“, also unbenutzbar gemacht. Allerdings lassen sich mit der ADB vorgenommenen Änderungen am System durch Zurücksetzen auf Werkseinstellungen rückgängig machen. Die ADB deinstalliert Systemapps nicht vollständig. Sie bleiben im Installationspackage des Betriebssystems erhalten und werden nur für das aktuelle Nutzerkonto deinstalliert, deakiviert. Ein System lässt sich allerdings soweit zerschießen, dass das Menü zum Zurücksetzen in den Einstellungen nicht mehr erreicht werden kann. Daher empfehle ich sich ZUERST mit dem Recovery-Menü vertraut zu machen. Dieses lässt sich meistens mit den Tasten am Rand des Smartphones (z.B. Funktionstaste + eine Lautstärketaste) beim Boot des Geräts erreichen und ermöglicht ein Zurücksetzen auf Werkseinstellungen auch wenn Android nicht mehr startet. Die Tastenkombinationen variieren je nach Hersteller und lassen sich im Internet recherchieren oder stehen in der Gebrauchsanleitung. Mit umsichtigem Vorgehen habe ich es bisher vermieden, ein Androidgerät mit der ADB so zu zerschießen, dass ich es zurücksetzen musste, obwohl ich den Ansatz bereits bei ca. einem halben Dutzend Geräten verschiedener Hersteller verfolgt habe. In jedem Fall ist eine Datensicherung vor der Arbeit mit der ADB vorzunehmen, da falls ein Zurücksetzen auf Werkseinstellungen notwendig ist, auch alle Nutzerdaten gelöscht werden. Ich will außerdem klarstellen, dass ich keine Verantwortung übernehme, wenn jemand diesen Blogbeitrag liest und daraufhin sein Gerät zerschießt! Leser handeln auf eigene Verantwortung!
Nachdem das Gerät von den „nach Hause funkenden“ Apps bereinigt wurde, empfehle ich einige weitere Einstellungen zu ändern, die ebenfalls nur mit der ADB oder speziellen Apps zur Administration und nicht mit den regulären Einstellungen zugänglich sind. Zudem müssen die deinstallierten Nutzerapps von Google und Handyhersteller, wie z.B. der Browser durch datenschutzfreundliche Alternativen ersetzt werden. Wenn auf die Googledienste und spionierende Nutzerapps, wie z.B. Whatsapp nicht verzichtet werden kann, lassen sich diese in einem Arbeitsprofil oder zweitem Nutzerprofil isolieren, so dass zumindest das Hauptnutzerkonto sauber bleiben kann.
- Installation von ADB und Apps zur Administration
Zuerst wird die ADB benötigt. Sie wird auf einem PC installiert. Das Androidgerät kann damit über ein USB DATEN-kabel oder WLAN (nützlich z.B. für Android TV) gesteuert, programmiert werden. Hier Links auf Beschreibungen zur Installation, Nutzung und zu den Befehlen:
https://www.giga.de/apps/android/tipps/adb-installieren-die-android-debug-bridge-zum-laufen-bringen/
https://developer.android.com/tools/adb?hl=de
Um die ADB nutzen zu können, müssen auf dem Androidgerät die Entwickleroptionen und USB- bzw. Wifi-Debugging freigeschaltet werden. Meist funktioniert die Freischaltung, indem unter Einstellungen / Softwareinformationen ca. 7-mal auf die Buildnummer getippt wird. Falls das für ein Gerät nicht funktioniert, hilft eine Internetrecherche.
Auf dem zu reinigenden Androidgerät sind neben der ADB die folgenden Apps notwendig oder zu empfehlen (teilweise gibt es Alternativen):
a. F-Droid Appstore, herunterzuladen von f-droid.org, Berechtigung zur Installation von Apps erteilen
b. Von F-Droid wird installiert:
RethinkDNS zur Überwachung des Datenverkehrs (alternativ Blokada von deren Webseite)
Package Manager zur Administration der Apps auf dem Gerät
Captive Portal Controller zur Administration der Verbindungschecks für WLAN-Netze
Shelter oder Insular zum Einrichten eines Arbeitsprofils
Aurora Store zum „pseudo-anonymen“ Zugriff auf den Google Playstore ohne eigenes Googlekonto
c. Von Aurora wird installiert:
Permission Pilot zur Administration von App-Berechtigungen
d. Alternative, datenschutzfreundliche Nutzerapps
Da die nach Hause funkenden Apps von Google und Handyhersteller ersetzt werden sollen, können auch gleich alternative, datenschutzfreundliche Apps aus F-Droid, teilweise auch Aurora installiert werden. Hier eine subjektive Auswahl:
Browser und Suchleiste: Fennec-, Tor Browser; Tastatur: AnySoftKeyboard inkl. deutsche Tastatur; SMS: Simple Mobile Tools; Start-App/Launcher: ADW-Launcher aus Aurora; File Manager: Amaze oder Simple Mobile Tools; Uhr: Simple Mobile Tools; Mail: K-9, Karten: Osmand; Videos & Musik: NewPipe; Medienplayer: VLC; Galerie: Simple Mobile Tools; Wetter inkl. Widget: Kleine Wettervorschau
Unter Einstellungen / Apps / Standard Apps werden nun anstatt der vorinstallierten Apps der Fennec Browser, die Simple Mobile SMS App, der ADW-Launcher und das AnySoftKeyboard eingetragen oder was der Nutzer sonst bevorzugt. Die Einstellung der Standardtastatur findet sich je nach Gerät in einem anderen Menü, z.B. unter „Allgemeine Verwaltung“. Falls die Dialer / Telefonapp von Google installiert ist, sollte auch diese ersetzt werden, da der Google-Dialer die Anrufliste regelmäßig an Google sendet. Bei alternativen Dialerapps zuerst prüfen, ob sie auf dem Gerät funktionieren.
- Deinstallation der vorinstallierten „funkenden“ Apps
Voraussetzung für diesen Schritt ist, dass die ADB installiert ist und Zugriff auf das Androidgerät hat (USB Debugging aktiviert). Die ADB „kennt“ Apps unter einem anderen Namen, als dem in den Einstellungen sichtbaren. Der Google Play Store z.B. wird von der ADB als „com.android.vending“ erkannt. Daher verschaffen wir uns mit dem Befehl „adb shell pm list packages“ eine Liste der Namen aller installierten Apps und kopieren diese am besten aus der Befehlszeile in eine separate Datei. Zum Übersetzen der Appnamen hilft z.B. die App Package Manager. Dessen Suchfunktion findet Apps unter allen Namen, die sie hat.
Nun schauen wir unter Einstellungen / Datennutzung oder nach dessen Aktivierung unter Rethink-DNS nach, welche Apps Daten versenden und deaktivieren, deinstallieren diese. Deaktivieren / wieder aktivieren geht unter ADB mit diesen beiden Befehlen:
adb shell pm disable-user <PACKAGE_NAME>
adb shell pm enable <PACKAGE_NAME>
<PACKAGE_NAME> ist der Name der App in der mit ADB erzeugten Appliste, also z.B. com.android.vending. Diese Befehle funktionieren in vielen Fällen selbst dann, wenn unter Einstellungen / Apps „Deaktivieren“ ausgegraut, also blockiert ist.
Deinstalliert werden Apps mit diesem Befehl:
adb shell pm uninstall -k <PACKAGE_NAME>
Diesen Befehl nie ohne den Zusatz „-k“ ausführen, da sonst das Apppaket komplett entfernt wird. „-k“ schränkt die Deinstallation auf das Nutzerkonto ein. Somit kann die App mit diesem Befehl ohne Appstore und APK-Datei wieder installiert werden, falls nach einer Deinstallation Probleme auftreten oder doch nützliche Funktionen verschwinden:
adb shell pm install-existing <PACKAGE_NAME>
Es ist eine Ermessensfrage, ob Apps nur deaktiviert oder gleich deinstalliert werden. Das Versenden von Daten ist nach meiner Erfahrung in beiden Fällen unterbunden. Deaktivieren per ADB kann in manchen Fällen blockiert sein, Deinstallieren funktioniert fast immer. Deaktivieren ist weniger riskant, da es immer rückgängig gemacht werden kann. Der Befehl „install-existing“ bringt dagegen in sehr wenigen Fällen eine App nicht zurück. Falls sie dennoch essentiell war, bleibt nur noch das Zurücksetzen auf Werkseinstellungen. Ich empfehle Deinstallieren nur, wenn eine Systemapp in mehr als einer Bloatliste als problemlos zu entfernen gelistet ist. Ein vorsichtiger Ansatz wäre, Apps wenn möglich zuerst nur zu Deaktivieren und erst wenn es damit keine Probleme gibt, zu deinstallieren. Weiter helfen auch die Bezeichnungen der Apps und gesunder Menschenverstand. Die Systemapp „com.google.android.permissioncontroller“ würde ich nicht deinstallieren, da das Berechtigungsmanagement essentiell ist, die Systemapp „com.google.android.syncadapters.contacts“ dagegen schon, da ich meine Kontakte nicht mit der Google-Cloud synchronisieren will.
Beim Deinstallieren von übergriffigen Systemapps kommt einem der modulare Aufbau von Android entgegen. Unter Android sind auch die Betriebssystembestandteile nur „Apps“, die weitgehend unabhängig voneinander funktionieren. Wird z.B. die App des Google Playdienstes „com.google.android.gms“ deinstalliert, verschwindet das Google-Menü aus den Einstellungen und es gibt keine Werbe-id mehr. Apps, die auf die Google Playdienste zugreifen, funktionieren nicht mehr, allen voran die diversen Googledienste (App Store, Karten, Mail, etc.). Alles andere ist davon aber unbeeinträchtigt und funktioniert weiter, inkl. dem weiter vorhandenen Rest der Einstellungen-App.
Nicht deinstalliert werden soll die App für System- und Sicherheitsupdates. Bei Samsung heißt sie aktuell „com.wssyncmldm“. Häufig tragen diese Apps oder die Domains, die sie kontaktieren das Kürzel (f)ota im Namen, das für „(firmware) over the air“ steht. Falls diese App nicht auf Anhieb zu erkennen ist, in den Einstellungen eine Updateanfrage manuell anstoßen und z.B. in RethinkDNS schauen, welche App und welche Verbindungen aktiv werden.
Die Apps und Systemapps von dritten Internetkonzernen, wie z.B. Spotify, Netflix, Facebook usw. empfehle ich unbedingt zur Deinstallation. Teilweise haben diese Konzerne Deals mit den Geräteherstellern, um vorinstallierten Apps erweiterte, invasive Berechtigungen einzuräumen, die für die Versionen im Google Playstore nicht erlaubt sind, da sie selbst die Richtlinien von Google verletzen würden.
Hier ist meine Debloatliste für Samsung veröffentlicht, erprobt am Tablet SM-T225 mit Mobilfunkmodem:
https://gist.github.com/Maetih/2718d0e0a23940d8cb0e6a9235adddd8
- Google Dienste
Die Gretchenfrage beim Säubern von Android ist, was mit den Google-Diensten geschehen soll. Die zusätzliche Bloatware des Herstellers, wie z.B. ein weiteres App Store und Nutzerkonto werden kaum vermisst werden. Ohne Googledienste glauben viele Nutzer allerdings nicht auskommen zu können und manche Nutzerapps funktionieren tatsächlich nicht ohne diese Dienste - die meisten überraschenderweise jedoch schon. Die Googledienste bestehen im engeren Sinn aus diesen vier Apps:
com.google.android.googlequicksearchbox Google App & Suchleiste
com.google.android.gms Google Play Dienste
com.android.vending Play Store
com.google.android.gsf Google Services Framework
Vending ist der Playstore. Im Kern bestehen die Playdienste aber aus der Google-App, die die Suchleiste erzeugt, der Systemapp Google Play Dienste (GMS), die in den Einstellungen das Google Untermenü erzeugt und der GSF App, die selbst keine sichtbare Funktion hat, ohne die die beiden anderen Apps aber nicht funktionieren. Unter Android TV heißt die Google App „com.google.android.katniss“. Solange diese drei Apps aktiv ist, wird jede Nutzung des Gerätes, jede installierte App, etc. an Google gemeldet und wenn Nutzer mit einem Konto eingeloggt sind, diesem Nutzerkonto zugeordnet (schaut in Eurem Googlekonto nach, was dort zu Geräten gelistet ist). Das ist für mich inakzeptabel. Ich habe mich daher gegen die allgemeine Nutzung der Googledienste entschieden, gehe jedoch folgenden Kompromiss ein: Mindestens die funkenden Apps Vending, GMS und die Google App sind in meinem Hauptnutzerprofil deinstalliert. Weitere Google Anwendungsapps (z.B. Chrome, Youtube, Mail) auch, da sie ohne diese Dienste nicht funktionieren oder Fehlermeldungen von sich geben. Ich habe ein Arbeitsprofil mit Shelter eingerichtet. In diesem sind alle vier Apps installiert, jedoch bin ich dort nicht mit Googlekonto registriert und zu mindestens 98% der Zeit sind alle 4 Apps „eingefroren“, erfassen und senden also keine Daten (Funktion des Arbeitsprofils, vergleichbar zu deaktivieren). Nur wenn ich im Arbeitsprofil eine App nutzen will, die die Googledienste tatsächlich benötigt (z.B. Google Translate um im Urlaub Speisekarten zu übersetzen) taue ich die Google-Dienste auf und betreibe sie ohne Nutzerkonto. Ich nutze keine App und vermisse auch keine, die ein Google Nutzerkonto voraussetzt.
- Arbeitsprofil und weitere Nutzerprofile
Wie beschrieben kann das Arbeitsprofil für übergriffige Apps und auch die Googledienste genutzt werden, um diese zu isolieren und ihren Zugriff auf persönliche Daten im Hauptprofil, wie Kontakte, Anruflisten, Mediendateien, Liste installierter Apps etc., zu unterbinden. Zusätzlich kann das Arbeitsprofil als Ganzes oder einzelne Apps davon eingefroren werden. Apps in diesem Zustand erfassen und senden keine Daten. Nach dem Auftauen laufen sie wie zuvor weiter. Sie verlieren durch das Einfrieren also auch keine Daten, wie z.B. Logins.
Das Arbeitsprofil ist im Stock-ROM implementiert - oder auch nicht oder nur schlampig. Apps wie Shelter oder Insular zum Einrichten des Arbeitsprofils rufen diese Funktion nur auf und machen die Einstellungen sichtbar. Ob das Arbeitsprofil funktioniert hängt daher vom Gerät, Hersteller und der Androidversion ab. Für jedes neu erzeugte Arbeits- und weitere Nutzerprofile gilt: Die im Hauptprofil deaktivierten, deinstallierten Apps und Systemapps sind dort in einer Untermenge wieder aktiv und müssen erneut per ADB deaktiviert, deinstalliert werden. Da nun mehrere Profile auf dem Gerät vorhanden sind, muss bei jedem ADB-Befehl spezifizert werden, für welches Profil er gelten soll. Der Befehl „adb shell pm list users“ zeigt die aktiven Nutzerkonten mit ihren Nummern an, der Befehl „adb shell pm get-max-users“ die maximal möglichen User. Insbesondere bei älteren Androidversionen und bei Android-TV kann die Anzahl der Profile auf eines beschränkt sein. Dann kann kein Arbeitsprofil eingerichtet werden. Wenn ein Befehl nur auf ein Nutzerkonto wirken soll, muss dessen Nummer mit dem Zusatz „–user “ eingefügt werden, wobei n die Nummer des Nutzers ist. Das Hauptprofil hat üblicherweise die Nummer 0, das Arbeitsprofil die Nummer 10. Dieser Befehl deinstalliert in diesem Fall z.B. den Google Play Store aus dem Arbeitsprofil:
adb shell pm uninstall -k --user 10 com.android.vending
Bei aktuellen Samsunggeräten sind einige der „Knox“ Apps und die App „com.samsung.android.container“ für das Arbeitsprofil notwendig. Diese daher nicht deinstallieren, obwohl sie auf manchen Debloatlisten auftauchen und zum Teil Daten versenden. Eine weitere Samsungspezialität ist, dass Arbeits- und Nutzerprofil so hermetisch getrennt sind, dass ein Dateitransfer zwischen beiden auf dem Gerät nicht möglich ist, selbst wenn diese Option in Shelter freigegeben ist. Ein Dateitransfer ist also nur über das Internet oder einen PC möglich.
- Verbindungschecks und Assisted-GPS
Mike hat in seiner Analyse der Custom ROMs auf den Datenverkehr von Closed Portal Verbindungschecks und Assisted-GPS hingewiesen, der teilweise sogar am VPN vorbeigeführt wird und daher in Firewall-Apps wie Rethink-DNS nicht sichtbar ist, die die VPN-Funktion nutzen. Für mein Samsunggerät habe ich den WLAN-Datenverkehr daher mit einer Fritzbox und Wireshark aufgezeichnet, nachdem ich die Systemapps, wie in meiner Bloatliste gelistet, entfernt hatte. Tatsächlich traten keine Anfragen zu SUPL- und PSDS-Servern bei eingeschaltetem GPS auf. Es treten aber Verbindungen auf zu einem Assissted-GPS Dienst namens EPO von Mediatek, dem Prozessorhersteller. Von dort wird versucht, ungefähr einmal wöchentlich eine Datei herunterzuladen. Mit den deinstallierten Systemapps habe ich also auch A-GPS in Bezug auf Anfragen bei Google entfernt (oder Google A-GPS ist bei Samsung von vornherein nicht eingerichtet). Falls ich es entfernt habe, weiß ich nicht mit welcher Systemapp Google A-GPS entfernt wurde. Verdächtig sind für mich der Google Playdienst und die App „com.google.android.gms.location.history“.
Die Closed Portal Verbindungsschecks können auch bei Stock ROMs auf andere Server, als den meist voreingestellten Google-Server umgeleitet werden. Mike hat hier die ADB Befehle dazu aufgelistet:
https://www.kuketz-blog.de/empfehlungsecke/#captive-portal
Mit der App „Captive Portal Controller“ z.B. aus F-Droid lässt sich diese Einstellung auch ändern und vor allem anzeigen.
- Berechtigungsmanagement
Das Berechtigungsmanagement unter Android ist leider ein tiefer, dunkler Sumpf in dem Daten unsichtbar versickern. Jedes Android kennt nicht nur die Standardberechtigungen, wie Standort, Kamera, Kontakte, etc., die in den Einstellungen angezeigt werden und teilweise vom Nutzer entzogen werden können. Jeder Entwickler kann sich für seine Apps, insbesondere für Systemapps neue Berechtigungen ausdenken und umsetzen, die nirgendwo unter Einstellungen sichtbar sind. So könnte z.B. der Entwickler einer App namens „datenkrake“ dieser eine alternative Standortberechtigung mit dem Namen „com.datenkrake_inc.datenkrake.permission.ALT_LOCATION“ geben, mit der die App auf das GPS zugreifen und Standortdaten nach Hause funken könnte, auch wenn die Standard-Standortberechtigung von Android der App nicht erteilt wurde. Tatsächlich könnte diese App in den Einstellungen so aussehen, als ob ihr überhaupt keine besonderen Berechtigungen erteilt worden wären. Solche Tricks sind vor allem bei vorinstallierten Systemapps anzutreffen, da ausgerechnet Google mit seinen Richtlinien für Apps im Playstore dort solchen Missbrauch einschränkt. Systemapps gehen an dieser Kontrolle vorbei, da sie direkt vom Gerätehersteller kommen. Wie verbreitet der Missbrauch ist und wie perfide er ausgenutzt wird, ist in diesen beiden Veröffentlichungen dokumentiert:
https://dspace.networks.imdea.org/bitstream/handle/20.500.12761/684/An_Analysis_of_Pre-installed_Android_Software_2019_EN.pdf?sequence=1
https://dspace.networks.imdea.org/bitstream/handle/20.500.12761/1715/Mules_and_Permission_Laundering_in_Android_Dissecting_Custom_Permissions_in_the_Wild.pdf?sequence=1
Von denselben Autoren bzw. dem Institut IMDEA wurden übrigens weitere bahnbrechende Analysen zum Thema Tracking über alle möglichen Internetanwendungen und Kanäle veröffentlicht. Die Autoren listen einige derartige, missbräuchliche Berechtigungen auf, nach denen Geräte untersucht werden können. Auf meinem Samsunggerät habe ich ein Beispiel gefunden. Samsung lieferte das Gerät mit der Systemapp „com.netflix.partner.activation“ aus, die über die Berechtigung „com.netflix.partner.activation.permission.CHANNEL_ID“ verfügt. Unter Einstellungen / Apps wird für diese App selbst mit „Alle Berechtigungen“ (auf 3 Punkte klicken) keine einzige Berechtigung angezeigt. Für den durchschnittlichen Nutzer ist sie also unsichtbar. Ich kann nur spekulieren, was es mit der Berechtigung „Channel-ID“ auf sich hat. Offensichtlich hat Netflix mit Samsung einen Deal, diese Systemapp mitzuliefern. Die App ist unauffällig und sendet keine Daten. Wahrscheinlich ist sie daher ein schlafender Trojaner, der erst aktiv wird, nachdem die eigentliche Netflix App installiert ist und der dazu dient, dieser die erweiterte Berechtigungen „Channel_ID“ weiterzugeben, da Google diese Berechtigung bei einer App im Playstore vielleicht nicht billigen würde. Die Berechtigung könnte darin bestehen, Medienkanäle außerhalb der Netflix App zu beobachten, also z.B. welche Streams ein Nutzer bei Disney+ schaut. An solchen Daten hätte Netflix sicher Interesse.
Um derartigen Missbrauch abzuschalten, ist es zuerst notwendig, solche Berechtigungen zu erkennen. Die App „Package Manager“ zeigt alle Berechtigungen einer App an, also z.B. auch die „Channel-ID“ Berechtigung der Netflix App. Noch besser ist die App „Permission Pilot“ aus dem Playstore. Mit ihr kann das ganze System nach Berechtigungen durchsucht werden. Als Stichwörter für die Suche können die üblichen Verdächtigen verwendet werden: Facebook, Amazon, Spotify, Netflix, MSC bzw. Microsoft, plus Handy- und SoC-Hersteller Samsung, LG, Lenovo, Sony, Qualcomm, Mediatek etc., bei Chinahandys auch QQ, Tencent, Mi bzw. Xiaomi, Huawei, Oppo, HTC etc. plus Telekomfirmen Vodafone, Telecom etc. Werden unerklärliche Berechtigungen gefunden gibt es zwei Möglichkeiten: Die betreffende App per ADB deinstallieren oder der App die Berechtigung entziehen. Dies ist per ADB auch für Custom-Permissions möglich. Der folgende Befehl würde der Netflix App die „Channel_ID“ Berechtigung nehmen:
adb shell pm revoke com.netflix.partner.activation com.netflix.partner.activation.permission.CHANNEL_ID
Die Berechtigung muss im Befehl am Ende so eingegeben werden, wie sie im Package Manager oder Permission Pilot angezeigt wird. „grant“ anstatt von „revoke“ gibt die Berechtigung zurück.
Unter Android gibt es eine Art Super-Berechtigung, die auf dieselbe Art kontrolliert werden sollte. Auch sie ist unter Einstellungen unsichtbar. Sie heißt „android.permission.READ_LOGS“. Android verfügt über eine Logdatei, in der vom ganzen System Daten eingesammelt werden, darunter auch sensible wie nutzerspezifische Ids, Standortdaten, usw. Wer diese Datei selbst durchschauen will, kann sie mit dem ADB-Befehl „logcat“ extrahieren. „adb logcat --help“ zeigt die Optionen an. Apps mit „READ_LOGS“ Berechtigung können sich an diesen Daten nach belieben bedienen. Daher sollte sie allen verdächtigen (System-) Apps entzogen werden, mit diesem ADB-Befehl:
adb shell pm revoke <PACKAGE_NAME> android.permission.READ_LOGS
Ob der Entzug von Berechtigungen funktioniert hat, kann im Package Manager oder Permission Pilot kontrolliert werden. Bei der entsprechenden App muss unter Berechtigungen das Häkchen bei der entzogenen Berechtigung entfernt sein. Ich kann hier das Thema Berechtigungen leider nur streifen. Permission Pilot zeigt für mein Samsunggerät ca. 900 Custom-Permissions alleine von Samsung an!
- Ergebnis
Nach den beschriebenen Änderungen und Deinstallationen sind im Zeitraum einer Woche für das Samsunggerät noch die folgenden, von Systemapps ausgehenden Verbindungen zu verzeichnen (ohne Closed Portal Verbindungsschecks):
Samsung System- und Sicherheitsupdates:
*.ospserver.net
Andere Verbindungen zu Samsung (zum Teil Tracking):
dc.dqa.samsung.com
poll.gras.samsungdm.com
dir-apis.samsungdm.com
gos-api.gos-gsp.io
euprod-knoxpp.samsungknox.com
Google (Updates, Zeitserver):
play.google.com
update.googleapis.com
clientservices.googleapis.com
time.android.com
Mediatek (EPO assisted GPS)
sfepodownload.mediatek.com
sgepodownload.mediatek.com
Zeitserver
*.pool.ntp.org
Diese Verbindungen treten mit niedriger Frequenz auf, manche im Abstand von Stunden, andere im Abstand von Tagen. An manchen Tagen wird nur ein Zeitserver kontaktiert. Das übertragene Datenvolumen und die Möglichkeit zum Tracking sind somit gering. Sie gehen von Systemapps aus, die essentiell sind, wie z.B. Webview. Die meisten davon sind für wichtige oder zumindest nützliche Funktionen, wie Updates, Zeitsynchronisation, GPS. Da es sich nur um wenige Verbindungen handelt, lassen sie sich auf Wunsch gezielt mit einer Firewall, wie RethinkDNS blockieren. Tatsächlich mache ich das nur bei den Verbindungen zu Samsung, die nicht an den Updateserver gehen. Kritischere Nutzer können weitere Verbindungen, wie die zu Google oder Mediatek auf diese Weise blockieren.
Insbesondere wenn einige der wenigen verbleibenden Verbindungen mit einer Firewall wie RethinkDNS blockiert werden, ist mit den beschriebenen Maßnahmen ein Datenschutzniveau irgendwo zwischen CustomROMs wie /e/ und CalyxOS beim aktuellen Samsung Stock-ROM zu erreichen. In jedem Fall ist das an Tracker übertragene Datenvolumen gegenüber einem unveränderten Android StockROM oder auch im Vergleich zum iPhone um Größenordnungen reduziert. Systemupdates werden dennoch pünktlich eingespielt. Ich hatte das System ursprünglich unter Android 12 eingerichtet, habe Android 13 und 14 als Updates stabil eingespielt bekommen und musste an der Einrichtung, installierten und deinstallierten Systemapps mit den Updates kaum etwas ändern. Deinstallierte, deaktivierte Systemapps bleiben nach einem Update in diesem Status. Ich habe zwei Apps entfernt, die erst mit Updates reinkamen. Eine erneute Kontrolle des Datensendeverhaltens ist dennoch nach jedem größeren Update angeraten, da bei einem kommerziellen Anbieter immer damit gerechnet werden muss, dass neue Trackingfeatures eingeführt werden.
Ich rate dennoch weiterhin zu guten Custom-ROMs als erste Wahl für ein datenschutzfreundliches Gerät, einfach weil es deutlich weniger Arbeit und vor allem weniger Kontrolle erfordert, einmalig ein Custom-ROM aufzuspielen, als ein Stock-ROM wie beschrieben zu säubern und sauber zu halten.
- Weitere Geräte bei denen der Ansatz erprobt wurde
Erstmalig hatte ich den beschriebenen Ansatz bei einem Asus ZenPad P024 unter Android 6 schon vor Jahren erprobt, mit ähnlich gutem Erfolg wie beim Samsung Tablet. Der Datenfluss zu Google und Asus ließ sich fast vollständig unterbinden. Asusgeräte sind aber nun schon länger nicht mehr aktuell. Relevanter sind meine Erfahrungen mit den folgenden Geräten:
a. Google Pixel 4a und 6a
Bei Google Pixelgeräten funktioniert der Ansatz mit dem StockROM Datenschutz zu erreichen gar nicht, da auch Systemupdates über die Google Play Dienste eingespielt werden. Werden sie entfernt lässt sich das System nicht mehr aktualisieren. Nach dem Entfernen der Play-Services App geben die Geräte außerdem im Sekundentakt Warnmeldungen und -töne von sich. Google will nicht ent-Googelt werden! Der Ansatz ist bei Pixelgeräten aber auch sinnlos, da für diese alle guten Custom-ROMs verfügbar und einfach zu installieren sind.
b. Xiaomi Redmi Note 10S
Datenschutz und Chinahandys schließen sich aus! Leider findet man gerade in Kinderhänden viele Smartphones aus China, da sie am billigsten sind, so auch in meinem Bekanntenkreis. Verdienen Kinder keine Privatspäre? Ich habe daher versucht bei einem Redmi Note 10S mit Android 12 aus dem Hause Xiaomi den Datenabfluss soweit wie möglich zu reduzieren. Das gelang nicht so gut, wie beim aktuellen Samsung Stock-ROM. Xiaomi hat seine Dienste tiefer in den Android Source Code eingebaut als Samsung, damit lassen sie sich nicht im selben Umfang entfernen, ohne grundlegende Funktionen des OS zu beschädigen. Es bleibt ein signifikanter Datenfluss an Xiaomi nach China bestehen, der nur mit einer Firewall blockiert werden kann. Immerhin lässt sich das Datenvolumen an Xiaomi signifikant reduzieren und viel lästige Bloatware entfernen. System- und Sicherheitsupdates funktionieren weiterhin problemlos. Debloatlisten für Xiaomi mit mehreren Updates, davon auch eines von mir, gibt es unter folgendem Link. Apps, die nicht entfernt werden sollten, sind mit aufgeführt. Hier besteht nicht das Ziel, die Googledienste vollständig zu entfernen:
https://gist.github.com/mcxiaoke/ade05718f590bcd574b807c4706a00b1
Soweit mein Exkurs durch die ADB und verschiedene Android-Plattformen. Android Stock ROMs und auch das iOS übertragen, so wie die Systeme ausgeliefert werden, im Minutenabstand Daten an Google, Apple und im Fall von Android den Gerätehersteller, also typischerweise einige 100 bis 1000 Datensätze pro Tag. Mit den beschriebenen Methoden lässt sich das für Android Stock ROMs im Idealfall um den Faktor 100 auf wenige, einstellige Datenverbindungen pro Tag reduzieren, die vom System ausgehen. Einige vorinstallierte Systemapps müssen sogar als Malware bezeichnet werden (siehe z.B. Netflix Partner Activation), installiert um Schutzmechanismen des Betriebssystems zu umgehen. Es stellt daher ein größeres Risiko in Bezug auf Sicherheit und Persönlichkeitsschutz dar, ein Androidgerät im Auslieferungszustand zu betreiben, als es mit den beschriebenen Methoden aufzuräumen. Ich würde mich freuen, wenn weitere Anwender die Fremdbestimmung ihrer Androidgeräten außer Kraft setzen und wie beschrieben, selbst von ihren Geräten Besitz ergreifen würden.
Die Kommunikation ist oftmals mit gewissen Schwierigkeiten verbunden, sodass Aussagen leicht missverstanden werden können. Eine Botschaft kann vom Gegenüber anders wahrgenommen werden als vom Sender gedacht. Ich empfehle dazu sich den Artikel über das