https://www.kuketz-blog.de/modern-solution-bundesverfassungsgerich-bestaetigt-wegsehen-ist-sicherer-als-aufdecken/
Mike Kuketz
23. September 2025 | 09:09 Uhr
Modern Solution: Bundesverfassungsgerich bestätigt – Wegsehen ist sicherer als Aufdecken
Karlsruhe hat gesprochen – und wieder einmal zeigt sich, wie absurd die deutsche Rechtsprechung im Bereich IT-Sicherheit funktioniert. Es geht im Fall Modern Solution nicht um einen dunklen Hacker aus dem Untergrund, sondern um einen IT-Experten, der eine grob fahrlässige Lücke in einer E-Commerce-Software offengelegt hat. Diese Software enthielt ein hartcodiertes Datenbankpasswort, im Klartext, identisch für alle Kunden und frei in einer Datei lesbar. Mit dieser Information konnte sich jeder, der die Software hatte, direkt auf eine zentrale Datenbank verbinden, in der personenbezogene Daten von rund 700.000 Käufern lagen – von Namen über Adressen bis hin zu Kontodaten. Das ist kein »Einbruch«, sondern ein offenes Scheunentor, das nur jemand bemerken musste, um den Missstand zu sehen.
Statt nun aber den Hersteller in die Pflicht zu nehmen, wurde derjenige verfolgt, der den Fehler dokumentiert und öffentlich gemacht hat. Die Gerichte haben sich dabei auf eine juristische Minimaldefinition von »Zugangssicherung« versteift: Ein Passwort – egal wie erbärmlich implementiert – reicht aus, um § 202a StGB auszulösen. Dass das Passwort im Klartext in der Software stand und für alle Kunden identisch ist – also keinerlei echte Schutzwirkung hat – spielt für die Gerichte keine Rolle. Sicherheit wird hier nicht technisch, sondern formaljuristisch gedacht – und das Ergebnis ist, dass jeder, der eine solche Schwachstelle nachweist, kriminalisiert wird.
Besonders zynisch ist, dass Screenshots, die den Zugang belegten, vor Gericht als Beweis für die Strafbarkeit gewertet wurden. Genau diese Dokumentation ist aber Voraussetzung für eine ernstzunehmende Meldung an Hersteller oder Behörden. Ohne Belege nimmt niemand eine Schwachstelle ernst. Mit Belegen macht man sich in Deutschland strafbar. Wer sich professionell mit Softwareanalyse beschäftigt, wird so in eine Sackgasse geschickt: Entweder man schweigt und lässt die Lücken offen, oder man dokumentiert und riskiert Hausdurchsuchung, Strafverfahren und Rufschaden.
Das Bundesverfassungsgericht hätte hier die Chance gehabt, Klarheit zu schaffen und § 202a StGB so auszulegen, dass Verantwortungsbewusstsein nicht mit krimineller Energie gleichgesetzt wird. Stattdessen lehnt Karlsruhe die Beschwerde ohne Begründung ab. Das ist nicht nur ein fatales Signal an die Community der Sicherheitsforscher, sondern eine gefährliche Einladung an Unternehmen, sich hinter billigsten Alibi-Maßnahmen zu verstecken und Kritiker mit Strafanzeigen mundtot zu machen.
Die Botschaft an alle, die in Deutschland für mehr IT-Sicherheit sorgen wollen, lautet: Finger weg, sonst seid ihr die Kriminellen. Damit macht man Responsible Disclosure faktisch unmöglich und fördert genau das, was man eigentlich verhindern will – dass Schwachstellen im Verborgenen bleiben oder auf grauen Märkten landen. In der Konsequenz schützt man nicht die Bürger, sondern einzig die Unternehmen, die es nicht hinbekommen, ihre Produkte auf einem Mindestniveau sicher zu entwickeln. So kriminalisiert man Verantwortung und erklärt Inkompetenz zum Standard. Deutschland und IT: Willkommen im Neuland.
Mike Kuketz
23. September 2025 | 09:09 Uhr
Modern Solution: Bundesverfassungsgerich bestätigt – Wegsehen ist sicherer als Aufdecken
Karlsruhe hat gesprochen – und wieder einmal zeigt sich, wie absurd die deutsche Rechtsprechung im Bereich IT-Sicherheit funktioniert. Es geht im Fall Modern Solution nicht um einen dunklen Hacker aus dem Untergrund, sondern um einen IT-Experten, der eine grob fahrlässige Lücke in einer E-Commerce-Software offengelegt hat. Diese Software enthielt ein hartcodiertes Datenbankpasswort, im Klartext, identisch für alle Kunden und frei in einer Datei lesbar. Mit dieser Information konnte sich jeder, der die Software hatte, direkt auf eine zentrale Datenbank verbinden, in der personenbezogene Daten von rund 700.000 Käufern lagen – von Namen über Adressen bis hin zu Kontodaten. Das ist kein »Einbruch«, sondern ein offenes Scheunentor, das nur jemand bemerken musste, um den Missstand zu sehen.
Statt nun aber den Hersteller in die Pflicht zu nehmen, wurde derjenige verfolgt, der den Fehler dokumentiert und öffentlich gemacht hat. Die Gerichte haben sich dabei auf eine juristische Minimaldefinition von »Zugangssicherung« versteift: Ein Passwort – egal wie erbärmlich implementiert – reicht aus, um § 202a StGB auszulösen. Dass das Passwort im Klartext in der Software stand und für alle Kunden identisch ist – also keinerlei echte Schutzwirkung hat – spielt für die Gerichte keine Rolle. Sicherheit wird hier nicht technisch, sondern formaljuristisch gedacht – und das Ergebnis ist, dass jeder, der eine solche Schwachstelle nachweist, kriminalisiert wird.
Besonders zynisch ist, dass Screenshots, die den Zugang belegten, vor Gericht als Beweis für die Strafbarkeit gewertet wurden. Genau diese Dokumentation ist aber Voraussetzung für eine ernstzunehmende Meldung an Hersteller oder Behörden. Ohne Belege nimmt niemand eine Schwachstelle ernst. Mit Belegen macht man sich in Deutschland strafbar. Wer sich professionell mit Softwareanalyse beschäftigt, wird so in eine Sackgasse geschickt: Entweder man schweigt und lässt die Lücken offen, oder man dokumentiert und riskiert Hausdurchsuchung, Strafverfahren und Rufschaden.
Das Bundesverfassungsgericht hätte hier die Chance gehabt, Klarheit zu schaffen und § 202a StGB so auszulegen, dass Verantwortungsbewusstsein nicht mit krimineller Energie gleichgesetzt wird. Stattdessen lehnt Karlsruhe die Beschwerde ohne Begründung ab. Das ist nicht nur ein fatales Signal an die Community der Sicherheitsforscher, sondern eine gefährliche Einladung an Unternehmen, sich hinter billigsten Alibi-Maßnahmen zu verstecken und Kritiker mit Strafanzeigen mundtot zu machen.
Die Botschaft an alle, die in Deutschland für mehr IT-Sicherheit sorgen wollen, lautet: Finger weg, sonst seid ihr die Kriminellen. Damit macht man Responsible Disclosure faktisch unmöglich und fördert genau das, was man eigentlich verhindern will – dass Schwachstellen im Verborgenen bleiben oder auf grauen Märkten landen. In der Konsequenz schützt man nicht die Bürger, sondern einzig die Unternehmen, die es nicht hinbekommen, ihre Produkte auf einem Mindestniveau sicher zu entwickeln. So kriminalisiert man Verantwortung und erklärt Inkompetenz zum Standard. Deutschland und IT: Willkommen im Neuland.
www.kuketz-blog.de
Modern Solution: Bundesverfassungsgerich bestätigt – Wegsehen ist sicherer als Aufdecken
Karlsruhe hat gesprochen – und wieder einmal zeigt sich, wie absurd die deutsche Rechtsprechung im Bereich IT-Sicherheit funktioniert. Es geht…
https://www.kuketz-blog.de/kommentar-zur-eu-data-boundary-die-illusion-europaeischer-souveraenitaet-bei-der-eu-kommission/
Mike Kuketz
1. August 2025
Kommentar zur »EU Data Boundary«: Die Illusion europäischer Souveränität bei der EU-Kommission
EU Data BoundaryDarf die Europäische Kommission intern mit Microsoft 365 arbeiten, obwohl dabei personenbezogene Daten in die USA fließen? Darum ging es in einem Verfahren durch den EU-Datenschutzbeauftragten. Der hat das Verfahren jetzt offiziell eingestellt. Die Begründung: Vertragsänderungen, vertraglich festgelegte Einschränkungen bei Datenübermittlungen – und die Einführung der sogenannten »EU Data Boundary«. Diese soll laut Wiewiórowski die Übermittlung personenbezogener Daten aus dem EWR »auf ein Minimum« reduzieren.
Soweit die Darstellung im offiziellen Schreiben des EU-Datenschutzbeauftragten. Aus unserer Sicht ist damit nichts gewonnen: Das Verfahren ist eingestellt, nichts muss sich ändern und die Details bleiben weiter unklar. Die Einschätzung folgt weitgehend den Angaben der Kommission, ohne erkennbare technische Gegenprüfung oder kritische Auseinandersetzung mit strukturellen Risiken. So entsteht der Eindruck, als sei das Datenschutzproblem rund um Microsoft 365 gelöst.
Im Kern bleibt vor allem unklar, wie belastbar die »EU Data Boundary« in der Praxis wirklich ist: Es fehlen technische Nachweise, unabhängige Kontrollen und rechtliche Garantien. Alles basiert auf Annahmen und Vertrauen – in ein US-Unternehmen, das Daten nach nationalem Recht auch außerhalb der EU offenlegen muss.
Politisch gewollt, technisch unüberprüft
Die Entscheidung wirkt wie der Versuch, ein strukturelles Problem durch vertragliche Kosmetik zu lösen. Es gibt keine unabhängige technische Analyse darüber, was Microsoft tatsächlich an Daten verarbeitet, übermittelt oder speichert. Die »Data Boundary« bleibt ein Konzept – kein überprüfbarer Schutzmechanismus. Kein Open Audit. Keine vollständige Dokumentation. Kein Einblick in die Backend-Telemetrie. Aber viel Vertrauen – in einen Anbieter, der nach US-Recht operiert.
Wer sich mit den rechtlichen Grundlagen und den Zugriffsmöglichkeiten US-Behörden beschäftigt, weiß: Daten, die unter der Kontrolle eines US-Unternehmens stehen, können abgerufen werden – auch wenn sie in Frankfurt oder Amsterdam liegen. Das wurde nicht nur mehrfach juristisch bestätigt, sondern auch politisch in Form des CLOUD Act verankert.
Kein Wort zu den Zugriffsmöglichkeiten der US-Behörden
Besonders irritierend ist, dass im offiziellen Schreiben des EU-Datenschutzbeauftragten zentrale Tatsachen völlig unberücksichtigt bleiben. Nur wenige Tage vor dem Schreiben erklärte ein ranghoher Microsoft-Justiziar unter Eid vor dem französischen Parlament, dass man »nicht garantieren könne«, dass EU-Daten nicht an US-Behörden übermittelt werden. Diese Aussage ist juristisch brisant – sie widerspricht dem Vertrauen in vertragliche Zusicherungen und relativiert zentrale Elemente der »Data Boundary«. Doch im Schreiben des EDPS fehlt jeder Hinweis darauf. Die strukturelle Zugriffsmacht der USA bleibt vollständig ausgeblendet.
Das Problem liegt tiefer
Die eigentliche Tragik liegt darin, dass politische Entscheidungsträger – und Teile der Datenschutz-Community – die Illusion von Souveränität bewusst mittragen. Statt auf europäische Open-Source-Lösungen zu setzen oder zumindest auf vollständige Kontrolle über Infrastruktur zu bestehen, wird der Einsatz US-amerikanischer Cloudlösungen als alternativlos akzeptiert.
Dass weder europäische Server noch eigene Schlüssel vor US-Zugriffen schützen, wurde längst ausführlich analysiert – etwa hier. Das eigentlich Erschreckende: Diese Risiken sind nicht nur bekannt, sondern werden inzwischen politisch offenbar bewusst verdrängt.
Mike Kuketz
1. August 2025
Kommentar zur »EU Data Boundary«: Die Illusion europäischer Souveränität bei der EU-Kommission
EU Data BoundaryDarf die Europäische Kommission intern mit Microsoft 365 arbeiten, obwohl dabei personenbezogene Daten in die USA fließen? Darum ging es in einem Verfahren durch den EU-Datenschutzbeauftragten. Der hat das Verfahren jetzt offiziell eingestellt. Die Begründung: Vertragsänderungen, vertraglich festgelegte Einschränkungen bei Datenübermittlungen – und die Einführung der sogenannten »EU Data Boundary«. Diese soll laut Wiewiórowski die Übermittlung personenbezogener Daten aus dem EWR »auf ein Minimum« reduzieren.
Soweit die Darstellung im offiziellen Schreiben des EU-Datenschutzbeauftragten. Aus unserer Sicht ist damit nichts gewonnen: Das Verfahren ist eingestellt, nichts muss sich ändern und die Details bleiben weiter unklar. Die Einschätzung folgt weitgehend den Angaben der Kommission, ohne erkennbare technische Gegenprüfung oder kritische Auseinandersetzung mit strukturellen Risiken. So entsteht der Eindruck, als sei das Datenschutzproblem rund um Microsoft 365 gelöst.
Im Kern bleibt vor allem unklar, wie belastbar die »EU Data Boundary« in der Praxis wirklich ist: Es fehlen technische Nachweise, unabhängige Kontrollen und rechtliche Garantien. Alles basiert auf Annahmen und Vertrauen – in ein US-Unternehmen, das Daten nach nationalem Recht auch außerhalb der EU offenlegen muss.
Politisch gewollt, technisch unüberprüft
Die Entscheidung wirkt wie der Versuch, ein strukturelles Problem durch vertragliche Kosmetik zu lösen. Es gibt keine unabhängige technische Analyse darüber, was Microsoft tatsächlich an Daten verarbeitet, übermittelt oder speichert. Die »Data Boundary« bleibt ein Konzept – kein überprüfbarer Schutzmechanismus. Kein Open Audit. Keine vollständige Dokumentation. Kein Einblick in die Backend-Telemetrie. Aber viel Vertrauen – in einen Anbieter, der nach US-Recht operiert.
Wer sich mit den rechtlichen Grundlagen und den Zugriffsmöglichkeiten US-Behörden beschäftigt, weiß: Daten, die unter der Kontrolle eines US-Unternehmens stehen, können abgerufen werden – auch wenn sie in Frankfurt oder Amsterdam liegen. Das wurde nicht nur mehrfach juristisch bestätigt, sondern auch politisch in Form des CLOUD Act verankert.
Kein Wort zu den Zugriffsmöglichkeiten der US-Behörden
Besonders irritierend ist, dass im offiziellen Schreiben des EU-Datenschutzbeauftragten zentrale Tatsachen völlig unberücksichtigt bleiben. Nur wenige Tage vor dem Schreiben erklärte ein ranghoher Microsoft-Justiziar unter Eid vor dem französischen Parlament, dass man »nicht garantieren könne«, dass EU-Daten nicht an US-Behörden übermittelt werden. Diese Aussage ist juristisch brisant – sie widerspricht dem Vertrauen in vertragliche Zusicherungen und relativiert zentrale Elemente der »Data Boundary«. Doch im Schreiben des EDPS fehlt jeder Hinweis darauf. Die strukturelle Zugriffsmacht der USA bleibt vollständig ausgeblendet.
Das Problem liegt tiefer
Die eigentliche Tragik liegt darin, dass politische Entscheidungsträger – und Teile der Datenschutz-Community – die Illusion von Souveränität bewusst mittragen. Statt auf europäische Open-Source-Lösungen zu setzen oder zumindest auf vollständige Kontrolle über Infrastruktur zu bestehen, wird der Einsatz US-amerikanischer Cloudlösungen als alternativlos akzeptiert.
Dass weder europäische Server noch eigene Schlüssel vor US-Zugriffen schützen, wurde längst ausführlich analysiert – etwa hier. Das eigentlich Erschreckende: Diese Risiken sind nicht nur bekannt, sondern werden inzwischen politisch offenbar bewusst verdrängt.
www.kuketz-blog.de
Kommentar zur »EU Data Boundary«: Die Illusion europäischer Souveränität bei der EU-Kommission
EU erlaubt Microsoft 365 trotz US-Datenzugriff – EDPS stellt Verfahren ein. Kritik: »Data Boundary« ohne echte Kontrolle oder rechtliche Sicherheit.
https://www.kuketz-blog.de/die-vergessene-vorratsdatenspeicherung-hintergrundbeitrag/
lacrosse
14. September 2025
Die vergessene Vorratsdatenspeicherung – Hintergrundbeitrag
1. EinleitungVorratsdatenspeicherung
Wenn in der Öffentlichkeit oder in Medien von »Vorratsdatenspeicherung« geredet wird, ist fast immer die Speicherung von Telekommunikationsdaten gemeint. Weitgehend unbemerkt von der Öffentlichkeit gibt es aber bereits eine andere Vorratsdatenspeicherung: Finanztransaktionsdaten werden über mehrere Jahre auf Vorrat gespeichert – vorgeschrieben im Geldwäschegesetz (GwG) zur Prävention von Geldwäsche und Terrorismusfinanzierung. Nach § 8 GwG sind »Verpflichtete« wie Finanzinstitute, Steuerberater etc. verpflichtet, Aufzeichnungen z.B. über Finanztransaktionen aufzubewahren.
In diesem Artikel erklären wir das System dahinter und ein zentrales Problem: Es erhebt systematisch viel öfter Daten als notwendig und trifft deswegen auch unschuldige Büger und Bürgerinnen.
Das Prinzip bei der Speicherung von Finanztransaktionsdaten ist im Prinzip genauso wie bei den Telekommunikationsdaten: Es wird nicht gespeichert, wer mit wem kommuniziert, sondern wer wem Geld überweist. Der entscheidende Unterschied besteht darin, dass die Telekommunikations-
unternehmen bei der »allseits bekannten« Vorratsdatenspeicherung verpflichtet wären, die Daten zu speichern und auf Ersuchen von Strafverfolgungsbehörden herauszugeben. Das GwG lagert diese »Ermittlungen« hingegen an Private aus. Die Verpflichteten müssen von sich aus nach bestimmten Kriterien Verdachtsmeldungen an die Financial Intelligence Unit (FIU) des deutschen Zolls erstatten. Durch diese gesetzliche Konstruktion entsteht eine Verkettung aufeinanderfolgender Daten-
speicherungen. Die FIU wertet die Verdachtsmeldungen aus und leitet ihre Erkenntnisse gegebenenfalls an die verschiedenen Strafverfolgungsbehörden oder Nachrichtendienste weiter.
lacrosse
14. September 2025
Die vergessene Vorratsdatenspeicherung – Hintergrundbeitrag
1. EinleitungVorratsdatenspeicherung
Wenn in der Öffentlichkeit oder in Medien von »Vorratsdatenspeicherung« geredet wird, ist fast immer die Speicherung von Telekommunikationsdaten gemeint. Weitgehend unbemerkt von der Öffentlichkeit gibt es aber bereits eine andere Vorratsdatenspeicherung: Finanztransaktionsdaten werden über mehrere Jahre auf Vorrat gespeichert – vorgeschrieben im Geldwäschegesetz (GwG) zur Prävention von Geldwäsche und Terrorismusfinanzierung. Nach § 8 GwG sind »Verpflichtete« wie Finanzinstitute, Steuerberater etc. verpflichtet, Aufzeichnungen z.B. über Finanztransaktionen aufzubewahren.
In diesem Artikel erklären wir das System dahinter und ein zentrales Problem: Es erhebt systematisch viel öfter Daten als notwendig und trifft deswegen auch unschuldige Büger und Bürgerinnen.
Das Prinzip bei der Speicherung von Finanztransaktionsdaten ist im Prinzip genauso wie bei den Telekommunikationsdaten: Es wird nicht gespeichert, wer mit wem kommuniziert, sondern wer wem Geld überweist. Der entscheidende Unterschied besteht darin, dass die Telekommunikations-
unternehmen bei der »allseits bekannten« Vorratsdatenspeicherung verpflichtet wären, die Daten zu speichern und auf Ersuchen von Strafverfolgungsbehörden herauszugeben. Das GwG lagert diese »Ermittlungen« hingegen an Private aus. Die Verpflichteten müssen von sich aus nach bestimmten Kriterien Verdachtsmeldungen an die Financial Intelligence Unit (FIU) des deutschen Zolls erstatten. Durch diese gesetzliche Konstruktion entsteht eine Verkettung aufeinanderfolgender Daten-
speicherungen. Die FIU wertet die Verdachtsmeldungen aus und leitet ihre Erkenntnisse gegebenenfalls an die verschiedenen Strafverfolgungsbehörden oder Nachrichtendienste weiter.
www.kuketz-blog.de
Die vergessene Vorratsdatenspeicherung – Hintergrundbeitrag
Deutschland praktiziert seit Jahren eine Vorratsdatenspeicherung. Unbeachtet von der Öffentlichkeit werden Finanztransaktionsdaten auf Vorrat gespeichert.
https://www.kuketz-blog.de/android-entwickler-verifizierung-weniger-offenheit-mehr-kontrolle/
Mike Kuketz
19. September 2025
Android: Entwickler-Verifizierung – weniger Offenheit, mehr Kontrolle
1. Entwickler-VerifizierungAndroid-Entwickler-Verifikation
Google führt eine Entwickler-Verifizierung für Android ein. Ab 2026 sollen auf zertifizierten Android-Geräten nur noch Apps installiert werden, die einem verifizierten Entwicklerkonto zugeordnet sind – gleichgültig, ob die App aus dem Play Store kommt, aus einem Dritt-Store stammt oder als APK direkt installiert wird. Die Durchsetzung startet in ausgewählten Ländern (Brasilien, Indonesien, Singapur und Thailand) und wird anschließend ausgeweitet. Installationen über ADB sind weiterhin möglich und nicht an die Verifizierung gebunden. Für normale Nutzer ist das jedoch keine alltagstaugliche Option.
Im Folgenden beleuchten wir, was diese Änderung konkret bedeutet – sowohl für Entwickler, die ihre Apps künftig nur noch mit Verifizierung auf zertifizierten Geräten anbieten können, als auch für Nutzer, deren Spielraum bei der Installation freier Apps eingeschränkt wird.
2. Was ändert sich konkret?
Google verlangt künftig, dass Entwickler ihre Identität nachweisen und ihre Apps (Paketnamen und ggf. Signierschlüssel) einem verifizierten Konto zuordnen. Dafür gibt es zwei Wege: Wer bereits die Play Console nutzt, kann darüber auch Apps registrieren, die außerhalb des Play Store verteilt werden. Für Entwickler, die nur jenseits des Play Store veröffentlichen, richtet Google eine eigene Android Developer Console (ADC) ein (Early Access ab Okt. 2025, allgemein ab März 2026).
Abgefragt werden unter anderem Name, Anschrift, E-Mail und Telefonnummer. Bei Organisationen zusätzlich eine Website sowie eine D-U-N-S-Nummer – eine neunstellige Kennziffer, die von der Firma Dun & Bradstreet vergeben wird und weltweit als eindeutige Identifikation von Unternehmen dient (auch Apple verlangt sie für Entwicklerkonten von Organisationen). Diese Pflicht betrifft nicht nur US-Firmen, sondern ebenso Entwickler aus Deutschland oder anderen europäischen Ländern, etwa GmbHs, UGs oder eingetragene Vereine. Teils ist auch ein amtlicher Ausweis erforderlich. Laut Google werden diese Daten nicht gegenüber Nutzern angezeigt. Für Hobby- und Studierenden-Entwickler soll es ein vereinfachtes Konto ohne Registrierungsgebühr geben.
Google begründet die Pflicht mit mehr Sicherheit und Nachverfolgbarkeit. In der Praxis entsteht damit jedoch eine zusätzliche Hürde – insbesondere für kleine, nebenberufliche oder anonyme FOSS-Projekte. Wer nicht verifiziert ist, scheitert künftig auf zertifizierten Geräten an einer Systemblockade: Android prüft beim Installieren ob die App von einem verifizierten Entwicklerkonto stammt und mit dem passenden Schlüssel signiert wurde. Fehlt die Verifizierung, blockiert das System – egal ob die App über F-Droid, einen anderen Store oder direkt von der Projektseite kommt.
Nach aktuellem Stand gilt die Pflicht nur für zertifizierte Android-Geräte – also solche mit Play Protect und vorinstallierten Google-Apps. Custom-ROMs wie GrapheneOS sind nicht zertifiziert und damit formal nicht betroffen. Für die große Mehrheit der Nutzer ändert das jedoch nichts: Sie verwenden zertifizierte Geräte – und genau dort wird die Installation freier Apps künftig erschwert.
3. Und was ist mit F-Droid und anderen App-Stores?
F-Droid baut die meisten Apps selbst aus dem Quellcode und signiert sie mit dem eigenen Reposchlüssel. Daneben gibt es den Mechanismus der reproduzierbaren Builds: Dabei erstellt F-Droid ein APK aus dem Quellcode und vergleicht es mit der vom Entwickler veröffentlichten Version. Sind beide Dateien bytegenau identisch – abgesehen von der Signatur –, kann F-Droid statt eines eigenen Builds auch das Original-APK mit der Signatur des Entwicklers ausliefern. Das Verfahren ist aufwendig und gelingt noch nicht bei jeder App, wird aber zunehmend genutzt, um mehr Transparenz und Vertrauen in die Builds zu schaffen.
Mike Kuketz
19. September 2025
Android: Entwickler-Verifizierung – weniger Offenheit, mehr Kontrolle
1. Entwickler-VerifizierungAndroid-Entwickler-Verifikation
Google führt eine Entwickler-Verifizierung für Android ein. Ab 2026 sollen auf zertifizierten Android-Geräten nur noch Apps installiert werden, die einem verifizierten Entwicklerkonto zugeordnet sind – gleichgültig, ob die App aus dem Play Store kommt, aus einem Dritt-Store stammt oder als APK direkt installiert wird. Die Durchsetzung startet in ausgewählten Ländern (Brasilien, Indonesien, Singapur und Thailand) und wird anschließend ausgeweitet. Installationen über ADB sind weiterhin möglich und nicht an die Verifizierung gebunden. Für normale Nutzer ist das jedoch keine alltagstaugliche Option.
Im Folgenden beleuchten wir, was diese Änderung konkret bedeutet – sowohl für Entwickler, die ihre Apps künftig nur noch mit Verifizierung auf zertifizierten Geräten anbieten können, als auch für Nutzer, deren Spielraum bei der Installation freier Apps eingeschränkt wird.
2. Was ändert sich konkret?
Google verlangt künftig, dass Entwickler ihre Identität nachweisen und ihre Apps (Paketnamen und ggf. Signierschlüssel) einem verifizierten Konto zuordnen. Dafür gibt es zwei Wege: Wer bereits die Play Console nutzt, kann darüber auch Apps registrieren, die außerhalb des Play Store verteilt werden. Für Entwickler, die nur jenseits des Play Store veröffentlichen, richtet Google eine eigene Android Developer Console (ADC) ein (Early Access ab Okt. 2025, allgemein ab März 2026).
Abgefragt werden unter anderem Name, Anschrift, E-Mail und Telefonnummer. Bei Organisationen zusätzlich eine Website sowie eine D-U-N-S-Nummer – eine neunstellige Kennziffer, die von der Firma Dun & Bradstreet vergeben wird und weltweit als eindeutige Identifikation von Unternehmen dient (auch Apple verlangt sie für Entwicklerkonten von Organisationen). Diese Pflicht betrifft nicht nur US-Firmen, sondern ebenso Entwickler aus Deutschland oder anderen europäischen Ländern, etwa GmbHs, UGs oder eingetragene Vereine. Teils ist auch ein amtlicher Ausweis erforderlich. Laut Google werden diese Daten nicht gegenüber Nutzern angezeigt. Für Hobby- und Studierenden-Entwickler soll es ein vereinfachtes Konto ohne Registrierungsgebühr geben.
Google begründet die Pflicht mit mehr Sicherheit und Nachverfolgbarkeit. In der Praxis entsteht damit jedoch eine zusätzliche Hürde – insbesondere für kleine, nebenberufliche oder anonyme FOSS-Projekte. Wer nicht verifiziert ist, scheitert künftig auf zertifizierten Geräten an einer Systemblockade: Android prüft beim Installieren ob die App von einem verifizierten Entwicklerkonto stammt und mit dem passenden Schlüssel signiert wurde. Fehlt die Verifizierung, blockiert das System – egal ob die App über F-Droid, einen anderen Store oder direkt von der Projektseite kommt.
Nach aktuellem Stand gilt die Pflicht nur für zertifizierte Android-Geräte – also solche mit Play Protect und vorinstallierten Google-Apps. Custom-ROMs wie GrapheneOS sind nicht zertifiziert und damit formal nicht betroffen. Für die große Mehrheit der Nutzer ändert das jedoch nichts: Sie verwenden zertifizierte Geräte – und genau dort wird die Installation freier Apps künftig erschwert.
3. Und was ist mit F-Droid und anderen App-Stores?
F-Droid baut die meisten Apps selbst aus dem Quellcode und signiert sie mit dem eigenen Reposchlüssel. Daneben gibt es den Mechanismus der reproduzierbaren Builds: Dabei erstellt F-Droid ein APK aus dem Quellcode und vergleicht es mit der vom Entwickler veröffentlichten Version. Sind beide Dateien bytegenau identisch – abgesehen von der Signatur –, kann F-Droid statt eines eigenen Builds auch das Original-APK mit der Signatur des Entwicklers ausliefern. Das Verfahren ist aufwendig und gelingt noch nicht bei jeder App, wird aber zunehmend genutzt, um mehr Transparenz und Vertrauen in die Builds zu schaffen.
www.kuketz-blog.de
Android: Entwickler-Verifizierung – weniger Offenheit, mehr Kontrolle
Google führt 2026 die Entwickler-Verifizierung ein. Nur Apps verifizierter Konten laufen auf zertifizierten Geräten. Was das für F-Droid und Co. bedeutet.
Mit der Entwickler-Verifizierung rückt auf zertifizierten Geräten künftig jedoch vor allem eine Frage in den Vordergrund: Wer signiert – und ist dieser Signierer bei Google verifiziert? Daraus ergeben sich aus meiner Sicht zwei Szenarien:
Wenn der ursprüngliche Entwickler signiert und verifiziert ist: Der Entwickler veröffentlicht das APK mit seinem eigenen Schlüssel und hat sein Konto bei Google verifiziert. F-Droid kann dieses Original-APK ausliefern. Auf zertifizierten Geräten lässt sich die App installieren, weil die Signatur einem verifizierten Konto zugeordnet ist.
Wenn F-Droid selbst signiert: F-Droid baut die App und versieht sie mit dem eigenen Schlüssel. Damit diese APKs künftig auf zertifizierten Geräten akzeptiert werden, müsste sich F-Droid als Organisation bei Google verifizieren und die Paketnamen registrieren. Ohne diese Verifizierung blockiert das System die Installation. Das würde zusätzlichen organisatorischen Aufwand, mehr Verantwortung und Haftungsfragen nach sich ziehen – aktuell erscheint dieses Modell wenig realistisch.
Ein offizielles Statement von F-Droid zu Googles Plänen gibt es bislang nicht. In der Community wird das Thema diskutiert, doch konkrete Zusagen – etwa ob sich F-Droid selbst verifizieren will oder ob Prozesse angepasst werden – liegen bisher nicht vor.
F-Droid und andere App-Stores können ihre Repositories zwar weiterhin betreiben. Ob eine App auf zertifizierten Geräten installiert werden darf, hängt künftig jedoch nicht mehr vom Store ab, sondern allein davon, wer sie signiert hat – und ob dieser Signierer bei Google verifiziert ist. Das kann entweder der ursprüngliche Entwickler sein oder, falls F-Droid selbst signiert, F-Droid als Organisation. Auf nicht zertifizierten ROMs wie GrapheneOS greift diese Schranke nicht.
4. Custom-ROMs: Was gilt?
Die neue Pflicht greift nur auf zertifizierten Android-Geräten mit Play Protect und vorinstallierten Google-Apps. Custom-ROMs sind in der Regel nicht zertifiziert – damit fällt die Sperre dort formal nicht an. Das betrifft bspw. GrapheneOS, LineageOS, CalyxOS, oder /e/OS. Auch wenn man nachträglich GApps oder microG installiert, wird das ROM dadurch nicht plötzlich Play-Protect-zertifiziert. Apps aus F-Droid lassen sich weiter wie gewohnt installieren.
Wichtig ist die Einordnung: Auch wenn Custom-ROM-Nutzer vorerst unbeeinträchtigt sind, verschiebt sich das Gleichgewicht im gesamten Ökosystem. Die große Mehrheit nutzt zertifizierte Geräte – dort entscheidet künftig die Verifizierung des Signierers. Das kann dazu führen, dass sich Entwicklerressourcen stärker auf verifizierte Kanäle konzentrieren. Für Custom-ROM-Nutzer ändert sich kurzfristig wenig – langfristig hängt vieles davon ab, wie sich F-Droid, Projekte und Maintainer auf die neuen Rahmenbedingungen einstellen.
5. Sicherheit oder Kontrolle?
Google verkauft die neue Pflicht als »Sicherheitsmaßnahme«. Tatsächlich ändert sich an der technischen Prüfung nichts – Play Protect scannt schon heute alle Apps, egal woher sie kommen. Neu ist allein, dass ein Entwicklerkonto mit einer überprüften Identität verknüpft sein muss.
Damit entscheidet künftig nicht mehr die Qualität des Codes darüber, ob eine App installiert werden kann, sondern allein die Verifizierung des Entwicklers durch Google. Fehlt sie, blockiert das System die Installation – selbst wenn die App frei, quelloffen und technisch einwandfrei ist.
Das schafft Risiken: Ein gesperrtes Konto oder ein fehlerhaft zugeordneter Paketname kann ausreichen, um Updates zu verhindern. Anonyme oder kleine FOSS-Projekte, die keine Organisation gründen oder ihre Identität nicht preisgeben wollen, stoßen auf eine fast unüberwindbare Barriere. Die offene Verteilung wird damit faktisch eingeschränkt.
Kurz gesagt: Das Sicherheitsargument wirkt vorgeschoben. In Wirklichkeit vergrößert Google seinen Kontrollhebel und verschiebt die Norm – App-Installationen außerhalb des Play Store werden nicht mehr als regulär behandelt, sondern als Ausnahme unter Vorbehalt.
Wenn der ursprüngliche Entwickler signiert und verifiziert ist: Der Entwickler veröffentlicht das APK mit seinem eigenen Schlüssel und hat sein Konto bei Google verifiziert. F-Droid kann dieses Original-APK ausliefern. Auf zertifizierten Geräten lässt sich die App installieren, weil die Signatur einem verifizierten Konto zugeordnet ist.
Wenn F-Droid selbst signiert: F-Droid baut die App und versieht sie mit dem eigenen Schlüssel. Damit diese APKs künftig auf zertifizierten Geräten akzeptiert werden, müsste sich F-Droid als Organisation bei Google verifizieren und die Paketnamen registrieren. Ohne diese Verifizierung blockiert das System die Installation. Das würde zusätzlichen organisatorischen Aufwand, mehr Verantwortung und Haftungsfragen nach sich ziehen – aktuell erscheint dieses Modell wenig realistisch.
Ein offizielles Statement von F-Droid zu Googles Plänen gibt es bislang nicht. In der Community wird das Thema diskutiert, doch konkrete Zusagen – etwa ob sich F-Droid selbst verifizieren will oder ob Prozesse angepasst werden – liegen bisher nicht vor.
F-Droid und andere App-Stores können ihre Repositories zwar weiterhin betreiben. Ob eine App auf zertifizierten Geräten installiert werden darf, hängt künftig jedoch nicht mehr vom Store ab, sondern allein davon, wer sie signiert hat – und ob dieser Signierer bei Google verifiziert ist. Das kann entweder der ursprüngliche Entwickler sein oder, falls F-Droid selbst signiert, F-Droid als Organisation. Auf nicht zertifizierten ROMs wie GrapheneOS greift diese Schranke nicht.
4. Custom-ROMs: Was gilt?
Die neue Pflicht greift nur auf zertifizierten Android-Geräten mit Play Protect und vorinstallierten Google-Apps. Custom-ROMs sind in der Regel nicht zertifiziert – damit fällt die Sperre dort formal nicht an. Das betrifft bspw. GrapheneOS, LineageOS, CalyxOS, oder /e/OS. Auch wenn man nachträglich GApps oder microG installiert, wird das ROM dadurch nicht plötzlich Play-Protect-zertifiziert. Apps aus F-Droid lassen sich weiter wie gewohnt installieren.
Wichtig ist die Einordnung: Auch wenn Custom-ROM-Nutzer vorerst unbeeinträchtigt sind, verschiebt sich das Gleichgewicht im gesamten Ökosystem. Die große Mehrheit nutzt zertifizierte Geräte – dort entscheidet künftig die Verifizierung des Signierers. Das kann dazu führen, dass sich Entwicklerressourcen stärker auf verifizierte Kanäle konzentrieren. Für Custom-ROM-Nutzer ändert sich kurzfristig wenig – langfristig hängt vieles davon ab, wie sich F-Droid, Projekte und Maintainer auf die neuen Rahmenbedingungen einstellen.
5. Sicherheit oder Kontrolle?
Google verkauft die neue Pflicht als »Sicherheitsmaßnahme«. Tatsächlich ändert sich an der technischen Prüfung nichts – Play Protect scannt schon heute alle Apps, egal woher sie kommen. Neu ist allein, dass ein Entwicklerkonto mit einer überprüften Identität verknüpft sein muss.
Damit entscheidet künftig nicht mehr die Qualität des Codes darüber, ob eine App installiert werden kann, sondern allein die Verifizierung des Entwicklers durch Google. Fehlt sie, blockiert das System die Installation – selbst wenn die App frei, quelloffen und technisch einwandfrei ist.
Das schafft Risiken: Ein gesperrtes Konto oder ein fehlerhaft zugeordneter Paketname kann ausreichen, um Updates zu verhindern. Anonyme oder kleine FOSS-Projekte, die keine Organisation gründen oder ihre Identität nicht preisgeben wollen, stoßen auf eine fast unüberwindbare Barriere. Die offene Verteilung wird damit faktisch eingeschränkt.
Kurz gesagt: Das Sicherheitsargument wirkt vorgeschoben. In Wirklichkeit vergrößert Google seinen Kontrollhebel und verschiebt die Norm – App-Installationen außerhalb des Play Store werden nicht mehr als regulär behandelt, sondern als Ausnahme unter Vorbehalt.
6. Was lässt sich jetzt tun?
Kurzfristig geht es vor allem darum, Apps aus möglichst nachvollziehbaren Quellen zu installieren – etwa direkt von der offiziellen Projektseite oder aus dem F-Droid-Hauptrepo. Wer bisher schon vorsichtig war und keine APKs aus dubiosen Download-Portalen nutzt, muss seine Gewohnheiten nicht grundlegend ändern. Wichtig ist lediglich, im Blick zu behalten, ob eine App plötzlich nicht mehr aktualisiert werden kann. Tritt dieser Fall ein, könnte die fehlende Entwickler-Verifizierung der Grund sein. Dann lohnt es sich, nach Hinweisen im Projekt oder bei F-Droid zu schauen, wie es weitergeht.
Mittelfristig braucht es stärkere Unterstützung für Projekte wie F-Droid. Das kann durch Spenden geschehen, durch Mithilfe bei Übersetzungen oder durch Beteiligung an Diskussionen in den Foren. Auch Entwickler profitieren, wenn ihnen Vorlagen und Werkzeuge zur Verfügung stehen, die den Veröffentlichungsprozess vereinfachen und reproduzierbare Builds erleichtern. Ebenso wichtig ist eine bessere Aufklärung für Nutzer: Schritt-für-Schritt-Anleitungen, die in verständlicher Sprache erklären, wie freie Apps auf zertifizierten Geräten installiert werden können und welche Einschränkungen zu erwarten sind, helfen mehr als technische Detailhinweise.
Langfristig wird entscheidend sein, Abhängigkeiten von Google zu verringern. Für manche bedeutet das den Umstieg auf Android-Varianten ohne Google-Zertifizierung wie bspw. GrapheneOS. Darüber hinaus braucht es politische Leitplanken: Wenn Google Verifizierungszwang mit dem (Schein-)Argument Sicherheit einführt, müssen Kriterien, Widerspruchswege und Transparenz rechtlich abgesichert werden. Nur so lässt sich verhindern, dass die Maßnahme als Vorwand genutzt wird, um unliebsame Software auszusperren. Stärken sollte man außerdem Projekte, die reproduzierbare Builds anbieten, da sie Vertrauen schaffen – unabhängig davon, ob Google sie akzeptiert oder nicht.
Kurzfristig geht es vor allem darum, Apps aus möglichst nachvollziehbaren Quellen zu installieren – etwa direkt von der offiziellen Projektseite oder aus dem F-Droid-Hauptrepo. Wer bisher schon vorsichtig war und keine APKs aus dubiosen Download-Portalen nutzt, muss seine Gewohnheiten nicht grundlegend ändern. Wichtig ist lediglich, im Blick zu behalten, ob eine App plötzlich nicht mehr aktualisiert werden kann. Tritt dieser Fall ein, könnte die fehlende Entwickler-Verifizierung der Grund sein. Dann lohnt es sich, nach Hinweisen im Projekt oder bei F-Droid zu schauen, wie es weitergeht.
Mittelfristig braucht es stärkere Unterstützung für Projekte wie F-Droid. Das kann durch Spenden geschehen, durch Mithilfe bei Übersetzungen oder durch Beteiligung an Diskussionen in den Foren. Auch Entwickler profitieren, wenn ihnen Vorlagen und Werkzeuge zur Verfügung stehen, die den Veröffentlichungsprozess vereinfachen und reproduzierbare Builds erleichtern. Ebenso wichtig ist eine bessere Aufklärung für Nutzer: Schritt-für-Schritt-Anleitungen, die in verständlicher Sprache erklären, wie freie Apps auf zertifizierten Geräten installiert werden können und welche Einschränkungen zu erwarten sind, helfen mehr als technische Detailhinweise.
Langfristig wird entscheidend sein, Abhängigkeiten von Google zu verringern. Für manche bedeutet das den Umstieg auf Android-Varianten ohne Google-Zertifizierung wie bspw. GrapheneOS. Darüber hinaus braucht es politische Leitplanken: Wenn Google Verifizierungszwang mit dem (Schein-)Argument Sicherheit einführt, müssen Kriterien, Widerspruchswege und Transparenz rechtlich abgesichert werden. Nur so lässt sich verhindern, dass die Maßnahme als Vorwand genutzt wird, um unliebsame Software auszusperren. Stärken sollte man außerdem Projekte, die reproduzierbare Builds anbieten, da sie Vertrauen schaffen – unabhängig davon, ob Google sie akzeptiert oder nicht.
Forwarded from Wild Kernels Bot
Wild_KSU_v0.0.150_13955-release.apk
17.4 MB
🔧 CI Manager (TEST BUILD) #ci_3755
📝 ci: add pull request conditions to workflow steps and handle skipped generate-version
🔗 Commit: https://github.com/WildKernels/Wild_KSU/commit/b347e9e6ad90b28cd06732e8b8e8ca0757e7ec35
🏃 Workflow: https://github.com/WildKernels/Wild_KSU/actions/runs/18159100396
📝 ci: add pull request conditions to workflow steps and handle skipped generate-version
🔗 Commit: https://github.com/WildKernels/Wild_KSU/commit/b347e9e6ad90b28cd06732e8b8e8ca0757e7ec35
🏃 Workflow: https://github.com/WildKernels/Wild_KSU/actions/runs/18159100396
Wild_KSU_v0.0.150-spoofed_13955-release.apk
17.4 MB
🔧 Spoofed Manager (TEST BUILD) #spoofed_3755
📝 ci: add pull request conditions to workflow steps and handle skipped generate-version
🔗 Commit: https://github.com/WildKernels/Wild_KSU/commit/b347e9e6ad90b28cd06732e8b8e8ca0757e7ec35
🏃 Workflow: https://github.com/WildKernels/Wild_KSU/actions/runs/18159100396
📝 ci: add pull request conditions to workflow steps and handle skipped generate-version
🔗 Commit: https://github.com/WildKernels/Wild_KSU/commit/b347e9e6ad90b28cd06732e8b8e8ca0757e7ec35
🏃 Workflow: https://github.com/WildKernels/Wild_KSU/actions/runs/18159100396
Forwarded from KernelSU Next Bot
KernelSU_Next_v1.1.1-23-g300a13f6_12874-release.apk
16.9 MB
CI Manager (TEST BUILD)
#ci_2674
Commit
Workflow run
#ci_2674
kernel: handle throned UID change if manager is reinstall or changed
drop old UID and throne the new one when the manager is reinstalled or changed
Commit
Workflow run
KernelSU_Next_v1.1.1-23-g300a13f6-spoofed_12874-release.apk
16.9 MB
CI Manager (SPOOFED BUILD)
#ci_2674
Commit
Workflow run
#ci_2674
kernel: handle throned UID change if manager is reinstall or changed
drop old UID and throne the new one when the manager is reinstalled or changed
Commit
Workflow run
Forwarded from Nagram X CI
NagramX-v12.0.1-25f9110(1219)-arm64-v8a.apk
48.4 MB
Test version.
Commit Message:
See commit details 25f9110
Commit Message:
feat: add retry for voice transcription and better inline translation
See commit details 25f9110
https://github.com/mikropsoft/StevenBlock
🚫 Advanced Ad-Blocking Module for Android | Compatible with Magisk, KernelSU, and APatch 🔒
🚫 Advanced Ad-Blocking Module for Android | Compatible with Magisk, KernelSU, and APatch 🔒
GitHub
GitHub - mikropsoft/StevenBlock: 🚫 Advanced Ad-Blocking Module for Android | Compatible with Magisk, KernelSU, and APatch 🔒
🚫 Advanced Ad-Blocking Module for Android | Compatible with Magisk, KernelSU, and APatch 🔒 - mikropsoft/StevenBlock
No deleted account found from
87 scanned users from this group 🚫👻Forwarded from Wild Kernels Bot
Wild_KSU_v0.0.159_13964-release.apk
17.4 MB
🔧 CI Manager (TEST BUILD) #ci_3764
📝 Exclude settings SharedPreferences from Android auto backup
🔗 Commit: https://github.com/WildKernels/Wild_KSU/commit/b63528331cba441d1da4f4117eb74da628a5f9b6
🏃 Workflow: https://github.com/WildKernels/Wild_KSU/actions/runs/18190275429
📝 Exclude settings SharedPreferences from Android auto backup
🔗 Commit: https://github.com/WildKernels/Wild_KSU/commit/b63528331cba441d1da4f4117eb74da628a5f9b6
🏃 Workflow: https://github.com/WildKernels/Wild_KSU/actions/runs/18190275429
Wild_KSU_v0.0.159-spoofed_13964-release.apk
17.4 MB
🔧 Spoofed Manager (TEST BUILD) #spoofed_3764
📝 Exclude settings SharedPreferences from Android auto backup
🔗 Commit: https://github.com/WildKernels/Wild_KSU/commit/b63528331cba441d1da4f4117eb74da628a5f9b6
🏃 Workflow: https://github.com/WildKernels/Wild_KSU/actions/runs/18190275429
📝 Exclude settings SharedPreferences from Android auto backup
🔗 Commit: https://github.com/WildKernels/Wild_KSU/commit/b63528331cba441d1da4f4117eb74da628a5f9b6
🏃 Workflow: https://github.com/WildKernels/Wild_KSU/actions/runs/18190275429
Forwarded from Morgan Weedman, Wild Kernels Owner (DMs OPEN)
Hey there!
GKI Users:
Anyone of you waiting for 1.5.10 WKSU GKI, sorry for the wait, susfs added new commits that are being tested, not all branches are in sync yet. There may be problems with these commits making hiding worse, so im going to wait for fixes.
When we build we use the latest susfs commits, not the 1.5.9 tag... so in reality you are using 1.5.10 beta.
Most of the time when Simon (Susfs Dev) updates version for example 1.5.9 -> 1.5.10 all he updates is the number 9 -> 10, all of the 1.5.10 commits are already done before the tags.
If you are on my latest kernel, you are updated to the best hiding you can get so just wait!
if this doesnt make sense im sorry, tag me and i can maybe explain better!
Thanks everyone!
If you like my work and would like to support me!
Donations:
https://t.me/WildKernels/90170/90171
GKI Users:
Anyone of you waiting for 1.5.10 WKSU GKI, sorry for the wait, susfs added new commits that are being tested, not all branches are in sync yet. There may be problems with these commits making hiding worse, so im going to wait for fixes.
When we build we use the latest susfs commits, not the 1.5.9 tag... so in reality you are using 1.5.10 beta.
Most of the time when Simon (Susfs Dev) updates version for example 1.5.9 -> 1.5.10 all he updates is the number 9 -> 10, all of the 1.5.10 commits are already done before the tags.
If you are on my latest kernel, you are updated to the best hiding you can get so just wait!
if this doesnt make sense im sorry, tag me and i can maybe explain better!
Thanks everyone!
If you like my work and would like to support me!
Donations:
https://t.me/WildKernels/90170/90171