Der Artikel beschreibt den Versuch, unter Android durch Umbau mittels der Android Debug Bridge (ADB), ohne Root soweit wie möglich an das Datenschutzniveau besserer Android Custom ROMs heranzukommen. Es ist der erste Teil einer voraussichtlich dreiteiligen Serie. Im ersten Teil wird der Ansatz für ein aktuelles Samsung Android (Stock-ROM) mit Android 14 demonstriert.

Es ist inzwischen kein Geheimnis mehr, dass Smartphones bereits im Auslieferungszustand, d.h. ohne vom Nutzer installierte zusätzliche Apps, im Minutenabstand Daten über das Nutzerverhalten an Hersteller von Gerät und Betriebssystem senden. Der Sicherheitsforscher Douglas J. Leith, Trinity College Dublin, hat in einer Veröffentlichung nachgewiesen, dass sowohl Androidgeräte, als auch das iPhone im Durchschnitt alle 4,5min Daten an Google, den Gerätehersteller und im Fall des iPhones an Apple senden (1). Daten, die geteilt werden, sind persönliche Identifier, die den Nutzer identifizieren wie eindeutige Gerätenummern, SIM-Kartennummern, sowie Standortdaten und einiges mehr, auch wenn der Nutzer dazu nicht einwilligt. Die Nutzung von Apps durch den Anwender wird gemeinhin protokolliert. Das iPhone schneidet datenschutztechnisch also nur in Werbeversprechen wesentlich besser ab als die Androidplattform. In einer zweiten Veröffentlichung hat derselbe Autor Androidgeräte der Hersteller Samsung, Xiaomi, Huawei, Realme und die zwei Custom-ROMs LineageOS und /e/OS verglichen und fand, dass mit „der bemerkenswerten Ausnahme von /e/OS, ... erhebliche Mengen an Informationen an den Betriebssystementwickler und auch an Dritte (Google, Microsoft, LinkedIn, Facebook usw.) gehen, die Systemanwendungen vorinstalliert haben“ (2).

Die Installation eines datensparsamen Custom-ROMs ist daher die wahrscheinlich beste Option, nach digitalem Detox, wenn Anwender der permanenten Überwachung durch ihre mobilen Geräte entgehen wollen. Mike Kuketz hat im Lauf des letzten Jahres gängige Custom ROMs im Detail in Bezug auf Datenschutz und Sicherheit untersucht (3). 

Dieser Beitrag ist als Reaktion auf Mikes Analyse von mir zuerst im Kuketzforum in einer ersten Version veröffentlicht worden (4), da die Nutzung eines Custom ROMs für datenbewusste Anwender zwar anzustreben, aber nicht immer praktikabel ist. 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 eingespielt werden. Darüber hinaus sind für weitere Gerätetypen, wie Tablets, Smart-TVs, Ebook-Reader Android und fast immer ist nur das Stock-ROM des Herstellers verfügbar.

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. Der Maßstab sind dabei die besseren Custom ROMs aus Mikes Test. Diesem Maßstab konnte ich bei einem Samsung Tablet vom Typ SM-T225 unter Android 14 relativ nahe kommen (Galaxy Tab A7 Lite LTE). Dieses Tablet hat ein Mobilfunkmodem, Telefon, ist also ein „Phablet“ und damit Smartphones vergleichbar. 

Hier im ersten Teil dieser Serie will ich den Ansatz an Hand dieses Gerätes demonstrieren. Das Vorgehen lässt sich direkt auf andere aktuelle Samsung Smartphones und Tablets übertragen, auf denen eine vergleichbare Androidversion von Samsung läuft. Im folgenden zweiten Teil wird es um Verbesserungen, Härtungen an Sicherheits- und Datenschutzeinstellungen von Android gehen. Im dritten Teil werde ich auf weitere Androidgeräte und -plattformen eingehen, bei denen ich den Ansatz auch verfolgt habe, mal mit, mal mit wenig Erfolg (Chinahandy, Android TV, Ebook-Reader).

Ich möchte vorab dennoch klarstellen, dass aus einem Stock-Android kein Hochsicherheits-Android vergleichbar einem GrapheneOS werden kann. Diese Anleitung richtet sich an Durchschnittsnutzer, die alltägliches Tracking reduzieren wollen. Die Sicherheit gegenüber Cyberangriffen wird durch die beschriebenen Methoden nicht wesentlich verbessert und wer diese Sicherheit in hohem Maß benötigt, sollte zu einem Gerät mit GrapheneOS greifen (3).

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 ist kein Root notwendig, der hier auch nicht verwendet werden soll. 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. Der schlimmste Fall wäre ein System zu "bricken", also unbenutzbar zu machen. 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, deaktiviert. 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 Starten 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 wird, auch alle Nutzerdaten und Nutzerapps gelöscht werden. Ich will außerdem klarstellen, dass ich keine Verantwortung übernehme, wenn jemand diesen Artikel 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.

1. 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. Wer die ADB noch nicht installiert und genutzt hat, findet hier (5), (6) gute Anleitungen.

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.

Neben der ADB sind auf dem Androidgerät die folgenden Apps notwendig oder zu empfehlen (teilweise gibt es Alternativen):

a. F-Droid Appstore, von f-droid.org, Berechtigung zur Installation von Apps erteilen

b. Von F-Droid wird installiert:

• RethinkDNS zur Überwachung des Datenverkehrs (alternativ personalDNSfilter, Blokada)
• 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

c. Von Aurora wird installiert:

• Permission Pilot zur Administration von App-Berechtigungen

d. Alternative, datenschutzfreundliche Nutzerapps

Da die nach Hause funkenden Nutzerapps von Google und Handyhersteller ersetzt werden sollen, können auch gleich alternative, datenschutzfreundliche Alternativen aus F-Droid, teilweise auch Aurora installiert werden. Hier eine subjektive Auswahl:

Browser und Suchleiste: Fennec-, Tor Browser; Tastatur: AnySoftKeyboard inkl. sprachspezifische Tastatur; SMS: Fossify; Start-App/Launcher: ADW-Launcher aus Aurora; File Manager: Amaze oder Fossify; Uhr: Fossify; Mail: K-9, Karten: Osmand; Videos & Musik: NewPipe; Medienplayer: VLC; Galerie: Fossify; Wetter inkl. Widget: Kleine Wettervorschau

Unter Einstellungen / Apps / Standard Apps werden nun anstatt der vorinstallierten Apps der Fennec Browser, die Fossify 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 (7), wie wieder D. J. Leith herausfand. Bei alternativen Dialerapps zuerst prüfen, ob sie auf dem Gerät funktionieren.

2. 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 die App Package Manager. Dessen Suchfunktion findet Apps unter allen ihren Bezeichnungen.

Nun schauen wir unter Einstellungen / Verbindungen / Datennutzung oder nach dessen Aktivierung unter RethinkDNS nach, welche Apps Daten versenden und deaktivieren, deinstallieren diese. Die ADB-Befehle für Deaktivieren / wieder Aktivieren sind:

adb shell pm disable-user <PACKAGE_NAME>  adb shell pm enable <PACKAGE_NAME>

„adb shell“ muss nur einmal ausgeführt werden, um die Shell zu starten. In der Shell reicht es, die Befehle mit „pm …“ zu beginnen. <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" gar nicht angezeigt wird oder ausgegraut, also blockiert ist. 

Deinstalliert werden Apps mit diesem Befehl: 

adb shell pm uninstall --user 0 <PACKAGE_NAME>

Ohne den Zusatz –user 0 könnte der Befehl Fehlermeldungen generieren. Mehr dazu weiter unten. Falls nach einer Deinstallation Probleme auftreten oder doch nützliche Funktionen verschwinden, kann die deinstallierte App mit diesem Befehl wieder zurückgeholt werden:

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 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.

Meine Debloatliste für Samsung, erprobt am Tablet SM-T225 ist unter Github veröffentlicht (8).

Sie sollte auch für andere, aktuelle Samsung Galaxies unter Android 12 bis 14 funktionieren. Bei moderneren Geräten als meinem Tablet sind aber zusätzliche Funktionen und damit Apps installiert. Somit sollte die Liste für diese erweitert werden.

Es gibt zwei Programme für den PC, die das Deaktivieren, Deinstallieren von Apps mittels ADB unterstützen, indem die ADB-Kommandozeile durch eine grafische Oberfläche ersetzt wird. Erfahrungen zu ihnen kann ich selbst noch nicht teilen. Nicht nur wer sich vor der Kommandozeile scheut, könnte Gefallen an ihnen finden (9), (10). 

3. Google Dienste

Die Gretchenfrage beim Säubern von Android ist, was mit den Google-Diensten geschehen soll. Die zusätzliche Bloatware des Herstellers, wie 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. Kern der Playdienste sind die Google-App, die die Suchleiste erzeugt, die Systemapp Google Play Dienste (GMS), die in den Einstellungen das Google Untermenü erzeugt und die 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 sind, wird jede Nutzung des Gerätes, jede installierte App und vieles mehr an Google gemeldet und wenn Nutzer mit einem Konto eingeloggt sind, diesem Nutzerkonto zugeordnet (schaut in Eurem Googlekonto nach, was dort unter Geräten an Daten gesammelt 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 Nutzerapps (z.B. Chrome, Youtube, Mail) auch. Es gibt datenschutzfreundlicheren Ersatz und ohne die Google-Dienste funktionieren sie nicht oder geben Fehlermeldungen von sich. 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. Einfrieren ist eine 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, verwende aber auch keine kostenpflichtigen Apps, die nur im Playstore zu kaufen sind, keine Bezahlfunktionen und keine Banking Apps mit Kontozugriff. TAN-Apps für Online-Banking funktionieren bei mir ohne Googledienste.

Abb. 2: Google Playdienste sind im Shelter Arbeitsprofil „eingefroren“

4. 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. Im Prinzip ist das Arbeitsprofil ein zweites Nutzerkonto, das über dieselbe Oberfläche erreichbar ist, wie das Hauptkonto. Apps aus beiden Konten können daher gleichzeitig geöffnet sein. Das Arbeitsprofil als Ganzes oder einzelne Apps davon lassen sich einfrieren. Apps in diesem Zustand erfassen und senden keine Daten. Nach dem Auftauen laufen sie wie zuvor weiter. Daten der Apps wie Logins bleiben also erhalten. Es ist möglich, den Standort nur im Hauptprofil, nicht aber im Arbeitsprofil freizugeben.

Das Arbeitsprofil ist im Stock-ROM des Geräteherstellers 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 spezifiziert 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 <n>" eingefügt werden, wobei <n> die Nummer des Nutzers ist. Das Hauptprofil hat üblicherweise die Nummer 0, das Arbeitsprofil häufig die Nummer 12. Dieser Befehl deinstalliert in diesem Fall z.B. den Google Play Store aus dem Arbeitsprofil: 

adb shell pm uninstall --user 12 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 im Hauptprofil nicht deinstallieren, obwohl sie auf manchen Debloatlisten auftauchen und zum Teil Daten versenden. 

Eine weitere Samsungspezialität ist, dass Arbeits- und Nutzerprofil hermetisch getrennt sind, so 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 z.B. per ADB möglich.

Wenn eine Firewall wie RethinkDNS aktiv sein soll, muss auch diese für jedes Nutzerkonto und das Arbeitsprofil getrennt installiert und eingerichtet werden. Unter Android 14 ist es immerhin möglich, in jedem Profil gleichzeitig eine VPN-App aktiv zu halten. Bei älteren Androidversionen hatte ich das Problem, nur eine VPN in einem Nutzerkonto pro Gerät aktivieren zu können.

5. Verbindungschecks und Assisted-GPS

Mike Kuketz hat in seiner Analyse der Custom ROMs auf den Datenverkehr von Assisted-GPS und Closed Portal Verbindungschecks hingewiesen. Letztere werden sogar am VPN vorbeigeführt und sind daher in VPN-basierten Firewall-Apps wie RethinkDNS nicht sichtbar (3). Für beides sind meistens Google-Server voreingestellt. A-GPS kann den Standort preisgeben. 

Tatsächlich konnte ich keine A-GPS Anfragen zu SUPL- und PSDS-Servern für mein Samsunggerät feststellen, auch nicht am VPN vorbei. Am VPN vorbeigehender Datenverkehr kann an einem guten Router, wie einer Fritzbox aufgezeichnet und mit Wireshark analysiert werden. Es treten aber Verbindungen auf zu einem A-GPS Dienst namens EPO von Mediatek, dem Prozessorhersteller. Von dort wird mindestens einmal wöchentlich eine Datei mit Satellitendaten heruntergeladen (11).  Vermutlich ist dieser A-GPS Dienst nur auf Geräten mit Mediatekprozessoren anzutreffen, wie dem Vorliegenden. Es ist nicht auszuschließen, dass wie beim Googledienst Standortdaten an Mediatek übertragen werden. Der Dienst kann blockiert werden, indem die Verbindungen zu Mediatek über die Firewall blockiert werden. Das Gerät benötigt dann nach Einschalten der Standortfunktion mehr als eine Minute um seinen Standort per GPS zu finden (WLAN-, Bluetooth Standortdienste abschalten), im Vergleich zu ca. einer Sekunde, wenn die Satellitendaten von Mediatek heruntergeladen werden können. Diese Zeit ist also ein sicherer Indikator, ob A-GPS aktiv ist.

Abb. 3: RethinkDNS zeigt die Verbindungen zum A-GPS Dienst EPO von Mediatek an.

Für die Closed Portal Verbindungsschecks können unter Android generell andere Server, als die meist voreingestellten Google-Server verwendet werden. Mike Kuketz betreibt hierfür einen eigenen Server. Er hat die Serveradressen und ADB Befehle veröffentlicht (12), um diesen einzustellen. Mit der App "Captive Portal Controller" aus F-Droid lässt sich diese Einstellung anzeigen und auch ohne ADB-Befehle ändern. Sie hat einen Preset für den Server von Mike Kuketz.

6. Ergebnis

Nach den beschriebenen Änderungen und Deinstallationen sind im Zeitraum einer Woche für das Samsunggerät noch die folgenden, von Systemapps ausgehenden Datenverbindungen zu verzeichnen (ohne Closed Portal Verbindungsschecks). Soweit bekannt ist der Zweck aufgeführt:

Samsung System- und Sicherheitsupdates:

• *.ospserver.net

Andere Verbindungen zu Samsung (Tracking):

• dc.dqa.samsung.com „Device quality agent”, prüft WLAN-Qualität
• poll.gras.samsungdm.com „DM“ Device Management oder Direct Messaging
• dir-apis.samsungdm.com
• gos-api.gos-gsp.io „Game optimizing service”
• euprod-knoxpp.samsungknox.com „Knox” Sicherheitsarchitektur

Google (Updates, Zeitserver, WebView):

• play.google.com Updates
• update.googleapis.com WebView
• clientservices.googleapis.com WebView
• time.android.com Zeitsynchronisation
• Mediatek (EPO assisted GPS)
• sfepodownload.mediatek.com
• sgepodownload.mediatek.com

Zeitsynchronisation

• *.pool.ntp.org

Diese Verbindungen dienen Software- und Sicherheitsupdates, der Zeitsynchronisation, Assisted GPS und zweifellos auch dem Tracking. Sie treten mit niedriger Frequenz auf, typisch ist insgesamt eine einstellige Anzahl an Verbindungen pro Tag. Da es sich nur um wenige Verbindungen handelt, lassen sie sich auf Wunsch gezielt mit einer Firewall, wie RethinkDNS blockieren. 

Erst beim Schreiben dieses Artikels habe ich herausgefunden, dass D. J. Leith et al für ihr Paper (2) eine Anlage veröffentlicht haben (13), in der sie detailliert auch für Samsung auflisten, welche Identifier in ihrer Analyse an welche Serveradresse übertragen wurden. Teils sind die oben gelisteten Samsungadressen dort aufgeführt. Dabei werden für die Adresse „ospserver.net“, über die Systemupdates eingespielt werden, folgende übertragene Identifier genannt:

IMEIs, Samsung Consumer ID, hardware serial number, mobile network cell ID/location

Es ist verständlich, dass Samsung zum Einspielen der passenden Softwareversion Hardware-Ids des Gerätes kennen muss. Nicht nachvollziehbar ist dagegen, dass dazu nicht nur der Gerätetyp, sondern auch einzigartige Gerätenummern, die Mobilfunkzelle und damit der ungefähre Standort übermittelt werden. Auch für die anderen aufgeführten Serveradressen von Samsung listen Leith et al vergleichbare eindeutige Identifier auf, die übertragen werden.

Es ist daher angeraten, alle verbleibenden Verbindungen zu Samsungadressen außer „ospserver.net“ in RethinkDNS zu blockieren. Für essentielle oder wünschenswerte Funktionen, wie Updates, Zeitsynchronisation und A-GPS kann eine Strategie sein, Verbindungen nur über WLAN zuzulassen und Verbindungen über Mobilfunk zu blockieren, um die Anzahl der übertragenen Standortdaten weiter zu reduzieren, da diese Funktionen keine pausenlose Internetanbindung benötigen. RethinkDNS bietet diese Option per App an, wenn auch nicht per Domainadresse. Beim vorliegenden Gerät kann für die App (-gruppen) „Dynamic System Updates“, „GPS“ und „WebView“ der Zugriff auf das Mobilfunknetz entzogen werden. Kritische Nutzer können auf einzelne Dienste ganz verzichten und sie komplett blockieren. Ein Verzicht auf Updates ist aber nicht zu empfehlen.

Abb. 4: RethinkDNS mit verbleibenden Verbindungen von Systemapps. Verbindungen für Updates, Zeitsynchronisation sind nur über WLAN erlaubt. Blockiert sind andere Verbindungen zu Samsung.

Ich hatte das Tablet SM-T225 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 dazukamen. 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.

Abb. 5: Systemstatus: Entwickleroptionen sind aktiviert. Softwareupdates werden eingespielt, solange Samsung sie bereitstellt. Google Play ist im Hauptprofil veraltet, da deinstalliert.

Gegenüber der von D. J. Leith beschriebenen Datenfrequenz und dem -volumen für iOS und Android Stock-ROMs im Auslieferungszustand (1), (2) wurde eine Reduktion der an Google und Samsung übertragenen Datenmenge um ca. den Faktor 100 erreicht, von vielen hundert Datenverbindungen pro Tag auf eine ungefähr einstellige Zahl. Nicht verhindert werden kann allerdings ohne Root, dass mit Anfragen für Software- und Sicherheitsupdates eindeutige Geräte-Ids und der ungefähre Standort des Gerätes an Samsung übertragen wird. Zu Bedenken ist dabei, dass mit jeder Internetverbindung auch ohne übertragene Identifier alleine über die IP-Adresse der ungefähre Standort preisgegeben wird. Kompromisse in Bezug auf die Sicherheit, wie offene Bootloader oder keine, verspätete Sicherheitsupdates mussten nicht eingegangen werden. Zumindest in Bezug auf die Quantität des Trackings liegt das umgebaute Samsung-Tablet damit nahe an besseren Custom-ROMs, ist aber natürlich nicht gleichwertig zu den besten, wie GrapheneOS.

Ich rate daher weiterhin zu sicheren, datensparsamen Custom-ROMs als erste Wahl für ein datenschutzfreundliches Gerät, wann immer das möglich ist, schon weil es deutlich weniger Arbeit und weniger Kontrolle erfordert, einmalig ein Custom-ROM aufzuspielen, als ein Stock-ROM wie beschrieben zu säubern und sauber zu halten. Wenn diese für ein Gerät nicht verfügbar sind, ist die beschriebene Methode aber eine gute Alternative und die einzige, die ohne Rootzugriff auskommt.

Literatur:

(1) Leith, 2021: https://www.scss.tcd.ie/doug.leith/apple_google.pdf
(2) Leith et al, 2021: https://www.scss.tcd.ie/Doug.Leith/Android_privacy_report.pdf
(3) https://www.kuketz-blog.de/android-grapheneos-calyxos-und-co-unter-der-lupe-custom-roms-teil1/
(4) https://www.kuketz-forum.de/t/datenschutzfreundliches-stock-android-mit-der-android-debug-bridge-adb-fuer-samsung-stock-rom-und-andere-plattformen/7843
(5) https://www.giga.de/apps/android/tipps/adb-installieren-die-android-debug-bridge-zum-laufen-bringen/
(6) https://developer.android.com/tools/adb?hl=de
(7) Leith, 2022: https://www.scss.tcd.ie/doug.leith/privacyofdialerandsmsapps.pdf
(8) https://gist.github.com/Maetih/2718d0e0a23940d8cb0e6a9235adddd8
(9) https://adbappcontrol.com/en/
(10) https://github.com/0x192/universal-android-debloater siehe auch: https://gnulinux.ch/google-apps-und-weitere-bloatware-loswerden-mit-dem-universal-android-debloater-next-generation
(11) https://www.locosystech.com/en/page/EPO-+install+guide.html
(12) https://www.kuketz-blog.de/empfehlungsecke/#captive-portal
(13) Leith et al, 2021: https://www.scss.tcd.ie/doug.leith/pubs/additional_material_neversleepingears.pdf

Dieser Artikel ist Teil einer Artikelserie

Teil 1: Samsung Phablet
Teil 2: Berechtigungen und Sensoren