1. Auf dem Prüfstand
In der Artikelserie »Custom-ROMs« möchte ich einige alternative Android-Systeme näher beleuchten. Der Schwerpunkt liegt dabei auf der Analyse des Datensendeverhaltens. Es wird untersucht, 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 daraus Tipps ableiten, wie sich das »Nach-Hause-Telefonieren« einschränken oder sogar vollständig abschalten lässt.
Im vorliegenden Beitrag wird /e/ einer Analyse unterzogen. Das Custom-ROM wird wie folgt beworben:
/e/OS is a complete, fully “deGoogled”, mobile ecosystem
Wird /e/ 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. /e/
/e/ ist ein Open-Source-Betriebssystem für mobile Geräte (Smartphones und Tablets), das auf dem quelloffenen Android von Google basiert. Es ist ein Fork von LineageOS und enthält keine Google-Play-Dienste, sondern verwendet microG als freien und quelloffenen Ersatz. Die erste Beta-Version von /e/ wurde bereits 2018 auf Basis von Android 7 veröffentlicht.
Aktuell werden von /e/ 246 Geräte unterstützt, wobei nur 19 davon als stable markiert sind. Hierzu gibt es die folgende Warnung:
Warning! Unless marked as stable, many /e/OS builds here are not intended for daily use. All builds labelled as dev have not been fully tested yet and may contain major bugs. All builds are provided as best effort, without any guarantee.
Dies ist bei Custom-ROMs nicht ungewöhnlich. In der Praxis funktionieren die mit dev (Entwicklung) gekennzeichneten Versionen meist problemlos oder weisen nur kleinere Fehler/Bugs auf. Zu den unterstützten Modellen gehören Hersteller wie Sony, Fairphone, Google, Samsung, OnePlus und Xiaomi. Bedenklich ist allerdings, dass einige der angebotenen Builds für bestimmte Geräte noch auf Android 10 (Quince Tart) basieren, das keine Sicherheitsupdates mehr erhält. Die neueste Version von /e/ basiert auf Android 13 (Tiramisu) und ist für 89 Geräte verfügbar. Für viele der angebotenen Geräte-Builds sind keine vollständigen Sicherheitsupdates für proprietäre Komponenten wie Bootloader oder Firmware zu erwarten. Beispielsweise werden Geräte wie das Google Pixel 4a vom Hersteller nicht mehr mit entsprechenden Updates versorgt.
Von Haus aus integriert /e/ ein umfangreiches Angebot an Apps bzw. Forks. Anbei eine Auswahl:
- Mail: Ein Fork der bekannten E-Mal-App K-9 Mail/Thunderbird
- Calendar: Ein Fork von der Kalender-App Etar
- Browser: Ein de-googled Fork von Chromium inkl. Werbeblocker
- Maps: MagicEarth (nicht quelloffen)
- Tasks: OpenTasks
Weitere Apps können über die App Lounge bezogen werden. Das Besondere: Es können Apps aus verschiedenen Quellen wie dem Google Play Store oder F-Droid heruntergeladen werden.
Zum Lieferumfang gehört auch die Murena Cloud, die auf NextCloud, Postfix, Dovecot und OnlyOffice basiert. Diese Cloud bietet 1 GB Speicherplatz und Funktionen wie E-Mail, Kalender, Kontakte, Office etc. Es besteht auch die Möglichkeit, die Cloud selbst zu hosten.
Im Vergleich zu den analysierten Custom-ROMs CalyxOS und iodéOS erfordert die Installation von /e/ etwas mehr Aufwand. Eine einfache Installationsroutine oder ein Installationsskript fehlt, was bedauerlich ist. Stattdessen muss sich der Benutzer durch eine Installationsanleitung kämpfen, was insbesondere Anfänger/Umsteiger abschrecken dürfte. Damit ist der Einstieg in /e/ im Vergleich zu Betriebssystemen wie GrapheneOS oder iodéOS etwas anspruchsvoller. Die Hürde, /e/ zum Laufen zu bringen, ist also ungleich höher.
Easy Installer
Für 21 Geräte ist ebenfalls ein Easy Installer verfügbar, der die Installation von /e/ stark vereinfacht.Interessierte können sich vorab in der umfangreichen Dokumentation über /e/ informieren und über das Community-Forum Hilfe erhalten. Ein Teil der Dokumentation ist den Netzwerkverbindungen gewidmet, die aufzeigen, wohin (Server/Gegenstelle) und zu welchem Zweck das System Verbindungen aufbaut. Leider ist die Übersicht unvollständig, so dass nicht klar ist, welche Netzwerkverbindungen das System und die mitgelieferten Apps initiieren.
Tschüß Überwachungswanze
Der Verzicht auf die Google-Play-Dienste geht übrigens mit einer erheblichen Steigerung der Privatsphäre einher. 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.Hilf mit die Spendenziele zu erreichen!
Unabhängig. Kritisch. Informativ. Praxisnah. Verständlich.
Die Arbeit von kuketz-blog.de wird vollständig durch Spenden unserer Leserschaft finanziert. Sei Teil unserer Community und unterstütze unsere Arbeit mit einer Spende.
2.1 Verwendetes Setup
Während der erstmaligen Einrichtung von /e/ kann die Standortermittlung und Cloud-Synchronisation aktiviert/deaktiviert werden. Unabhängig von eurer Entscheidung bei der Einrichtung kann die Einstellungen jederzeit während des Betriebs angepasst werden:
Während der Testphase kam die folgende /e/-Version zum Einsatz:
- Google Pixel 6a (bluejay): e-1.17-t-20231111351094-dev-bluejay.zip (11. November 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 gesetzt. 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 Systemumgebung, als auch die (Netzwerk-)Tools, mit denen die Datenmitschnitte erfolgen, wurden im ersten Teil der Artikelserie beschrieben. Nachfolgend werden unterschiedliche (Anwendungs-)Szenarien beleuchtet. Was passiert bspw. beim Start des Gerätes? Welche Verbindungen werden initiiert, wenn die GPS-Schnittstelle aktiviert wird? Und welche Daten überträgt der Standardbrowser nach dem Aufruf?
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:
- pool.ntp.org
- connectivity.murena.io
Nach der Auflösung der Domainnamen in die zugehörige IP-Adresse startet das System eine Aktualisierung der (Netzwerk-)Zeit via NTP zum Server 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 /e/ eine Anfrage an die Adresse connectivity.murena.io. Die Überprüfung der Konnektivität erfolgt durch folgende GET-Anfrage:
GET / HTTP/1.1 Connection: close User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.32 Safari/537.36 Host: connectivity.murena.io Accept-Encoding: gzip, deflate
Als Antwort erfolgt dann ein 204er-Statuscode:
HTTP/1.1 204 No Content cache-control: no-cache connection: close
Eine zweite Verbindung erfolgt dann erneut zu connectivity.murena.io und ist eine Art Fallback, wenn die unverschlüsselte HTTP-Verbindung zu connectivity.murena.io fehlschlägt. Während der Tests erfolgte die zweite Verbindung jedes Mal, sobald der Captive-Portal-Check durchgeführt wurde.
Datenminimierung
Es ist nicht möglich, den Captive-Portal-Check bei /e/ zu deaktivieren. Es ist jedoch erfreulich festzustellen, dass die standardmäßigen Google-Server (connectivitycheck.gstatic.com) nicht kontaktiert werden.3.2 Geräte-Updates
/e/ prüft regelmäßig (standardmäßig einmal täglich), ob neue System-Updates verfügbar sind. Der Update-Check erfolgt über die Adresse ota.ecloud.global:
GET https://ota.ecloud.global/api/v1/bluejay/dev/eng.root.20231111.121300?ota_anon_hash=anondf7302758c4740e298296396fa64815e User-Agent: null eOS v1.17 Host: ota.ecloud.global Connection: Keep-Alive Accept-Encoding: gzip
Interessant ist der GET-Parameter ota_anon_hash: anondf7302758c4740e298296396fa64815e, der bei einem Update-Check übermittelt wird. Wenn wir da etwas tiefer einsteigen, finden wir diese Änderungen im Quellcode:
- Updater: Generate license ID for ota requests
- Settings: add preference for license id
- base: add ota license id settings
Zusammenfassend kann festgestellt werden, dass /e/ offenbar ein Lizenzschlüsselsystem für OTA-Updates eingeführt hat. Die Änderungen an der GUI wurden jedoch wieder entfernt. Als Benutzer kann man seine einzigartige OTA-ID (Unique-Device-Identifier) nicht einsehen:
Ich halte solche Anpassungen in einem System, das auf den Schutz der Privatsphäre spezialisiert ist, für fragwürdig. Die OTA-ID ist ein eindeutiger Identifikator, aber für das Einspielen von Updates nicht notwendig.
Update 08.04.2024
Gaël Duval hat mich kontaktiert und mir den Zweck der OTA-ID wie folgt erläutert:For context, and I agree that this feature can be perceived with mixed feelings, especially because it was stupidly called „licence ID“ at the beginning of its implementation, we added it because we suffered from not having good statistics on /e/OS usage.
Of course we are not interested in tracking users at all, but we do want to know how many devices are running this or that build of /e/OS. This is very useful for making some decisions about device support and setting priorities for future development.
Just running statistics on OTA server request logs along with the device model didn’t give good results.
Now, and this is still part of our internal discussions, if we are able to find a way to get good quality stats without this OTA anon-unique identifier, we will consider it.
However, we sincerely believe that this anonID probably has no impact on user privacy (tracking IPs or device fingerprints would probably be much worse).
Die (negative) Antwort auf eine solche Aktualisierungsanfrage sieht wie folgt aus:
[Paket-Header]
{
"error": null,
"id": null,
"response": []
} Wenn ein Update verfügbar ist, wird der Download nicht automatisch gestartet, sondern der Benutzer muss den Download und die Installation des Updates manuell starten.
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.
Datenminimierung
Die OTA-ID (Unique-Device-Identifier) kann über einen Factory-Reset oder per ADB-Befehl zurückgesetzt werden:adb shell settings put secure ota_anon_hash <new value>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 in einem Zeitraum von 24 Stunden nicht benutzt. Stattdessen wird geprüft, welche Verbindungen das (Standard-)System innerhalb von 24 Stunden initiiert hat. Es wurde mehrfach versucht, die (Netzwerk-)Zeit via NTP zu aktualisieren und Update-Checks durchgeführt – obwohl die Prüfung nur Einmal am Tag erfolgen sollte:
Da microG standardmäßig in /e/ aktiviert ist, verbindet sich das System mit Google-Servern. Zur Erinnerung: microG ist eine (nicht vollständige) Nachbildung der Google-Play-Dienste. Im Gegensatz zu den Google-Play-Diensten verfolgt microG zumindest nicht die Aktivitäten des Nutzers auf dem Gerät. Außerdem kann der Nutzer teilweise selbst bestimmen, welche API-Funktionen (Google Cloud Messaging, SafetyNet, Exposure Notification Framework) er nutzen möchte.
In der Standardkonfiguration von microG nimmt das System regelmäßig Kontakt mit Google auf, um über diesen Kanal Push-Notifications (von Apps) zu empfangen. Das erfolgt über eine TCP-Verbindung zur Gegenstelle mtalk.google.com (bspw. 173.194.76.188:5228) – einem Server von Google. Ein solcher TCP-Stream sieht ein- und ausgehend (zu Google) wie folgt aus:
Anfrage:
)
Antwort:
)
Anfrage:
android-33..mcs.android.com..3459028520354100750".3459028520354100750*.37548079087200356932.android-3000f01ccfa6b60eB.
Antwort:
android-33..user@firebase.com/notifications0.@
Auch wenn (noch) keine Apps für den Erhalt von Push-Notifications registriert sind, erfolgt eine dauerhafte Aktualisierung der Verbindung zu mtalk.google.com.
Datenminimierung
Diese Registrierung bzw. Anmeldung bei Google kann überSystem -> microG -> Google Geräte-Registrierung deaktiviert werden. 4.2 Aktivierung Netzwerkschnittstelle
Bereits während des Boot-Vorgangs wird ein Captive-Portal-Check durchgeführt, sofern eine Netzwerkschnittstelle (WiFi, Mobile) aktiv ist. Wird das Gerät zwischenzeitlich in den Flugmodus versetzt und danach wieder ein Netzwerkinterface aktiviert, wird erneut ein Captive-Portal-Check initiiert. Dies bedeutet einen erneuten Verbindungsaufbau zu connectivity.murena.io. Was dabei auffällt: Die Verbindungen werden nicht durch das VPN getunnelt, sondern werden einfach daran vorbeigeleitet. 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 vorbei getunnelt. Android leakt also Traffic, was nicht nur die VPN-Option infrage stellt, sondern auch ein echtes Datenschutzproblem darstellen kann. Wenn Daten einfach an einem VPN-Tunnel vorbeigeschleust werden können, dann ist die Implementierung fragwürdig.
Das Problem scheint übrigens nicht neu zu sein. Mullvad VPN berichtete bereits im Oktober 2022 darüber: 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). Dies wird wie folgt begründet:
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 Passage:
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 zwar technisch nachvollziehbar, aber das müsste dann 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.
Hinweis: Man kann nie sicher sein, welche Systemanwendungen oder Datenverbindungen das VPN unbemerkt passieren.
Datenminimierung
Es ist nicht möglich, den Captive-Portal-Check bei /e/ zu deaktivieren. Es ist jedoch erfreulich festzustellen, dass die standardmäßigen Google-Server (connectivitycheck.gstatic.com) nicht kontaktiert werden.4.3 /e/OS Browser
/e/ wird mit dem /e/OS Browser ausgeliefert. Der Browser ist ein Fork von Cromite (ehemals Bromite), der auf Chromium basiert und unter der GNU General Public License v3.0 lizenziert und verbreitet wird. Die folgenden Anpassungen werden von /e/ für den Browser vorgenommen:
- Standardmäßig deaktiviert:
- Autofill
- Asynchroner DNS
- Standardmäßig aktiviert:
- Do Not Track
- Benutzerdefinierte Registerkarten
- Suchvorschläge
- Mitgelieferte Suchmaschinen eingeschränkt auf:
- DuckDuckGo
- DuckDuckGo Lite
- Qwant
- espot
- Mojeek
Nachfolgend wird das Datensendeverhalten des Browsers betrachtet. Unmittelbar nach dem Start werden die folgenden Verbindungen initiiert:
- Laden von Favicons:
- e.foundation
- spot.murena.io
- community.e.foundation
- Laden einer Filterliste zum Blockieren von Werbung und Tracking: www.bromite.org
[1] Betrachten wir den Verbindungsaufbau zum Host »www.bromite.org« etwas genauer:
HEAD https://www.bromite.org/filters/filters.dat HTTP/2.0 pragma: no-cache cache-control: no-cache sec-fetch-site: none sec-fetch-mode: no-cors sec-fetch-dest: empty user-agent: Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Mobile Safari/537.36 accept-encoding: gzip, deflate, br
Weshalb der /e/OS Browser eine Filterliste vom Bromite-Projekt nachlädt, ist mir ein Rätsel. Die Entwicklung von Bromite wurde vor weniger als einem Jahr eingestellt. Wenn man das Datum der Filterliste überprüft, stellt man fest, dass es sich um eine veraltete Filterliste vom 14. Dezember 2022 handelt:
curl -I https://www.bromite.org/filters/filters.dat HTTP/2 200 server: GitHub.com content-type: application/octet-stream last-modified: Wed, 14 Dec 2022 21:12:20 GMT
Filterlisten sollten regelmäßig aktualisiert werden, um Werbung und Tracker zuverlässig erkennen und filtern zu können. Über Einstellungen -> AdBlock settings kann der Pfad zur Filterliste angepasst werden.
Insgesamt gibt es am Datensendeverhalten des Browsers nichts auszusetzen. Lediglich die Voreinstellungen könnten kritisiert werden. Über Einstellungen -> Datenschutz und Sicherheit kann man bspw. wählen, ob jede Tastatureingabe an die Suchmaschine übermittelt werden soll oder erst nachdem der Suchbegriff vollständig eingegeben und abgeschickt wurde: Suchvorschläge verbessern an/aus.
Ein Browser ist der »Schlüssel« zum Internet bzw. zum World Wide Web, mit dem wir sowohl private als auch berufliche Aufgaben erledigen. Insofern ist es von Bedeutung, dass (Sicherheits-)Updates zeitnah in den Browser integriert werden. Bei der aktuell installierten Version 1.17 von /e/ (11. November) wird die WebView-Version 117.0.5938.156 vom 18.10.2023 ausgeliefert. Die aktuelle Version stammt vom 30. November und trägt die Versionsnummer 120.0.6099.43. Das bedeutet: Es fehlen ca. über 40 (Sicherheits-)Updates im /e/OS Browser. Darunter auch kritische Updates wie bspw.:
- CVE-2023-5996: Use after free in WebAudio in Google Chrome prior to 119.0.6045.123 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.
- CVE-2023-5997: Use after free in Garbage Collection in Google Chrome prior to 119.0.6045.159 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.
- CVE-2023-6112: Use after free in Navigation in Google Chrome prior to 119.0.6045.159 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.
- CVE-2023-5482: Insufficient data validation in USB in Google Chrome prior to 119.0.6045.105 allowed a remote attacker to perform out of bounds memory access via a crafted HTML page.
- CVE-2023-5849: Integer overflow in USB in Google Chrome prior to 119.0.6045.105 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.
Betrachtet man die bisherigen Veröffentlichungszyklen von WebView, so scheint diese Verzögerung leider eher die Regel als die Ausnahme zu sein. Erst mit der Veröffentlichung der /e/-Version 1.17 im November 2023 wurde die WebView-Version auf 117.0.5938.156 aktualisiert. Davor wurde seit dem Februar 2023 die Version 108.0.5359.156 (12.12.2022) ausgeliefert. Zwischen diesen Versionen liegen nicht weniger als über 290 bekannte Sicherheitslücken.
Generell ist die derzeitige Situation alles andere als ideal, da wesentliche Sicherheitsupdates zeitnah zur Verfügung gestellt werden sollten. Hier sollte das /e/-Projekt dringend nachbessern.
4.4 (GPS-)Standort
Die Positionsbestimmung erfolgt standardmäßig ausschließlich 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/TQ3A.230901.001)
Host: location.services.mozilla.com
Connection: close
Accept-Encoding: gzip, deflate
Content-Length: 1044
{
"radioType":"lte",
"cellTowers":[
{
"radioType":"lte",
"mobileCountryCode":262,
"mobileNetworkCode":2,
"locationAreaCode":47222,
"cellId":18416660,
"signalStrength":-94,
"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 über den aktiven/verbundenen Mobilfunkmast werden auch Informationen über alle umliegenden bzw. im Empfangsbereich des Smartphones befindlichen WiFi-Netze ausgelesen und übertragen. Dazu gehören z.B. die MAC-Adresse der Router, der Übertragungskanal und auch die Signalstärke.
Durch die Verwendung von microG bzw. der integrierten Ortungsmodule hat der Benutzer die Möglichkeit, die Ortung zu beeinflussen. Die einzelnen Module können je nach Bedarf aktiviert oder deaktiviert werden:
4.5 (GPS-)Standort: Optional
/e/ ist das bisher erste Custom-ROM, das auf eine Standortbestimmung über das Secure-User-Plane-Location-Protokoll (SUPL) verzichtet. SUPL wird nur verwendet, wenn unter Einstellungen -> Standort die Option Unterstütztes GPS verwenden aktiviert ist. Standardmäßig wird dabei ein Google-Server kontaktiert und die personenbeziehbare IMSI-Nummer übermittelt. Nachfolgend habe ich diese Funktion daher testweise aktiviert, um zu prüfen, wie sich /e/ verhält.
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 /e/ wird hierbei die Gegenstelle supl.google.com über Port 7275 kontaktiert. Anbei der gekürzte Datenmitschnitt:
Internet Protocol Version 4, Src: 10.215.173.1, Dst: 74.125.71.192
Transmission Control Protocol, Src Port: 48052, Dst Port: 7275, Seq: 1, Ack: 1, Len: 98
[...]
OMA UserPlane Location Protocol
ULP-PDU
length: 98
version
maj: 2
min: 0
servind: 0
sessionID
setSessionID
sessionId: 5
setId: nai (4)
nai: suplsetid@broadcom.com
message: msSUPLSTART (1)
msSUPLSTART
sETCapabilities
posTechnology
..0. .... agpsSETassisted: False
...1 .... agpsSETBased: True
.... 1... autonomousGPS: True
.... .0.. aflt: False
.... ..1. ecid: True
.... ...0 eotd: False
0... .... otdoa: False
ver2-PosTechnology-extension
gANSSPositionMethods: 5 items
Item 0
GANSSPositionMethod
ganssId: Galileo (0)
gANSSPositioningMethodTypes
.... ..0. 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: 1190420 [bit length 28, 4 LSB pad bits, 0001 0001 1001 0000 0100 0001 0100 .... decimal value 18416660]
physCellId: 335
trackingAreaCode: b876 [bit length 16, 1011 1000 0111 0110 decimal value 47222]
rsrqResult: -17,5dB <= RSRQ < -17,0dB (8)
ta: 6
earfcn: 1801
status: current (1)
qoP
horacc: 51,159090m (19)
maxLocAge: 1s Anders als bei CalyxOS festgestellt, übermittelt /e/ nicht die personenbeziehbare IMSI-Nummer an den SUPL-Server – ein entsprechender Patch (SUPL: Don’t send IMSI / Phone number to SUPL server) verhindert dies. Dennoch erhält Google ungefähre Standortdaten, 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 eingerichtet (supl.grapheneos.org), der alle SUPL-Anfragen stellvertretend entgegennimmt bzw. weiterleitet. Das Ergebnis: Google kann die Ortungsanfrage keinem Nutzer/Gerät zuordnen. Fairerweise muss ich allerdings erwähnen, dass GrapheneOS diesen SUPL-Proxy-Server als Reaktion auf meine Analyse von CalyxOS betreibt. Das Team um 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"
Datenminimierung
Standardmäßig erfolgt die Standortbestimmung nicht über SUPL bzw. die Server von Google. Deaktiviert man die OptionUnterstütztes GPS verwenden wieder, erfolgt die Standortbestimmung ausschließlich über den Mozilla Location Service.Zur Beschleunigung der Standortbestimmung verwendet /e/ 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 /e/ von der Gegenstelle »agnss.goog« (Google Cloud):
- https://agnss.goog/rto.dat
- https://agnss.goog/lto2.dat
- https://agnss.goog/rtistatus.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://agnss.goog/rtistatus.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/TQ3A.230901.001) Host: agnss.goog Connection: Keep-Alive Accept-Encoding: gzip
Im Gegensatz zu /e/, das die (alternativen) Google-Cloud-Server 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.6 Initialisierung 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 (Push-Nachrichten) 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: 3930 [decoded gzip] Protobuf (flattened) [m:auto] [uint64] 2 3459028520354100750 [string] 3 1-929a0dca0eee55513280171a8585da7dcd3700f8 [message] 4 [message] 4.1 [string] 4.1.1 google/walleye/walleye:8.1.0/OPM1.171019.011/4448085: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-9894665 [string] 4.1.6 android-google [uint32] 4.1.7 1699704704 [string] 4.1.9 walleye [uint32] 4.1.10 33 [string] 4.1.11 Pixel 2 [string] 4.1.12 Google [string] 4.1.13 walleye [uint32] 4.1.14 0 [uint64] 4.2 1701083747039 [message] 4.3 [string] 4.3.1 system_update [string] 4.3.2 1536,0,-1,NULL [uint64] 4.3.3 1701677340580 [string] 4.6 26207 [string] 4.7 26207 [string] 4.8 mobile-notroaming [uint32] 4.9 0 [string] 6 de_DE [uint64] 7 5480246709349380108 [string] 9 b407f94a1c86 [string] 10 355031043582887 [message] 11 [string] 12 Europe/Berlin [fixed64] 13 3754807908720035693 [uint32] 14 3 [string] 15 71Q6Rn2DDZl1zPDVaaeEHItd [string] 16 008741C0F6D5C0E9 [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 420 [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 [...]
Die übermittelten Informationen sind verkürzt dargestellt, lassen aber dennoch einige Rückschlüsse zu. Es werden eine Reihe von Gerätedaten (Gerätemodell, Sprache, Land, installierte Systembibliotheken, Hardware-Features, CPU-Typ, UUIDs, Android-Version usw.) an Google übermittelt. Dazu ein Hinweis des microG-Entwicklers:
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 kann über System -> microG -> Google Geräte-Registrierung deaktiviert werden. Vor der Deaktivierung sollte man sich jedoch darüber im Klaren sein, dass danach Push-Notifications, SafetyNet und andere API-Komponenten nicht mehr (korrekt) funktionieren. Das Deaktivieren des Schiebereglers ist also gleichbedeutend mit dem Abschalten von microG:
5. Tabelle mit Datenverbindungen
/e/ hat die vom System initiierten Verbindungen nur unvollständig dokumentiert. Die nachfolgende Tabelle fasst alle identifizierten Netzwerkverbindungen in einer Übersicht zusammen:
| Domain | Zweck | Einschätzung |
|---|---|---|
| connectivity.murena.io [System] | /e/ stellt eine Verbindung zu diesem Murena-Dienst her, um festzustellen, ob das Gerät eine Verbindung zum Internet herstellen kann. | Diese Verbindung bzw. der »Check« wird am VPN vorbeigeschleust. Wie bereits erwähnt, kann man trefflich darüber streiten, ob dies ein VPN-Leak oder eine bewusste Design-Entscheidung ist. Ich sehe an dieser Stelle jedoch keinen Handlungsbedarf bei /e/ – dies ist ein Android-spezifisches Problem. |
| pool.ntp.org [System] | /e/ verbindet sich mit einem freien NTP-Server-(Pool), um die interne Uhr des Geräts zu synchronisieren. | Das kann man so machen. Alternativ könnte /e/ selbst einen NTP/SNTP-Dienst hosten. |
| ota.ecloud.global [System] | Wird verwendet, um nach System-Updates zu suchen bzw. diese zu beziehen. | Das Gerät bekommt eine einzigartige OTA-ID (Unique-Device-Identifier) zugewiesen, die bei jedem Update-Check übermittelt wird. |
| firebaseinstallations. googleapis.com [Carrier Settings] | – | Wird einmalig durchgeführt. Projekte wie DivestOS und GrapheneOS zeigen: Das ist nicht notwendig. |
| www.bromite.org [/e/OS Browser] | Laden einer Filterliste zum Blockieren von Werbung und Tracking. | Die Entwicklung von Bromite wurde vor weniger als einem Jahr eingestellt. Wenn man das Datum der Filterliste überprüft, stellt man fest, dass es sich um eine veraltete Filterliste vom 14. Dezember 2022 handelt. |
| location.services.mozilla. com [microG] | Wenn die »Location modules« von microG aktiv sind: Wird zur (Beschleunigung der) Positionsbestimmung verwendet. | Jeder muss selbst entscheiden, ob er damit einverstanden ist, dass der Mozilla Location Service Informationen über den eingebuchten Mobilfunkmast und alle (vom Smartphone) erreichbaren WiFi-Netzwerke erhält. |
| supl.google.com [System] | Wenn die Funktion »Unterstütztes GPS verwenden« aktiv ist: Wird zur (Beschleunigung der) Positionsbestimmung verwendet. | Die Verwendung eines Google SUPL-Servers ist aus meiner Sicht nicht gerade datenschutzfreundlich. Immerhin kann der Nutzer die Verwendung deaktivieren. Hinweis: Diese Funktion ist standardmäßig deaktiviert. |
| agnss.goog [System] | Wenn die Funktion »Unterstütztes GPS verwenden« aktiv ist: Wird zur (Beschleunigung der) Positionsbestimmung verwendet. | Die PSDS-Hilfsdaten werden direkt von den Google-Cloud-Servern bezogen. Dabei werden (mit Ausnahme der IP-Adresse) keine sensiblen Daten übermittelt. Hinweis: Diese Funktion ist standardmäßig deaktiviert. |
| mtalk.google.com [microG] | Wenn microG aktiv ist: Dient zum Empfang von Push-Benachrichtigungen oder zur Aufrechterhaltung der Serververbindung. | Der »Preis« für den Empfang von Push-Notifications über den Google-Dienst Firebase Cloud Messaging (FCM) ist eine ständige Aktualisierung der Verbindung – zu Google-Servern. |
| android.clients.google.com [microG] | Wenn microG aktiv ist: Mit dieser Verbindung wird das Gerät für die Nutzung von Google-Diensten vorbereitet. | Der »Preis« für die Nutzung von Google-Diensten wie Push-Notifications, SafetyNet und anderen (von microG implementierten) API-Komponenten ist eine (permanente) Datenübertragung mit den Google-Servern. Es werden eine Reihe von Gerätedaten (Gerätemodell, Sprache, Land, installierte Pakete/Apps, CPU-Typ, UUIDs, Android-Version etc. |
6. Zusätzliche Informationen zu/über das Custom-ROM
6.1 Entwickler | Institution
/e/ wird von Murena (Frankreich) entwickelt. Viele Informationen über das Entwickler-Team sind nicht verfügbar. Der Gründer hinter /e/ bzw. Murena ist Gaël Duval. Die selbsterklärte Mission von Murena lautet:
To give people freedom of choice, so they can regain control over their lives. We are committed to privacy with outstanding and transparent products and services that help people escape from digital surveillance.
Das Projekt bietet Murena-Telefone mit vorinstalliertem /e/ an, die direkt über die Website erworben werden können.
Murena bewirbt /e/ unter anderem mit folgender Aussage:
Our smartphones are running the open-source “/e/OS” operating system, which is fully “deGoogled”: by default it doesn’t send any data to Google and it’s been designed to offer a great and natural user experience.
Es scheint, dass sich meine Auffassung von deGoogled von der des /e/Projekts unterscheidet. Meine Definition ist folgende: Völlige Unabhängigkeit von Google-Diensten und der Google-Infrastruktur. Diese Unabhängigkeit könnte von /e/ sogar dadurch erreicht werden, dass microG erst dann initialisiert wird, wenn der Nutzer dies ausdrücklich wünscht. Derzeit ist microG jedoch standardmäßig aktiv und interagiert mit den Google-Servern.
6.2 Installationsvorgang
Die Installation von /e/ ist nicht ganz einfach und birgt einige Risiken. Bei der Installation auf dem Google Pixel 6a hatte ich erhebliche Schwierigkeiten. Zunächst war das Build-Image fehlerhaft, und nachdem dieses Problem behoben war, traten Schwierigkeiten mit dem Recovery-Image auf. Dadurch zogen sich die Installation und die anschließende Analyse über mehrere Wochen hin. Vermutlich sind diese Probleme darauf zurückzuführen, dass /e/ erst seit Kurzem für das Pixel 6a verfügbar ist – dennoch war es äußerst mühsam.
Abgesehen von diesen Problemen sollte die Installation bei Befolgung der Schritt-für-Schritt-Anleitung im Allgemeinen reibungslos verlaufen. Im Vergleich zu den untersuchten Custom-ROMs CalyxOS und iodéOS erfordert die Installation von /e/ etwas mehr Aufwand. Leider fehlt eine einfache Installationsroutine oder ein Installationsskript.
Easy Installer
Für 21 Geräte ist ebenfalls ein Easy Installer verfügbar, der die Installation von /e/ stark vereinfacht.6.3 Verfügbarkeit (Sicherheits-)Updates
Der wirksamste Schutz gegen bekannt gewordene oder geschlossene Schwachstellen ist das Einspielen von (Sicherheits-)Updates. Google stellt mittlerweile monatliche Sicherheitsupdates zur Verfügung, die traditionell um den 5. eines Monats veröffentlicht werden. Leider stehen viele Nutzer vor einem Dilemma: Einige Smartphone-Hersteller schaffen es oft nicht, Updates für ihre herstellerspezifischen Android-Versionen zeitnah bereitzustellen oder unterstützen ältere Geräte aus Kostengründen einfach nicht mehr. Dadurch entsteht zwangsläufig ein »Vakuum« in der Android-Welt, das viele Geräte anfällig für kritische Sicherheitslücken macht.
/e/ schreibt Folgendes zum Thema »Security«:
How does /e/OS compare against other Privacy focused Operating Systems
If you are looking for an OS with hardened security, use Graphene, if you are searching for an OS that helps you keep your data safe from Google, use /e/OS . The choice depends on your needs.
Personal privacy is a commonly accepted need. You can have the most secure device, but that will not change the fact that your data will be constantly streaming your data to Google or Facebook . Zero-privacy can be achieved in a very secure way.
There can be cases where security supports privacy, like if your device gets stolen or if you are targeted by an organization etc.
So the ideal world is a mix of security and privacy.
When do /e/OS builds get AOSP security updates and vendor patches?
When we build /e/OS, we apply the security patches available from AOSP for this Android version (ie: Android 10, Android 11, etc…). AOSP is open-source, with both Google and a large community of developers, including /e/OS working on it.
The availability of an AOSP version for a given device mostly depends on how long the open-source community is ready to support this device. Sometimes technical blocking points require moving to a more recent Android version. It is also possible that the community, for example /e/OS, LineageOS or others, will back-port the latest security patches to an older AOSP version.
With /e/OS, we sometimes have the option to make an /e/OS version based on newer Android version to provide a longer lifetime to key devices. For example, your device is initially based on Android 11, but there is a new OS version for your device based on Android 12, this will mean that your device will get security updates for a longer period. This is different from vendor provided device patches. Which end, when the last stock ROM update is published by the device manufacturer.
Es gibt keine klaren Informationen darüber, wie regelmäßig und rechtzeitig Updates bereitgestellt werden. Zur Erinnerung: /e/ ist ein Fork von LineageOS ist, das in meiner Analyse bezüglich der Bereitstellung von monatlichen Sicherheitsupdates nur mittelmäßig abgeschnitten hat. Das bedeutet, dass nach der Veröffentlichung eines Updates für LineageOS (weitere) Anpassungen an /e/ vorgenommen werden müssen, bevor das Update ausgeliefert werden kann. Je nach Gerät und aktiver Community/Maintainer kann dies zu weiteren Verzögerungen bei der Auslieferung führen. Werfen wir einen Blick auf die Verzögerungen der letzten Monate:
- 06.11.2023 -> Noch ausstehend (über 4 Wochen)
- 02.10.2023 -> 14. November 2023 (44 Tage)
- 05.09.2023 -> 24. Oktober 2023 (50 Tage)
- 07.08.2023 -> 18. September (43 Tage)
- 05.07.2023 -> 18. August (44 Tage)
Die Auslieferung von Sicherheitsupdates hat sich in den letzten Monaten um durchschnittlich 6 Wochen (und mehr) verzögert. Eine der Schwachstellen des Oktober-Updates (CVE-2023-40129) wurde beispielsweise als kritisch eingestuft, da sie Angreifern die Ausführung von Schadcode aus der Ferne und ohne Interaktion mit dem Nutzer ermöglicht. Diese Lücke wurde erst gut 6 Wochen später für /e/-Nutzer geschlossen. Je nach Schweregrad einer Sicherheitslücke ist dies ziemlich träge und setzt Nutzer einem unnötigen Risiko aus.
Zu beachten ist auch, dass viele der angebotenen Geräte-Builds keine vollständigen Sicherheitsupdates für proprietäre Komponenten wie Bootloader oder Firmware erhalten. Beispielsweise werden Geräte wie das Google Pixel 4a vom Hersteller nicht mehr mit entsprechenden Updates versorgt.
Als Anwender von /e/ sollte man sich dem erhöhten Sicherheitsrisiko bewusst sein, das mit der Verwendung von /e/ einhergeht.
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« wird aufgezeigt, welche Daten Google von einem Gerät erhebt – und das, obwohl praktisch alle Einstellungen möglichst datenschutzfreundlich konfiguriert sind.
In /e/ ist microG, die Alternative zu den 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 -> microG Dienste« kann microG auch komplett deaktiviert werden.
Aus Datenschutzsicht wäre es meines Erachtens wünschenswert, dem Nutzer bei der erstmaligen Einrichtung von /e/ die Möglichkeit zu geben, zu entscheiden, ob microG aktiviert werden soll oder nicht.
6.5 Sicherheit/Datenschutz
Aktuell unterstützt /e/ nur für sehr wenige Geräte Verified Boot. Bei der Installationsanleitung für das Google Pixel 6a wird nicht erläutert, wie man den Bootloader nach der Installation wieder sperrt (engl. locked). Bei einem Gerät, das bspw. einen offenen (unlocked) Bootloader hat und/oder auf das zusätzlich ein Recovery Image aufgespielt wurde, ist es für einen versierten Angreifer möglich, Veränderungen vorzunehmen, die für den Nutzer im Nachhinein nicht erkennbar sind. Ohne die Unterstützung von Verified Boot bewegt sich die Sicherheit von /e/ auf einem niedrigeren Niveau als die von Standard-Android-Geräten.
Neben den Standard-Sicherheitsfunktionen von Android enthält /e/ Advanced Privacy:
Advanced Privacy is a specific tool we have developed to limit your data exposure once you have installed third party apps.
When an application snoops in the background, it will use trackers to log your activity even if you are not using the app. It will also collect the IP address, so it can potentially link internet activity to a specific device and to a persona, and finally it will try to pinpoint your exact location.
Advanced Privacy lets you manage in app trackers, IP address and location. It’s available as a widget and within the operating system settings.
Advanced Privacy ist eine Kombination aus Firewall (Tracker-Blocker), GPS-Spoofer und IP-Verschleierung. Der Tracker-Blocker verwendet Filterlisten (wie AdAway, Exodus Privacy etc.) auf DNS-Ebene und funktioniert technisch ähnlich wie AdAway. Die Zusatzfunktionen Fake My Location und Hide My IP sind standardmäßig deaktiviert und sollten mit Vorsicht verwendet werden. Mit Hide My IP wird der gesamte Datenverkehr oder ausgewählte Apps über das Tor-Netzwerk geleitet. Es ist jedoch wichtig zu beachten, dass die bloße Verschleierung der IP-Adresse gegenüber einem Dienst oder einer Website nicht unbedingt eine Verbesserung des Datenschutzes/Privatsphäre bedeutet.
7. Fazit
Wir erinnern uns an das Eingangszitat:
/e/OS is a complete, fully “deGoogled”, mobile ecosystem
Ich würde dem zustimmen, wenn /e/ nicht standardmäßig microG aktivieren würde. Wenn microG aktiviert ist, sollte man sich bewusst sein, dass einige Verbindungen zu Google-Servern hergestellt werden. Meine Definition von deGoogled ist: Völlige Unabhängigkeit von den Google-Diensten und der Google-Infrastruktur. Abgesehen von der standardmäßigen Initialisierung von microG und der einmaligen Verbindung zu firebaseinstallations.googleapis.com (Carrier-Settings-App) haben die Entwickler gute Arbeit geleistet, um /e/ von Google zu befreien.
Um /e/ als datenschutzfreundlich zu bezeichnen, müsste die eindeutige OTA-ID (Unique Device-Identifier), die bei jeder Update-Prüfung übermittelt wird, entfernt werden. Ich halte solche Anpassungen in einem System, das auf den Schutz der Privatsphäre spezialisiert ist, für bedenklich.
Beim Datenschutz schneidet /e/ recht gut ab. Bei der Sicherheit muss man jedoch beide Augen zudrücken und hoffen, dass alles gut geht. Nicht nur die verzögerte Bereitstellung von Sicherheitsupdates (6 Wochen und mehr) ist erwähnenswert, sondern vor allem auch die langsame Aktualisierung der WebView-Komponenten. Wenn hier über 6 Monate keine Updates bereitgestellt werden, kann man von einem erheblichen Sicherheitsrisiko sprechen. Zusammengefasst:
- (Stark) verzögerte Auslieferung von (Sicherheits-)Updates und der WebView-Komponenten
- Ältere Geräte erhalten keine vollständigen Sicherheitsupdates von proprietären Komponenten wie Bootloader oder Firmware
- Keine Unterstützung von Verified Boot – abgesehen von sehr wenigen Geräten
In erster Linie richtet sich /e/ an datenschutzbewusste Nutzer, die ihre älteren Geräte weiter verwenden möchten, da diese möglicherweise nicht mehr vom Hersteller mit den neuesten Android-Versionen und Sicherheitsupdates versorgt werden. Allerdings sollte man sich bewusst sein, dass auch Sicherheitslücken den Datenschutz untergraben können, wenn sie von einem Angreifer ausgenutzt werden. Die alleinige Konzentration auf den Datenschutz ist daher keine Garantie dafür, dass dieser auch tatsächlich gewährleistet ist. Es sind zusätzliche Maßnahmen erforderlich, einschließlich eines aktuellen Systems, das zeitnah mit Sicherheitsupdates versorgt wird. Hier besteht bei /e/ noch erheblicher Nachholbedarf.
Über den Autor | Kuketz
In meiner freiberuflichen Tätigkeit als Pentester / Sicherheitsforscher (Kuketz IT-Security) schlüpfe ich in die Rolle eines »Hackers« und suche nach Schwachstellen in IT-Systemen, Webanwendungen und Apps (Android, iOS). Des Weiteren bin ich Lehrbeauftragter für IT-Sicherheit an der Dualen Hochschule Karlsruhe, sensibilisiere Menschen in Workshops und Schulungen für Sicherheit und Datenschutz und bin unter anderem auch als Autor für die Computerzeitschrift c’t tätig.
Der Kuketz-Blog bzw. meine Person ist regelmäßig in den Medien (heise online, Spiegel Online, Süddeutsche Zeitung etc.) präsent.
Unterstützen
Die Arbeit von kuketz-blog.de wird zu 100% durch Spenden unserer Leserinnen und Leser finanziert. Werde Teil dieser Community und unterstütze auch du unsere Arbeit mit deiner Spende.
Wenn du über aktuelle Beiträge informiert werden möchtest, hast du verschiedene Möglichkeiten, dem Blog zu folgen:
iodéOS: Datenschutzfreundlich, aber Abstriche bei der Sicherheit – Custom-ROMs Teil3
CalyxOS: De-Googled geht anders – Custom-ROMs Teil2
Klimaschutz mit Datenschutz? Der große Elektroauto-Ladeapp-Test
GrapheneOS: Der Goldstandard unter den Android-ROMs – Custom-ROMs Teil7
Ich freue mich auf Deine Beteiligung zum Artikel
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.