Wie ein defekter Datenschutzlink das Release einer Lern-App aufhielt

Die Ablehnung deckte eine nicht erfasste Release-Abhängigkeit auf

Die Einreichung einer mobilen Lern-App wurde bei der Prüfung abgelehnt, weil die hinterlegte URL zur Datenschutzerklärung HTTP 404 zurückgab. Der gemeldete Fehler betraf eine öffentlich zugängliche Ressource, nicht die Ansichten für Lernende. Eine separat veröffentlichte Version war davon nicht betroffen.

Google Play unterscheidet zwischen Ablehnung und Entfernung und stellt klar: Wird ein Update abgelehnt, bleibt die zuvor veröffentlichte Version verfügbar. (support.google.com) Dieser Fall zeigt ein Problem bei der Veröffentlichung. Er ist kein Beleg für weitergehende Sicherheits- oder Datenschutzverstöße.

Zum Release gehört mehr als die App-Datei

Die Google Play-Programmrichtlinie für Entwickler, die sofern nicht anders angegeben ab dem 29. Oktober 2026 gilt, verlangt eine Datenschutzerklärung unter einer aktiven, öffentlich zugänglichen URL ohne geografische Zugriffsbeschränkung. Die Erklärung darf nicht bearbeitbar sein und nicht als PDF vorliegen. Außerdem muss ein Link in der Play Console hinterlegt sein. In der App selbst muss entweder ein Link zur Erklärung oder ihr Text enthalten sein. (support.google.com) Ein gültiger Build allein erfüllt diese Bedingungen nicht.

Bei den webbasierten und mobilen Akademien von App-Learning im eigenen Markendesign sollte die Prüfung vor dem Release Builds, gehostete Lektionen, Identitätsverwaltung, öffentliche Compliance-Seiten und Metadaten für die Veröffentlichung umfassen. So können Produktverantwortliche in einem Fintech einheitlich über die Freigabe entscheiden, statt sich auf getrennte Zusicherungen von Teams zu stützen, die unterschiedliche Teile testen.

Im Release-Manifest sollte jede externe URL mit der zugehörigen App, dem Store, der Sprach- und Länderversion, dem erwarteten Dokument und der zuständigen Person erfasst sein. So wird die Compliance für mobile LMS-Anwendungen zu einem eigenen Aufgabenbereich bei der Veröffentlichung – statt bei funktionierendem Code einfach vorausgesetzt zu werden.

Links zu Richtlinien brauchen auch inhaltliche Abnahmetests

Bei HTTP liefert eine HEAD-Anfrage keinen Antwortinhalt, während GET die Repräsentation der Ressource abruft. (rfc-editor.org) Der Abnahmetest sollte deshalb das Dokument selbst prüfen, nicht nur seine Header.

1. Rufe die exakt eingereichte URL per GET über HTTPS ab.
2. Folge Weiterleitungen nur bis zu einer festgelegten Grenze und verlange als abschließende Antwort HTTP 200.
3. Teste den Zugriff ohne Authentifizierung und ohne vorhandene Cookies aus mehreren Regionen.
4. Prüfe, ob das Ziel eine lesbare, nicht bearbeitbare Seite mit der Datenschutzerklärung ist.
5. Prüfe, ob die erwartete App oder das erwartete Unternehmen genannt wird und der freigegebene Richtlinientext vorliegt.

Freigabeprüfungen sollten produktive URLs testen

Auch eine HTTP-200-Antwort kann eine Fehlerseite enthalten. Google dokumentiert dieses Muster als Soft 404. (developers.google.com) Verfügbarkeitsprüfungen müssen deshalb neben dem Status auch den Inhalt prüfen, etwa die Überschrift der Datenschutzerklärung und den erwarteten Firmennamen.

Die vorgeschlagene Freigabeprüfung sollte vor der Einreichung die produktiven URLs prüfen und anschließend in festgelegten Intervallen laufen. Store-Metadaten und Links in der App müssen jeweils unabhängig mit dem Manifest abgeglichen werden. Bei Fehlern sollte die Einreichung blockiert und die zuständige Person benachrichtigt werden – mit Antwortstatus, Weiterleitungskette und nicht erfüllter Prüfbedingung. Die Automatisierung prüft die Auslieferung; eine benannte Person gibt die Datenschutzerklärung selbst inhaltlich frei.

Für Website-Änderungen braucht es eine benannte Person, die das Release verantwortet

Google Play verlangt außerdem, dass die Angaben zur Datensicherheit korrekt bleiben und mit den Informationen in der Datenschutzerklärung übereinstimmen. (support.google.com) Die Verantwortung muss deshalb sowohl die Erreichbarkeit der Seite als auch ihre Übereinstimmung mit der tatsächlichen Datenverarbeitung der App abdecken.

Bei einem Website-Umzug sollten alle erfassten Pfade zu Richtlinienseiten, Weiterleitungen sowie Sprach- und Länderversionen geprüft werden. Wer die Website betreut, verantwortet die Auslieferung, wer den Datenschutz prüft, die inhaltliche Freigabe. Die für das Release zuständige Person bestätigt die eingereichten Adressen. Bei einem Domainwechsel sollten bestehende Pfade nach Möglichkeit erhalten bleiben und alle Ersatz-URLs überprüft werden.

Mit einer Checkliste ist die Release-Prüfung komplett

Eine kompakte Checkliste für die Veröffentlichung mobiler Lern-Apps sollte fünf Entscheidungen festhalten.

• Das Manifest enthält alle produktiv genutzten URLs zu Richtlinien.
• Die Prüfungen von HTTP-Antworten, Weiterleitungen, Zugriff und Inhalt sind bestanden.
• Store-Felder und Linkziele in der App sind getrennt geprüft.
• Für die inhaltliche Prüfung der Richtlinien und Angaben ist eine Person verantwortlich.
• Für die laufende Überwachung und erneute Prüfungen bei Migrationen ist eine verantwortliche Person benannt.

Eine bei Google Play hinterlegte Datenschutz-URL mit 404-Fehler ist ein Fall für die Release-Diagnose, nicht nur für die Website-Wartung. Wird die URL zur Datenschutzerklärung abgelehnt, ist ein neuer Build nicht zwangsläufig die Lösung. Als Technologiepartner Verantwortung zu übernehmen heißt, den gesamten Weg bis zur Veröffentlichung zu testen – einschließlich der Abhängigkeiten außerhalb der Codebasis.