Seite 3: Differential Privacy im Praxiseinsatz

Inhaltsverzeichnis

Ein Beispiel macht die Kernkonzepte von Differential Privacy klarer: Die Mitarbeiter Martin, Mark, Markus und Peter sind in einer Steuerkanzlei tätig. Beim Erstellen von Dokumenten verwendet die Kanzlei eine Software, welche die von den Mitarbeitern eingegebenen Wörter speichert, um eine bessere Wortvervollständigung anzubieten. Beispiel:

{Mitarbeiter: Martin, Wörter: {Steuerschlupfloch, Bewerbung, Hausbau, …}},
{Mitarbeiter: Markus, Wörter: {Finanzamt, BREXIT, Bewerbung, …}},
{Mitarbeiter: Mark, Wörter: {Auftragssituation, Finanzamt, Bewerbung, BREXIT,…}},
{Mitarbeiter: Peter, Wörter: {BREXIT, Finanzamt, Steuerschlupfloch, Kindergeburtstag, …}}

Bei unbeschränktem Vollzugriff auf die Daten lassen sich aus diesen Daten exakte und personenscharfe Abfragen formulieren, zum Beispiel: Welche Mitarbeiter suchen eventuell einen neuen Arbeitgeber und haben heute das Wort "Bewerbung" eingegeben? Das Ergebnis lautet: Markus, Martin und Mark. Differential Privacy anonymisiert und verfremdet die Daten direkt beim Erfassen. Hierbei kommen spezielle Verfahren wie Hashing, Subsampling und Noise Injection zum Einsatz.

Hashing wandelt personenbezogene Daten in eine zufällige Zeichenkette, die man nicht mehr in ihren ursprünglichen Zustand zurück überführen kann. In unserem Beispiel würde man dies auf den Anwendernamen anwenden, so dass im Datensatz nur "081d026c" etwa für den Namen "Martin" steht. Wie bereits erwähnt, lassen sich derartige Anonymisierungen durch Abgleich mit mehreren Datenbanken unter Umständen aushebeln; dann sind die Daten genauso personenbeziehbar wie ohne Hashing.

Daher kann Hashing nur ein Baustein sein. Das Subsampling-Verfahren beschreibt eine Art Datensparsamkeit, nämlich die Beschränkung auf Stichproben zur Auswertung. Es erfolgt eine Reduktion des Datensatzes, so dass nur ein Teil der erhobenen Daten für spätere Analysen bereit steht. Im Beispiel wären das beispielsweise nur die ersten drei Wörter in jeder Mitarbeiterdatenbank. Der spannendste und wichtigste Teil von Differential Privacy nennt sich Noise Injection, also das erwähnte Einfügen von "Rauschen" in den Datenbestand. Ein Rauschen von ca. 30 Prozent hätte auf unsere Datenbank folgende Auswirkung (die verfälschten Daten sind kursiv gedruckt):

{Mitarbeiter: 081d026c, Wörter: {Steuerschlupfloch, Finanzamt, Hausbau}},
{Mitarbeiter: 081f0274, Wörter: {Finanzamt, BREXIT, Behörde}},
{Mitarbeiter: 03aa018c, Wörter: {Auftragssituation, Mandant, Bewerbung}}
{Mitarbeiter: 05c10201, Wörter: {BREXIT, Finanzamt, Steuer}}

Selbst bei einer kompletten De-Anonymisierung würden die Daten nun nicht mehr dazu taugen, ein realistisches Profil dieser Person zu erstellen. Bei einzelnen Wörtern könnte man nicht sicher sagen, ob diese verfälscht wurden oder nicht. Abgesehen von einer ausreichenden "Störung" gilt es jedoch ebenso, den Umfang der gesamt erfassten Daten zu regulieren, um die Anonymität nicht zu riskieren. Diesen Umfang bezeichnet man als Privacy Budget. Es gilt hier das richtige Maß zu finden. Zu viele valide, also unverfälschte, Daten heben die Anonymität der betreffenden Person auf. Zu wenige Daten machen die Auswertung schwierig bis nutzlos.

Das Privacy Budget ist dabei kein statischer Wert, der sich aus einer einfachen Abfrage ermitteln lässt. Die maximale Privatsphäre bei maximaler Auswertbarkeit ist ein dynamisch individuell zu ermittelnder Algorithmus je Datenmenge. Ist das Privacy Budget überschritten, können keine weiteren Abfragen gestartet werden. Dies macht das dahinter liegende mathematische Modell sehr aufwendig und diesen Punkt zur Achillesferse.

Differential Privacy ergibt in Bereichen Sinn, bei denen man den Lösungskorridor kennt. In unserem Beispiel waren es die am häufigsten verwendeten Wörter. Bei einer großen Datenbank, die Daten vieler Personen enthält, extrahieren Algorithmen statistisch relevante Informationen. Die enthaltenen Störungen lassen sich herausfiltern, nach dem Gesetz der großen Zahlen (die Häufigkeit eines immer gleich durchgeführten Zufallsexperiment nähert sich immer weiter der rechnerischen Wahrscheinlichkeit an), wenn der gesuchte Erwartungswert bekannt ist. Das Ergebnis ist dementsprechend vertrauenswürdig, unabhängig davon, ob die detaillierten Nutzerdaten stimmen oder nicht. Ist allerdings im Voraus nicht klar, für welche Abfragen die Nutzerdaten herangezogen werden sollen, steht das Verfahren vor großen Herausforderungen, sowohl bei der richtigen Dosierung des Privacy Budgets als auch bei der statistischen Auswertung.

In einer zentralen Datenbank kommen nach dieser Veränderung lediglich die folgenden Informationen in unserem Beispiel an: Eine personenscharfe Auswertung, welche Mitarbeiter sich gerade beruflich neu orientieren wollen, ist damit nicht mehr möglich. Mit Blick auf den eigentlichen Lösungskorridor, den Mitarbeitern bessere Wortvorschläge für eingegebene Wörter zu liefern, erscheint die Auswertung jedoch sehr hilfreich.