Warum Murena's /e/OS eine Mogelpackung ist

Heute möchte ich mich mal Murena's /e/OS widmen und warum es, wenn man genauer hinschaut, eine ziemliche Mogelpackung ist. Dieser Bericht ist eine Zusammenfassung aus verschiedenen Quellen, und beschreibt, warum /e/OS nicht das ist, was es verspricht. Wir haben uns auch deshalb vor einiger Zeit entschieden, /e/OS nicht mehr als Custom ROM Installation anzubieten. Murena selbst beschreibt sein Betriebssystem so:

"/e/OS is the leading pro-privacy operating system for smartphones. It consists of a fully deGoogled mobile operating system (OS) and carefully selected applications, together forming a privacy-enabled internal environment for mobile phones."

- e.foundation

Warum diese Aussage so ihreführend ist, und warum es /e/OS mit dem Datenschutz, der Sicherheit und der Privatsspähre nicht so ernst nimmt, schauen wir uns in diesem Beitrag an.

Themen in diesem Artikel sind unter anderem die fragwüdigen Lizenschlüssel für Sytem-Updates, die Intialisierung des Systems, bzw. der Simkarte, der Standard Browser, die standardmässige Aktivierung von MicroG, die allgemeine Sicherheit des Gerätes, der eigene Appstore und der Easy-Installer von /e/OS.

Dabei wurden einige fragwürdige Entscheidungen getroffen, die weder der Sicherheit des Systems dienen, noch der Privatspähre zuträglich sind. Fangen wir an:

Lizenzschlüssel für Updates

/e/ überprü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

//Quelle: kuketz-blog.de//

Ein interessanter Aspekt ist der GET-Parameter ota_anon_hash: anondf7302758c4740e298296396fa64815e, der bei einem Update-Check übermittelt wird. Wenn wir tiefer in den Quellcode eintauchen, entdecken wir folgende Änderungen:

• Updater: Generierung einer Lizenz-ID für OTA-Anfragen
• Einstellungen: Hinzufügen einer Präferenz für die Lizenz-ID
• Entfernung dieser Einstellungen
• Basis: Hinzufügen von OTA-Lizenz-ID-Einstellungen

Es ist zu sehen, dass /e/ offenbar ein Lizenzschlüsselsystem für OTA-Updates verwendet. Die Änderungen an der Benutzeroberfläche wurden jedoch wieder entfernt. Als Benutzer kann man seine einzigartige OTA-ID (Unique-Device-Identifier) nicht verändern.

Kritik am Updateverhalten

Aus einer Datenschutzperspektive gibt es bei diesem Vorgehen mehrere kritische Punkte:

1. Transparenz und Benutzerinformation:
   • Die Einführung eines Lizenzschlüsselsystems für OTA-Updates ohne ausreichende Information der Benutzer ist problematisch. Benutzer haben ein Recht darauf zu wissen, welche Daten gesammelt und verarbeitet werden. Die Tatsache, dass die Änderungen an der GUI entfernt wurden und Benutzer ihre einzigartige OTA-ID nicht einsehen können, verstärkt das Gefühl der Intransparenz.
2. Datensicherheit und Anonymität:
   • Der übermittelte Parameter ota_anon_hash mag auf den ersten Blick anonym erscheinen, jedoch handelt es sich um eine eindeutige Identifikationsnummer. Solche IDs können, wenn sie nicht richtig gesichert und verwaltet werden, missbraucht werden, um Benutzer zu verfolgen oder ihre Aktivitäten zu überwachen.
3. Zweckbindung und Datenminimierung:
   • Es stellt sich die Frage, warum ein Lizenzschlüsselsystem überhaupt notwendig ist und ob es keine weniger invasive Methode gibt, um Updates zu verwalten. Prinzipien der Datenminimierung und Zweckbindung verlangen, dass nur die notwendigsten Daten erhoben werden. In diesem Fall scheint die Erhebung einer eindeutigen Identifikationsnummer über das hinauszugehen, was für die reine Bereitstellung von Updates erforderlich ist.
4. Rechtliche Rahmenbedingungen und Einwilligung:
   • Abhängig von der Rechtsordnung, in der /e/ operiert, könnte die Einführung eines solchen Systems ohne explizite Einwilligung der Benutzer gegen Datenschutzgesetze verstoßen. Insbesondere in der EU sind die Anforderungen der DSGVO (Datenschutz-Grundverordnung) zu beachten, die klare Richtlinien zur Einholung von Einwilligungen und zur Information der betroffenen Personen vorschreibt.
5. Risikobewertung und Folgenabschätzung:
   • Vor der Einführung eines solchen Systems sollte eine Datenschutz-Folgenabschätzung durchgeführt werden, um die Risiken für die Privatsphäre der Benutzer zu bewerten und geeignete Maßnahmen zur Risikominderung zu implementieren. Es ist unklar, ob /e/ eine solche Bewertung durchgeführt hat und welche Schutzmaßnahmen ergriffen wurden.

Zusammenfassend lässt sich sagen, dass das Vorgehen von /e/ ziemliche Datenschutzbedenken aufwirft. Es mangelt an Transparenz, Benutzerinformation und einer klaren Zweckbindung. Darüber hinaus ist die rechtliche Grundlage für die Erhebung und Verarbeitung der eindeutigen Identifikationsnummer fragwürdig. Ohne angemessene Schutzmaßnahmen und eine klare Kommunikation gegenüber den Benutzern könnte dieses Vorgehen das Vertrauen der Benutzer in den Service erheblich beeinträchtigen.

GrapheneOS oder CalyxOS verwenden solche Identifier zum Beispiel nicht.

Initialisierung der SIM-Karte

Bei der (ersten) Inbetriebnahme der SIM-Karte initiiert die App Carrier Settings eine Verbindung zu Google Firebase – einer 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"
}

//Quelle: kuketz-blog.de//

Die Anwendung Carrier Settings nimmt einige Systemeinstellungen für das Modem und den Netzbetreiber vor, darunter auch APN-Einstellungen. Es ist jedoch unklar, warum dazu eine Verbindung zu firebaseinstallations.googleapis.com notwendig ist. Projekte wie DivestOS, CalyxOS und GrapheneOS entfernen die Carrier-Settings-App (und weitere Komponenten) aus dem System, was darauf hindeutet, dass dieser Vorgang nicht notwendig ist.

Kritik am Initialiserungsverhalten

Wenn ein Betriebssystem sich als "degoogled" bewirbt, also ausdrücklich damit wirbt, ohne die Dienste von Google auszukommen, dann wirft die Einbindung von Google Firebase durch die Carrier Settings App mehrere kritische Fragen auf, vor allem, da dies in keinster weise notwendig ist.

/e/OS Standard Browser

Filterlisten und Einstellungen

/e/ wird mit dem /e/OS Browser ausgeliefert. Dieser Browser ist ein Fork von Cromite (früher bekannt als Bromite), der auf Chromium basiert und unter der GNU General Public License v3.0 (GPLv3) lizenziert und verbreitet wird. /e/ nimmt die folgenden Anpassungen an dem Browser vor:

• 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

Der Browser lädt eine komplett veraltete Filterliste nach, die seit 2022 nicht mehr geupdated wurde:

Warum so eine veraltete Liste verwendet wird, ist mir schleierhaft.

Updateverhalten vom Browser

Ein Webbrowser fungiert als Zugangstor zum Internet, und andersrum auch Eintrittspforte ins System, und spielt somit eine zentrale Rolle bei der Ausführung sowohl privater als auch beruflicher Aufgaben. Daher ist es kritisch, dass Sicherheitsupdates schnell in den Browser integriert werden. Historisch gesehen dauerte es bei /e/OS jedoch oft sehr lange, bis Sicherheitslücken geschlossen wurden. Zum Beispiel wurde die Version 1.17 des /e/OS im November 2023 veröffentlicht, die die WebView-Version 117.0.5938.156 enthielt, obwohl diese Version bereits seit Oktober desselben Jahres verfügbar war. Somit fehlten in dieser Installation bereits über 40 wichtige Sicherheitsupdates, darunter kritische Patches gegen Schwachstellen, die etwa durch manipulierte HTML-Seiten ausgenutzt werden könnten, wie zum Beispiel Speicherfehler und Datenüberläufe.

Die Verzögerungen bei der Aktualisierung von WebView in /e/OS scheinen eher die Regel als die Ausnahme zu sein. Beispielsweise war vor der Aktualisierung im November 2023 die seit Dezember 2022 installierte Version 108.0.5359.156 fast ein Jahr lang in Gebrauch, während dieser Zeit wurden über 290 bekannte Sicherheitslücken nicht behoben.

Kritik am Browser

Insgesamt zeigt sich, dass /e/OS erheblichen Nachholbedarf bei der Integration von Sicherheitsupdates hat, was eine schnellere Reaktion auf neue Bedrohungen erfordert, um die Sicherheit der Nutzer zu gewährleisten. Ausserdem seid ihr mit einem besonderen Browser wie Cromite viel besser zu identifzieren, als mit einem Standard Open Source Browser wie Chromium oder Firefox.

Standardmässige Aktivierung von MicroG

Der grösste Kritikpunkt ist wohl die standardmässige Aktivierung von MicroG. Es gibt keine Möglichkeit, /e/OS ohne MicroG zu verwenden, und sämtliche MicroG Funktionen sind beim ersten Start per default aktiviert. Das heisst, dass sich euer /e/OS Phone standardmässig bei Google-Servern registriert, und auch Push Verbindungen aufgebaut werden.

In der Grundeinstellung des microG-Systems stellt dieses häufig eine Verbindung zu Google her. Diese Verbindung dient dazu, Push-Benachrichtigungen von Apps über einen TCP-Stream zu empfangen. Dies geschieht durch die Herstellung einer TCP-Verbindung zu einem Google-Server, beispielsweise mtalk.google.com (zum Beispiel unter der IP-Adresse 173.194.76.188 auf dem Port 5228). Der Datenverkehr auf diesem TCP-Stream erfolgt sowohl eingehend als auch ausgehend in Bezug auf Google.

Das Problem an der Sache ist, dass die Verbindungen aufgebaut werden, sollte das Phone mit aktivierter Interverbindung eingerichtet werden.

Wer /e/OS nutzt, und keine Verbindung zu Google-Servern möchte, muss das Smartphone mit /e/OS ohne Internet/WLAN einrichten, und danach direkt die Geräteregistrierung in MicroG deaktivieren

Kritik an der standardmässigen MicroG Aktivierung

Die Tatsache, dass bei /e/OS microG standardmäßig aktiviert ist und eine Verbindung zu Google aufbaut sowie das Gerät registriert, wenn das Smartphone nicht offline eingerichtet und die Geräteregistrierung nicht deaktiviert wird, ist aus mehreren Gründen höchst problematisch, insbesondere für ein Betriebssystem, das sich als "degoogled" bezeichnet:

Es ist ein kompletter Widerspruch zur Kernphilosophie: /e/OS wirbt damit, ein datenschutzfreundliches und Google-freies Betriebssystem zu sein. Die automatische Aktivierung von microG und die damit verbundene Registrierung bei Google steht im direkten Widerspruch zu diesem Versprechen. Nutzer, die sich für /e/OS entscheiden, erwarten ein System, das vollständig unabhängig von Google-Diensten ist.

Die Verbindung zu Google und die Registrierung des Geräts bedeutet, dass Nutzerdaten, einschließlich möglicherweise sensibler Informationen, an Google übermittelt werden. Viele Nutzer wählen /e/OS gerade, um ihre Daten vor den neugierigen Augen großer Technologiekonzerne wie Google zu schützen. Diese unerwartete Datenübertragung kann das Vertrauen der Nutzer erheblich untergraben.

Wenn Nutzer nicht explizit informiert werden, dass microG aktiviert ist und eine Verbindung zu Google herstellt, fehlt es an Transparenz. Die Nutzer sollten klar und deutlich darüber informiert werden und die Möglichkeit haben, diese Funktion bei der Einrichtung des Geräts zu deaktivieren. Die Notwendigkeit, das Smartphone offline einzurichten, um die Registrierung zu vermeiden, ist umständlich und nicht intuitiv.

CalyxOS lässt euch bei der Installation/Einrichtung die Wahl, ob MicroG installiert werden soll oder nicht. Der Umstand, dass euch /e/OS weder die Wahl lässt, noch aufklärt, welche Verbindungen wirklichen aufgebaut werden, lässt mich stark an der wirklichen Intention von Murenas /e/OS zweifeln.

Sicherheit des Gerätes

Derzeit bietet /e/ für eine begrenzte Anzahl von Geräten die Funktion Verified Boot an. Die Installationshinweise für viele Geräte beinhalten keine Anweisungen, wie man den Bootloader nach der Installation wieder verriegelt. Geräte mit einem entsperrten Bootloader oder denen zusätzlich ein Recovery-Image hinzugefügt wurde, sind anfällig dafür, dass ein erfahrener Angreifer Änderungen vornimmt, die vom Nutzer später nicht bemerkt werden können. In Ermangelung der Verified Boot Unterstützung ist die Sicherheit bei /e/ geringer als bei herkömmlichen Android-Geräten. Ein Standard Google Phone ist somit sicherer, als ein Phone, auf dem /e/OS installiert worden ist.

Die Geräte, die bei /e/OS offiziel gekauft werden können, bieten jedoch einen gesperrten Bootloader, und gelten somit als sicher.

Eigener App Store mit Sicherheitsproblemen

/e/OS setzt nicht auf F-Droid oder den Aurora, sondern bietet einen eigenen Appstore namens App Lounge an, der scheinbar eine reiche Auswahl mit Zehntausenden Apps bietet. Nutzer können sowohl über die /e/OS-Website als auch direkt im Betriebssystem Apps durchstöbern. Bei näherer Betrachtung zeigt sich jedoch, dass viele Apps veraltet sind. Beispielsweise wird auf der Website eine zwei Jahre alte Version von Signal (4.54.3) gelistet, obwohl die aktuellste Version 5.35.3 ist. Ähnlich veraltet ist die angebotene Firefox-Version 68.4.2, was ziemliche Sicherheits- und Datenschutzrisiken birgt.

Nicht nur die veralteten App-Versionen stellen ein Problem dar, sondern auch die Herkunft der Apps gibt Anlass zur Sorge. Die F-Droid Apps werden über Cleanapk.org bezogen, deren Betreiber laut den FAQ von /e/OS anonym bleiben möchten. Anders als in den FAQ angegeben, wird in der Entwicklerseite des App Stores im Gitlab nicht F-Droid, sondern der Google Play Store als Quelle genannt, wobei die Apps über die GplayAPI des Aurora Stores bezogen werden.

Für Nutzer, die Wert auf Sicherheit legen, ist die Installation des alternativen App-Stores F-Droid empfehlenswert. Wer auf Apps aus dem Google Play Store nicht verzichten möchte, sollte besser auf den Aurora Store zurückgreifen, anstatt den vorinstallierten App Store von /e/OS zu nutzen.

Die Versprechen von der e.foundation, cleanapk aus dem Repetoir zu werfen, wurde bis heute nicht umgesetzt, man kommt lieber mit Ausreden, und lässt die Leute mit Pauschalen Aussagen im Regen stehen:

https://community.e.foundation/t/why-is-e-os-still-using-cleanapk-org-and-passing-users-ip-addresses/51809

https://community.e.foundation/t/app-lounge-vs-aurora-store/59464/11

eOS Easy-Installer nur über Snap installierbar

Die Entscheidung von /e/OS, ihren Easy Installer ausschließlich über Snap zu vertreiben, kann für viele Nutzer eine ziemliche Einschränkung darstellen. Snap, entwickelt von Canonical für Ubuntu, ist ein Paketmanagement- und Verteilungssystem, das darauf abzielt, die Installation und Aktualisierung von Apps zu vereinfachen und sicherer zu gestalten. Trotz dieser Vorteile steht Snap in der Linux-Gemeinschaft unter Kritik. Einige der Hauptkritikpunkte umfassen:

1. Performance-Probleme: Snaps starten oft langsamer als traditionelle Pakete, da sie in einem Container laufen, was zusätzliche Overheads verursacht. Dies kann besonders auf älterer Hardware oder Systemen mit begrenzten Ressourcen spürbar sein.
2. Speicherplatzverbrauch: Snaps können mehr Speicherplatz beanspruchen, weil jede Snap-Anwendung ihre eigenen Abhängigkeiten mitbringen muss, statt sich vorhandene Systembibliotheken zu teilen.
3. Automatische Updates: Snaps aktualisieren sich automatisch und ohne die Möglichkeit für den Benutzer, dies zu steuern. Während regelmäßige Updates aus Sicherheitssicht vorteilhaft sein können, bevorzugen viele Linux-Nutzer eine feinere Kontrolle über den Update-Prozess, insbesondere wenn Updates potenzielle Stabilitätsprobleme verursachen könnten.
4. Proprietäres Backend: Der Snap Store, betrieben von Canonical, ist nicht vollständig offen. Dies steht im Widerspruch zu den Grundsätzen vieler in der Linux-Gemeinschaft, die eine vollständige Transparenz und Offenheit bevorzugen.

Die exklusive Bereitstellung des /e/OS Easy Installers über Snap könnte daher Nutzer abschrecken, die diese Bedenken teilen oder die aus technischen oder ideologischen Gründen alternative Paketmanager bevorzugen. Linux-Nutzer schätzen in der Regel Vielfalt und Flexibilität in ihrer Softwareverwaltung, und die Beschränkung auf ein einzelnes Verteilungssystem kann als unnötig restriktiv wahrgenommen werden.

Zusätzlich könnte die Verfügbarkeit in anderen Formaten wie .deb, .rpm oder sogar als Flatpak die Zugänglichkeit und Akzeptanz des Installers erheblich verbessern. Indem man Nutzern mehrere Installationswege bietet, könnte /e/OS hier eine breitere und vielfältigere Benutzerbasis erreichen und damit die Verbreitung und Akzeptanz ihres Betriebssystems fördern, anstatt dies aber zu tun, wird nur ein proprietäres Back-End zur Installation des Easy-Installers angeboten.

Fazit

Warum lasse ich mich an /e/OS so aus, und warum biete ich immer noch Lineage Systeme an? Ich persönlich finde, LineageOS kann ein guter Einstieg sein, um herauszufinden, ob man mit einem System ohne die G-Play Services zurecht kommt, oder nicht. Viele haben noch ein älteres Gerät zuhause rumliegen, welches möglicherweise mit Lineage kompatible ist und können dies als Testobjekt verwenden. Ich gebe bei Lineage auch immer mit, dass das System seine Macken hat, nicht vollständig googlefrei ist und wirklich nur für eine Übergangsphase verwendet werden sollte. Der Unterschied ist jedoch, bei LineageOS behaupted man nicht vollmundig, dass man vollständig "degoogled" ist, und man verkauft auch keine Phones mit diesem falschen Versprechen. Deshalb stösst mir /e/ auch sauer auf, und deshalb habe ich diesem Thema einen eigenen Beitrag gewidmet.

/e/OS wird als vollständig „deGoogled“es mobiles Ökosystem beschrieben. Diese Einschätzung könnte eventuell zutreffen, wenn nicht standardmäßig microG aktiviert wäre, das Verbindungen zu Google-Servern herstellt. Unter „deGoogled“ verstehe ich eine komplette Unabhängigkeit von Google-Diensten und -Infrastruktur. Bis auf die Anfangsaktivierung von MicroG und eine einmalige Verbindung via firebaseinstallations.googleapis.com haben die Entwickler jedoch teilweise Anstrengungen unternommen, um /e/ von Google zu lösen, daz gehört aber nicht nur das reine Entfernen von den G-Play Services.

Desweiteren ist für eine datenschutzfreundlichere Bewertung von /e/ ist die Entfernung der Unique Device-Identifier, die bei Update-Prüfungen übermittelt wird, notwendig. Dies stellt bei einem auf Privatsphäre ausgelegten System eine problematische Anpassung dar.

Im Datenschutzbereich schneidet /e/ aufgrund der entfernten G-Play Services noch ganz okay ab, doch bei der Sicherheit gibt es bedeutsame Schwächen. Die verzögerte Bereitstellung von Sicherheitsupdates und die langsame Aktualisierung der WebView-Komponenten, oft über sechs Monate hinweg, stellen ein erhebliches Sicherheitsrisiko dar. Geräte erhalten zudem nicht durchgehend vollständige Updates für proprietäre Komponenten wie Bootloader oder Firmware, und die Unterstützung von Verified Boot ist begrenzt.

An welche Nutzer sich /e/OS richtet, kann ich nicht wirklich definieren. Das Betriebssystem setzt fragwürdige Einstellungen, und verkauft das ganze als komplett Google-Frei. Man könnte die Nutzer wenigsten vor die Wahl stellen, beispielsweise MicroG zu verwenden, oder nicht. Zudem können die vielen Sicherheitslücken auch den Datenschutz erheblich beeinträchtigen. Die alleinige Fokussierung auf das entfernen der G-Play Services bietet keine Sicherheit und keine Privatspähre. Es sind zusätzliche Maßnahmen und zeitnahe Sicherheitsupdates erforderlich, worin bei /e/ noch enormes Verbesserungsbedarf besteht.

Quellen: https://www.kuketz-blog.de/e-datenschutzfreundlich-bedeutet-nicht-zwangslaeufig-sicher-custom-roms-teil6/

Vielen Dank an Mike Kuketz für die ausführliche Analyse zum Datensendeverhalten von /e/OS!