- F-Droid kritisiert, dass Android Developer Verification (ADV) bereits auf Geräten mit Android 8 oder höher ausgerollt wurde und zu einem zentralen Kontrollmechanismus werden könnte, der die Ausführung von Apps von Entwicklern verhindert, die Google nicht genehmigt hat
- Google führt die Eindämmung der Verbreitung von Malware als Begründung an, doch F-Droid sieht ADV weniger als Mittel zur Blockade der Erstverbreitung, sondern eher als Mechanismus, der die Kosten für die erneute Registrierung wiederholt auffälliger Entwickler erhöht
- Für die Entwicklerregistrierung sind Kontoerstellung, Gebühren, die Übermittlung personenbezogener Daten und eines staatlich ausgestellten Ausweisdokuments, die Registrierung von App-Kennungen und Signaturschlüsseln sowie die Zustimmung zu den Android Developer Console Terms erforderlich
- Die zentrale Sorge ist, dass Google den Kreis der blockierten Ziele aus geschäftlichen Gründen oder auf staatlichen Druck ausweiten könnte, wenn die Bedingungen keine klare Definition von Malware enthalten
- Die Anwendung beginnt am 30. September 2026 in Brasilien, Indonesien, Singapur und Thailand; die tatsächlichen Auswirkungen auf die F-Droid-App, installierte Apps, App-Daten und Googles Verifizierungs-Telemetrie sind noch unklar
Warum F-Droid ADV mit Malware vergleicht
- F-Droid geht davon aus, dass Android Developer Verifier (ADV) auf Geräten mit Android 8 oder höher installiert ist und auf eine Remote-Aktivierung wartet
- ADV wurde demnach bereits auf bis zu 4 Milliarden Android-Smartphones und -Tablets ausgerollt; es wird geschätzt, dass etwa die Hälfte der Weltbevölkerung betroffen sein könnte
- Dieser Systemdienst läuft im Hintergrund, und F-Droid erklärt, ihn nicht blockieren, deaktivieren oder entfernen zu können
- Play Protect ist auf Android-Certified-Geräten ein Dienst zur Erkennung und Bekämpfung allgemeiner Malware, doch F-Droid kritisiert, dass ADV über Play Protect verbreitet und installiert werde
- Nach der Aktivierung besteht das Ziel von ADV nach Einschätzung von F-Droid darin, die Ausführung von Software von Entwicklern zu verhindern, die Google nicht zentral genehmigt hat
Erwiderung auf die Begründung der Malware-Abwehr
- F-Droid äußerte seine Bedenken zu Android Developer Verification erstmals im September 2025 in F-Droid and Google’s Developer Registration Decree
- Googles Pflicht zur zentralen Entwicklerregistrierung wird als Maßnahme gegen die Verbreitung von Malware dargestellt, doch F-Droid ist der Ansicht, dass dieses System die Erstverbreitung durch böswillige Akteure nicht verhindert
- Der tatsächliche Effekt liege eher darin, bereits identifizierte Wiederholungstäter zu verlangsamen, wenn sie Malware mit einem neuen Signaturschlüssel weiterverbreiten wollen und dafür ein neues Konto erstellen oder kaufen müssen
- F-Droid verweist darauf, dass auch weniger zwanghafte Alternativen möglich wären
- Play Protect könnte neu installierte Apps mit hohen Berechtigungen oder Apps aus verdächtigen Quellen genauer prüfen
- Auch ein Modell föderierter Verifizierer wäre möglich, bei dem Nutzer selbst wählen, welchen Prüfern und Autoritäten sie vertrauen, wie bei DCM: A Developers Certification Model for Mobile Ecosystems
- F-Droid kritisiert, dass Google das Android-Ökosystem wegen eines engen Bedrohungsvektors neu gestalten und zum einzigen Gatekeeper dafür werden wolle, welche Apps existieren dürfen
Entwicklerregistrierung und Risiken der Bedingungen
- Entgegen der Empfehlung von F-Droid müssen Entwickler, die sich bei Google als „verified“ registrieren, folgenden Prozess durchlaufen
- Konto erstellen und Gebühr zahlen
- Detaillierte personenbezogene Daten übermitteln
- Staatlich ausgestelltes Ausweisdokument hochladen
- Kennungen und Signaturschlüssel für aktuell und künftig zu verbreitende Apps registrieren
- Der größte Streitpunkt ist, dass sie gezwungen sind, den Android Developer Console Terms of Service zuzustimmen
- Abschnitt 6.5 der Bedingungen besagt, dass Google den Zugriff auf die ADC beenden kann, wenn ein Entwickler gegen die Bedingungen verstößt oder Malware beziehungsweise eine harmful application verbreitet
- F-Droid weist darauf hin, dass dieses Dokument nirgends eine offizielle Definition, Kriterien oder Richtlinien für „malware“ enthält
- Wenn die Definition leer bleibt, wird „malware“ zu Software, die Google so bezeichnet, und der Umfang kann sich je nach geschäftlichen Motiven oder starkem staatlichem Druck verändern
Das Beispiel Adblocker zeigt das Problem der Reichweite von Sperren
- F-Droid warnt davor, umstrittene Begriffe von einer Partei mit abweichenden Interessen definieren zu lassen
- Als zentrales Beispiel nennt F-Droid Adblocker, also Tools zum persönlichen Filtern von Inhalten
- Adblocker sind seit Langem in einigen Fällen aus dem Play Store verbannt worden
- In manchen Fällen wurden sie als Malware eingestuft
- F-Droid befürchtet, Google könne jede Adblocking-Software als Malware einstufen, ihre Installation auf Android-Certified-Geräten weltweit verhindern und die betreffenden Entwickler als Malware-Autoren klassifizieren
- Diese Möglichkeit passe nach Einschätzung von F-Droid zu Googles geschäftlichen Motiven im Bereich Werbetechnologie und zum Wortlaut der Android-Developer-Console-Bedingungen
Behauptete Akzeptanzquote und Gegenbewegung
- Google erklärte kürzlich, dass sich mehr als 99 % der Play-Entwickler-Apps registriert hätten; F-Droid widerspricht jedoch, dass dies als Beleg für eine breite Akzeptanz von ADV gelten könne
- Laut F-Droid waren diese Entwickler bereits an bestehende Play-Store-Verträge gebunden und wurden daher ohne ausreichende vorherige Zustimmung automatisch einbezogen
- Auch die Gegenbewegung gegen ADV hält an
- Hunderttausende haben eine Petition gegen ADV unterzeichnet
- Den Open Letter von keepandroidopen.org haben mehr als 70 Organisationen weltweit unterzeichnet, darunter EFF, FSF, FSFE, ACLU und Forbrukerrådet
- F-Droid gibt an, dass bei einem Entwickler-Roundtable-Video zur Verteidigung des Programms 90 % der Zuschauer ein Dislike abgegeben hätten
- F-Droid sagt, Gesetzgeber und Regulierungsbehörden hätten bislang nicht auf die Gegenwehr reagiert
- F-Droid sieht sein auf Open-Source-Transparenz basierendes Sicherheitsmodell in grundlegendem Konflikt mit dem Vertrauensmodell geschlossener kommerzieller App-Stores
Verbleibende Unsicherheit vor der Anwendung am 30. September
- Es ist noch nicht genau bekannt, in welchen Fehlermodi sich die ADV-Aktivierung am 30. September 2026 zeigen wird
- Laut Googles öffentlichem Zeitplan sind Brasilien, Indonesien, Singapur und Thailand die ersten betroffenen Länder
- In diesen vier Ländern leben demnach 580 Millionen Menschen
- Der weltweite Rollout ist für „2027 und später“ vorgesehen
- Für Nutzer in den betroffenen Regionen bleiben Fragen offen, die noch beantwortet werden müssen
- Es ist unklar, was passiert, wenn sie versuchen, die F-Droid-App zu installieren oder auszuführen
- Es ist ungewiss, ob über F-Droid installierte Apps deaktiviert oder gelöscht werden
- Es ist nicht bekannt, ob Nutzer weiterhin an die Daten in Apps gelangen können, auf die sie angewiesen waren, falls diese plötzlich verschwinden
- Es ist unklar, welche Telemetrieinformationen enthalten sind, wenn jede Softwareinstallation und -ausführung zur Google-Verifizierung gemeldet wird
- F-Droid hat entsprechende Anfragen geschickt und erklärt, in den Wochen und Monaten vor der Sperrung zusätzliche Hinweise und Unterstützung für betroffene Nutzer bereitzustellen
2 Kommentare
Eigentlich ist das Argument, es gebe ja alternative Betriebssysteme und deshalb sei alles in Ordnung, sinnlos. Wenn man etwa auf einem Galaxy ein anderes OS installieren will, muss man den Hardware-Sicherheitschip deaktivieren; dann werden aber Dinge wie Payment- und Banking-Apps vermutlich nicht mehr funktionieren.
Hacker-News-Kommentare
Das löst das Problem zwar nicht sofort, aber falls sich dieser Trend nicht aufhalten lässt, ist es gut zu wissen, dass es mehrere echte mobile Linux-Betriebssysteme gibt
SailfishOS basiert auf Linux, und die Community wirkt ziemlich offen, aber der UI-Stack ist Closed Source. Es ist die einzige Option hier, die Android-Apps offiziell per Emulation ausführen kann, existiert schon lange, ist leichtgewichtig und wirkt in dieser Liste am stabilsten und am wenigsten fehleranfällig
Ubuntu Touch ist vollständig Open Source und Community-getrieben, nutzt zur Sicherheit Snap-Pakete und kann möglicherweise ebenfalls Android-Apps ausführen. Als ich es zuletzt benutzt habe, war es auch ziemlich stabil
PureOS ist vollständig Open Source und auf Datenschutz ausgerichtet. Soweit ich weiß, ist es unter den mit dem Librem 5 veröffentlichten Systemen die einzige Option, die bei der Hardware-Integration proprietäre binäre Blobs vermeiden kann. Es wirkt weniger stabil als SailfishOS oder Ubuntu Touch, und man muss dafür ein ziemlich teures, veraltetes Librem 5 kaufen
PostmarketOS ist vollständig Open Source und fokussiert sich auf Leichtgewichtigkeit und die Wiederbelebung alter Telefone, unterstützt sehr viele getestete Geräte und basiert auf Alpine
Mobian ist die mobile Variante von Debian und in dieser Liste vergleichsweise neu. Es gibt noch weitere mobile Linux-Betriebssysteme, aber soweit ich weiß, sind das die wichtigsten Optionen; manches habe ich vor langer Zeit getestet, daher könnte einiges ungenau sein, und die letzten beiden habe ich nie selbst verwendet
Apps, die darauf laufen, sind gegenüber dem Linux-Kernel nicht stärker, sondern schwächer isoliert. Wenn einem Datenschutz und Sicherheit wichtig sind, sind diese Betriebssysteme viel weniger privat und viel weniger sicher als das Android Open Source Project. Es gibt weder eine vollständige, funktionierende App-Sandbox oder ein Berechtigungsmodell noch moderne Maßnahmen zur Schwachstellenminderung oder ernsthafte hardwaregestützte Verschlüsselungsfunktionen, die nötig sind, um das Auslesen von Daten zu verhindern
Während ein AOSP-basiertes Betriebssystem auf ordentlicher Hardware eine Alternative zum iPhone sein kann, sind diese Systeme aus Datenschutz- und Sicherheitsgründen keine ernsthafte Alternative. Diese Warnung wird zu Google Mobile Services OS hinzugefügt und hat keine negativen Auswirkungen auf andere auf dem Android Open Source Project basierende Betriebssysteme
Linux bedeutet nicht automatisch GNU/Linux oder systemd/Linux und auch nicht, dass glibc, systemd, GNU coreutils, Bash, GNOME usw. verwendet werden. Auch Android-basierte Betriebssysteme einschließlich AOSP und GrapheneOS sind Linux-Distributionen. Alpine nutzt kein glibc, und SailfishOS hat ebenfalls seine eigene Mischung aus offener und proprietärer Software. Ob ein typischer Desktop-Linux-Userspace-Stack verwendet wird, entscheidet nicht darüber, ob etwas Linux ist, und selbst auf dem Desktop sind die verwendeten Konfigurationen nicht einheitlich
Ich persönlich nutze auf dem Librem 5 keine Android-Apps, aber im PureOS-Repository gibt es Waydroid. Waydroid ist ein containerbasierter Ansatz, der auf allgemeinen GNU/Linux-Systemen mit Wayland-basierter Desktop-Umgebung ein vollständiges Android-System bootet
PureOS bietet über Phosh auch Konvergenz. Damit ist gemeint, dass dieselben Apps sowohl auf dem Telefon als auch auf größeren Bildschirmen genutzt werden können und sich die GUI an die verfügbare Bildschirmgröße anpasst
Phosh möchte eine robuste und einfach zu nutzende grafische Benutzerumgebung bereitstellen, die auf mobilen Geräten mit Mainline-Linux alltagstauglich ist. Ursprünglich wurde es von Purism-Entwicklern für das Librem 5 begonnen, wird inzwischen aber auf vielen Geräten wie Smartphones, Tablets und Convertibles genutzt und wurde auch schon auf Laptops gezeigt
UI/UX ist teuer, und die meisten freien Open-Source-Projekte können ohne große Unternehmensinvestitionen oder Unterstützung durch Startups kaum vernünftig umgesetzt werden. So haben etwa die UX-Designer von Red Hat erheblich zu GNOME beigetragen, und es gibt Startup-Beispiele wie Zed, Element und Bluesky
Projekte ohne solche Rückendeckung sind zumindest aus Sicht der Gen Z meist schwer benutzbar
Android-Nutzer sollten zu Graphene wechseln
Jemand sollte eine Linux-basierte Mobile-OS-Stiftung gründen. Googles Dominanz läuft auch den Interessen vieler Großunternehmen zuwider, und wenn man auf Firmen wie Meta zugeht, könnten diese wegen strategischer Interessen viel Geld spenden.
Sobald Google das Gefühl hat, bei gehärteten Speicher-Allokatoren und Tagged Memory genug Stabilität und Kompatibilität erreicht zu haben und Qualcomm dazu bringen kann, dies über die gesamte Produktpalette zu unterstützen, wird es Graphene erst erschweren und am Ende unmöglich machen.
Laut [1] ist es Google und Mitgliedern der Open Handset Alliance vertraglich untersagt, Geräte herzustellen, die nicht von Google genehmigt sind, auch wenn der Artikel alt ist.
Um zu konkurrieren, müsste man auch kompatible Google Play Services entwickeln und Hersteller finden, die das unterstützen. Samsung betrieb eine Zeit lang mit Tizen eigene Apps und einen eigenen Store [2], vielleicht um Verhandlungsmacht zu gewinnen oder einen theoretischen Wechsel vorzubereiten. Später hat man diese Bemühungen aber aufgegeben.
[1] https://arstechnica.com/gadgets/2018/07/googles-iron-grip-on...
[2] https://arstechnica.com/tech-policy/2021/07/google-bought-of...
Viele normale Nutzer, besonders außerhalb der USA, können sich das nicht leisten. Außerdem finanziert man mit dem Kauf eines Google-Smartphones Google mit, was ich persönlich vermeiden möchte.
Auch mit AOSP kann man die Notwendigkeit proprietärer User-Space-Treiber für Komponenten wie aktuelle Mali-GPUs beseitigen, und das wäre für die meisten Menschen am vorteilhaftesten. Wenn viele Unternehmen und andere Akteure ihre Kräfte bündeln, ist das in AOSP möglich.
Wegen Googles Verstößen gegen das Kartellrecht könnte das auch durch staatliches Eingreifen passieren, aber im schlimmsten Fall könnte es auf eine Weise geregelt werden, die Open Source schadet.
Ich verstehe die Frustration. Ich nutze fdroid auf mehreren Geräten ebenfalls intensiv. Aber dieser Artikel wirkt wegen Formulierungen wie Virus, Trojaner und „Malware-Unternehmen“ kindisch.
Solche Texte liefern vielen Leuten, vielleicht sogar Google, einen Vorwand, fdroid als „kindische Behauptungen, die man nicht ernst nehmen muss“ abzutun. Zum Beispiel würde eine seriöse Nachrichtenredaktion diesen Text nicht veröffentlichen.
Ergänzend ist https://keepandroidopen.org/ das besser gemachte Beispiel.
Es gibt keinerlei Garantie, dass das nicht auch für andere Zwecke als Sicherheit genutzt wird. Und es stimmt auch, dass es der Sicherheit in der Praxis nicht wesentlich hilft.
Wenn man die Google-Suche fragt, erklärt die KI Malware als Software, die für unbefugten Zugriff, Störung, finanzielle Erpressung oder die Übernahme eines Geräts entwickelt wurde. Wenn du trotzdem meinst, dass der Ausdruck nicht passt, stell dir einfach vor, jemand anderes würde eine App mit derselben Funktion entwickeln. Google würde sie sofort als Malware entfernen. Es würde das eindeutig als Malware betrachten.
Ich nutze Android, weil ich auf meinem Telefon installieren können will, was ich möchte, und das sollte nicht umstritten sein. Das Telefon gehört entweder mir oder eben nicht. Ich will keinen Schutz von Google, erst recht nicht, wenn ich ihn nicht ablehnen kann.
In der Informatik ist ein Trojaner eine Art von Malware, die sich als legitimes Programm tarnt und Nutzer über ihre tatsächliche Absicht täuscht [1].
Google ist bis ins Mark ein Trojaner. Was ist die eigentliche Absicht fast aller Google-Produkte? Datenernte.
Jedes Produkt ist in irgendeiner Form Spyware. Sie subventionieren Hersteller, damit diese ihre eigene Spyware vorinstallieren, und haben sogar Fernseher in Trojaner verwandelt.
[1] https://en.wikipedia.org/wiki/Trojan_horse_(computing)
Um ein paar Dinge herauszugreifen: Sideloading wird weltweit nur von weniger als 1–2 % der Android-Nutzer verwendet, also höchstens von etwa 50 Millionen Menschen. Google hat es im Grunde nur mit einer 24-Stunden-Verzögerung offengelassen und zeigt damit eher noch Entgegenkommen. Es hätte schlimmer kommen können, aber solange es beim ewigen Hobby bleibt, in den Entwickleroptionen herumzuspielen, ist das derzeit kein großes Ding. Persönlich bin ich Google dafür dankbar
GMS bietet App-Entwicklern, die eine starke Kontrolle benötigen, einschließlich staatlicher Stellen, enormen Komfort. Damit lassen sich Apps gegenüber Nutzern jeder Couleur schützen. Nimmt man noch das Potenzial für versteckte Backdoors zur Unterstützung von Überwachung und Googles direktes Lobbying in der EU hinzu, wird es trotz des derzeit eher antiamerikanischen Kurses der EU sehr schwer, ohne GMS auszukommen, und in Europa wird es wohl als Letztes ersetzt werden
Es gibt verschiedene Stufen von „De-Googling“. Das Spektrum reicht von der Installation eines vollständig offenen OS mit oder ohne microG bis dazu, sich auf einem normalen Android einfach nicht mit einem Google-Konto anzumelden. Aber Menschen am freien Ende dieses Spektrums werden niemals dieselben Rechte haben wie Menschen am Gefängnisende
Entwicklerverifizierung dient nicht dazu, Werbeblocker zu verhindern. Es gibt eine einfache und kostenlose Möglichkeit, auf DNS-Ebene alles zu blockieren, was man möchte. Man wählt Private DNS und trägt eine passende URL von Anbietern wie controld.com für das Blockieren von Werbung, Trackern und Pornografie ein. Dafür muss es also andere Vorwände geben. Etwa eine starke Nutzerkontrolle, um weiter mit Regierungen im Bett zu liegen, oder den Vorwand, mit der bald kommenden Alters- bzw. Kinder-Identitätsprüfung die ultimative Nutzerüberwachung zu erreichen
Alles Übrige sind nur weitere Varianten der Google-Verteidigung. Ehrlich gesagt ist das zutiefst enttäuschend, und noch mehr ausgerechnet bei „Hacker“-News
Herkunftsnachweise sind eine mächtige Waffe im Kampf gegen Malware, aber die Fähigkeit zu bewahren, anonyme Software zu installieren und auszuführen, ist essenziell, um sich autoritären Regimen und korrupten Systemen entgegenzustellen
Wenn wir akzeptieren, dass nur signierte und genehmigte Software auf den Telefonen der Nutzer installiert und ausgeführt werden darf, dann sind Demokratie und Freiheit am Ende. Das gilt im Westen wie im Osten und auch in einem Szenario gegen AI-Herrscher
An vielen Hardware- und Softwarekomponenten, von denen wir abhängig sind, können wir keine beliebigen Änderungen vornehmen. Wir können ihr Design nicht prüfen, nicht nachbauen und manchmal nicht einmal reparieren
Manchmal wissen wir nicht einmal, ob sie gegen unsere Interessen entworfen wurden, und selbst wenn wir es wissen, können wir oft nichts dagegen tun. Wir werden gezwungen, zwischen Preis und Privatsphäre, zwischen Monopol bzw. offiziellen Systemen und Interoperabilität auf der einen Seite und Freiheit auf der anderen zu wählen
Dass Android in diese Richtung noch einen weiteren Schritt geht, ist schlecht. Aber machen wir uns nichts vor: Wir stecken seit Jahrzehnten bis zum Hals in der cyberpunkigen Leibeigenschaft. Selbst wenn wir diesen Android-Kampf gewinnen, wäre das nur ein kleiner Sieg
Das soll nicht defätistisch klingen, sondern nur daran erinnern, den größeren Kampf nicht zu vergessen. Wie wird dieser feudale Goliath enden? Wann ist genug wirklich genug?
Unterdessen hat Google in Luxemburg den Prozess um die 4,7-Milliarden-Dollar-Android-Strafe der EU verloren
https://www.msn.com/en-us/money/other/google-loses-fight-aga...
Ich bin immer noch etwas verwirrt, warum die EU in dieser Sache nicht einschreitet. Das ist ganz klar Übergriff eines Monopolisten und hätte von Anfang an verhindert werden müssen
https://www.eu-digital-markets-act.com/Digital_Markets_Act_A...
Wir haben jahrzehntelang akzeptiert, dass OS-Anbieter so etwas tun dürfen. Ich denke, das war der Fehler: sich auf Google als den einzig möglichen Anbieter zu verlassen. Man kann kein Gesetz machen, das Google dafür bestraft, dass es bisher offen war
Natürlich bin ich wie andere HN-Hacker auch dafür, dass auch Apple zur Öffnung gezwungen wird, aber die derzeitigen Machteliten der EU und viele Wähler scheinen Remote-DRM-Attestierung ziemlich zu mögen für das Digital-Identity-Projekt, das bald für alles nötig sein dürfte, was nicht kindgerecht und nicht über das Dark Web erreichbar ist
HN-Nutzer, besonders Amerikaner, sind naiv genug, die EU für eine Bastion der Freiheit zu halten. Das ist sie überhaupt nicht. Die EU will nur ein riesiger Nanny State werden, eine hübsch klingende Form, in der man alles tun darf, solange es genehmigt ist