Empfehlungen zu Telemetrie- und Diagnosedaten

Die Internationale Arbeitsgruppe für Datenschutz in der Technologie (IWGDPT), die so genannte „Berlin Group“, hat ein Arbeitspapier zu Telemetrie veröffentlicht. Damit möchte sie insbesondere Hersteller mit praktischen Empfehlungen bei der Gestaltung von datenschutzfreundlicheren Telemetrie- und Diagnosefunktionen unterstützen. Wir haben das Dokument zusammengefasst.

Wer oder was ist die „Berlin Group“ überhaupt?

Die IWGDPT ist auch unter dem Namen „Berlin Group“ bekannt, da ihre Gründung im Jahr 1983 auf die Initiative des Berliner Beauftragten für Datenschutz und Informationsfreiheit zurückgeht. Dieser unterstützte die Arbeiten dieser Gruppe bereits von Anfang an. Heute gehören der Gruppe Datenschutzbeauftragte aus Europa, Amerika, dem asiatisch-pazifischen Raum und Afrika an, darunter auch der Europäische Datenschutzbeauftragte (EDSB). Zudem sind ausgewählte Rechts- und Technikexperten der Zivilgesellschaft, aus Forschung, Lehre und Wirtschaft Mitglieder der Gruppe.

Die Berlin Group möchte weltweit auf neue technologische Herausforderungen für den Schutz personenbezogener Daten aufmerksam machen. Dazu erarbeitet sie Arbeitspapiere zu bestimmten technologischen Entwicklungen, die sie ihren Mitgliedern und der Öffentlichkeit zur Verfügung stellt. Wir berichteten z.B. über das Arbeitspapier zum Datenschutz für Kinder.

Was sind Telemetrie- und Diagnosedaten?

In der Pressemitteilung des Bundesbeauftragten für den Datenschutz und die Informationsfreiheit (BfDI) heiß es hierzu:

„Unter dem Stichwort Telemetrie sammeln Apps und Betriebssysteme oftmals große Mengen an personenbezogenen Daten. […] Telemetrie- und Diagnosedaten sind Daten, die von Geräten und Anwendungen rund um die Nutzung erfasst werden. Zum Beispiel Angaben darüber, wie oft Nutzende bestimmte Funktionen einer App verwenden oder zu welchen Zeiten.“

Generell geht es um das Sammeln von Rohdaten, die im Falle von Telemetriedaten automatisch und kontinuierlich im Hintergrund z.B. an die Entwickler eine App oder Software übertragen werden. Diagnosedaten dagegen werden nur bei bestimmten Ereignissen, wie z.B. Fehlern, erhoben und übertragen.

Das Arbeitspapier spricht von der Sammlung und Übermittlung von Informationen, die zu technischen Zwecken erhoben werden, die nichts mit dem eigentlichen Zweck des Geräts oder der Anwendung zu tun haben. Zu diesen Zwecken gehören z.B.

• die Überwachung der Leistung von Geräten und Diensten
• die Fehlersuche und -behebung
• die Qualitätssicherung
• die Verbesserung von Diensten sowie
• die Entwicklung neuer Produkte und Dienste

Die Entwickler bzw. die Firmen dahinter wollen durch die Auswertung dieser gesammelten Daten in erster Linie ihre Produkte verbessern. Dabei könnten aber auch bei scheinbar harmlosen Szenarien schnell personenbezogene Daten betroffen sein, beispielsweise wenn Daten über Systemabstürze erhoben werden, heißt es in der Pressemitteilung.

Problem: Nichtbeachtung datenschutzrechtlicher Grundsätze

Ein Problem bei der Erhebung und Auswertung von Telemetrie- und Diagnosedaten ist häufig, dass Nutzer nicht ausreichend über solche Datenerhebungen informiert werden. Datenschutzrechtliche Grundsätze wie z.B. Zweckbindung und Datenminimierung werden oftmals nicht eingehalten. Zum Teil werden gesammelte Informationen wohl auch für andere Zwecke verwendet und so zu Geld gemacht, heißt es in dem Arbeitspapier:

„The information thus collected is then used for other purposes and sometimes monetized via other channels, providing another revenue stream for the developer or vendor.”

Ein weiteres Problem ist, dass die Nutzer in der Regel nur wenige oder gar keine Möglichkeiten haben, den Umfang der gesammelten Daten zu begrenzen oder der Datenerfassung zu widersprechen.

Einheitliche Definition von personenbezogenen Daten

Zunächst hat die Gruppe festgestellt, dass Anbieter und Entwickler oftmals ein ganz anderes Verständnis davon haben, was personenbezogene Daten sind, als z.B. Datenschützer oder Behörden. Daher stellt sie in ihrem Papier zunächst klar, dass sie alle Informationen, die sich auf eine identifizierte oder identifizierbare natürliche Person beziehen, als personenbezogene Daten definiert. Daten werden nur dann als anonymisiert angesehen, wenn sie mit keinem vernünftigerweise zu erwartenden Mittel mit einer natürlichen Person in Verbindung gebracht werden können.

Die Gruppe betont, dass Daten auch dann personenbezogene Daten sind, wenn die Verbindung zu einer Person nicht direkt ist (d.h. über natürliche Identifikatoren wie Vor- und Nachname oder eine offizielle ID-Nummer), sondern bspw. über ein Pseudonym. Daten, die mit einer identifizierbaren Person in Verbindung gebracht werden können, sind auch dann personenbezogene Daten, wenn die Daten verarbeitende Stelle die Person nicht identifiziert hat und auch nicht die Absicht hat, dies zu tun.

Weiterhin wird klargestellt, dass selbst dann, wenn in den gesammelten Daten keine anderen Faktoren vorhanden wären, die eine Verknüpfung mit einer Person ermöglichen würden, bereits die Verbindung eines Geräts oder einer Anwendung mit einem individuellen Benutzerkonto alle gesammelten Informationen eindeutig zu personenbezogenen Daten macht. Die IWGDPT betont, dass Telemetriedaten auch dann personenbezogene Daten sein können, wenn sie keine direkte Kennung wie eine ID-Nummer oder eine E-Mail-Adresse enthalten.

Anwendungsbeispiele aus dem Arbeitspapier

Das Papier nennt drei Anwendungsbeispiele, die hier kurz erläutert werden:

Anwendungsfall 1: Betriebssysteme

Durch die Registrierung eines Geräts oder des auf dem Gerät installierten Betriebssystems ist die Verbindung zu einer natürlichen Person möglich. Erst recht, wenn die Person über ein Online-Konto mit dem Gerät verbunden ist, z.B. über ein Google-Konto bei Android, eine Apple-ID bei iOS oder ein Microsoft-Konto bei Windows-Geräten.

Wenn zudem noch die Standortdaten des Geräts erfasst werden, trägt dies weiter zum Charakter der von diesem Gerät erfassten Informationen als personenbezogene Daten bei, da die Bewegungsprofile in den meisten Fällen Personen zugeordnet werden können.

Anwendungsfall 2: Clientseitige Anwendungen

Ähnlich wie Betriebssysteme sammeln auch Apps Telemetrie- oder Diagnosedaten. Hierbei nutzen sie oft die Möglichkeiten des zugrundeliegenden Betriebssystems, indem sie eines von mehreren verfügbaren Frameworks oder Bibliotheken einbeziehen oder eine eigene Sammelfunktion implementieren. Bei der Verwendung von Bibliotheken von Drittanbietern kann die App Telemetrie- oder Diagnosedaten nicht nur an den App-Entwickler, sondern auch an die Drittanbieter der von ihnen in die App eingebetteten Bibliotheken übermitteln.

Wie bei Betriebssystemen werden die Daten in der Regel mit einem bestimmten Gerät verknüpft, und zwar sowohl durch die Verwendung von Geräte- oder Betriebssystemkennungen (siehe Anwendungsfall 1) als auch durch eine „Installations-ID“. Zudem kann eine Verknüpfung zu einer natürlichen Person über Informationen erfolgen, die zur Registrierung der App verwendet werden. Die Identifizierung des Geräts kann auch indirekt erfolgen, z. B. durch bestimmte Merkmale des Geräts, insbesondere wenn eine app-übergreifende Identifizierung gewünscht ist.

Anwendungsfall 3: Serverseitige Anwendungen

Hierbei liegt der Fokus der Datensammlung nicht auf dem Betriebsstaus des genutzten Geräts, sondern auf der Überwachung der Nutzung von Anwendungen. Dennoch ermöglicht es diese Datenerfassung dem Betreiber des Dienstes, Profile des Nutzerverhaltens zu erstellen und die auf der Serverseite erfassten Daten gegebenenfalls mit den auf der Clientseite erfassten Daten zu kombinieren.

Bestehende Datenschutzrisiken

Die Gruppe erläutert weiterhin die Risiken, die sich aus der Erhebung und Verarbeitung von Telemetrie- und Diagnosedaten ergeben, wobei die Aufzählung nicht abschließend ist:

• Mangelndes Bewusstsein für Telemetrie- und Diagnosedaten als personenbezogene Daten sowohl seitens der Entwickler/Anbieter als auch der Kunden/Nutzer
• Mangel an Transparenz
• Unzureichende Datenminimierung, d.h. es werden zum Teil mehr Daten gespeichert als erforderlich
• Unzureichende Speicherbegrenzung
• Unzureichende Zweckbindung oder Verknüpfung mit anderen personenbezogenen Daten
• Mangelnde Fairness
• Unzureichende Verfahren zur Gewährleistung der Rechte des Einzelnen
• Fehlende Maßnahmen zur Sicherstellung der Vertraulichkeit/Integrität/Verfügbarkeit von Daten

Empfehlungen der Berlin Group

Im letzten Abschnitt gibt das Arbeitspapier Empfehlungen für einen datenschutzfreundlichen Umgang mit Telemetrie- und Diagnosedaten für die Gesetzgeber, Entwickler/Anbieter/Hersteller, Kunden, (End-)Verbraucher und auch für Datenschutzberater:

Für Gesetzgeber

Diese sollten insbesondere prüfen, ob die in dem Papier beschriebenen Fragen in den einschlägigen Rechtsvorschriften des jeweiligen Landes angemessen berücksichtigt werden. Falls erforderlich, sollten rechtliche Klarstellungen erfolgen, unter welchen Bedingungen und zu welchen Zwecken Daten verarbeitet werden dürfen und welche Daten ohne Zustimmung verarbeitet werden dürfen.

Für Entwickler / Anbieter / Hersteller

An diese richten sich die meisten Empfehlungen, wie z.B.

• Anerkennung der Tatsache, dass Informationen, die über Telemetrie- oder Diagnosefunktionen gesammelt werden, in vielen Fällen personenbezogene Daten sind
• Klare Definition und Dokumentation der Zwecke, für die Daten gesammelt werden und Festlegung der Datenarten, die für den jeweiligen Zweck erforderlich sind, verbunden mit transparenten Informationen gegenüber den Kunden
• Begrenzung des Umfangs der Telemetrie- und Diagnosedaten auf Grundlage von Erforderlichkeit und Verhältnismäßigkeit
• Begrenzung des Speicherzeitraums
• Standardmäßig nur Daten sammeln, welche ohne Zustimmung erhoben werden dürfen
• Bereitstellung einer Möglichkeit, ein Gerät einzurichten, ohne ein Konto mit persönlichen Daten erstellen zu müssen
• Pseudonymisierungstechniken verwenden, wann immer dies möglich ist, und so weit wie möglich mit aggregierten und anonymisierten Daten arbeiten

Für institutionelle / gewerbliche Kunden

Diese sollten v.a. verfügbare Informationen über Telemetrie- und Diagnosedaten sowie deren Datenschutzmerkmale als Kriterien bei der Auswahl von Anbietern / Produkten nutzen. Zudem sollten sie Produktkonfigurationen verwenden, die den Fluss von Telemetrie- und Diagnosedaten möglichst unterbinden.

Für Verbraucher / Endverbraucher

Auch diese sollten von den Anbietern zur Verfügung gestellte Informationen bei der Produktauswahl berücksichtigen.

Für Datenschutzbeauftragte, Berater und Anwälte für den Schutz der Privatsphäre und des Datenschutzes

Deren Aufgabe sollte es sein, Entwickler hinsichtlich des Datenschutzes zu sensibilisieren und vom Gesetzgeber klare rechtliche Anforderungen zu fordern. Insbesondere sollten sie Entwicklern / Anbietern Vorschläge für Verfahren zur Auswahl von Zwecken, zur Festlegung, welche und wie viele Daten gesammelt werden dürfen, für die Handhabung der gesammelten Daten und für die Informationen, die den Nutzern über die Sammlung der Daten zur Verfügung gestellt werden an die Hand geben.

Datenschutzlücken lassen sich schließen!

Nach einiger Theorie und anschaulichen Beispielen gibt das Arbeitspapier betroffenen Personengruppen, insb. Entwicklern sowie Kunden / Nutzern, aber auch Gesetzgebern hilfreiche Tipps zur Berücksichtigung des Datenschutzes im Zusammenhang mit dem Sammeln und Auswerten von Telemetrie- und Diagnosedaten. Danach wird der Datenschutz derzeit noch nicht ausreichend berücksichtigt. Das Papier ermutigt aber alle Interessierten, sich zukünftig intensiver mit dem Thema auseinanderzusetzen. So liegt es nun vor allem an den Entwicklern / Anbietern, aber auch den diese Beratenden, die Empfehlungen der Berlin Group bestmöglich umzusetzen, um in Zukunft datenschutzfreundlich(er) zu agieren.