Der Kern von Android ist freie Software, aber dieser Kern hat keinen App Store. Die meisten Anwender von Aftermarket-Systemen wie LineageOS oder GrapheneOS nutzen daher F-Droid, um Open Source-Apps zu beziehen. Das ist nicht unproblematisch, aber leider alternativlos.
Via Linuxnews erreichte mich heute dieser sehr lesenswerte Artikel zu den problematischen Implikationen von F-Droid für die Sicherheit von Android. Der Autor nennt einige substanzielle Probleme von F-Droid, die ich im Folgenden knapp zusammenfassen möchte. Für die ausführliche Darstellung bitte den Artikel lesen.
- Die Probleme beginnen schon bei den Signaturen der Apps, da F-Droid alle Apps mit seinen eigenen Keys signiert. Das untergräbt den sonst verfolgten Ansatz, dass Entwickler ihre Apps selbst signieren und der Anwender dem Vertriebskanal nicht vertrauen muss.
- Die Apps bei F-Droid müssen frei von proprietären Bibliotheken sein und unterscheiden sich deshalb von den Varianten der gleichen App, die auf anderen Wegen bezogen werden können.
- Die Qualitätskontrollen von F-Droid sind praktisch wertlos. Ein offener Quellcode bedeutet nicht, dass die Überprüfung leicht ist.
- Updates werden mit teils starker Verzögerung verteilt.
- F-Droid hinkt beim API-Level hinterher, für den Apps gebaut werden, was wiederrum negativ für die Sicherheit sein kann.
- Mehrere Repositorien in einer einzigen App widersprechen dem Android-Sicherheitsprinzip.
- Die neue API in Android für automatische Hintergrundaktualisierungen von Apps ohne Root-Privilegien wird mit F-Droid nicht funktionieren bzw. nur mit einem “schmutzigen” Hack.
- Viele kleinere Probleme, die der Autor als “mangelnde gute Praxis” beschreibt wie z. B. fehlendes Zeritfikat-Pinning oder ganz allgemein, dass Änderungen bei F-Droid erst nachvollzogen werden, wenn sie dazu durch Änderungen in der Android-Basis gezwungen werden und nicht wenn diese bereits ratsam sind.
Einige dieser Probleme wie die Updateverzögerung, die fehlende tiefgreifende Überprüfung von Anwendungen oder die Signaturproblematik könnte man auch auf Linux-Distribution übertragen, ebenso den oft unbegründete Konnex von Open Source und Sicherheit. Das ist keineswegs ein Problem, das auf Android oder F-Droid beschränkt wäre. Andere Probleme wie das fehlende tiefergehende Verständnis für Sicherheit und laxe Praktiken kann man auch bei anderen Projekten im AOSP-Umfeld wie LineageOS, XDA & Co beobachten und wurde von mir bereits mehrfach kritisiert. Ein Grund, weshalb ich inzwischen GrapheneOS nutze.
Der Autor empfiehlt als sichere Alternative den Play Store. So mancher mag da aufschreien, aber das ist eben einer dieser Bereiche, bei denen sich Datenschutz und Sicherheit in die Quere kommen. Was für die Sicherheit geboten wäre, muss nicht zwangsläufig gut für den Datenschutz sein. Deshalb finde ich persönlich den Artikel zwar interessant und bedenkenswert, aber werde trotzdem vorerst weiter an F-Droid festhalten, denn mein GrapheneOS ist frei von Play Diensten und Play Store und es gibt aktuell keinen anderen App Store außer F-Droid.
Mittelfristig interessant könnte der “App Store” werden, den die GrapheneOS-Entwickler in der Pipeline haben. Hier bleibt aber abzuwarten, was der alles enthalten wird und ob das ausreicht, um auf F-Droid zu verzichten.
Ein kurzer Kommentar zur Aussage:
“Die Probleme beginnen schon bei den Signaturen der Apps, da F-Droid alle Apps mit seinen eigenen Keys signiert. Das untergräbt den sonst verfolgten Ansatz, dass Entwickler ihre Apps selbst signieren und der Anwender dem Vertriebskanal nicht vertrauen muss.”
Das ist das gängige Vertrauensmodell _aller_ Linux-Distributionen: Debian/Ubuntu/OpenSUSE/Arch/Gentoo-Pakete sind _immer_ mit den Schlüsseln der Maintainer signiert, wobei diese eben genau die Verantwortung haben, dass sie keinen Mist ausliefern. Das Vertrauensmodell ist also im Gegensatz zum Playstore, dass man nur einigen wenigen Menschen vertrauen muss und nicht beliebig vielen. Ein Malwareautor wird seine Malware _immer_ signieren.
Google macht dann so workarounds wie automatischen Virenscan, der nur so mäßig funktioniert, weil eben der Quellcode nicht vorliegt (Stichwort: proprietäre Bibliotheken).
Falls es dir wichtig als App-Autor wichtig ist, dass du deine eigene Software selbst signierst, so geht das mittlerweise ohne Probleme mit Reproducible Builds, sodass dann du als Entwickler als auch der F-Droid-Maintainer das gleiche Stück Binärblob als “gut und kommt aus dem Quellcode” signieren kann.
Also im Gegensatz zu der in diesem Blog propagierten These nutze ich F-Droid gerade wegen dieses Vertrauensmodell. Google hat nämlich inhärent keine Chance, mir sicher nur guten Code auszuliefern (weil ein 4-Augen -Prinzip bei proprietärem Code unmöglich ist).
Was meinst du mit “in diesem Blog”? Mein Blog hier oder das verlinkte Blog? Ich habe das am Schluss doch ziemlich klar eingeordnet und auch geschrieben, dass ich F-Droid weiter nutze, eben weil der Play Store keine Alternative ist?
Trotzdem finde ich es valide sich mal damit zu befassen. Ein paar Aspekte wie hinterherhinkende Versionen, der API-Level oder suboptimale Gewohnheiten in der AOSP-Community sind nun bei weitem keine Einzelmeinungen.
Wie viel Maintainer noch wert sind und was diese wirklich prüfen (können) – freier Quellcode hin oder her – ist wohl ein anderes Thema und würde hier den Rahmen sprengen.
Ich hoffe doch, das GrapheneOS wenn schon nicht den Fdroid doch wenigstens beim verifizierren von gutem, sicherem Quellcode mit fdroid zusammen arbeiten.
Es wäre nicht schlecht wenn die beiden da zusammenarbeiten. Vielleicht könnten sie gar dieselbe Server Architektur verwenden/weiterentwickeln.
Da F-Droid im Prinzip einfach nur Paketquellen einbindet, also bei Bedarf auch mit Fremdquelle kann, wäre die App selber sicherlich eine gute Grundlage um eigene Paketquellen bereitzustellen. Eine angepasste Version würde sich bestimmt auch den Konzepten von GrapheneOS beiordnen können. Im Endeffekt wäre es – wie immer – wünschenswert, wenn dabei nicht jeder auf irgendwelche Eigenlösungen setzt, die dann mit Bus-Faktor 1,5 entwickelt werden …
Die meisten dieser Punkte beziehen sich auf f-droid als Repository, nicht als App. Es steht Leuten, die Android-Apps entwickeln, frei, die selbst signierten, aktuellen, auf einem aktuellen API-Level aufsetzenden Original-APKs in einem eigenen F-Droid-fähigen Repository zu veröffentlichen. Die Tagesschau-App tut das. Es bleiben die fehlenden automatischen Hintergrund-Updates.
Ich weiß nicht so recht ob F-Droid gut, schlecht, sicher oder unsicher ist. Mir ist aufgefallen, das F-Droid laufend Daten verbraucht. Und wenn ich F-Droid “beenden erzwingen” benutze, startet es dann selbstständig wieder und wird mit irgendwelchen Updates genötigt. Wo ist das dann besser als Google Play?
Ich verstehe deinen Punkt nicht. Natürlich verbraucht F-Droid ständig Daten. Wie soll es denn sonst Paketquellen aktualisieren oder Updates herunterladen? Dazu muss sich die App natürlich auch selbstständig starten können, wenn sie mal beendet wurde. Die Probleme bei Google Play bzw. Google liegen doch nicht darin, dass deren Apps im Hintergrund laufen, sondern in der Datenerhebung.