F-Droid Sicherheitsbedenken und aktuelle Probleme
Dies ist einer ein übersetzter Artikel der die aktuellen Sicherheitsbedenken und aktuelle Probleme die zunehmend zu F-Droid herauskommen in deutscher Sprachen aufgreifen soll. Wir haben den Artikel auch für Laien etwas verständlicher gestaltet, damit dies auch jeder verstehen kann. Wir selber, haben F-Droid bis jetzt auch grösstenteils in Schutz genommen, und deren Philosophie gefeiert, doch an der Umsetzung und Sicherheit des F-Droid Ökosystems hapert es mittlerweile eher schlecht als recht.
F-Droid ist ein bekannter alternativer App-Store für Android, der sich auf freie und quelloffene Software spezialisiert hat. Besonders unter Datenschutz- und Sicherheitsfans wird F-Droid häufig empfohlen. Doch wie schneidet F-Droid im Vergleich zum Play Store und anderen Appstores tatsächlich ab? In diesem Artikel werfen wir einen Blick auf einige wichtige Sicherheitsaspekte von F-Droid, die ihr kennen solltet.
Vorab ein paar wichtige Hinweise
- Ziel dieses Artikels ist es, euch zu informieren, damit ihr fundierte Entscheidungen treffen könnt – nicht, die Arbeit anderer schlechtzureden. Die Entwickler von F-Droid verfolgen gute Absichten, und das verdient Respekt.
- Eure persönlichen Gründe, Open-Source- oder freie Software zu nutzen, stehen hier nicht zur Diskussion. Dennoch sollte kein Entwicklungsmodell als Garant für Sicherheit betrachtet werden, wenn es diese nicht bieten kann.
- Viele Informationen in diesem Artikel stammen aus vertrauenswürdigen und offiziellen Quellen. Dennoch: Recherchiert gerne selbst weiter.
- Diese Analyse berücksichtigt keine individuellen Bedrohungsszenarien oder Vorlieben. Es geht hier allein um Fakten – nicht um Ideologien.
- Dieser Artikel dient nicht dazu, Angst über F-Droid zu verbreiten, sondern soll zum nachdenken anregen, Alternativen aufzeigen und eventuell auch das F-Droid Team erreichen, um längst verlangte Sicherheitstandards umzusetzen.
Dies ist keine ausführliche Sicherheitsbewertung und auch nicht den Anspruch 100% vollständig zu sein.
1. Das Problem mit der vertrauenswürdigen Partei
Um dieses Problem zu verstehen, muss man die Architektur von F-Droid, die Unterschiede zu anderen App-Repositorien und das Sicherheitsmodell von Android kennen. Einige der hier genannten Probleme gehen über das Sicherheitsmodell von Android hinaus, aber viele fallen in diesen Bereich.
Wie F-Droid Apps signiert
Anders als andere Repositories signiert F-Droid alle Apps im F-Droid Hauptrepository mit seinen eigenen Schlüsseln (einzigartig pro App), außer bei wenigen reproduzierbaren Builds. Diese Signaturen garantieren die Echtheit der heruntergeladenen Apps. Android verwendet ein „Trust-on-first-use“-Modell: Beim ersten Installieren wird die Signatur einer App gespeichert. Zukünftige Updates müssen dieselbe Signatur haben, sonst können sie nicht installiert werden. (Deshalb kann F-Droid Apps auch nicht über Aurora updaten und etc.)
Normalerweise signiert der Entwickler seine App selbst, bevor er sie hochlädt – sei es auf eine Website oder in ein Repository. Nutzer müssen nur der ersten Quelle vertrauen; spätere Updates sind durch die Signatur gesichert. Bei F-Droid jedoch signiert eine zusätzliche Partei (F-Droid) die Apps. Das bedeutet, ihr müsst sowohl dem Entwickler als auch F-Droid vertrauen, was nicht ideal ist.
Vergleich mit dem Play Store
Der Play Store hat seit August 2021 mit „Play App Signing“ ein ähnliches Modell eingeführt, bei dem Google die Signaturschlüssel für neue Apps verwaltet. Diese Schlüssel werden sicher in Googles Cloud Key Management Service gespeichert. Der Entwickler muss die App jedoch zuerst mit einem eigenen Schlüssel signieren, damit Google deren Echtheit prüfen kann. Entwickler älterer Apps (vor August 2021) können ihre privaten Schlüssel weiterhin selbst verwalten, tragen jedoch auch das Risiko, dass ein kompromittierter Schlüssel für schädliche Updates genutzt werden könnte.
Anforderungen und Sicherheitsprobleme bei F-Droid
F-Droid verlangt, dass der Quellcode einer App frei von proprietären Bibliotheken oder Werbediensten ist. Entwickler müssen oft separate Versionen ihres Codes erstellen, die den F-Droid-Anforderungen entsprechen. Doch selbst der Zugriff auf den Quellcode garantiert keine gründliche Prüfung. Obwohl der Play Store für schädliche Apps bekannt ist, gibt es bei F-Droid eine trügerische Sicherheit – viele glauben, das Hauptrepository sei frei von schädlichen Apps, was nicht stimmt.
Kann man F-Droid einfach vertrauen?
F-Droid selbst gibt zu, dass der Prüfprozess sehr rudimentär ist. Er basiert hauptsächlich auf automatischen Scans, die nach proprietären Elementen und Trackern suchen. Nutzer müssen also weiterhin sowohl F-Droid als auch den Entwicklern vertrauen – wie bei jedem anderen Repository.
Ein Vergleich mit dem Desktop-Linux-Modell, bei dem Nutzer ihren Distributionsmaintainern vertrauen, hinkt. Android ist eine viel homogenere Plattform mit klareren Regeln, weshalb dieser Ansatz nicht eins zu eins übertragbar ist.
Infrastrukturprobleme bei F-Droid
F-Droid kontrolliert nicht nur die Signaturserver, sondern auch die Build-Server. Diese verwenden virtuelle Maschinen, um Apps zu bauen. Zwischen Juni und November 2022 lief die F-Droid-Infrastruktur jedoch auf einer veralteten Debian-Version (Stretch), die schon zwei Jahre zuvor als „End-of-Life“ deklariert wurde. Das wirft erhebliche Fragen zur Sicherheit der gesamten Infrastruktur auf.
Reproduzierbare Builds: Eine Lösung?
Eine theoretische Lösung von F-Droid ist die Verwendung von reproduzierbaren Builds. Dabei können Entwickler sicherstellen, dass der veröffentlichte Code exakt dem Quellcode entspricht. Doch das setzt zusätzliche Arbeit für Entwickler und F-Droid voraus, was häufig zu veralteten App-Versionen führt. Zudem sind reproduzierbare Builds selten, da sie viel Aufwand erfordern.
Google bietet mit „Code Transparency“ eine andere Lösung: App-Bundles enthalten ein von Entwicklern signiertes Token, das Hashes wichtiger Dateien speichert. So können Nutzer überprüfen, ob der Code wirklich vom Entwickler stammt. Dieses System ist noch nicht perfekt, da es nicht alle Ressourcen abdeckt und die Überprüfung manuell erfolgen muss. Dennoch ist es ein hilfreicher Ansatz.
Andere App-Repositorien
Der Amazon Appstore verändert hochgeladene Apps und versieht sie mit eigenem Code, einschließlich Trackern. Huawei verwendet ein ähnliches Modell wie Google: Neue Apps werden von Huawei signiert, ältere können aber weiterhin vom Entwickler signiert werden.
2. F-Droids strikte Richtlinien und ihre Folgen
F-Droid verfolgt mit seiner „Leidenschaft für Freie und Open-Source-Software (FOSS) auf der Android-Plattform“ eine sehr strenge Aufnahme-Richtlinie. Um eine App im Hauptrepository zu hosten, verlangt F-Droid, dass der Quellcode frei von proprietären Bibliotheken oder Werbediensten ist. Diese strikte Vorgabe hat sich jedoch oft als nachteilig für Entwickler und Endnutzer erwiesen.
Der zusätzliche Aufwand für Entwickler
Entwickler müssen häufig eine separate Version ihres Codes erstellen, um den Anforderungen von F-Droid gerecht zu werden. Das bedeutet zusätzlichen Zeit- und Energieaufwand. Zudem müssen Entwickler manchmal auf ältere Bibliotheken und Tools zurückgreifen, die F-Droid als „FOSS-konform“ einstuft. Dies kann nicht nur die Entwicklungszeit verlängern, sondern auch die Qualität der App beeinträchtigen.
Fallbeispiel: Snikket
Ein anschauliches Beispiel für die negativen Auswirkungen der F-Droid-Richtlinien lieferte das Snikket-Projekt im Dezember 2022. In einem Blogpost richtete sich das Team an Nutzer, die die App über F-Droid heruntergeladen hatten, und wollte Panik vermeiden, nachdem F-Droid vor einer angeblichen Sicherheitslücke in der App gewarnt hatte. Laut F-Droid solle die App „unmittelbar deinstalliert“ werden.
Snikket klärte später in einem weiteren Blogpost, dass das Problem nicht an ihrer App lag, sondern an der von F-Droid gebauten Version. Diese Version nutzte eine veraltete WebRTC-Bibliothek, um den Anforderungen der F-Droid-Richtlinien zu entsprechen. Die Entwickler-Versionen der App, die im Play Store veröffentlicht wurden, waren von diesem Problem nicht betroffen, da sie auf einer modernen WebRTC-Version basierten.
Auswirkungen auf die Nutzer
Die veraltete WebRTC-Version in der F-Droid-App hatte nicht nur Sicherheitsprobleme zur Folge, sondern verhinderte auch, dass neue Funktionen und Verbesserungen aus der aktuellen Entwicklung in die App übernommen werden konnten. Damit schadete F-Droids rigides Festhalten an seiner Ideologie den Endnutzern direkt.
Dieses Beispiel zeigt deutlich, wie die strengen Aufnahme-Richtlinien von F-Droid nicht nur den Entwicklungsprozess erschweren, sondern auch Nutzer gefährden können. Der Zwang, veraltete oder ungeeignete Tools zu nutzen, untergräbt letztlich das Ziel, qualitativ hochwertige und sichere Software anzubieten. FOSS-Ideologie darf nicht wichtiger sein als die Sicherheit und Benutzerfreundlichkeit der Apps.
3. Langsame und unregelmäßige Updates
Wenn eine zusätzliche Partei in den Prozess eingebunden wird, liegt es an dieser, die App korrekt zu bauen und zu veröffentlichen. Dieses Prinzip kennt man von traditionellen Linux-Distributionen und ihren Paketverwaltungssystemen. Während einige Distributionen wie Arch Linux regelmäßig und schnell Updates liefern, bevorzugen andere wie Debian umfangreiche Anpassungen, die oft nur einen Teil der Sicherheitsprobleme adressieren.
Zusätzlicher Aufwand durch F-Droid
F-Droid verlangt von Entwicklern spezifische Änderungen, damit ihre App den Aufnahme-Richtlinien entspricht. Dies bedeutet oft mehr Wartungsaufwand. Doch das Problem geht tiefer: Der Prozess zur Erstellung neuer Builds bei F-Droid wirkt ungewöhnlich und ineffizient. Teile des Build-Prozesses sind zwar automatisiert – was man zumindest erwarten würde – aber der Signaturprozess der Apps wird durch die Nutzung eines „air-gapped“ Servers (ohne Netzwerkverbindung) verlangsamt.
Da die Signatur der Apps manuell angestoßen werden muss, entstehen unregelmäßige Update-Zyklen. Dies ist keine optimale Lösung und birgt zudem Risiken: Da alle Signaturschlüssel bei einer einzigen Partei liegen, entsteht ein zentraler Schwachpunkt. Sollte das System kompromittiert werden – sei es durch einen internen oder externen Angriff – könnte dies ernste Sicherheitsprobleme für viele Nutzer verursachen.
Warum Signal F-Droid ablehnt
Einer der Hauptgründe, warum Signal sich weigert, eine Drittanbieter-Version ihrer App im offiziellen F-Droid-Repository zu unterstützen, liegt genau in diesen Problemen. Eine ältere Diskussion auf GitHub zeigt, dass viele der damals vorgebrachten Punkte auch heute noch gültig sind.
https://github.com/signalapp/Signal-Android/issues/127
Auswirkungen auf Updates und Sicherheit
Das langsame und fehleranfällige Build-System von F-Droid führt dazu, dass Updates oft verzögert veröffentlicht werden. Veraltete Tools verstärken dieses Problem zusätzlich. Langsame Updates setzen Nutzer länger als nötig Sicherheitslücken aus. Besonders bei sicherheitskritischen Apps wie einem Browser wäre es äußerst riskant, sich auf Updates über das F-Droid-Hauptrepository zu verlassen.
Drittanbieter-Repositories als Alternative?
F-Droid erlaubt Entwicklern, eigene Repositories zu erstellen und zu verwalten, um das Problem langsamer Updates zu umgehen. Diese Repositories können Updates schneller bereitstellen, da sie direkt vom Entwickler verwaltet werden. Allerdings ist auch diese Lösung nicht ideal, wie in späteren Abschnitten erläutert wird.
4. Low target API level (SDK) bei Client & Apps
Das SDK (Software Development Kit) ist ein Sammlung von Werkzeugen, um Apps für eine Plattform zu entwickeln. Auf Android ermöglicht ein höheres API-Level die Nutzung moderner Schnittstellen (APIs), die mit jeder Version Sicherheits- und Datenschutzverbesserungen bringen. Zum Beispiel bietet API-Level 31 die Vorteile von Android 12.
Warum ein aktuelles API-Level wichtig ist
Android verwendet ein starkes Sandboxing-Modell, bei dem jede App in einer eigenen Umgebung läuft. Apps, die mit einem aktuellen API-Level kompiliert wurden, profitieren von den neuesten Sicherheitsfunktionen. Ältere API-Level, wie API 25 (Android 7.1), sind hingegen anfällig für Schwachstellen und erfordern zusätzliche SELinux-Ausnahmen, um älteren Apps Zugriff auf bestimmte Systemressourcen zu ermöglichen – was die Sicherheit beeinträchtigt.
Problem mit dem F-Droid-Client
Der offizielle F-Droid-Client verwendet immer noch API-Level 25, das aus dem Jahr 2016 stammt. Das bedeutet, dass es nicht von den Verbesserungen moderner Android-Versionen profitiert. Einige Nutzer empfehlen Drittanbieter-Clients wie Foxy Droid oder Droid-ify, da diese technisch überlegen sein können. Allerdings bringen auch diese eine zusätzliche Partei ins Spiel und sind nicht immer gut gepflegt.
Keine Mindestanforderungen an das API-Level im Repository
F-Droid setzt kein Mindest-API-Level für Apps im offiziellen Repository voraus. Im Gegensatz dazu hat der Play Store strenge Anforderungen:
- Seit August 2021 müssen neue Apps mindestens API-Level 30 (Android 11) anvisieren.
- Seit November 2021 müssen bestehende Apps dasselbe API-Level erreichen, um Updates einzureichen.
Diese Maßnahmen sind notwendig, um das App-Ökosystem aktuell und sicher zu halten. F-Droid sendet durch das Fehlen solcher Anforderungen jedoch ein falsches Signal an Entwickler und Nutzer. Das Hauptrepository von F-Droid enthält viele veraltete Apps, die nur deswegen lauffähig bleiben, damit sie noch auf über zehn Jahre alten Android-Versionen wie 4.0 (Ice Cream Sandwich) funktionieren.
Rückwärtskompatibilität vs. Sicherheit
Während Rückwärtskompatibilität wichtig ist, darf sie nicht auf Kosten der Sicherheit gehen. Entwickler können moderne Ziel-APIs verwenden und gleichzeitig ältere Geräte unterstützen, indem sie ein Mindest-API-Level (minSdkVersion) setzen. Dies erlaubt die Nutzung moderner Funktionen auf neueren Plattformen und sichert gleichzeitig die Kompatibilität mit älteren Geräten. Ein zu niedriges Mindest-API-Level führt jedoch zu übermäßigem Aufwand durch zusätzliche Code-Pfade und veraltete Bibliotheken.
Aktuelle Realität
Zum Zeitpunkt dieses Artikels:
- Android 9 ist die älteste Android-Version, die noch Sicherheitsupdates erhält.
- Rund 80 % der Android-Geräte weltweit nutzen mindestens Android 8.0 (Oreo).
Die Statistik zeigt, dass die meisten Nutzer bereits modernere Geräte verwenden. Alte Geräte machen einen kleinen Anteil aus, und Entwickler sollten sich nicht auf diese konzentrieren, sondern die Sicherheit und Aktualität ihrer Apps priorisieren.
5. Allgemeiner Mangel an bewährten Sicherheitspraktiken
Der F-Droid-Client ermöglicht es, mehrere Repositories in derselben App zu verwalten. Während sich viele der bisher besprochenen Probleme auf das offizielle Hauptrepository beziehen, bringt die Möglichkeit, zusätzliche Repositories hinzuzufügen, weitere Sicherheitsrisiken mit sich. Androids Sicherheitsmodell ist nicht dafür ausgelegt, mehrere Quellen für Apps innerhalb einer einzigen App zu mischen. Das Betriebssystem betrachtet F-Droid als eine einzelne vertrauenswürdige Quelle, was zu einem falschen Sicherheitsgefühl führt. Dies wird besonders kritisch, wenn die „Privileged Extension“ ins Spiel kommt.
Sicherheitsprobleme durch die Privileged Extension
Die Privileged Extension nutzt die mächtige API INSTALL_PACKAGES, ohne angemessene Sicherheitsüberprüfungen umzusetzen. Sie akzeptiert alle Installationsanforderungen von F-Droid, was bei einem kompromittierten oder fehlerhaften Repository fatale Folgen haben könnte. Besonders problematisch ist, dass F-Droid benutzerdefinierte Repositories erlaubt, wodurch Sicherheitslücken entstehen können.
CalyxOS benutzt diese Privileged Extention zum Beispiel standardmässig für ihre F-Droid Installation.
Unzureichend signierte Metadaten
Das Format für Repository-Metadaten bei F-Droid ist schlecht gesichert. Es fehlt an einer vollständigen Datei-Signatur und einer zuverlässigen Schlüsselrotation. Das aktuelle Index-Format (v1) verwendet JAR-Signaturen mit jarsigner, das bekannte Sicherheitsprobleme hat. Zwar arbeitet F-Droid an einem v2-Format mit Unterstützung für apksigner, aber die Umsetzung bleibt abzuwarten. Bessere Alternativen wie signify könnten hier einfacher und sicherer eingesetzt werden.
Keine Unterstützung für moderne Update-APIs
Die neue API für automatische Updates (eingeführt mit Android 12, API-Level 31) ermöglicht reibungslose Updates ohne privilegierten Zugriff. Der F-Droid-Client unterstützt diese Funktion nicht. Drittanbieter-Clients wie Neo-Store tun dies zwar, doch die grundlegenden Probleme mit der F-Droid-Infrastruktur bleiben bestehen. Für diese API müssen der Client API-Level 31 und die Apps mindestens API-Level 29 verwenden, was bei F-Droid oft nicht gegeben ist.
Fehlen von TLS-Zertifikat-Pinning
F-Droid unterstützt kein TLS-Zertifikat-Pinning, eine bewährte Sicherheitsmaßnahme, die verhindert, dass manipulierte Zertifikate verwendet werden können. Zertifikat-Pinning sorgt dafür, dass nur bekannte, vertrauenswürdige Zertifikate akzeptiert werden, und schützt vor Man-in-the-Middle-Angriffen. Moderne App-Stores wie der GrapheneOS App Store nutzen diese Technik konsequent.
Ein Beispiel für Zertifikat-Pinning aus dem GrapheneOS-App-Client:
<network-security-config>
<base-config cleartextTrafficPermitted="false"/>
<domain-config>
<domain includeSubdomains="true">apps.grapheneos.org</domain>
<pin-set>
<!-- Bekannte Root- und CA-Zertifikate -->
<pin digest="SHA-256">C5+lpZ7tcVwmwQIMcRtPbsQtWLABXhQzejna0wHFr8M=</pin>
...
</pin-set>
</domain-config>
</network-security-config>F-Droid hat zwar darüber nachgedacht, zumindest für Standard-Repositories Zertifikat-Pinning einzuführen, doch bisher gibt es keine funktionierende Implementierung. Angesichts der Komplexität von F-Droid ist das verständlich, aber unglücklich.
Veraltete Signaturschemata
F-Droid hielt lange an der veralteten v1-Signaturmethode fest, die seit 2017 als unsicher gilt, und wurde erst durch Android 11 gezwungen, die moderneren v2/v3-Schemata zu unterstützen. Einige Apps und Metadaten verwenden jedoch immer noch die alten Signaturen, was schlichtweg schlecht ist. Der Einsatz von GPG zur Signierung ist ebenfalls keine gute Alternative, da PGP und dessen Referenzimplementierung GPG für viele Schwachstellen bekannt sind. Selbst Debian arbeitet daran, GPG zu ersetzen. F-Droid sollte dringend vollständig auf moderne Signaturschemata umsteigen und die alten Standards vollständig ausmustern.
6. Verwirrende Benutzererfahrung (UX)
Ein oft kritisiertes Problem bei F-Droid ist die Benutzererfahrung, die durch einige fragwürdige Entscheidungen unnötig verkompliziert wird.
Veraltete APKs auf der Website
Auf der offiziellen F-Droid-Website wird nach wie vor eine veraltete Version der APK-Datei bereitgestellt. Das führt dazu, dass viele Nutzer sich fragen, warum sie F-Droid nicht in einem sekundären Benutzerprofil installieren können. Grund dafür ist die von Android erzwungene Verhinderung von Downgrades. Laut F-Droid dient dies der „Stabilität“ – eine fragwürdige Begründung, da entweder eine Version bereit für die Veröffentlichung ist oder nicht. Neue Nutzer sollten stets einfachen Zugang zur aktuellsten stabilen Version haben.
Schlechte Praxis bei Paketnamen und Signaturen
F-Droid verwendet für alternative Builds häufig denselben Paketnamen (Application ID) wie für die Standardversion. Das führt zu Problemen bei der Signaturprüfung, wenn Nutzer versuchen, die App aus anderen Quellen zu aktualisieren oder erneut zu installieren, beispielsweise direkt vom Entwickler. Das Sicherheitsmodell von Android verlangt bei jeder Installation eine Übereinstimmung der Signaturen, was durch diese Praxis häufig scheitert.
Eine bessere Lösung wäre es, alternative Builds mit einem spezifischen Präfix oder Suffix im Paketnamen zu versehen, beispielsweise org.f-droid oder .fdroid. Dadurch könnten Konflikte und Verwirrung vermieden werden, insbesondere wenn Apps über mehrere Distributionskanäle angeboten werden. Auch Entwickler, die Play App Signing nutzen, werden ermutigt, eine solche Strategie zu verfolgen, um ähnliche Probleme zu vermeiden.
Verwirrung bei der Herkunft von Apps
Diese Probleme führen zu einer unübersichtlichen Benutzererfahrung, bei der Nutzer oft nicht wissen, wer eine App signiert hat und aus welchem Repository sie eine App beziehen oder aktualisieren sollten. Für Endnutzer ist dies nicht nur umständlich, sondern birgt auch potenzielle Sicherheitsrisiken, da die Quellen und Signaturen der Apps nicht transparent genug sind.
7. Irreführender Umgang mit Berechtigungen
F-Droid zeigt für jede App eine Liste von „Low-Level“-Berechtigungen an, die direkt aus dem App-Manifest stammen. Diese werden normalerweise in Android zu „High-Level“-Berechtigungen zusammengefasst, wie Standort, Mikrofon oder Kamera, oder in spezielle Optionen wie den Zugriff auf nahegelegene WLAN-Netzwerke oder Bluetooth-Geräte. Während diese detaillierte Liste für Entwickler nützlich sein kann, ist sie für Endnutzer oft verwirrend und führt zu Missverständnissen.
Veraltetes Berechtigungsmodell
Seit Android 6 (API-Level 23) müssen Apps zur Laufzeit nach wichtigen Berechtigungen fragen. Einfaches Installieren gibt einer App keine Berechtigungen mehr. F-Droid zeigt jedoch alle im Manifest definierten Berechtigungen an, unabhängig davon, ob sie tatsächlich aktiv sind. Dies verkompliziert das Berechtigungsmodell unnötig und führt dazu, dass Nutzer falsche Schlüsse ziehen.
F-Droid rechtfertigt dies mit der Unterstützung von Android 5.1 und älter, wo Berechtigungen noch zur Installationszeit erteilt wurden. Das Problem dabei: Diese Android-Versionen sind über acht Jahre alt und erhalten keine Sicherheitsupdates mehr. Nutzer, die auf Sicherheit achten, sollten solche alten Geräte ohnehin nicht verwenden.
Diskussion über irreführende Berechtigungen
Eine Diskussion im F-Droid-GitLab zeigte, dass die Entwickler die Problematik herunterspielten. Der Hauptentwickler bezeichnete das Android-Berechtigungsmodell als „Dumpster Fire“ (Müllhaufen) und argumentierte, dass das Betriebssystem unsichere Apps nicht ordentlich isolieren könne, ohne dabei an Nutzbarkeit einzubüßen.
Tatsächlich haben moderne Android-Versionen Mechanismen, um selbst für ältere Apps mit niedrigen API-Levels Berechtigungsanfragen zu erzwingen. Eine App, die beispielsweise API-Level 22 (Android 5.1) oder niedriger anvisiert, löst beim Installieren einen Dialog aus, der die angeforderten Berechtigungen erklärt. Das Betriebssystem berücksichtigt also automatisch ältere Apps und deren Anforderungen.
Beispiele für problematische Darstellungen
Ein häufig missverstandenes Beispiel ist die Berechtigung RECEIVE_BOOT_COMPLETED, die in F-Droid als „Run at startup“ (Beim Start ausführen) beschrieben wird. Diese Berechtigung ermöglicht es der App lediglich, auf ein Signal zu reagieren, das das System nach dem Hochfahren sendet. Sie erlaubt jedoch nicht, beliebige Hintergrundprozesse auszuführen, und beeinflusst die Leistung des Geräts nur minimal. Moderne Android-Versionen kontrollieren Hintergrundaktivitäten über die Option „Hintergrundbeschränkung“.
Ein weiteres Beispiel ist die Berechtigung QUERY_ALL_PACKAGES, die in F-Droid als „Abfrage aller installierten Apps“ beschrieben wird. Während dies technisch korrekt ist, können Apps auch ohne diese Berechtigung einige installierte Apps im selben Benutzerprofil auflisten, insbesondere seit Android 11, das die Sichtbarkeit einschränkt. Eine ungenaue Darstellung dieser Berechtigungen führt dazu, dass Nutzer deren Bedeutung und Auswirkungen falsch interpretieren.
Vergleich mit dem Play Store
Der Play Store zeigt Berechtigungen nutzerfreundlicher an, indem sie in High-Level-Kategorien zusammengefasst werden. Zusätzliche Low-Level-Berechtigungen werden unter „Andere“ aufgeführt und sind nur über mehrere Menüs zugänglich. Seit Juli 2022 zeigt der Play Store keine vollständige Liste der Low-Level-Berechtigungen mehr an, um Verwirrung zu vermeiden.
Zudem schränkt der Play Store den Einsatz invasiver Berechtigungen wie MANAGE_EXTERNAL_STORAGE stark ein. Nur Apps, die ihre Notwendigkeit für diese Berechtigung überzeugend begründen können (z. B. Dateimanager), dürfen sie verwenden. Apps, die diesen Anforderungen nicht entsprechen, können aus dem Play Store entfernt werden. Diese strenge Kontrolle schützt Nutzer davor, Apps zu installieren, die ihre Privatsphäre gefährden könnten.
F-Droid’s Ansatz, Low-Level-Berechtigungen anzuzeigen, ist irreführend und veraltet. Stattdessen sollte das Berechtigungsmodell klarer erklärt werden, um Verwirrung zu vermeiden. Eine moderne Darstellung wie im Play Store wäre für Endnutzer weitaus hilfreicher, da sie den Fokus auf relevante, tatsächlich aktive Berechtigungen legt.
Fazit: Was solltet ihr tun
Bis hierhin wurden Fakten präsentiert, die leicht überprüfbar sind. Im Folgenden werden Meinungen und Empfehlungen geäußert, die ihr gerne hinterfragen könnt, aber sie sollten den Rest der Argumente nicht überschatten.
F-Droid: Probleme und Potenziale
Während einige Probleme leicht gelöst werden könnten, leidet F-Droid unter grundlegenden Schwächen in seiner Architektur. Zudem scheint die zugrunde liegende Philosophie von F-Droid nicht immer mit modernen Sicherheitsprinzipien vereinbar zu sein. Dennoch bleibt F-Droid eine der bekanntesten Alternativen zu kommerziellen App-Stores und wird von vielen Nutzern geschätzt. Ich persönliche hoffe, dass sich F-Droid in Zukunft verbessert.
Gibt es Alternativen zu F-Droid
F-Droid wird oft als einzige Möglichkeit angesehen, Open-Source-Apps zu entdecken und zu unterstützen. Das stimmt nicht. Viele Entwickler veröffentlichen ihre Open-Source-Apps auch im Play Store, auf ihrer Website oder über GitHub. Auf GitHub könnt ihr Veröffentlichungen über Atom-Feeds verfolgen, und die Authentizität von APKs lässt sich mit Tools wie apksigner prüfen. Auf einem Linux Rechner muss apksigner zuerst mit
sudo apt install apksigner installiert werden, danach könnt ihr mit dem Tool APKs überprüfen:
apksigner verify --print-certs --verbose myCoolApp.apkNach der Installation einer App pinnt Android deren Signatur und führt bei Updates eine Signaturprüfung durch. Damit ist die Quelle der App nach der ersten Installation weniger wichtig.
Alternative Appstores – Empfehlungen
Aurora Store:
Für die meisten Nutzer ist der Aurora Store eine hervorragende Alternative, da er als inoffizieller Client für den Play Store Zugang zu vielen Apps bietet – ohne ein Google-Konto zu benötigen. Allerdings gibt es Schwächen wie fehlendes Zertifikat-Pinning und teilweise unnötige Berechtigungen. Um die Sicherheit zu erhöhen, solltet ihr im idealfall ein ein eigenes Google-Wegwerf-Konto erstellen, anstatt die geteilten „anonymen“ Konten zu nutzen.
Google Play Store:
Trotz berechtigter Kritik bleibt der Play Store eine solide Wahl für Nutzer, die Wert auf aktuelle Sicherheitsstandards legen. Google setzt mit dem Play Store moderne Datenschutzpraktiken um und fördert die Nutzung sicherer Berechtigungsmodelle. Mit einem separaten Google-Wegwerf-Konto könnt ihr eure persönlichen Informationen minimieren und dennoch auf ein breites App-Angebot zugreifen.
Accrescent:
Accrescent ist ein aufstrebendes Projekt, das viele der hier beschriebenen Probleme angeht. Es konzentriert sich auf Sicherheit und Transparenz und könnte in Zukunft eine spannende Alternative für sicherheitsbewusste Nutzer werden.
GrapheneOS App Store:
Dieser geplante App Store richtet sich an Nutzer des GrapheneOS und bietet eine kleine, kuratierte Auswahl hochwertiger Apps. Mit einem starken Fokus auf Sicherheit und Einfachheit wird er besonders für technisch versierte Nutzer mit spezifischen Anforderungen interessant sein.
Diese Empfehlungen sind nach Nutzerfreundlichkeit und Sicherheitsfokus geordnet – vom benutzerfreundlichen Aurora Store über den etablierten Play Store bis hin zu spezialisierten Projekten wie Accrescent und dem GrapheneOS App Store.
Häufige Fragen
Sollte ich mir Sorgen machen?
Das hängt von eurem Bedrohungsmodell und euren persönlichen Vorlieben ab. Euer Handy wird nicht explodieren, weil ihr F-Droid benutzt. Dennoch ist es ratsam, bei der Nutzung von App-Stores pragmatisch vorzugehen und Sicherheit vor Ideologie zu stellen. Ausserdem gilt, Apps, die älter als 5 Jahre ohne Updates sind, sollten nicht mehr installiert werden.
Hat der Play Store mehr Malware?
Zwar gibt es im Play Store Malware, doch das liegt daran, dass eine vollständige Analyse jeder hochgeladenen App unrealistisch ist. Trotzdem erfüllt der Play Store seine Rolle recht gut, indem er die meisten bösartigen Apps abwehrt.
Ist Play App Signing genauso problematisch wie F-Droid?
Nein, das ist zu kurz gegriffen. Play App Signing hat seine eigenen Nuancen, aber es unterscheidet sich grundlegend von den Problemen, die F-Droid hat. Lies dazu am besten die entsprechenden Abschnitte und die offizielle Dokumentation.
Sind Open-Source-Apps sicherer?
Nicht zwangsläufig. Sicherheit ergibt sich durch ein modernes Betriebssystem mit robustem Sandboxing und Berechtigungsmodellen, wie sie Android, GrapheneOS oder iOS bieten. Vermeide es, älteren Apps invasive Berechtigungen zu erteilen, und vertraue nicht blind darauf, dass Open Source immer sicherer ist.
Ist der Play Store „Spyware“?
Der Play Store hat Datenschutzprobleme, da er ein proprietärer Dienst ist, der ein Google-Konto erfordert. Doch auf Systemen wie GrapheneOS läuft er unprivilegiert in einer Sandbox, was einige Probleme abmildert. Für zusätzliche Privatsphäre kann man ein Konto mit minimalen persönlichen Informationen verwenden.
Meta: Über den Zweck des Artikels
Dieser Artikel verfolgt einen rein technischen Ansatz. Es handelt sich nicht um einen Angriff auf F-Droid oder dessen Mission, sondern um eine informative Darstellung für Endnutzer und eine Grundlage zur Verbesserung des F-Droid-Projekts.
Negative Reaktionen der F-Droid-Community
Trotz dieses klaren Ziels hat die Veröffentlichung des Original-Artikels leider zu einer überwiegend negativen Reaktion seitens des F-Droid-Teams und Teilen der Community geführt. Statt sachliche Gegenargumente vorzubringen, nehmen einige eine ablehnende Haltung ein. Es ist besorgniserregend, dass manche sogar Belästigungskampagnen gegen Projekte und Sicherheitsforscher starten, die andere Ansichten vertreten. Solches unethisches Verhalten schadet nicht nur der Reputation von F-Droid, sondern untergräbt auch das Vertrauen in das Projekt. Ein Konflikt zwischen Entwicklern und Sicherheitsforschern ist im Interesse von niemandem.
Unbegründete Verbindungen zu GrapheneOS
Einige haben diesen Artikel fälschlicherweise mit GrapheneOS in Verbindung gebracht. Dies ist nicht korrekt: Der Original-Artikel ist eine völlig unabhängige Arbeit und steht in keinerlei Zusammenhang mit dem GrapheneOS-Projekt. Er wurde nicht von einem GrapheneOS-Entwickler verfasst und spiegelt nicht die offizielle Haltung des Projekts wider. Artikel auf Basis einer vermeintlichen Verbindung abzulehnen, anstatt den technischen Inhalt zu analysieren, ist nicht zielführend und bringt niemandem etwas.
Die offielle Haltung von GrapheneOS kommt aber auf ein ähnlich prekäres Ergebnis ihrer Analysen:
F-Droid has had major unaddressed security issues for years which have been repeatedly raised. The development team have demonstrated an extremely anti-security attitude. They disregard basic security best practices for Android development and are highly resistant to improving it. This is one symptom of the poor security of F-Droid rather than even being one of the major issues with it. The entire approach of automatically fetching and building apps in an outdated environment on outdated, poorly maintained infrastructure which are then signed with their own keys while using the official app IDs is horrible. The whole thing needs to be thrown out and replaced. They also don’t follow the security model for app sources, don’t support key rotation and many other issues. F-Droid causes major usability issues with profiles due to not following Android development best practices, which has put a substantial support burden on us. Steering people away from it is important to avoiding them having a bad experience using profiles due to their misuse of app ids not belonging to them.
GrapheneOS Diskussion um F-Droid
Denoch soll nochmals gesagt werden, dass der Artikel eine unabhängige Arbeit darstellte, der zu einem ähnlichen Ergebnis gelangte.
F-Droid Installationsanwendung gibts hier zu lesen, wer sich nach alternativen Umschauen will, findet mit Obtainium einen etwas anderen, jedoch etwas komplexeren Ansatz. Der Appstore Accrescent, versucht aktuell alle Sicherheitsbedenken von F-Droid zudem auszumerzen. Es gibt jedoch noch wenige Apps:
Original Artikel
https://privsec.dev/posts/android/f-droid-security-issues
Aktuellste Diskussionen im GrapheneOS Forum:
https://discuss.grapheneos.org/d/18731-f-droid-vulnerability-allows-bypassing-certificate-pinning
