Zusammenfassung

  • Matcha rückt die Erstellung von Datenschutzangaben an den Code und die SDKs heran, die den Umgang mit Daten prägen; die Einordnung seiner Hinweise bleibt Aufgabe der Entwickler.
  • In einer Studie wurden die Angaben bei den meisten von zwölf Teilnehmenden genauer. Die Arbeit dauerte länger als mit dem Store-Formular und belegt keine plattformweite Richtigkeit.

Datenschutzangaben stehen direkt neben der Download-Entscheidung, werden aber oft außerhalb der Entwicklungsumgebung erstellt. Diese Trennung ist folgenreich. Ein Formular verlangt eine Einordnung dessen, was eine App erhebt, teilt und nutzt. Die Belege liegen jedoch verteilt im eigenen Code, in Bibliotheken Dritter, in der Konfiguration und auf Servern. Ein Team kann den Zweck seiner App kennen und trotzdem übersehen, was eine eingebundene Abhängigkeit tut.

Apple und Google haben dafür unterschiedliche Systeme. Apples App-Privacy-Angaben gelten auf App-Ebene, müssen Praktiken externer Partner einschließen und bei Änderungen aktualisiert werden. Google Play verlangt je Paket eine globale Data-Safety-Erklärung für noch vertriebene Versionen und relevante SDK-Praktiken. Google sagt, nur die Entwickler verfügten über alle nötigen Informationen für vollständige und richtige Angaben; die Store-Prüfung sei nicht darauf ausgelegt, deren Richtigkeit zu verifizieren. Die Taxonomien und Abläufe sind nicht austauschbar. (Apple; Google Play)

Belege dorthin bringen, wo Code entsteht

Lorrie Cranor arbeitet an der Schnittstelle von Privacy Engineering, öffentlicher Politik und nutzbarer Sicherheit. Das CUPS-Labor der Carnegie Mellon University schreibt, Patrick Gage Kelley habe das Designteam des Privacy-Nutrition-Labels geleitet und Cranor sei Teil des Teams gewesen. Ziel war, Datenschutzpraktiken verständlicher und vergleichbarer zu machen; die Arbeit war keine Einzelleistung Cranors. (CMU CUPS; Profil an der CMU)

Ein 2024 von Cranor, Tianshi Li, Yuvraj Agarwal und Jason Hong veröffentlichter Beitrag stellt Matcha vor, ein Android-Studio-Plugin für Google-Play-Angaben. Es sucht im eigenen Code anhand von API-Aufrufen und Schlüsselwörtern nach Hinweisen, unterstützt Annotationen zu Datenzugriff und -übertragung und nutzt eine bearbeitbare XML-Datei für Praktiken von Drittanbieter-SDKs. Daraus entsteht eine CSV-Datei zum Import in die Play Console. Der zentrale Entwurf: Hinweise erscheinen dort, wo Entwickler den Code ohnehin prüfen und deshalb bestätigen, korrigieren oder verwerfen können. (Matcha-Studie; offene Fassung; Projektseite)

Mehr Genauigkeit kostet Zeit

Zwölf Entwickler erstellten in der Studie Angaben für ihre eigenen Apps; elf erreichten mit Matcha eine höhere Genauigkeit als mit dem Formular der Play Console. Die Apps gehörten zu sechs Google-Play-Angeboten. Mit Matcha dauerte die Aufgabe durchschnittlich 30 Minuten, mit der Konsole 9,8 Minuten. Der Unterschied ist erheblich: Der stärker belegte Prozess benötigte in dieser Studie ungefähr die dreifache Zeit.

Das ist ein vielversprechender Befund über Arbeitsabläufe, aber kein Beweis für universelle Genauigkeit. Die Autoren weisen darauf hin, dass die erste Runde in der Konsole die zweite erleichtert haben könnte, dass keine vollständige Referenz für alle Fehler vorlag und dass sich die Stichprobe womöglich nicht auf große Unternehmen übertragen lässt. Codeanalyse kann zudem nicht sämtliche Speicherung und spätere Nutzung auf Servern bestimmen, nachdem Daten das Gerät verlassen haben. Entwickler müssen Kontext beisteuern und Ergebnisse prüfen.

Ein Store-Label spiegelt daher, was seine Regeln von Entwicklern zu wissen erwarten. Matcha versucht, diese Erwartung praktikabler zu machen, indem es Code- und SDK-Hinweise mit einer Erklärung verbindet. Das macht die Erklärung nicht zum Audit. Der bleibende Wert liegt darin, Unsicherheit und Abweichungen sichtbar und vor der Veröffentlichung korrigierbar zu machen.