iodéOS: Datenschutzfreundlich, aber Abstriche bei der Sicherheit – Custom-ROMs Teil3

1. Auf dem Prüfstand

In der Artikelserie »Custom-ROMs« möchte ich einige alternative Android-Systeme näher beleuchten. Der Schwerpunkt wird in der Analyse des Datensendeverhaltens liegen. Es wird geprüft, wohin die Custom-ROMs Verbindungen aufbauen und welche Daten dabei übermittelt werden. Die Ergebnisse sollen Aufschluss darüber geben, wie datenschutzfreundlich ein Custom-ROM in der Standardkonfiguration ist und Tipps ableiten, wie sich das »Nach-Hause-Telefonieren« einschränken oder sogar vollständig abschalten lässt.

Im vorliegenden Beitrag wird iodéOS einer Analyse unterzogen. Das Custom-ROM wird wie folgt beworben:

iodéOS ist ein auf Android basierendes Betriebssystem, welches von Googles Datensammelwut befreit wurde. […]

Wird iodéOS dem gerecht? Nachfolgend werfen wir einen Blick in das Datensendeverhalten des Systems.

• Android: GrapheneOS, CalyxOS und Co. unter der Lupe – Custom-ROMs Teil1
• CalyxOS: De-Googled geht anders – Custom-ROMs Teil2
• iodéOS: Datenschutzfreundlich, aber Abstriche bei der Sicherheit – Custom-ROMs Teil3
• LineageOS: Weder sicher noch datenschutzfreundlich – Custom-ROMs Teil4
• DivestOS: Datenschutzfreundlich und erhöhte Sicherheit – Custom-ROMs Teil5
• /e/: Datenschutzfreundlich bedeutet nicht zwangsläufig sicher – Custom-ROMs Teil6
• GrapheneOS: Der Goldstandard unter den Android-ROMs – Custom-ROMs Teil7

2. iodéOS

iodéOS ist ein Android-basiertes mobiles Betriebssystem, das von der französischen Firma iodé entwickelt wird. Das Betriebssystem ist ein Fork von LineageOS und enthält keine Google-Play-Dienste, sondern verwendet microG als freien und quelloffenen Ersatz. Das Betriebssystem ist für zahlreiche Geräte verfügbar, wie das Fairphone (FP3, FP3+ und FP4), Samsung (S9, S10 etc.) und Google (Pixel 3, Pixel 4, Pixel 6a etc.). Allerdings sollte man bei einigen Geräten keine vollständigen Sicherheitsupdates von proprietären Komponenten wie Bootloader oder Firmware erwarten. So werden bspw. Geräte wie das Google Pixel 3 nicht mehr mit entsprechenden Updates vom Hersteller versorgt. iodéOS richtet sich vermutlich hauptsächlich an Anwender, deren Fokus eher auf Datenschutz als auf Sicherheit liegt.

Sowohl die Installation als auch die initiale Inbetriebnahme ist relativ einfach gestaltet, um möglichst vielen Nutzern den Umstieg auf das System zu ermöglichen. Dem Nutzer steht es frei, entweder auf Google Play-Dienste zu verzichten oder diese durch die quelloffene Alternative microG zu ersetzen.

Interessierte können sich vorab über iodéOS in den FAQs informieren und im iodéOS-Forum Hilfe erhalten. Leider gibt es keine Übersicht darüber, welche Netzwerkverbindungen das System und die mitgelieferten Apps initiieren. Es ist nirgendwo dokumentiert. Nachfolgend werden wir dies nun ändern.

2.1 Verwendetes Setup

Während der erstmaligen Einrichtung von iodéOS können Push-Benachrichtigungen und Standortermittlung über die Alternative zu Google-Play-Diensten namens microG aktiviert werden. Unabhängig von eurer Entscheidung bei der Einrichtung wird microG installiert, und die Einstellungen können jederzeit während des Betriebs angepasst werden:

In meinem Testsetup wird microG einmal nicht aktiviert und nach einem Reset des Geräts dann aktiviert. Es werden also beide Szenarien beleuchtet: microG aktiv bzw. nicht aktiv.

Während der mehrwöchigen Testphase kamen folgende iodéOS-Versionen zum Einsatz:

• Google Pixel 6a (bluejay): 4.0-20230216-bluejay (16. Februar 2023)
• Google Pixel 6a (bluejay): 4.1-20230327-bluejay (02. April 2023)

2.2 Privates DNS

Standardmäßig ist die Option »Privates DNS« auf Automatisch eingestellt. Über Einstellungen -> Netzwerk & Internet -> Privates DNS wird die Einstellung auf Aus gestellt. DNS-Anfragen sollen meinen (Test-)Router erreichen bzw. für diesen lesbar sein und nicht über DNS over TLS getunnelt werden.

3. Datensendeverhalten: Start – Anmeldung – Updates

Sowohl die Voraussetzungen an die System-Umgebung, als auch die (Netzwerk-)Tools, mit denen die Datenmitschnitte erfolgen, sind im ersten Teil der Artikelserie beschrieben. Nachfolgend werden unterschiedliche (Anwendungs-)Szenarien beleuchtet. Was passiert bspw. beim Geräte-Start? Welche Verbindungen werden bei der Aktivierung der GPS-Schnittstelle initiiert? Und welche Daten übermittelt der Standard-Browser nach dem Aufruf?

Das Kommunikationsverhalten unterscheidet sich, sofern sich der Nutzer bei der Inbetriebnahme für die Installation von microG entscheidet. Nachfolgend wird dies mit dem Zusatz [mit microG] in der Überschrift unterschieden.

3.1 Start/Neustart

Noch während des Boot-Vorgangs bzw. sobald ein Netzwerkinterface (WiFi, Mobile) verfügbar ist, werden folgende (DNS-)Namensauflösungen initiiert:

• 1.android.pool.ntp.org
• captiveportal.kuketz.de

Nach der Auflösung der Domainnamen in die zugehörige IP-Adresse startet das System eine Aktualisierung der (Netzwerk-)Zeit via NTP zum Server 1.android.pool.ntp.org. Unmittelbar danach erfolgt ein Connectivity- bzw. Captive-Portal-Check, um sicherzustellen, dass ein Gerät vom Access-Point bzw. Internet Service Provider nicht nur eine IP-Adresse erhalten hat, sondern tatsächlich auch Ziele im Internet erreichen kann. Zur Prüfung, ob eine Verbindung besteht, sendet iodéOS eine Anfrage an die Adresse captiveportal.kuketz.de. Die Überprüfung der Konnektivität erfolgt durch folgende GET-Anfrage:

GET http(s)://captiveportal.kuketz.de

User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.32 Safari/537.36
Host: captiveportal.kuketz.de 
Connection: Close
Accept-Encoding: gzip
Content-Length: 0

Als Antwort erfolgt dann ein 204er-Statuscode:

Response Version: HTTP/1.1
Status Code: 204
Connection: Close
Content-Length: 0

Aufmerksame Leser dürften bemerkt haben, dass es sich bei einer Gegenstelle des Captive-Portal-Checks um einen Dienst handelt, den ich unter der Adresse captiveportal.kuketz.de anbiete. Dazu ein Auszug aus meinen Datenschutzhinweisen:

Unter der Adresse captiveportal.kuketz.de wird ein Connectivity-Check für Android-Smartphones angeboten. Wer die Seite aufruft, erhält folgende Rückmeldung:

HTTP/1.1 204 No Content

Die Nutzung des Dienstes ist freiwillig. Eine Datenerhebung in irgendeiner Form erfolgt nicht. Nach der Beantwortung der Anfrage durch den nginx-Webserver werden alle Informationen wie die IP-Adresse sofort verworfen und in keinem Logfile gespeichert.

Natürlich freut es mich, wenn anstelle des Standard Captive-Portal-Checks von Google (connectivitycheck.gstatic.com) eine datenschutzfreundliche Alternative verwendet wird.

Der Vollständigkeit wegen: Beim ersten Start/Anmeldung des Geräts tauchte im Datenmitschnitt ebenfalls die Domain remoteprovisioning.googleapis.com auf. Diese Gegenstelle dient der Erneuerung der Zertifikatsketten, die für die hardwarebasierte Beglaubigung als Teil der Hardware-Keystore-API – Remote Provisioning genannt – benötigt werden. Details dazu siehe »CalyxOS: De-Googled geht anders – Custom-ROMs Teil2« Ziffer 3.2 »Nach Anmeldung am System«. Diese Verbindung trat nur einmalig auf und konnte von mir inhaltlich leider nicht erfasst werden, da die Schritte zum Mitschnitt TLS-verschlüsselter Verbindungen zu diesem Zeitpunkt noch nicht erfolgt sind.

3.2 Geräte-Updates

iodéOS prüft regelmäßig (bspw. nach einem Geräte-Neustart), ob neue System-Updates zur Verfügung stehen. Der Update-Check erfolgt über die Adresse gitlab.com:

GET https://gitlab.com/iode/ota/-/raw/los-20/bluejay.json

User-Agent: Dalvik/2.1.0 (Linux; U; Android 13; Pixel 6a Build/TQ1A.230205.002)
Host: gitlab.com
Connection: Keep-Alive
Accept-Encoding: gzip

Als Antwort erfolgt dann (hier im Beispiel Update auf iodéOS 4.1):

{  
   "response": [    
      {      
         "datetime": 1679913441,      
         "filename": "iode-4.1-20230401-bluejay.zip",      
         "id": "f9424cbe45736de13b5b7e05e370b1cadc2c1f6340096fcd612dbedeb254ed4d",      
         "romtype": "UNOFFICIAL",      
         "size": 1279075598,      
         "url": "https://github.com/iodeOS/ota/releases/download/v4-bluejay/iode-4.1-20230401-bluejay.zip",      
         "version": "4.1"    
      }  
   ]
}

Darin sind Informationen des neuen Builds bzw. inkrementellen Updates enthalten:

• Dateiname: iode-4.1-20230401-bluejay.zip
• Bezugsquelle: https://github.com/iodeOS/ota/releases/download/v4-bluejay/iode-4.1-20230401-bluejay.zip
• Version: 4.1
• […]

Sofern ein Update bereitsteht, wird der Download nicht automatisch initiiert, sondern der Nutzer muss dies mit einem Tipp auf HERUNTERLADEN auslösen:

GET https://140.82.121.4/iodeOS/ota/releases/download/v4-bluejay/iode-4.1-20230401-bluejay.zip

User-Agent: Dalvik/2.1.0 (Linux; U; Android 13; Pixel 6a Build/TQ1A.230205.002)
Host: github.com
Connection: Keep-Alive
Accept-Encoding: gzip

Fassen wir zusammen: Die Prüfung auf Updates und auch die anschließende Benachrichtigung erfolgt automatisch. Das Herunterladen und auch die Installation der neuen Version muss allerdings vom Nutzer initiiert werden. Bei Systemen wie GrapheneOS oder CalyxOS erfolgt dies alles automatisch, was ich in Bezug auf Sicherheit als vorteilhaft(er) empfinde.

Update-Informationen werden übrigens direkt bei GitLab geladen, das wiederum das Content Delivery Network Cloudflare einsetzt. Die Adresse bzw. Gegenstelle gitlab.com löst direkt zu Cloudflare auf.

3.3 Aktivierung SIM-Karte

Bei der (ersten) Inbetriebnahme der SIM-Karte initiiert die App Carrier Settings eine Verbindung zu Google Firebase – eine Entwicklungsplattform für mobile Anwendungen:

POST /v1/projects/wfcactivation-e5dd9/installations HTTP/1.1
Content-Type: application/json
Accept: application/json
Cache-Control: no-cache
X-Android-Package: com.google.android.wfcactivation
x-firebase-client: H4sIAAAAAAAAANWQwW7DIAyGX6XyOYQAh0p9lVFVTnAyNgIVsEpT1Xef06SdtNOknSZOfOa3zXeFV8Jce8Ja4PByBZwoVjgARpeTd8LHUjEEylbuRp9JbAUrjVmBXy5atXx2ji5-IDEnR8HKPnzQG35uz9ZGWH2KxUq1b7tWn9T5kYk403dkg33mcVZOKU2B1j5DyvxOc7hVS_wOx2FmZniHe8vH8mceN6bMtSeafRTFvfP63ZNVzBPVDRtowGGlRQfoThuhlNAGjrfmr3Z-5eGHu39hZ892jg1cKBf-FfvRcPsCP8NID1oCAAA
X-Android-Cert: 9CE4288D89DD444CCD8FE66AD9427684C237BC7D
x-goog-api-key: AIzaSyD2206BSXtXkmK5QsMfbwGGAvjRglv3coU
User-Agent: Dalvik/2.1.0 (Linux; U; Android 13; Pixel 6a Build/TQ3A.230901.001)
Host: firebaseinstallations.googleapis.com
Connection: close
Accept-Encoding: gzip, deflate
Content-Length: 132

{
   "fid":"fm-euxJxTMCCwP88fDelOQ",
   "appId":"1:202982214007:android:05963fd1185dfcea",
   "authVersion":"FIS_v2",
   "sdkVersion":"a:17.0.2_1p"
}

Die Anwendung Carrier Settings führt einige Systemeinstellungen für das Modem und den Netzbetreiber durch, darunter auch APN-Einstellungen. Mir bleibt jedoch unklar, weshalb dazu eine Verbindung zu firebaseinstallations.googleapis.com notwendig ist, um diese Einstellungen vorzunehmen. Offenbar ist dieser ganze Vorgang nicht notwendig, denn Projekte wie DivestOS, CalyxOS und GrapheneOS entfernen die Carrier-Settings-App (und mehr) aus dem System.

4. Datensendeverhalten: Im Betrieb

4.1 24 Stunden Mitschnitt

Das Smartphone wird innerhalb eines 24-Stunden-Zeitraums nicht benutzt. Stattdessen wird geprüft, welche Verbindungen das (Standard-)System innerhalb von 24 Stunden initiiert hat.

In einem 30-Minuten-Takt werden die neuesten Wetterdaten via Geometric-Weather-App bei api.accuweather.com abgefragt. Solch eine Aktualisierung besteht aus insgesamt 24-Datenpaketen, von denen hier ein Ausschnitt zu sehen ist:

GET https://api.accuweather.com/forecasts/v1/hourly/24hour/167218.json?apikey=srRLeAmTroxPinDG8Aus3Ikl6tLGJd94&language=de&metric=true&details=true

Die Zahlenfolge 167218 (Karlsruhe) steht stellvertretend für den Ort/Stadt, für den die Wetterabfrage erfolgt und kann ebenfalls über den Browser bei AccuWeather abgerufen werden.

Antwort (Ausschnitt):

[...]
"RainProbability": 0,        
"RealFeelTemperature": {            
   "Phrase": "Frostig",            
   "Unit": "C",            
   "UnitType": 17,            
   "Value": 3.9        
},       
"RealFeelTemperatureShade": {            
   "Phrase": "kalt",            
   "Unit": "C",            
   "UnitType": 17,            
   "Value": 1.9        
},        
"RelativeHumidity": 61,        
"Snow": {            
   "Unit": "cm",            
   "UnitType": 4,            
   "Value": 0.0        
},        
"SnowProbability": 0,        
   "SolarIrradiance": {            
   "Unit": "W/m²",            
   "UnitType": 33,            
   "Value": 625.5        
},        
"Temperature": {            
   "Unit": "C",            
   "UnitType": 17,            
   "Value": 6.8        
},

Abgesehen von der permanenten Abfrage der aktuellen Wetterdaten ist das System relativ ruhig. Neben Updates-Checks (gitlab.com) wurde zweimal versucht, die (Netzwerk-)Zeit via NTP zu aktualisieren. Ansonsten wurden keine weiteren Verbindungen vom System initiiert. Das ändert sich natürlich dann, wenn der Nutzer weitere Apps installiert und diese bspw. mittels Polling/Push Daten abfragen bzw. erhalten.

4.2 24 Stunden Mitschnitt [mit microG]

Sofern der Nutzer microG aktiviert, ist das System gleich etwas gesprächiger – was natürlich nicht ungewöhnlich ist, denn microG ist eine (nicht vollständige) Nachbildung der Google-Play-Dienste. Im Gegensatz zu den Google-Play-Diensten verfolgt microG die Nutzeraktivitäten auf dem Gerät zumindest nicht. Weiterhin können Nutzer teilweise selbst bestimmen, welche API-Funktionen (Google Cloud Messaging, SafetyNet, das Exposure Notification Framework) sie nutzen möchten.

In der Standardkonfiguration von microG nimmt das System regelmäßig Kontakt zu Google auf, um über diesen Kanal Push-Notifications (von Apps) zu empfangen. Das erfolgt über eine TCP-Verbindung zur Gegenstelle mtalk.google.com (173.194.76.188:5228) – einem Server von Google. Ein solcher TCP-Stream sieht ein- und ausgehend (zu Google) wie folgt aus:

Anfrage:

)

Antwort:

02

Anfrage:

8b

Antwort:

\x01
android-33\x12\x0fmcs.android.com\x1a\x134348609616008786336"\x134348609616008786336*\x11593639880221464842\x18android-3c595d67e50d31a0B\x0b\x06new_vc\x12\x011`\x00p\x01\x80\x01\x02\x88\x01\x01

Anfrage:

)

Antwort:

\x036
android-33\x12\x1fuser@firebase.com/notifications0\x01@\x8b\x9b\x8e\xd9\xf40

Auch wenn noch keine Apps für den Erhalt von Push-Notifications registriert sind, erfolgt eine dauerhafte Aktualisierung der Verbindung zu mtalk.google.com.

4.3 Aktivierung Netzwerkschnittstelle

Bereits während des Boot-Vorgangs wird ein Captive-Portal-Check durchgeführt, sofern ein Netzwerkinterface (WiFi, Mobile) aktiv ist. Wird das Gerät in der Zwischenzeit in den Flugmodus versetzt und danach wieder eine Netzwerkschnittstelle aktiviert, wird erneut ein Captive-Portal-Check initiiert. Das bedeutet erneut ein Verbindungsaufbau zu captiveportal.kuketz.de. Das ist allerdings nicht der einzige Check. Sobald der Nutzer den mitgelieferten iodé Browser (siehe Ziffer 4.4) einmal startet bzw. dieser aktiv/im Hintergrund ist, wird ein weiterer Captive-Portal-Check bei Änderung der Netzwerkkonnektivität initiiert. Per GET-Anfrage wird die Gegenstelle detectportal.firefox.com kontaktiert:

GET /success.txt?ipv4 HTTP/1.1
Host: detectportal.firefox.com
User-Agent: Mozilla/5.0 (Android 13; Mobile; rv:109.0) Gecko/109.0 Firefox/109.0
Accept: */*
Accept-Language: de-DE
Accept-Encoding: gzip, deflate
Connection: close
Pragma: no-cache
Cache-Control: no-cache

Als Rückmeldung erhält der Browser ein HTTP-200 inkl. success-Meldung.

Was dabei auffällt: Die Verbindungen werden nicht durch das VPN getunnelt, sondern werden einfach daran vorbeigeführt. Das hat mich stutzig gemacht, denn selbst wenn bei der VPN-Verbindung die Option Verbindungen ohne VPN blockieren aktiv ist, werden die Captive-Portal-Checks einfach am VPN vorbeigetunnelt. Android leakt also Traffic, was nicht nur die VPN-Option infrage stellt, sondern ein echtes Problem hinsichtlich der Privatsphäre sein kann. Wenn einfach Daten an einem VPN-Tunnel vorbeigeschleust werden können, dann ist die Implementierung fragwürdig.

Das Problem scheint übrigens nicht neu zu sein. Mullvad VPN hatte darüber bereits im Oktober 2022 berichtet: Android leaks connectivity check traffic. Offenbar wird Google an diesem Verhalten allerdings nichts ändern. Ein dazu eingereichtes Issue hat den Status »Won’t Fix« (Intended Behavior). Begründet wird das wie folgt:

We have looked into the feature request you have reported and would like to inform you that this is working as intended. We do not think such an option would be understandable by most users, so we don’t think there is a strong case for offering this.
As for disabling connectivity checks :

• the VPN might be actually relying on the result of these connectivity checks (they are available through public APIs).
• the VPN may be a split tunnel, letting part of the traffic over the underlying network, or only affect a given set of apps. In both these cases, the connectivity checks are still necessary for smooth operation of all the legitimate traffic that doesn’t go over the VPN.
• the connectivity checks are far from the only thing exempted from the VPN ; privileged apps can also bypass the VPN and this is necessary for their operation in many cases. An example is IWLAN, or tethering traffic.
• it’s unclear to us what specific privacy impact is meant. The connectivity checks reveal there is an Android device at this address, which is plenty clear from the L2 connection and from the traffic going over the VPN anyway.

Ich zitiere mal eine entscheidende Stelle:

We do not think such an option would be understandable by most users, […]

Einverstanden. Aber wenn jemand aktiv die Option Verbindungen ohne VPN blockieren aktiviert, dann erwartet er genau das – mit all seinen Konsequenzen. So sehe ich das jedenfalls. Die Connectivity-Checks am VPN vorbei sind technisch zwar nachvollziehbar, aber dann sollte das verständlicher erklärt werden. Das Setzen der Option Verbindungen ohne VPN blockieren ist in meinen Augen irreführend. Dazu kommt ja auch noch:

the connectivity checks are far from the only thing exempted from the VPN ; privileged apps can also bypass the VPN and this is necessary for their operation in many cases. An example is IWLAN, or tethering traffic.

Merke: Man kann sich nie sicher sein, welche System-Apps bzw. Datenverbindungen am VPN vorbeigeschleust werden.

4.4 Browser: Firefox/iodé Browser

Der mitgelieferte Browser ist ein Firefox-Fork, der sich iodé Browser nennt und wie folgt angepasst wurde:

Der iodé browser basiert auf Firefox mit abgeschalteter Telemetrie, entfernten Trackern und alternativen Suchmaschinen: Qwant (Standard), Brave, Ecosia, Metager, Qwant light, Startpage und mehreren Searx Instanzen.

Unmittelbar nach dem ersten/initialen Start werden folgenden Verbindungen initiiert:

• contile.services.mozilla.com
• firefox.settings.services.mozilla.com
• detectportal.firefox.com

Was hierbei genau übermittelt wird, kann ich leider erst einmal nicht einsehen, da Firefox/iodé Browser das ausgerollte CA-Zertifikat von mitmproxy (Systemzertifikate) standardmäßig ignoriert, weil intern ein eigener Zertifikatsspeicher verwendet wird. Damit das Mitlesen des TLS-Verkehrs gelingt, muss man die Firefox Entwickleroptionen wie folgt aktivieren: Über Einstellungen bei »About iodé Browser/Über iodé Browser« siebenmal auf das iodé-Browser-Logo tippen. Danach geht es wieder eine Ebene zurück und unter Secret Settings muss der Schieberegler bei Use third party CA certificates aktiviert werden.

Der Verbindungsaufbau zu »contile.services.mozilla.com« triggert das Nachladen von zwei gesponserten Favicons: Amazon und Adidas. Diese können wie folgt entfernt werden:

• Längerer Fingertipp auf Amazon/Adidas
• Einstellungen wählen
• Das Häkchen bei »Gesponserte Verknüpfungen« entfernen

Sobald man beginnt, den Browser aktiv zu nutzen, werden dann weitere Verbindungen initiiert:

• shavar.services.mozilla.com
• tracking-protection.cdn.mozilla.net
• firefox.settings.services.mozilla.com
• content-signature-2.cdn.mozilla.net
• safebrowsing.googleapis.com

Im vorliegenden Artikel werde ich nicht auf jede einzelne Datenverbindung eingehen, sondern verweise auf den Beitrag »Mozilla Firefox: Datensendeverhalten Desktop-Version – Browser-Check Teil20«. Dort könnt ihr euch über die oben genannten Verbindungen informieren. Weitere Hinweise zu der Verbindung sind auch hier zusammengefasst: Firefox baut unaufgefordert Verbindungen auf (Mozilla). Zitat zu »firefox.settings.services.mozilla.com«:

Um die jeweils aktuellen Informationen über bekannte Datenlecks bei Zugangsdaten von Online-Konten und andere Datenlecks zu erhalten, verbindet sich Firefox mit firefox.settings.services.mozilla.com

Die Verbindung zu Google nehmen wir nachfolgend etwas genauer unter die Lupe:

GET https://safebrowsing.googleapis.com/v4/threatListUpdates:fetch?$ct=application/x-protobuf&key=AIzaSyC7jsptDS3am4tPx4r3nxis7IMjBc5Dovo&$httpMethod=POST&$req=ChUKE25hdmNsaWVudC1hdXRvLWZmb3gaCggFEAI iAiACKAEaCggBEAMiAiACKAEaCggDEAMiAiACKAE= HTTP/2.0

user-agent: Mozilla/5.0 (Android 13; Mobile; rv:109.0) Gecko/109.0 Firefox/109.0
accept: */*
accept-language: de-DE
accept-encoding: gzip, deflate, br
x-http-method-override: POST
sec-fetch-dest: empty
sec-fetch-mode: no-cors
sec-fetch-site:  none
pragma: no-cache
cache-control: no-cache
te: trailers

Um den Nutzer vor schädlichen Domains bzw. Schadsoftware(-Downloads) zu schützen, lädt Firefox/iodé Browser in regelmäßigen Abständen eine Blockliste bei Google. Die Schutzfunktion basiert auf Google Safe Browsing und ist unter anderem auch in Chrome/Chromium anzutreffen. Eine Überprüfung auf schädliche Domains erfolgt zunächst lokal auf dem Gerät des Anwenders. Bei einem Treffer sendet der Browser einen Hash der aufgerufenen Seite (URL) an Google, um zu prüfen, ob die Seite seit der letzten Aktualisierung von der Liste entfernt worden ist oder blockiert werden sollte. Diese Anfrage enthält nicht die vollständige Adresse der besuchten Seite, sondern nur Teildaten, die aus der Adresse generiert wurden.

Wie bereits unter Ziffer »4.3 Aktivierung Netzwerkschnittstelle« dargestellt, kontaktiert der Browser beim Wechsel der Netzwerkkonnektivität die Gegenstelle detectportal.firefox.com. Insgesamt zeigt der Browser ein reges Datensendeverhalten – da besteht möglicherweise noch Optimierungsbedarf.

Was unabhängig des Datensendeverhaltens auffällt: (Sicherheits-)Update für den Browser werden über F-Droid ausgerollt. Leider gibt es Verzögerungen bei der Bereitstellung dieser Updates. Das Update auf die Firefox-Version 110.0 wurde Mitte März ausgerollt. Bei Version 111.0 ging es dann etwas schneller, diese erschien am 21. März. Insgesamt ist diese Situation nicht ideal, da wichtige Sicherheitsupdates zeitnah bereitgestellt werden sollten.

4.5 (GPS-)Standort

Der Standort eines Smartphones kann auf verschiedene Arten ermittelt werden. Die wohl wichtigsten Hilfsmittel dafür sind GPS/GLONASS, WiFi und das Mobilfunk-Netzwerk. Im Falle von GPS ermittelt das Gerät selbst seine Position durch Kommunikation mit Satelliten. Da die Bestimmung des Standorts via GPS vergleichsweise lang dauert, wird zusätzlich Assisted GPS (abgekürzt als A-GPS) eingesetzt. A-GPS ist ein System, das die Zeit bis zum ersten Fixieren eines satellitengestützten Positionierungssystems (GPS) meist deutlich verbessert – die GPS-Positionsbestimmung wird also beschleunigt. Wie funktioniert das? Bei Mobiltelefonen ist anhand der Funkzelle, in der euer Gerät eingebucht ist, der ungefähre Aufenthaltsort bereits bekannt. Via Secure-User-Plane-Location-Protokoll (SUPL) wird nun dieser ungefähre Standort an einen SUPL-Server gesendet, der anhand dieser Informationen den Suchbereich für die Satellitensignale einschränkt und somit eine schnelle GPS-Positionsbestimmung ermöglicht. Die Kommunikation mit dem SUPL-Server erfolgt via TCP/IP über das UserPlane Location Protocol.

Solch einen SUPL-Server nutzen Android-Systeme, um die Ortungszeit für GNSS (GPS, GLONASS usw.) erheblich zu beschleunigen. Bei iodéOS wird hierbei die Gegenstelle supl.vodafone.com über Port 7275 kontaktiert. Die Adresse ist allerdings lediglich ein CNAME und verweist wiederum auf supl.google.com. Anbei der gekürzte Datenmitschnitt:

Internet Protocol Version 4, Src: 10.215.173.1, Dst: 74.125.133.192
Transmission Control Protocol, Src Port: 59418, Dst Port: 7275, Seq: 1, Ack: 1, Len: 83

[...]

OMA UserPlane Location Protocol
    ULP-PDU
        length: 83
        version
            maj: 2
            min: 0
            servind: 0
        sessionID
            setSessionID
                sessionId: 2
                setId: nai (4)
                    nai: suplsetid@broadcom.com                       
        message: msSUPLSTART (1)
            msSUPLSTART
                sETCapabilities
                    posTechnology
                        ..1. .... agpsSETassisted: True
                        ...1 .... agpsSETBased: True
                        .... 1... autonomousGPS: True
                        .... .0.. aflt: False
                        .... ..1. ecid: True
                        .... ...0 eotd: False
                        1... .... otdoa: False
                        ver2-PosTechnology-extension
                            gANSSPositionMethods: 5 items
                                Item 0
                                    GANSSPositionMethod
                                        ganssId: Galileo (0)
                                        gANSSPositioningMethodTypes
                                            .... ..1. setAssisted: False
                                            .... ...1 setBased: True
                                            1... .... autonomous: True
                                        gANSSSignals: 80 [bit length 1, 7 LSB pad bits, 1... .... decimal value 1]
                                            1... .... = signal1: True
                                            .0.. .... = signal2: False
                                            ..0. .... = signal3: False
                                            ...0 .... = signal4: False
                                            .... 0... = signal5: False
                                            .... .0.. = signal6: False
                                            .... ..0. = signal7: False
                                            .... ...0 = signal8: False

[...]                    
                   
                locationId
                    cellInfo: ver2-CellInfo-extension (3)
                        ver2-CellInfo-extension: lteCell (2)
                            lteCell
                                cellGlobalIdEUTRA
                                    plmn-Identity
                                        mcc: 3 items
                                            Item 0
                                                MCC-MNC-Digit: 2
                                            Item 1
                                                MCC-MNC-Digit: 6
                                            Item 2
                                                MCC-MNC-Digit: 2
                                        mnc: 2 items
                                            Item 0
                                                MCC-MNC-Digit: 0
                                            Item 1
                                                MCC-MNC-Digit: 2
                                    cellIdentity: 11904140 [bit length 28, 4 LSB pad bits, 0001 0001  1001 0000  0100 0001  0100 .... decimal value 18416660]
                                physCellId: 280
                                trackingAreaCode: b876 [bit length 16, 1011 1000  0111 0110 decimal value 47222]
                    status: current (1)
                qoP
                    horacc: 51,159090m (19)
                    maxLocAge: 1s

Anders als bei CalyxOS festgestellt, übermittelt iodéOS nicht die personenbeziehbare IMSI-Nummer an den SUPL-Server – ein entsprechender Patch (IMSI removal patch for SUPL) verhindert das. Dennoch wird Google mit ungefähren Standortdaten beliefert, die unter anderem mit der IP-Adresse verknüpft werden können. Um dies zu verhindern, hat bspw. das Custom-ROM GrapheneOS einen SUPL-Proxy-Server aufgesetzt (supl.grapheneos.org), der alle SUPL-Anfragen stellvertretend entgegennimmt bzw. weiterleitet. Das Resultat: Google kann die Anfrage zur Standortermittlung keinem Nutzer/Gerät zuordnen. Fairerweise muss ich allerdings erwähnen, dass GrapheneOS diesen SUPL-Proxy-Server als Reaktion auf meine Analyse zu CalyxOS betreibt. Das Team unter der Leitung von Daniel Micay hat umgehend auf meine kritischen Ergebnisse zu CalyxOS reagiert und eine Lösung für das Google-SUPL-Problem gefunden.

Hinweis: Die Verbindung zum SUPL-Server ist eigentlich TLS-verschlüsselt. Nach einer Anpassung der Datei /system/vendor/gnss/gps.xml erfolgt der Verbindungsaufbau dann unverschlüsselt und konnte mitgelesen werden:

tlsEnable="false"

Zur Beschleunigung der Standortbestimmung nutzt iodéOS neben SUPL zusätzlich PSDS-Hilfsdaten. PSDS steht für Predicted Satellite Data Service, der Informationen über die Umlaufbahnen, den Status der Satelliten, Daten über die Umweltbedingungen auf der Erde und Informationen zur Zeitanpassung liefert. Die statischen PSDS-Daten bezieht iodéOS von der Gegenstelle »gllto.glpals.com« (Broadcom):

• https://gllto.glpals.com/rto/v1/latest/rto.dat
• https://gllto.glpals.com/7day/v5/latest/lto2.dat
• https://gllto.glpals.com/rtistatus4.dat

Außer der IP-Adresse werden bei der Abfrage der sogenannten Almanache keine Informationen übermittelt. Es handelt sich um einfache GET-Anfrage, ohne Parameter. Nachfolgend eine dieser Abfragen:

GET https://gllto.glpals.com/rto/v1/latest/rto.dat

Accept:           */*, application/vnd.wap.mms-message, application/vnd.wap.sic                                                                                                                                 
x-wap-profile:    http://www.openmobilealliance.org/tech/profiles/UAPROF/ccppschema-20021212#                                                                                                                   
User-Agent:       Dalvik/2.1.0 (Linux; U; Android 13; Pixel 6a Build/TQ1A.230205.002)                                                                                                                        
Host:             gllto.glpals.com                                                                                                                                                                                    
Connection:       Keep-Alive                                                                                                                                                                                    
Accept-Encoding:  gzip

Im Gegensatz zu iodéOS, das die Standardserver von Broadcom verwendet, betreibt GrapheneOS seine eigenen Server, auf denen es die Almanache bereitstellt. Dies verringert die Abhängigkeit von Google:

• https://broadcom.psds.grapheneos.org/rto.dat
• https://broadcom.psds.grapheneos.org/lto2.dat
• https://broadcom.psds.grapheneos.org/rtistatus.dat

4.5 (GPS-)Standort [mit microG]

Auch bei der microG-Variante erfolgt zur Beschleunigung der Standortbestimmung eine SUPL-Anfrage an supl.vodafone.com -> supl.google.com. Zusätzlich erfolgt die Positionsbestimmung mittels Mozilla Location Service:

The Mozilla Location Service (MLS) is an open service, which lets devices determine their location based on network infrastructure like Bluetooth beacons, cell towers and WiFi access points. This network based location service complements satellite based navigation systems like A-GPS.

Eine solche Anfrage zur Standortbestimmung wird an die Gegenstelle location.services.mozilla.com übermittelt (gekürzte Darstellung):

POST /v1/geolocate?key=068ab754-c06b-473d-a1e5-60e7b1a2eb77 HTTP/1.1

Content-Type: application/x-www-form-urlencoded
User-Agent: Dalvik/2.1.0 (Linux; U; Android 13; Pixel 6a Build/TQ1A.230205.002)
Host: location.services.mozilla.com
Connection: close
Accept-Encoding: gzip, deflate
Content-Length: 1273

{

   "radioType":"lte",
   "cellTowers":[
      {
         "radioType":"lte",
         "mobileCountryCode":262,
         "mobileNetworkCode":2,
         "locationAreaCode":47222,
         "cellId":18416660,
         "signalStrength":-97,
         "psc":280,
         "asu":43
      }
   ],
   "wifiAccessPoints":[
      {
         "macAddress":"54:fa:3e:ae:4d:17",
         "channel":128,
         "frequency":5640,
         "signalStrength":-67
      },
      {
         "macAddress":"1c:ed:6f:38:62:7f",
         "channel":6,
         "frequency":2437,
         "signalStrength":-76
      }

[15 weiter WiFis]

      }
   ],
   "fallbacks":{
      "lacf":true,
      "ipf":false
   }
}

Neben Informationen zum aktiven/verbundenen Mobilfunkmast werden Informationen von allen umliegenden bzw. in der Empfangsreichsweite des Smartphones befindlichen WiFi-Netzwerkinformationen ausgelesen und übermittelt. Dazu zählt bspw. die MAC-Adresse der Router, der Sendekanal und ebenfalls die Signalstärke.

Durch die Nutzung von microG bzw. den integrierten Location-Modulen hat der Nutzer die Möglichkeit, die Standortbestimmung zu beeinflussen. Es besteht die Option, die verschiedenen Module nach Belieben ein- oder auszuschalten:

4.6 Initialisierung microG [mit microG]

Bei der erstmaligen Initialisierung von microG und ebenfalls in vordefinierten Zuständen (bspw. nach jedem Neustart) nimmt microG eine Verbindung zu Google bzw. der Gegenstelle android.clients.google.com auf. Bei dieser Verbindung wird das Gerät zur Nutzung von Google-Diensten vorbereitet. Das sieht im Detail wie folgt aus:

POST https://android.clients.google.com/checkin

Content-type: application/x-protobuffer
Content-Encoding: gzip
Accept-Encoding: gzip
User-Agent: Android-Checkin/2.0 (vbox86p JLS36G); gzip
Host: android.clients.google.com
Connection: Keep-Alive
Content-Length: 3777

[uint32] 2 0
[string] 3 1-929a0dca0eee55513280171a8585da7dcd3700f8
[message] 4
[message] 4.1
[string] 4.1.1 google/bluejay/bluejay:13/TQ1A.230105.001.A2/9325585:user/release-keys
[string] 4.1.2 bluejay
[string] 4.1.3 google
[string] 4.1.4 unknown
[string] 4.1.5 bluejay-1.2-9288097
[string] 4.1.6 android-google
[uint32] 4.1.7 1676540823
[string] 4.1.9 bluejay
[uint32] 4.1.10 33
[string] 4.1.11 Pixel 6a
[string] 4.1.12 Google
[string] 4.1.13 bluejay
[uint32] 4.1.14 0
[uint32] 4.2 0
[message] 4.3
[string] 4.3.1 event_log_start
[uint64] 4.3.3 1680593956566
[string] 4.6 26207
[string] 4.7 26207
[string] 4.8 mobile-notroaming
[uint32] 4.9 0
[string] 6 de_DE
[uint64] 7 3857468346209894329
[string] 9 b407f9dcdd83
[string] 10 355031046176927
[message] 11
[string] 12 Europe/Berlin
[uint32] 14 3
[string] 15 71Q6Rn2DDZl1zPDVaaeEHItd
[string] 16 008741D2F2F7C3C1
[message] 18
[uint32] 18.1 3
[uint32] 18.2 1
[uint32] 18.3 1
[uint32] 18.4 2
[uint32] 18.5 0
[uint32] 18.6 0
[uint32] 18.7 403
[uint32] 18.8 196610
[string] 18.9 android.ext.shared
[string] 18.9 android.hidl.base-V1.0-java
[string] 18.9 android.hidl.manager-V1.0-java
[string] 18.9 android.net.ipsec.ike
[string] 18.9 android.system.virtualmachine
[string] 18.9 android.test.base
[string] 18.9 android.test.mock

[...]

[string] 18.10 android.hardware.camera.autofocus
[string] 18.10 android.hardware.camera.capability.manual_post_processing
[string] 18.10 android.hardware.camera.capability.manual_sensor
[string] 18.10 android.hardware.camera.capability.raw
[string] 18.10 android.hardware.camera.concurrent
[string] 18.10 android.hardware.camera.flash
[string] 18.10 android.hardware.camera.front
[string] 18.10 android.hardware.camera.level.full
[string] 18.10 android.hardware.context_hub
[string] 18.10 android.hardware.device_unique_attestation
[string] 18.10 android.hardware.faketouch
[string] 18.10 android.hardware.fingerprint
[string] 18.10 android.hardware.hardware_keystore
[string] 18.10 android.hardware.identity_credential
[string] 18.10 android.hardware.keystore.app_attest_key
[string] 18.10 android.hardware.location
[string] 18.10 android.hardware.location.gps
[string] 18.10 android.hardware.location.network
[message] 18.10
[fixed64] 18.10.12 7507048032877306990
[fixed64] 18.10.12 7867337140998726770
[fixed64] 18.10.13 7308901739622527587
[string] 18.10 android.hardware.nfc
[string] 18.10 android.hardware.nfc.any
[string] 18.10 android.hardware.nfc.ese
[string] 18.10 android.hardware.nfc.hce
[string] 18.10 android.hardware.nfc.hcef
[string] 18.10 android.hardware.nfc.uicc
[string] 18.10 android.hardware.opengles.aep
[message] 18.10
[fixed64] 18.10.12 7507048032877306990
[fixed64] 18.10.12 7867337140998726770
[fixed64] 18.10.13 7809643567100341869
[string] 18.10 android.hardware.screen.landscape
[string] 18.10 android.hardware.screen.portrait
[string] 18.10 android.hardware.se.omapi.ese
[string] 18.10 android.hardware.se.omapi.uicc
[string] 18.10 android.hardware.security.model.compatible
[string] 18.10 android.hardware.sensor.accelerometer
[string] 18.10 android.hardware.sensor.barometer
[string] 18.10 android.hardware.sensor.compass
[string] 18.10 android.hardware.sensor.dynamic.head_tracker
[string] 18.10 android.hardware.sensor.gyroscope
[string] 18.10 android.hardware.sensor.hifi_sensors
[string] 18.10 android.hardware.sensor.light
[string] 18.10 android.hardware.sensor.proximity
[string] 18.10 android.hardware.sensor.stepcounter

[...]

Die übermittelten Informationen sind gekürzt dargestellt, dennoch kann man einiges herauslesen. Es werden etliche Gerätedaten (Gerätemodell, Sprache, Land, installierte System-Bibliotheken, Hardware-Features, CPU-Type, UUIDs, Android-Version etc.) an Google übermittelt. Dazu ein Hinweis vom microG-Entwickler:

Generell sind die Daten, die bei der Geräte-Registrierung gesendet werden, soweit möglich, praktisch anonymisiert. Wenn der Speicher des Geräts zurückgesetzt wird, ist es aus Googles Sicht nicht mehr wiederzuerkennen. Die gerätespezifischen Daten sind alle nur Modell-spezifisch, aber nicht auf das individuelle Gerät zugeschnitten – alle Pixel 6a mit iodéOS und deutscher Sprache sehen für Google also gleich aus.

Diese Registrierung bzw. Anmeldung bei Google lässt sich über microG-Einstellungen -> Google Geräte-Registrierung deaktivieren. Nur sollte man sich vor der Deaktivierung darüber im Klaren sein, dass anschließend Push-Notifications, SafetyNet und weitere API-Komponenten nicht mehr (korrekt) funktionieren. Die Deaktivierung des Schiebereglers kommt also einer Stilllegung von microG gleich:

5. Tabelle mit Datenverbindungen

iodéOS hat Verbindungen, die vom System initiiert werden, an keiner Stelle dokumentiert. Die nachfolgende Tabelle fasst alle identifizierten Netzwerkverbindungen in einer Übersicht zusammen:

6. Zusätzliche Informationen zu/über das Custom-ROM

6.1 Entwickler | Institution

Das Team von iodé ist international mit Mitgliedern aus Frankreich und Deutschland besetzt. Weshalb man iodéOS nutzen sollte, beschreibt die FAQ wie folgt:

Studien und Skandale haben gezeigt, wie weit die konstante Datensammelei auf Android durch verschiedene Akteure geht.Die Risiken sind zu hoch und das Google-Apple Duo monopolisiert Smartphone-Verkäufe, welche die Hauptquelle von Datenpannen sind. Wir brauchen mehr Lösungen um unsere Privatsphäre zu schützen.

iodé ist eine privatsphärefreundliche, alternative Lösung. iodé basiert auf Open Source Komponenten. iodé ist umweltfreundlich. iodé ist “Made in Europe”.

Was ich an iodéOS schätze, ist die Tatsache, dass es nicht mit dem Versprechen der Sicherheit wirbt. Angesichts der Verzögerungen bei der Auslieferung von (Sicherheits-)Updates wäre dies auch unangemessen. Vielmehr richtet sich iodéOS hauptsächlich an Nutzer, die Wert auf Datenschutz legen und ältere Geräte weiterhin nutzen möchten. Aus ökologischer Sicht ist dies auch sinnvoll, da die meisten Geräte hardwareseitig noch einwandfrei funktionieren, aber aufgrund der Konsumorientierung durch den Kapitalismus oft den Platz räumen müssen. Am Ende bedeutet das: Noch mehr Elektroschrott – und darauf können wir alle gut und gerne verzichten.

6.2 Installationsvorgang

Sofern man etwas Geduld und Zeit mitbringt, sollte der Installationsvorgang von jedem durchführbar sein, der in der Lage ist, einer Anleitung 1:1 zu folgen. Nach Auswahl des entsprechenden Geräts steht eine kurze Installationsanleitung bereit. Exemplarisch verlinke ich hier die Flash-Anleitung für das Google Pixel 6a. Kurz zusammengefasst sind die Schritte wie folgt:

• Entwickleroptionen, USB-Debugging und OEM-Unlocking aktivieren
• Falls notwendig: Benötigte Linux-Pakete bzw. Software installieren
• Den Device-Flasher und das Geräteimage (fastboot package) herunterladen
• Die heruntergeladene Zip-Datei entpacken
• Den Device-Flasher (flash-all.sh/flash-all.bat) ausführen/starten
• Den Bootloader im Installationsvorgang mittels Tastenwippe entsperren
• Warten, bis der Device-Flasher den Vorgang beendet
• Den Bootloader des Geräts wieder sperren

Für jemanden, der sich mit dieser Materie bisher nicht beschäftigt hat, sind da natürlich ein paar »Fremdwörter« dabei. Davon sollte man sich jedoch nicht abschrecken lassen.

6.3 Verfügbarkeit (Sicherheits-)Updates

Der wirkungsvollste Schutz gegen bekanntgewordene bzw. geschlossene Schwachstellen ist das Einspielen von (Sicherheits-)Updates. Google stellt mittlerweile monatlich Sicherheitsupdates bereit, die traditionell um den 5. eines Monats veröffentlicht werden. Leider stecken viele Anwender in einem Dilemma: Einige Smartphone-Hersteller schaffen es oftmals nicht, zeitnah Updates für ihre herstellerspezifischen Android-Versionen bereitzustellen oder unterstützen ältere ihrer Geräte einfach aus Kostengründen nicht mehr. Damit entsteht zwangsläufig ein »Vakuum« in der Android-Welt, das viele Geräte anfällig für kritische Sicherheitslücken macht.

iodéOS wirbt nicht öffentlichkeitswirksam mit Sicherheit, sondern erläutert in den FAQs unter dem Punkt »Wie oft werden Systemupdates bereit gestellt?«:

Systemupdates werden im Schnitt alle 2 Monate bereit gestellt. Du bekommst bei jedem Update von iodéOS eine Benachrichtigung, die dich zum Updater weiterleitet. Dort kannst du das neueste Update herunterladen und installieren. Wir empfehlen dir, dein System stets auf dem neuesten Stand zu halten.

Wir veröffentlichen auch Beta Updates, in kürzeren Abständen. Wenn du ein Beta Tester für iodé werden möchtest, findest du mehr Infos unter „Wie kann ich mithelfen?

Das bedeutet: (Sicherheits-)Updates erscheinen nicht so zeitnah, wie man es von Systemen wie GrapheneOS kennt. Die auf dem Testgerät installierte Version 4.0-20230216-bluejay (16. Februar 2023) war am 28.03.2023 noch auf dem Stand vom 5. Februar. Das ist natürlich nicht optimal, da bspw. die kritische Sicherheitslücke CVE-2023-24033 mit dem März-Update (5. März) geschlossen wurde. Erst am 02.04.2023 erschien das Update auf den Stand vom 5. März. Das bedeutet: Knapp einen Monat lang, klaffte also eine »Internet-to-Baseband Remote Code Execution (RCE)« im System. Auf einer Skala von 1 bis 10 ist das eine 11. Zumindest für solche schwerwiegenden Sicherheitslücken sollte das Team um iodéOS den Update-Zyklus überdenken.

Die iodéOS Version 4.1-20230327-bluejay (02. April 2023) ist nun aktuell und hebt den Stand der Sicherheitsupdates auf den 5. März an. Wie lange wird es nun aber dauern, bis die insgesamt 68 behobenen Schwachstellen vom April-Update in iodéOS einfließen? Zwei der Schwachstellen (CVE-2023-21085, CVE-2023-21096) sind als kritisch eingestuft, da sie Angreifern ermöglichen, Schadcode auszuführen.

6.4 Alternative zu Google-Play-Diensten

In der Privacy-Szene haben die Google-Play-Dienste nicht umsonst den Ruf einer Überwachungswanze. Im Beitrag »Google Play Services: Die Überwachungswanze von Google« ist aufgezeigt, welche Daten Google von einem Gerät erhebt – und das, obwohl praktisch alle Einstellungen möglichst datenschutzfreundlich konfiguriert wurden.

In iodéOS ist microG, die Alternative zu Google-Play-Diensten, fest integriert. Das bedeutet, dass Nutzer nicht die Wahl haben, auf die Installation/Integration von microG zu verzichten. Allerdings können sie entscheiden, ob microG aktiviert ist oder nicht. Über »Einstellungen -> Apps -> Alle [XY] Apps ansehen -> Drei Punkte -> System-Apps anzeigen -> microG Services Core« kann microG auch komplett deaktiviert werden. Alternativ ist ebenfalls eine Deinstallation im laufenden Betrieb möglich – ein Reset auf Werkseinstellungen ist nicht erforderlich: Einstellungen -> Apps -> Vorinstallierte Apps -> Services microG-Reiter aufklappen und die Mülltonne antippen -> Gerät neu starten.

Zitat aus der FAQ:

Die microG services ersetzen die Google Play Services auf deinem iodé Smartphone. Sie erlauben dir, neben anderen Services, Google’s alternative Geolocation Module zu nutzen. Zwei Module werden standardmäßig gekoppelt: ‘Déjà vu’ & ‘Mozilla Location Service’.

‘Google Cloud Messaging’ (GCM) ist ein Dienst für Push Benachrichtigungen der dir erlaubt, Benachrichtigungen auf deinem iodé Smartphone zu empfangen. Viele Android Apps nutzen diesen Dienst. Wir haben GCM standardmäßig aktiviert, aber du kannst ihn jederzeit in den microG Einstellungen deaktivieren.

Mit iodéOS, kannst du jede vorinstallierte App, wie z. B. microG, direkt im Installationsassistenten oder später deinstallieren.

Gegenüber den Google-Play-Diensten ist microG deutlich weniger invasiv und ebenfalls quelloffen. Dennoch sollte man sich hier vor Augen führen, (auch) weiterhin auf die Infrastruktur von Google angewiesen zu sein. Es ist daher empfehlenswert auf microG zu verzichten – sofern das eure Anforderungen/Apps etc. zulassen.

6.5 Sicherheit/Datenschutz

iodéOS unterstützt Verified Boot – jedenfalls für einige der Geräte, unter anderem dem Google Pixel 6a. Dieses soll sicherstellen, dass der gesamte ausgeführte Code von einer vertrauenswürdigen Quelle stammt und ein Angreifer keine Manipulation daran vorgenommen hat. Das soll unter anderem Evil-Maid-Angriffe erkennen, bei dem ein Angreifer Zugang zum Gerät hat. Bei einem Gerät, das bspw. einen offenen Bootloader (unlocked) hat und/oder bei dem zusätzlich ein Recovery-Image aufgespielt wurde, ist es für einen versierten Angreifer möglich Veränderungen vorzunehmen, die man als Nutzer im Nachhinein nicht erkennt. Die Android-Geräteverschlüsselung, die auch beim Booten ins Recovery abgefragt wird, schützt nämlich nur die Nutzerdaten. Ein Angreifer kann aber mittels ADB (Android Debug Bridge) weiterhin auf die Systempartition zugreifen und daran Veränderungen vornehmen. Denkbar ist auch eine Veränderung des Bootloaders. Zugegeben ist das ein eher geringes Risiko, aber die Möglichkeit besteht dennoch. iodéOS bootet nur dann, wenn keine (manipulative) Veränderung durch einen Dritten am Bootloader, System, Vendor-Dateien etc. festgestellt wurde. Das ist auch der Grund, weshalb der Bootloader nach dem Aufspielen von iodéOS wieder geschlossen werden sollte.

Von diesem Standard-Sicherheitsfeature mal abgesehen, bietet iodéOS noch folgende Änderungen, die sich positiv auf die Sicherheit und den Datenschutz auswirken können. Zitat:

iodéOS installation -> OS:

• Default DNS server: Google’s DNS replaced by Quad9’s ‘unblocked’ servers in all parts of the system.
• A-GPS: patches to avoid leaking personnal information like IMSI to supl server.
• Captive portal login: connectivitycheck.gstatic.com replaced by captiveportal.kuketz.de for connectivity check.
• Dialer: Google default option replaced by OpenStreetMap for phone number lookup.

Weiterhin sind folgende Erweiterungen integriert:

Obwohl es dem normalen Android sehr ähnlich ist, so ist dein iodé Smartphone darauf ausgerichtet, deine persönlichen Daten zu schützen. Es enthält folgende Funktionen, die du kennen solltest:

• […]
• Trust (von LineageOS): Ein Interface welches dein iodé Smartphone absichert und deine Privatsphäre schützt.
• iodé: Ein Interface welches deine Apps in Echtzeit scannt und dich vor Datenabflüssen schützt.
• […]
• microG Services: Eine quelloffene, privatsphärefreundliche Implementierung der Google Play Services.Einer dieser Services ermöglicht es dir, Google’s alternative Standortmodule zu wählen. 2 Module sind standardmäßig angestellt: ‘Déjà vu’ & ‘Mozilla Location Service’. Für mehr Information über diese Module, siehe „Wie funktionieren die microG Standortmodule?“. Die ‘Google Cloud Messaging’ Push Benachrichtigung, die von vielen Apps dazu genutzt wird, um dir Benachrichtigungen senden, ist standardmäßig aktiviert. Du kannst sie natürlich jederzeit deaktivieren.

Trust ist eine Erweiterung von LineageOS, die wichtige Informationen zu Sicherheit und Datenschutz an einem zentralen Ort bündelt. Während meiner Überprüfung von Trust bemerkte ich jedoch, dass die installierte Version 4.0-20230216-bluejay knapp zwei Monate veraltet war. Trotzdem wurde der Stand der Android-Sicherheitspatches als aktuell angezeigt. Obwohl ich keine Aussage über den tatsächlichen Nutzen von Trust treffen möchte, wollte ich diese Beobachtung teilen.

Wirklich positiv muss ich hingegen die in iodéOS integrierte Firewall erwähnen. Zitat:

Vom Kern des Betriebssystems aus beobachtet dein iodé Smartphone DNS Anfragen und Datenübertragungen.

iodé blockiert Anfragen und Übertragungen zu unerwünschten Empfängern (Werbung, Malware, Spam, Spyware, Statistik & Tracker), die von der Open Source Community zusammengetragen werden.

Mit der Firewall, die wir von Grund auf entwickelt haben, kannst du verschiedene Arten und Kategorien der Blockierung für jede deiner Apps wählen. So gibt es das voreingestellte Standard-Blockieren oder das verstärkte Blockieren. Mit iodéOS kannst du jede Netzwerkverbindung blockieren oder deine eigene Filterliste für Tracker erstellen!

Zu guter Letzt kannst du mit der iodé App blockierte Anfragen und Übertragungen in Echtzeit auf einer Weltkarte visualisieren und die Blocker individuell einstellen.

Als iodéOS-Nutzer sollte man sich mit diesem Tool gut vertraut machen, denn es ersetzt Lösungen wie AdAway oder NetGuard:

7. Fazit

Wir erinnern uns an das Eingangszitat:

iodéOS ist ein auf Android basierendes Betriebssystem, welches von Googles Datensammelwut befreit wurde. […]

Tatsächlich ist es iodéOS relativ gut gelungen, Googles Datensammelwut zu reduzieren – allerdings nicht vollständig. Um die Standortbestimmung zu beschleunigen, greift das System beispielsweise auf den Google SUPL-Server zu und der mitgelieferte Browser nutzt Google Safe Browsing. Abgesehen davon haben die Entwickler einen guten Job gemacht, iodéOS zu »entgooglen«. Wenn man jedoch microG aktiviert, muss man sich bewusst sein, dass einige Verbindungen zu Google hergestellt werden. Dies ist jedoch rein optional und man kann iodéOS nahezu frei von Google nutzen.

Insgesamt hinterlässt iodéOS einen relativ datenschutzfreundlichen Gesamteindruck. Allerdings sollte man ebenfalls die Nachteile berücksichtigen:

• Verzögerte Auslieferung von (Sicherheits-)Updates
• Ältere Geräte erhalten keine vollständigen Sicherheitsupdates von proprietären Komponenten wie Bootloader oder Firmware
• iodéOS unterstützt nicht bei jedem Gerät Verified Boot

iodéOS könnte insbesondere durch eine schnellere Bereitstellung von (Sicherheits-)Updates verbessert werden. Insgesamt müssen jedoch einige Einschränkungen hinsichtlich der Sicherheit in Kauf genommen werden. Letztlich richtet sich iodéOS hauptsächlich an datenschutzsensible Nutzer, die ihre (älteren) Geräte weiterhin nutzen möchten.

Bildquellen:

iodéOS: Manonrouget from wikimedia.org is licensed by CC BY-SA 4.0

Wenn du über aktuelle Beiträge informiert werden möchtest, hast du verschiedene Möglichkeiten, dem Blog zu folgen:

Bleib aktuell ➡

Ähnliche Beiträge

10. Februar 2023

CalyxOS: De-Googled geht anders – Custom-ROMs Teil2

Die Analyse des Datensendeverhaltens zeigt: CalyxOS ist leider nicht so de-googled, wie man vermuten würde.

5. Dezember 2023

/e/: Datenschutzfreundlich bedeutet nicht zwangsläufig sicher – Custom-ROMs Teil6

/e/ punktet beim Datenschutz, aber hinsichtlich der Sicherheit bestehen erhebliche Bedenken.

24. April 2023

LineageOS: Weder sicher noch datenschutzfreundlich – Custom-ROMs Teil4

LineageOS hinterlässt weder einen datenschutzfreundlichen, noch wirklich sicheren Eindruck.

1. Juni 2023

DivestOS: Datenschutzfreundlich und erhöhte Sicherheit – Custom-ROMs Teil5

DivestOS stellt Datenschutz und Sicherheit als grundlegende Prinzipien in den Vordergrund: Man kann berechtigterweise sagen: Take back (some) control!

10. September 2023

Klimaschutz mit Datenschutz? Der große Elektroauto-Ladeapp-Test

Manche Ladeapps sind eine Datenschutzkatastrophe. Wir haben 41 Apps getestet und geben Tipps für datensparsames Laden.

Weitere Themen

AndroidAuditAutonomieBackupBezahlenBrowserCloudDatenschutzDatensendeverhaltenDigitalpolitikDSGVOE-MailFirewallHackingHärteniOSKuketz-BlogLinuxmacOSMessengerOpenWrtPasswortPentestRaspberryPiRechtSicherheitslückeSicherheitsmaßnahmeTorTrackingTTDSGÜberwachungVerschlüsselungWindowsWordPressXMPP

---

Diskussion

Ich freue mich auf Deine Beteiligung zum Artikel

Wenn du Ergänzungen oder konkrete Fragen zum Beitrag hast, besuche das offizielle Forum. Dort kann der Beitrag diskutiert werden. Oder besuche den Chat, um dein Anliegen zu besprechen. zur Diskussion ➡

Abschließender Hinweis

Blog-Beiträge erheben nicht den Anspruch auf ständige Aktualität und Richtigkeit wie Lexikoneinträge (z.B. Wikipedia), sondern beziehen sich wie Zeitungsartikel auf den Informationsstand zum Zeitpunkt des Redaktionsschlusses.

Kritik, Anregungen oder Korrekturvorschläge zu den Beiträgen nehme ich gerne per E-Mail entgegen.