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 DivestOS einer Analyse unterzogen. Das Custom-ROM wird wie folgt beworben:
A mobile operating system divested from the norm.
»take back (some) control of your device«
Wird DivestOS 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. DivestOS
DivestOS ist ein Open-Source-Betriebssystem für mobile Geräte (Smartphones und Tablets), das auf dem quelloffenen Android von Google basiert. Es handelt sich um einen Soft Fork von LineageOS, der darauf abzielt, die Sicherheit und den Datenschutz zu erhöhen sowie ältere Geräte zu unterstützen. DivestOS strebt an, proprietäre Android-Komponenten weitestgehend zu entfernen und ausschließlich freie Software zu verwenden.
Das aktuelle DivestOS-Betriebssystem ist in der Version 20.0 für eine Vielzahl von Geräten erhältlich, darunter Modelle von Herstellern wie Sony, Fairphone, Google, Samsung, OnePlus und Xiaomi. Es ist jedoch zu beachten, dass nicht alle Builds lauffähig sind, einige sind als Broken gekennzeichnet. Für bestimmte Geräte sollte man keine vollständigen Sicherheitsupdates für proprietäre Komponenten wie Bootloader oder Firmware erwarten. Beispielsweise werden Geräte wie das Google Pixel 3 nicht mehr vom Hersteller mit entsprechenden Updates versorgt. DivestOS richtet sich hauptsächlich an Nutzer, deren Fokus auf dem Betrieb älterer Geräte liegt, die keine Android-Updates mehr von den Herstellern erhalten. Es spricht jedoch nicht nur diese Zielgruppe an, wie die nachfolgende Analyse zeigt. Auch Nutzer, mit einem hohen Anspruch an Datenschutz, werden von DivestOS nicht enttäuscht. Wenn man ein aktuelles Gerät (Golden Devices) verwendet, das noch mit Updates für proprietäre Komponenten vom Hersteller versorgt wird, spricht DivestOS auch Nutzer an, die Wert auf Sicherheit legen.
Insgesamt ist DivestOS relativ minimalistisch und integriert nur eine kleine Auswahl an Standardanwendungen. Weitere Apps können aus dem F-Droid-Store bezogen werden, der fest im System integriert ist. Durch die Entfernung unnötiger proprietärer Komponenten (Blobs) und die Fokussierung auf freie Software möchte DivestOS die Kontrolle über persönliche Daten in die Hände der Nutzer legen.
Im Vergleich zu den analysierten Custom-ROMs CalyxOS und iodéOS erfordert die Installation von DivestOS etwas mehr Aufwand. Es fehlt eine einfache Installationsroutine oder ein Installer-Skript, was bedauerlich ist. Stattdessen muss sich der Nutzer durch eine teils verwirrende Installationsanleitung hangeln, die insbesondere Anfänger/Umsteiger abschrecken dürfte. Daher ist der Einstieg in DivestOS im Vergleich zu Betriebssystemen wie GrapheneOS oder iodéOS etwas anspruchsvoller. Die Hürde, DivestOS zu betreiben, liegt damit ungleich höher.
Interessierte können sich in der umfangreichen Dokumentation (Website -> Menü links -> Docs) vorab über DivestOS informieren und über diverse Support-Kanäle (XMPP, Matrix, Reddit, Discord etc.) Hilfe erhalten. Ein Teil der Dokumentation widmet sich den Network Connections, die aufzeigen, wohin (Server/Gegenstelle) und zu welchem Zweck das System Verbindungen aufbaut. Zitat aus der Dokumentation:
Here is a list of expected network connections for security/verification purposes. Address key:
- ✅ – should not contain any of the following: personal information, device identifiers, or other persistent identifiers.
- ❌ – known to contain personal information or identifiers.
- ❓ – has not been sufficiently reviewed
DivestOS bietet übrigens keine Unterstützung für Google-Play-Dienste, microG oder Sandboxed Play Services (GrapheneOS). Das schränkt die Auswahl an lauffähigen Apps bzw. Funktionen (Push-Benachrichtigungen) etwas ein.
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.Unterstütze den Blog mit einem Dauerauftrag!
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 DivestOS kann die Standortermittlung aktiviert/deaktiviert werden. Unabhängig von eurer Entscheidung bei der Einrichtung kann die Einstellungen jederzeit während des Betriebs angepasst werden:
Während der mehrwöchigen Testphase kamen folgende DivestOS-Versionen zum Einsatz:
- Google Pixel 6a (bluejay): divested-20.0-20230416 (16. April 2023)
- Google Pixel 6a (bluejay): divested-20.0-20230505 (5. Mai 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?
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:
- www.google.com
- android.pool.ntp.org
- connectivitycheck.gstatic.com
Nach der Auflösung der Domainnamen in die zugehörige IP-Adresse startet das System eine Aktualisierung der (Netzwerk-)Zeit via NTP zum Server 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 Android eine Anfrage an die Adresse connectivitycheck.gstatic.com. Die Überprüfung der Konnektivität erfolgt durch folgende GET-Anfrage:
GET http://connectivitycheck.gstatic.com/generate_204 User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.32 Safari/537.36 Host: connectivitycheck.gstatic.com 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
Die dritte Verbindung erfolgt dann zu www.google.com und ist eine Art Fallback, wenn die unverschlüsselte HTTP-Verbindung zu connectivitycheck.gstatic.com fehlschlägt. Während der Tests erfolgte die Verbindung zu www.google.com jedes Mal, sobald der Captive-Portal-Check durchgeführt wurde.
Datenminimierung
Bei DivestOS kann der Captive-Portal-Check über »Einstellungen -> Netzwerk & Internet -> Internet connectivity check« angepasst werden. Standardmäßig wird für den Connectivity-Check ein Google-Server verwendet. Es stehen allerdings noch zahlreiche Alternativen zur Verfügung wie bspw. DivestOS (US), Ubuntu (UK) oder auch mein Captive-Portal-Check Kuketz (DE). Wahlweise kann der Connectivity-Check auch vollständig deaktiviert werden – die Deaktivierung bedeutet allerdings auch, dass Captive-Portals dann nicht (immer) zuverlässig erkannt werden können.3.2 Geräte-Updates
DivestOS prüft regelmäßig (standardmäßig einmal pro Woche), ob neue System-Updates zur Verfügung stehen. Der Update-Check erfolgt über die Adresse divestos.org:
GET https://divestos.org/updater.php?base=LineageOS&device=bluejay&inc=engemy20230504212139 User-Agent: Dalvik/2.1.0 (Linux; U; Android 13; Pixel 6a Build/TQ2A.230505.002) Host: divestos.org Connection: Keep-Alive Accept-Encoding: gzip
Als Antwort erfolgt dann (hier im Beispiel Update auf divested-20.0-20230505-dos-bluejay.zip):
{
?"response": [
?{
?"filename": "divested-20.0-20230505-dos-bluejay.zip",
?"url": "https://divestos.org/mirror.php?base=LineageOS&f=bluejay/divested-20.0-20230505-dos-bluejay.zip",
?"version": "20.0",
?"romtype":"dos",
?"id": "b65f2dedefc50460e59c74e4818157c6",
?"datetime": 1683252053,
?"size": 1060341352,
?"status": 0
?}
?]
} Darin sind Informationen des neuen Builds bzw. inkrementellen Updates enthalten:
- Dateiname: divested-20.0-20230505-dos-bluejay.zip
- Bezugsquelle: https://divestos.org/mirror.php?base=LineageOS&f=bluejay/divested-20.0-20230505-dos-bluejay.zip
- Version: 20.0
- […]
Sofern ein Update bereitsteht, wird der Download nicht automatisch initiiert, sondern der Nutzer muss dies mit einem Tipp auf HERUNTERLADEN auslösen:
GET https://divestos.org/builds/LineageOS/bluejay/divested-20.0-20230505-dos-bluejay.zip Range: bytes=4847682- User-Agent: Dalvik/2.1.0 (Linux; U; Android 13; Pixel 6a Build/TQ2A.230505.002) Host: divestos.org 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.
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. Es wurde mehrmals 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.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 connectivitycheck.gstatic.com bzw. www.google.com. 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.
Datenminimierung
Bei DivestOS kann der Captive-Portal-Check über »Einstellungen -> Netzwerk & Internet -> Internet connectivity check« angepasst werden. Standardmäßig wird für den Connectivity-Check ein Google-Server verwendet. Es stehen allerdings noch zahlreiche Alternativen zur Verfügung wie bspw. DivestOS (US), Ubuntu (UK) oder auch mein Captive-Portal-Check Kuketz (DE). Wahlweise kann der Connectivity-Check auch vollständig deaktiviert werden – die Deaktivierung bedeutet allerdings auch, dass Captive-Portals dann nicht (immer) zuverlässig erkannt werden können.4.4 Browser: Mull
DivestOS wird ohne vorinstallierten Browser ausgeliefert – es existiert lediglich ein Placeholder für den Mull-Browser, der von DivestOS stammt:
Mull is not installed by default, only an empty shim/placeholder is. F-Droid will prompt you to „update“ it on first run which will install it.
Beim ersten Start von F-Droid wird Mull automatisch geladen. Mit einem Tipp auf Aktualisieren ist der Browser dann installiert. Allerdings muss nach der Installation zunächst der »Netzwerkzugriff erlaubt« werden – offenbar eine Eigenheit von DivestOS 19.1 und 20.0.
Mull ist ein Firefox-Fork, der von DivestOS wie folgt angepasst wurde:
This is a privacy oriented and deblobbed web browser based on Mozilla technology. It enables many features upstreamed by the Tor uplift project using preferences from the arkenfox-user.js project. It is compiled from source and proprietary blobs are removed using scripts by Relan from here.
Daneben gibt es noch einige Besonderheiten bei Mull, die man kennen sollte. Hier ein Ausschnitt:
- Dark mode for websites is disabled due to resist fingerprinting. Please do not disable RFP.
- Refresh rate is capped to 60hz due to resist fingerprinting. Please do not disable RFP.
- If audio/video content fails to play in private tabs navigate to about:config and change browser.privatebrowsing.forceMediaMemoryCache to false, this is however a privacy risk.
- […]
Sofern man die Einschränkungen und Fallstricke kennt, die im Betrieb auftreten können, ist es nun Zeit den Browser ein erstes Mal zu starten. Unmittelbar nach dem ersten/initialen Start werden folgenden Verbindungen initiiert:
- www.wikipedia.org (Erfolgt aufgrund des Nachladens des Favicons)
- firefox.settings.services.mozilla.com
- shavar.services.mozilla.com
Was hierbei genau übermittelt wird, kann ich leider erst einmal nicht einsehen, da Mull 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 Mull Entwickleroptionen wie folgt aktivieren: Über Einstellungen bei »Über Mull« siebenmal auf das Mull-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. Zusätzlich muss nun noch das Certificate-Pinning über die about:config deaktiviert werden. Das erfolgt über den folgenden Parameter:
security.cert_pinning.enforcement_level = 0
Nachdem diese »Hürden« genommen sind, können wir die Datenverbindungen nachfolgend genauer unter die Lupe nehmen.
[1] Verbindungsaufbau zu Mozilla zum Host »shavar.services.mozilla.com«:
POST https://shavar.services.mozilla.com/downloads?client=Firefox&appver=113.0&pver=2.2
Host: shavar.services.mozilla.com
User-Agent: Mozilla/5.0 (Android 13; Mobile; rv:109.0) Gecko/113.0 Firefox/113.0
Accept: */*
Accept-Language: de-DE
Accept-Encoding: gzip, deflate, br
Content-Type: text/plain
Content-Length: 453
Connection: close
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: no-cors
Sec-Fetch-Site: none
Pragma: no-cache
Cache-Control: no-cache
mozplugin-block-digest256;
ads-track-digest256;
social-track-digest256;
analytics-track-digest256;
content-track-digest256;
mozstd-trackwhite-digest256;
google-trackwhite-digest256;
base-fingerprinting-track-digest256;
base-cryptomining-track-digest256;
social-tracking-protection-facebook-digest256;
social-tracking-protection-linkedin-digest256;
social-tracking-protection-twitter-digest256;
base-email-track-digest256;
content-email-track-digest256; Hinter der Adresse »tracking-protection.cdn.mozilla.net« verbirgt sich der Shavar-Server von Mozilla. Dieser Server überträgt neue Filterlisten für Werbung, Fingerprinting, Cryptomining und ähnliche Inhalte an den Client, sofern ein Update verfügbar ist. Diese Filterlisten sind ein integraler Bestandteil der in Firefox integrierten Tracking Protection, die einen verbesserten Schutz vor Aktivitätenverfolgung bietet. Wenn Updates verfügbar sind, werden sie von dieser Adresse bezogen. Ein Beispiel dafür wäre:
- https://tracking-protection.cdn.mozilla.net/mozplugin-block-digest256/1604686195
- https://tracking-protection.cdn.mozilla.net/social-track-digest256/1668785275
- https://tracking-protection.cdn.mozilla.net/analytics-track-digest256/1683905755
- […]
[2] Verbindungsaufbau zu Mozilla zum Host »firefox.settings.services.mozilla.com«:
GET https://firefox.settings.services.mozilla.com/v1/buckets/monitor/collections/changes/changeset?collection=anti-tracking-url-decoration&bucket=main&_expected=0 user-agent: Mozilla/5.0 (Android 13; Mobile; rv:109.0) Gecko/113.0 Firefox/113.0 accept: */* accept-language: de-DE accept-encoding: gzip, deflate, br sec-fetch-dest: empty sec-fetch-mode: no-cors sec-fetch-site: cross-site te: trailers
Bei der Gegenstelle »firefox.settings.services.mozilla.com« handelt es sich um einen Server von Mozilla, der auf Anfrage XML-Dateien zurückgibt. Diese XML-Dateien enthalten unter anderem die neuesten Informationen zu Datenlecks bei Zugangsdaten oder Zertifikatswiderrufen. Weitere Informationen zur Verbindung finden ihr auch in der Zusammenfassung »Firefox baut unaufgefordert Verbindungen auf« von Mozilla. Anbei ein 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
Insgesamt gibt es am Datensendeverhalten des Browsers nichts auszusetzen. Man könnte lediglich Kritik an der Standardsuchmaschine DuckDuckGo üben. Über Einstellungen -> Suchen lässt sich dies allerdings anpassen. Dort kann man wählen, ob jede Tastatureingabe an die Suchmaschine übermittelt wird oder erst nachdem der Suchbegriff vollständig eingegeben und abgesendet wurde: Suchvorschläge anzeigen an/aus.
Die (Sicherheits-)Updates befinden sich ebenfalls auf dem aktuellsten Stand. Oftmals erscheinen die Aktualisierungen von Mull nur wenige Stunden, nachdem Mozilla eine neue Firefox-Version veröffentlicht hat – das ist wirklich zeitnah und fix.
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 LineageOS 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: 108.177.15.192
Transmission Control Protocol, Src Port: 58736, 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: 6
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: 280
trackingAreaCode: b876 [bit length 16, 1011 1000 0111 0110 decimal value 47222]
rsrqResult: -16,0dB <= RSRQ < -15,5dB (8)
ta: 5
earfcn: 6300
status: current (1)
qoP
horacc: 51,159090m (19)
maxLocAge: 1s Anders als bei CalyxOS festgestellt, übermittelt DivestOS nicht die personenbeziehbare IMSI-Nummer an den SUPL-Server – ein entsprechender Patch (0003-SUPL_No_IMSI.patch) 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"
Datenminimierung
Seit DivestOS (11.02.2023) lässt sich das Verhalten über »Einstellungen -> Standort -> Force disable Secure User Plane (SUPL)« beeinflussen. Aktiviert man die Option, wird die SUPL-Anfrage zur Standortbestimmung deaktiviert und Google damit nicht angefragt. Auch dies wurde erstmals in GrapheneOS implementiert und dann vom DivestOS-Team nachgebaut. Einziger Wermutstropfen: Die Standortbestimmung erfolgt dann ausschließlich über die GNSS-Schnittstelle, was die Ortungszeit allerdings erheblich verlängern kann.Zur Beschleunigung der Standortbestimmung nutzt DivestOS 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 DivestOS 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/TQ2A.230505.002) Host: gllto.glpals.com Connection: Keep-Alive Accept-Encoding: gzip
Im Gegensatz zu DivestOS, 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
5. Tabelle mit Datenverbindungen
DivestOS hat Verbindungen, die vom System initiiert werden, vollständig dokumentiert. Die nachfolgende Tabelle fasst alle identifizierten Netzwerkverbindungen in einer Übersicht zusammen:
| Domain | Zweck | Einschätzung |
|---|---|---|
| connectivitycheck. gstatic.com www.google.com [System] | DivestOS stellt eine Verbindung zu diesem Google-Dienst her, um festzustellen, ob das Gerät eine Verbindung zum Internet herstellen kann. | Diese Verbindung ist aus unterschiedlichen Gründen problematisch. Zunächst einmal wird sie am VPN vorbeigeschleust. Wie bereits dargestellt, kann man sich trefflich darüber streiten, ob dies nun ein VPN-Leak darstellt oder eine bewusste Design-Entscheidung. DivestOS bietet die Möglichkeit, die Gegenstelle/Server, bei dem der Captive-Portal-Check erfolgt, über das GUI anzupassen. |
| android.pool.ntp.org [System] | DivestOS verbindet sich mit einem freien NTP-Server, um die interne Uhr des Geräts zu synchronisieren. | Das kann man so machen. Alternativ könnte DivestOS selbst einen NTP/SNTP-Dienst hosten. |
| divestos.org [System] | Wird verwendet, um nach System-Updates zu suchen bzw. diese zu beziehen. | – |
| firefox.settings. services.mozilla.com shavar.services. mozilla.com [Mull Browser] | Die Filterlisten für die Tracking Protection in Firefox werden regelmäßig aktualisiert, um Werbung, Fingerprinting und andere unerwünschte Inhalte zu blockieren. Ferner werden auch Updates für den Schutz vor Datenlecks und Zertifikatswiderrufen vorgenommen. | – |
| supl.google.com [System] | Wird für die (Beschleunigung der) Positionsbestimmung verwendet. | Die Verwendung eines Google SUPL-Servers ist aus meiner Sicht nicht gerade datenschutzfreundlich. Immerhin kann der Nutzer die Verwendung deaktivieren. |
| gllto.glpals.com [System] | Wird für die (Beschleunigung der) Positionsbestimmung verwendet. | Die PSDS-Hilfsdaten werden direkt von Broadcom bezogen. Dabei werden (außer der IP-Adresse) keine sensiblen Daten übermittelt. |
6. Zusätzliche Informationen zu/über das Custom-ROM
6.1 Entwickler | Institution
DivestOS selbst beschreibt sich wie folgt:
DivestOS is a full-time passion project (not a company) maintained solely by Tad (SkewedZeppelin) since 2014. It has many goals, but primarily: prolonging the life-span of discontinued devices, enhancing user privacy, and providing a modest increase of security where/when possible. The devices DivestOS supports are not fully free (as-in-freedom) and there are many security issues we cannot solve such as insecure proprietary blobs, insecure firmware, insecure bootloaders, and insecure ancient kernels. We are also fully aware of our „off-the-rails“ approach, however mostly attribute it to the sheer effectiveness provided by „80%“ solutions instead of mulling around and not doing anything. We genuinely believe that what DivestOS offers is something unlike any other project, especially with regards to the project scope and our persistence. We hope you find some benefit in our fruits, and remind you to have fun!
Es fällt dem aufmerksamen Leser schnell auf, dass DivestOS tatsächlich nur von einem einzigen Maintainer betreut wird. Man muss sich daher ernsthaft die Frage stellen, wie Tad das schafft. Ich habe ihn gefragt:
I’d like to take a look behind the scenes. Can you briefly describe how you manage this?
Organizational and technical insights would be great so readers can get some idea.
Seine Antwort nachfolgend etwas gekürzt und vom Englischen ins Deutsche übersetzt:
Das ist eine Frage mit offenem Ausgang. Daher die Antwort in keiner bestimmten Reihenfolge:
- Ich erledige viele der Wartungsaufgaben aus dem Gedächtnis
- Die meisten Wartungsaufgaben sind im Allgemeinen automatisiert und werden manuell überprüft, aber viele werden immer noch vollständig von Hand erledigt
- Ich habe keine E-Mails/Chat auf meiner Workstation und auch keine E-Mails auf dem Telefon. Ich antworte hauptsächlich vom Laptop aus
- Ich behalte Einträge in meinem E-Mail-Posteingang solange, bis ich entweder auf sie antworte oder feststelle, dass sie nicht bearbeitet werden können
- Häufig wiederkehrende Aufgaben verwalte ich mit der Habits-App
- Weniger häufig wiederkehrende Aufgaben werden in einem Abschnitt meiner Klartext-TODO-Liste erfasst
- Bald zu erledigende TODOs kommen in einen anderen Abschnitt, den ich versuche, möglichst leer/klein zu halten
- Normalerweise bleiben weniger priorisierte Aufgaben unbeachtet und werden in einem separaten Abschnitt abgelegt
- Ich überwache sorgfältig alle Projekte, die ich geforkt habe, um sicherzustellen, dass alles reibungslos verläuft und gut organisiert ist
- Mein täglicher Zeitplan ist ziemlich frei gestaltet und ich arbeite mich einfach durch alles durch
- Da mein Tag frei gestaltet ist, kann ich in der Regel ziemlich schnell auf alles reagieren, was auftaucht
- Diese flexible Struktur führt oft dazu, dass mein Schlafplan durcheinandergerät, was nicht besonders angenehm ist
- Im Allgemeinen habe ich zwischen der Arbeit genug freie Zeit, in der ich tun kann, was ich will und mich komplett von der Arbeit abkoppeln
- An manchen Tagen mache ich überhaupt nichts, an anderen bin ich ohne Unterbrechung beschäftigt
- Es ist wichtig, dass ich diese Tage nicht als unproduktiv betrachte, solange sie nicht zu häufig auftreten
- In der Regel teile ich meine Arbeit per E-Mail mit anderen, wenn sie für sie nützlich ist, insbesondere wenn ich bemerke, dass sie etwas wiederholen, was ich bereits erledigt habe
- Wenn ich etwas umsetzen/verbessern will, setze ich mich normalerweise hin und erledige es, wenn möglich, in einem Rutsch
- Die Projekte erfüllen in erster Linie meine Anforderungen und ich betrachte sie größtenteils als stabil
- […]
- Ich zögere nicht, Dinge zu kennzeichnen, die nicht in meinen Verantwortungsbereich fallen, da ich bei allem, was ich tue, nicht alles machen kann oder möchte
- […]
- Meine Dokumentation mag nicht perfekt sein, aber ich achte stets darauf, ein gewisses Maß an Dokumentation zu haben, da die Arbeit ohne sie ansonsten nutzlos wäre
- Selbst eine einfache Dokumentation kann ein wirksames Mittel sein, um sich von anderen Projekten abzuheben
- Bei meiner Arbeit bevorzuge ich es, Kontextwechsel zu minimieren, daher konzentriere ich mich normalerweise auf eine Aufgabe.
- Bei Wartungsarbeiten erledige ich möglicherweise paralle eine zweite Aufgabe
- […]
- Beim Arbeiten bevorzuge ich im Allgemeinen entweder Musik oder absolute Stille
- Wenn ich auf eine Blockade stoße, habe ich gelernt, nicht stur weiterzumachen, sondern anzuhalten und etwas anderes zu tun, insbesondere wenn ich unter Schlafmangel leide
- Die Lösungen ergeben sich in der Regel später, wenn ich alltägliche Aufgaben erledige, aber frische Augen helfen dennoch
Basierend auf den Antworten und der E-Mail-Kommunikation mit Tad würde ich behaupten, dass DivestOS sich in guten, verantwortungsvollen Händen befindet. Da weiß jemand, was er tut.
6.2 Installationsvorgang
Die Installation von DivestOS ist nicht unkompliziert und birgt gewisse Risiken – insbesondere das Locking (Schließen) des Bootloaders. Allerdings verläuft die Installation in der Regel reibungslos, solange man sich an die Schritt-für-Schritt-Anleitung hält, die verfügbar ist. Im Gegensatz zu den untersuchten Custom-ROMs CalyxOS und iodéOS erfordert die Installation von DivestOS etwas mehr Aufwand. Es fehlt eine einfache Installationsroutine oder ein Installer-Skript, was bedauerlich ist.
Insgesamt könnte die Anleitung etwas ausführlicher sein, um Einsteigern/Interessierten den Wechsel zu DivestOS zu erleichtern. Mit den teils kurzen Anweisungen ohne Hintergrundinformationen dürften einige Nutzer Probleme haben.
Hinweis
Nach der Installation sollten Nutzer die Ratschläge befolgen, die DivestOS in der Dokumentation empfiehlt.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.
DivestOS schreibt Folgendes zum Thema »Security«:
All supported devices receive monthly security updates. Select devices support incremental updates for smaller update downloads. DivestOS however cannot and does not include all ASB patches as detailed here.
Laut dieser Aussage erscheinen (Sicherheits-)Updates monatlich. Monatlich bedeutet zwar regelmäßig, aber nicht automatisch auch zeitnah. In einer Tabelle dokumentiert DivestOS das Erscheinen der monatlichen Android-(Sicherheits-)Updates und wann sie bei DivestOS bzw. anderen Custom-ROMs erschienen sind. Am zeitnahesten stellt GrapheneOS die Updates zur Verfügung. Bei DivestOS (Version 20.0) werden die Updates meist binnen einer Woche integriert – das ist für ein Ein-Mann-Projekt beachtlich. Je nach Schweregrad der Sicherheitslücke ist eine Woche natürlich immer noch ein »langer Zeitraum« – allerdings noch im Rahmen.
Auch in der Vergangenheit (ältere DivestOS-Versionen) hat DivestOS noch im gleichen Monat die (Sicherheits-)Updates bereitgestellt. Das lässt auf eine gewisse Zuverlässigkeit schließen.
Hinweis
Wer sich mit dem Thema (Sicherheits-)Updates bzw. den Patch Levels eingehender beschäftigen möchte, dem sei ein Blick in die DivestOS-Dokumentation empfohlen. Hier werden die unterschiedlichen Ebenen herausgearbeitet, die bei der Sicherheit eines Android-Geräts eine Rolle spielen.Zum Thema Sicherheit bzw. empfohlenes Gerät schreibt DivestOS übrigens:
If you can acquire/afford a Pixel 6/6a/7, go buy one and use GrapheneOS. Otherwise please see the list of „golden“ devices.
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.
DivestOS bietet keine Unterstützung für Google-Play-Dienste, microG oder Sandboxed Play Services (GrapheneOS). Für einige Nutzer, die auf die Google-Play-Dienste angewiesen sind, wird DivestOS daher vermutlich nicht infrage kommen. Persönlich verzichte ich seit Jahren auf die Google-Play-Dienste und vermisse nichts.
Update 05.01.2024
Seit dem Juli-Update im Jahr 2023 bietet DivestOS die Möglichkeit microG zu nutzen/aktivieren.6.5 Sicherheit/Datenschutz
DivestOS unterstützt für viele Geräte Verified Boot – unter anderem für das Google Pixel 6a Testgerät, mit dem die vorliegende Analyse entstand. 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. DivestOS 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 DivestOS wieder geschlossen werden sollte.
Von diesem Standard-Sicherheitsfeature mal abgesehen, bietet DivestOS noch folgende Änderungen, die sich positiv auf die Sicherheit und den Datenschutz auswirken können. Ein Teil dieser Anpassungen werden nachfolgend kurz erläutert:
- Integrierter Tracker- und Werbeblocker: DivestOS beinhaltet eine Hosts-Datei, die über 900.000 Werbe- und Trackingserver blockiert. Erstellt wird die Liste durch den DNSBLFilter, der über 180 Millionen URLs analysiert.
- CVE patcher: DivestOS hat das Tool CVE patcher entwickelt, mit dem sich das Patchen von bekannten Kernel-Schwachstellen automatisieren lässt. Obwohl es nicht perfekt ist, erhöht es die Sicherheit der Geräte, insbesondere solcher, die vom Hersteller keine (Sicherheits-)Updates mehr erhalten.
- Entfernung von Blobs: Über 700 proprietäre Blobs werden während der Erstellung/Building (Deblob.sh) entfernt. Die Entfernung dieser proprietären Blobs kann die Sicherheit durch Verringerung der Angriffsfläche erhöhen und die Privatsphäre/den Datenschutz verbessern.
Dies war nur ein Ausschnitt aus den bemerkenswerten Bemühungen, die DivestOS unternimmt, um den Nutzern ein höheres Maß an Sicherheit und Datenschutz zu bieten. Abgesehen von GrapheneOS kenne ich kein anderes Custom-ROM, das so weitreichende Anstrengungen unternimmt. Natürlich kann auch DivestOS keine Wunder vollbringen, insbesondere wenn Hersteller proprietäre Komponenten von Geräten nicht mehr mit Updates versorgen. Klammern wir diesen Umstand allerdings mal aus, bietet DivestOS mehr zusätzliche Sicherheit als die bisher analysierten Custom-ROMs.
7. Fazit
Wir erinnern uns an das Eingangszitat:
A mobile operating system divested from the norm.
»take back (some) control of your device«
DivestOS unternimmt erhebliche Anstrengungen, um dieses Ziel zu verwirklichen. Im Auslieferungszustand kontaktiert das System zwar noch einige wenige Google-Dienste, aber auf Wunsch kann sich der Nutzer vollständig von Google lösen. DivestOS ist bisher das einzige Custom-ROM, das es geschafft hat, alle Netzwerkverbindungen vollständig zu dokumentieren – an dieser Stelle gebührt ihnen ein großes Lob dafür.
Insgesamt hinterlässt DivestOS einen äußerst datenschutzfreundlichen Eindruck. Und auch bei der Sicherheit kann DivestOS punkten – wenngleich man einschränkend erwähnen muss, dass eben nicht mehr jedes von DivestOS unterstützte Gerät noch mit Hersteller-Updates für die proprietären Komponenten versorgt wird. Wer allerdings ein aktuelles Gerät wie ein Google Pixel 7a einsetzt, der ist auch bei DivestOS für die kommenden Jahre auf »der sicheren Seite«. Wahrscheinlich findet man nur bei GrapheneOS noch größere Anstrengungen in Bezug auf die Sicherheit.
Es gibt jedoch zwei Aspekte, die ich erwähnen möchte:
- Google-Play-Dienste: DivestOS unterstützt weder Google-Play-Dienste noch microG oder Sandboxed Play Services (wie bei GrapheneOS). Diese Einschränkung gilt es zu beachten, da einige Apps aus dem Google Play Store ohne die Google-Play-Dienste nicht funktionieren.
- Ein-Mann-Armee: Tad ist sozusagen eine Ein-Mann-Armee. Wenn er jedoch ausfällt oder beschließt, das DivestOS-Projekt einzustellen, wird es schnell düster.
Letztendlich richtet sich DivestOS nicht nur an Nutzer, die ihre älteren Geräte weiterhin nutzen möchten, weil sie möglicherweise keine Unterstützung vom Hersteller für die neuesten Android-Versionen und Sicherheitsupdates erhalten. Es richtet sich auch an diejenigen, die Wert auf Datenschutz und Sicherheit legen (vorausgesetzt, sie haben ein aktuelles Gerät). Insgesamt setzt DivestOS die Messlatte ziemlich hoch.
Ü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:
GrapheneOS: Der Goldstandard unter den Android-ROMs – Custom-ROMs Teil7
Mozilla Firefox: Datensendeverhalten Desktop-Version – Browser-Check Teil20
iodéOS: Datenschutzfreundlich, aber Abstriche bei der Sicherheit – Custom-ROMs Teil3
/e/: Datenschutzfreundlich bedeutet nicht zwangsläufig sicher – Custom-ROMs Teil6
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.