erberkk/datenschutz-und-erklaerungen

Datenschutz und Erklärungen

Zweck

Wahrheitsgemäße, konsistente Datenschutzantworten in beiden Stores, untermauert durch Nachweise aus dem Code. Die meisten Datenschutzablehnungen beruhen auf Inkonsistenzen: Die Richtlinie sagt das eine, die App tut das andere, das Formular sagt ein Drittes.

Voraussetzungen

• Quellcode-Zugriff (App und Backend) sowie die Lock-Dateien (pubspec.lock, Podfile.lock, Gradle-Abhängigkeiten, package.json).
• Die aktuelle Datenschutzerklärung und die AGB.
• Kenntnis jedes Backend-Endpunkts und jedes Drittanbieterdienstes, der Benutzerdaten empfängt.

1. Das Dateninventar erstellen (aus Code, nicht aus dem Gedächtnis)

Führen Sie scripts/scan-sdks.mjs im Repository-Stammverzeichnis aus. Es listet bekannte SDKs aus Lock-Dateien mit den Datenkategorien auf, die sie typischerweise berühren, und sucht nach der Verwendung von erforderlichen Grund-APIs, Berechtigungs-Strings, Werbe-ID- und Tracking-APIs. Vervollständigen Sie dann das Inventar, indem Sie die Netzwerkschicht und das Backend lesen:

Daten	Quelle (Bildschirm / SDK)	Vom Gerät gesendet? An wen?	Mit Benutzer verknüpft?	Zweck	Aufbewahrung	Optional?

Regeln:

• „Nur auf dem Gerät verarbeitet“ bedeutet, dass Daten niemals gesendet werden, auch nicht an den eigenen Server. Wenn sie mit dem Backend synchronisiert werden, werden sie erhoben.
• Ihre Auftragsverarbeiter (Hosting, KI-Anbieter, der auf Ihre Anweisung hin handelt, Payment-SDK) werden immer noch als „erhoben“ betrachtet; ob sie als „geteilt“ gelten, unterscheidet sich je nach Store (siehe unten).
• Anonyme Absturzberichte und Nutzungszählungen werden ebenfalls erhoben (Diagnose / Nutzungsdaten), in der Regel „nicht verknüpft“.

Speichern Sie das Inventar als docs/privacy-inventory.md. Jede Antwort unten bezieht sich auf eine Zeile.

2. Apple App-Datenschutz (App Store Connect › App-Datenschutz)

• Ordnen Sie jede Inventarzeile den Apple-Kategorien zu (Kontaktinformationen, Gesundheit & Fitness, Benutzerinhalte, Kennungen, Käufe, Nutzungsdaten, Diagnose…), Zwecken, verknüpft vs. nicht verknüpft und Tracking.
• Tracking = Verknüpfen Ihrer Daten mit Drittanbieterdaten für zielgerichtete Werbung oder Werbemessung oder Weitergabe an Datenmakler. Kein Werbe-SDK und kein Datenmakler bedeutet in der Regel „Kein Tracking“ und keine ATT-Aufforderung.
• Optionale Offenlegung gilt nur, wenn alle Bedingungen von Apple erfüllt sind (selten, optional, jedes Mal vom Benutzer initiiert, kein Tracking/Werbung). Für App-Funktionen selten anwendbar.
• Dokumentation: App-Datenschutzdaten.

3. Google Play-Datensicherheit (Richtlinie › App-Inhalt › Datensicherheit)

• Dasselbe Inventar, Plays Taxonomie (Persönliche Daten, Gesundheit und Fitness, Fotos und Videos, Nachrichten, App-Aktivität, App-Informationen und Leistung, Geräte- oder andere IDs, Finanzinformationen…).
• Weitergabe schließt Übertragungen an Dienstleister aus, die in Ihrem Auftrag verarbeiten; ein SDK, das kundenübergreifende Werbeprofile erstellt, ist Weitergabe.
• Flüchtig: nur im Speicher verarbeitet, nicht gespeichert, nur für die Echtzeitanforderung (z. B. ein analysiertes und verworfenes Foto).
• Verwenden Sie Export to CSV / Import from CSV: behalten Sie die CSV im Repository (store/data-safety.csv), sodass Änderungen wie Code überprüft werden. Importieren überschreibt alle Antworten.
• Dokumentation: Datensicherheit.

4. Andere Play-Erklärungen

• Health-Apps-Erklärung: Jede App muss sie ausfüllen, auch ohne Gesundheitsfunktionen. Dokumentation.
• Health Connect: Eine Begründung pro Berechtigung; nur Berechtigungen anfordern, die eine sichtbare Funktion verwendet; eine Begründungsaktivität (ACTION_SHOW_PERMISSIONS_RATIONALE) mit Verweis auf die Richtlinie. Play kann eine Bildschirmaufzeichnung des Ablaufs verlangen.
• Werbe-ID: Geben Sie an, ob Sie sie verwenden. Wenn kein Werbe-/Attributions-SDK vorhanden ist, geben Sie „Nein“ an und stellen Sie sicher, dass keine Abhängigkeit com.google.android.gms.permission.AD_ID hinzufügt (überprüfen Sie das zusammengeführte Manifest; entfernen Sie es mit tools:node="remove", falls hinzugefügt).
• Zielgruppe, Alterseinstufung (IARC), Werbung, App-Zugriff, Nachrichten, Finanzfunktionen, Regierungsbehörden: Antworten Sie aus dem Inventar. Wenn Teile hinter einem Login stehen, geben Sie dem Prüfer Zugangsdaten im App-Zugriff.
• Kontolöschung: Siehe Abschnitt 8.

5. Datenschutzmanifest (iOS)

• Fügen Sie PrivacyInfo.xcprivacy zum App-Ziel hinzu (Vorlage: templates/PrivacyInfo.xcprivacy).
• Deklarieren Sie NSPrivacyTracking, NSPrivacyTrackingDomains, NSPrivacyCollectedDataTypes (konsistent mit App-Datenschutz) und NSPrivacyAccessedAPITypes für jede Kategorie erforderlicher Grund-APIs, die der eigene Code der App verwendet: Dateizeitstempel, Systemstartzeit, Festplattenspeicher, aktive Tastaturen, UserDefaults. Wählen Sie die genehmigten Grund-Codes aus Apples Liste aus. Flutter-Apps verwenden UserDefaults über Plugins wie shared_preferences – prüfen Sie, ob jedes Plugin sein eigenes Manifest mitliefert; fügen Sie hinzu, was Ihr Code und Plugins ohne Manifeste verwenden.
• Überprüfen Sie nach dem Build die App Store Connect-E-Mail / Build-Warnungen auf fehlende Manifest-Gründe.
• Dokumentation: Privacy-Manifest-Dateien, Erforderliche Grund-API.

6. Export-Compliance (iOS)

• ITSAppUsesNonExemptEncryption in Info.plist: false ist angemessen, wenn die App keine oder nur ausgenommene Verschlüsselung verwendet (z. B. HTTPS über das Betriebssystem, Standardalgorithmen nur zum Schutz der eigenen Daten des Benutzers in einer App, deren Hauptfunktion nicht Sicherheit ist). Diese Einstellung überspringt die questions pro Build.
• Wenn Sie proprietäre Kryptografie implementieren oder bündeln oder Verschlüsselung eine primäre Funktion ist, beantworten Sie stattdessen die Fragen und prüfen Sie, ob eine Dokumentation oder ein jährlicher Selbstklassifizierungsbericht erforderlich ist.
• Dies ist eine rechtliche Einstufung; fragen Sie im Zweifelsfall einen Handels-Compliance-Berater. Dokumentation: Einhaltung der Exportbestimmungen für Verschlüsselung.

7. Altersfreigabe

• Beantworten Sie den aktuellen Apple-Fragebogen und den Play-IARC-Fragebogen wahrheitsgemäß, einschließlich Fragen zu Gesundheit/Wohlbefinden, KI-Chat oder generierten Inhalten, benutzergenerierten Inhalten und uneingeschränktem Webzugriff.
• Halten Sie die Altersfreigabe konsistent mit dem Mindestalter Ihrer AGB und etwaigen In-App-Altersbeschränkungen. Wenn das Fragebogenergebnis niedriger ist als das Mindestalter Ihrer AGB, verwenden Sie die Option des Stores, eine höhere Altersfreigabe festzulegen, anstatt eine Diskrepanz zu belassen.

8. Kontolöschung

• In-App: Wenn Benutzer ein Konto erstellen können, müssen sie die Löschung innerhalb der App starten können (Kontoeinstellungen). Deaktivierung allein reicht nicht aus. Auch für Gast-/automatisch erstellte Konten. Erneute Authentifizierung oder Bestätigung ist erlaubt, darf aber nicht unnötig schwer sein. Apple: Kontolöschung anbieten.
• Web-URL (Play): Eine Seite, die ohne App oder Login erreichbar ist, die App wie im Eintrag nennt, erklärt, wie die Löschung beantragt wird, was gelöscht und was aufbewahrt wird (und warum), sowie etwaige vorherige Schritte (Abonnement kündigen). Dokumentation: Play-Kontolöschung.
• Abonnements: Das Löschen des Kontos kündigt kein Store-Abonnement. Warnen Sie im Löschformular und verlinken Sie auf die Abonnementverwaltung des Stores.
• Mit Apple anmelden: Widerrufen Sie die Tokens des Benutzers über die REST-API von „Mit Apple anmelden“ bei der Löschung.
• Dritte: Löschen Sie den Benutzer auch bei Auftragsverarbeitern (z. B. RevenueCat-Kunde, Analyse-/Absturz-IDs, E-Mail-Listen).
• Wiederauthentifizierungs-Rollout: Wenn Sie eine erneute Authentifizierungsanforderung zum Lösch-Endpunkt hinzufügen, veröffentlichen Sie die App, die die neue Antwort verarbeitet, gleichzeitig mit der Backend-Änderung, oder behalten Sie das alte Verhalten für alte App-Versionen bei.
• Verwenden Sie überall dieselbe Bezeichnung für den Pfad (App, Richtlinie, Store-Formulare, Webseite), z. B. „Profil › Konto löschen".

9. KI-Funktionen

• Apple 5.1.2(i): Legen Sie offen, wo personenbezogene Daten an Dritte weitergegeben werden, einschließlich KI von Drittanbietern, und holen Sie zuerst eine ausdrückliche Erlaubnis ein.
• Vor der ersten Nutzung einer KI-Funktion: Ein kurzes Zustimmungsblatt, das den Anbieter und die Rolle nennt („verarbeitet von , um die Antwort zu generieren"), was gesendet wird, dass es nicht zum Trainieren von Modellen verwendet wird (nur, wenn die AGB des Anbieters dies für Ihren Tarif besagen), und Aufbewahrung (Anbieter und Ihre). Ein Schalter in den Einstellungen zum Widerruf.
• Richtlinienformulierung: Der KI-Anbieter fungiert als Auftragsverarbeiter/Dienstleister auf Ihre Anweisung hin; listen Sie ihn mit Standort und Aufbewahrung auf.
• Store-Formulare: KI-Eingaben (Nachrichten, Fotos, Text) sind erhobene Daten (Benutzerinhalte); in der Regel nicht „geteilt“ auf Play, wenn der Anbieter ein Auftragsverarbeiter ist.
• Erwägen Sie: einen Hinweis „keine professionelle Beratung“ bei KI-Antworten zu Gesundheit oder Finanzen und einen definierten sicheren Antwortbereich für Krisenthemen.

10. Gesundheitsdaten

• Senden Sie HealthKit-/Health Connect-Daten niemals an KI-Anbieter oder andere Dritte. Apple (5.1.3) schränkt die Verwendung und Weitergabe von Gesundheitsdaten ein; Health Connects Richtlinie beschränkt auch Übertragungen. Das einfachste konforme Design: Aus Apple Health / Health Connect gelesene Daten verbleiben auf dem Gerät (oder nur im eigenen Kontospeicher des Benutzers, offengelegt), und Funktionen, die eine KI aufrufen, verwenden nur Daten, die der Benutzer in Ihre App eingegeben hat.
• Verwenden Sie Gesundheitsdaten nicht für Werbung oder Marketing; speichern Sie sie nicht in iCloud.
• Info.plist-Nutzungsstrings (NSHealthShareUsageDescription, NSHealthUpdateUsageDescription) müssen die tatsächliche Verwendung angeben. Wenn der String besagt, dass Daten „niemals mit Dritten geteilt werden“, muss der Code dies garantieren.
• Erzwingen Sie dies im Code: Der Request-Builder für KI-Aufrufe nimmt eine explizite Positivliste von Feldern entgegen; fügen Sie einen Test hinzu, der fehlschlägt, wenn ein gesundheitsbezogenes Feld in einer KI-Nutzlast erscheint.

Entscheidungspunkte mit menschlicher Genehmigung

Endgültige Antworten zu jedem Formular (der Kontoinhaber ist rechtlich verantwortlich), die Export-Compliance-Einstufung, die Altersfreigabe, der KI-Anbieter und seine Datenbedingungen, jede Änderung daran, welche Gesundheitsdaten das Gerät verlassen.

Überprüfung

• Jede Formularantwort verweist auf eine Inventarzeile; das Inventar verweist auf Code.
• Differenzprüfung: Datenschutzerklärung ↔ App-Datenschutz ↔ Data Safety CSV ↔ In-App-Zustimmungstext ↔ Info.plist-Strings. Keine Widersprüche.
• Test: Löschen Sie ein Testkonto; bestätigen Sie, dass Backend-Zeilen, Verarbeiter-Datensätze und Auth-Benutzer gelöscht sind; die Web-Löschseite ist ohne Anmeldung erreichbar.
• Der Build zeigt keine Privacy-Manifest-Warnungen.

Häufige Fallstricke

• „Daten verlassen niemals das Gerät“ in der Richtlinie, während eine Synchronisierungs- oder KI-Funktion sie sendet.
• Vergessen der eigenen anonymen Absturz-/Nutzungsberichterstattung in den Formularen.
• Eine Abhängigkeit fügt stillschweigend die AD_ID-Berechtigung hinzu.
• Gesundheitsdaten gelangen über einen „Kontext“-Builder, der „alles, was wir wissen“ enthält, in eine KI-Aufforderung.
• Löschpfad in App, Richtlinie und Store-Formularen unterschiedlich benannt.
• Altersfreigabe 4+ während AGB 16+ besagen.