Differential Privacy-Semantik für die On-Device-Personalisierung

In diesem Dokument wird der Datenschutzansatz für die On-Device-Personalisierung (ODP) speziell im Zusammenhang mit dem differenziellen Datenschutz zusammengefasst. Andere Auswirkungen auf den Datenschutz und Designentscheidungen wie die Datenminimierung werden bewusst weggelassen, um den Fokus dieses Dokuments zu wahren.

Differential Privacy

Die Differential Privacy 1 ist ein weit verbreiteter Datenschutzstandard bei der statistischen Datenanalyse und beim maschinellen Lernen 2 3. In nicht-formeller Sprache bedeutet das, dass ein Angreifer fast dasselbe über einen Nutzer aus der Ausgabe eines algorithmusbasierten Differential Privacy-Systems erfährt, unabhängig davon, ob sein Datensatz im zugrunde liegenden Datenpool enthalten ist. Dies bedeutet einen starken Schutz für Einzelpersonen: Alle Rückschlüsse auf eine Person können nur aufgrund aggregierter Eigenschaften des Datensatzes erfolgen, die mit oder ohne den Datensatz dieser Person gelten würden.

Im Kontext des maschinellen Lernens sollten die Ausgabe des Algorithmus als die trainierten Modellparameter betrachtet werden. Der Ausdruck fast dasselbe wird mathematisch durch zwei Parameter (ε, δ) quantifiziert, wobei ε in der Regel als kleine Konstante gewählt wird und δ ≪ 1/(Anzahl der Nutzer).

Datenschutz-Semantik

Das ODP-Design soll dafür sorgen, dass jeder Trainingsdurchlauf auf (ε,δ)-Nutzerebene differenziell vertraulich ist. Im Folgenden wird unser Ansatz zur Erreichung dieser Semantik beschrieben.

Bedrohungsmodell

Wir definieren die verschiedenen Parteien und stellen Annahmen zu jeder davon auf:

  • Nutzer:Der Nutzer, der Eigentümer des Geräts ist und Produkte oder Dienstleistungen des Entwicklers nutzt. Ihre privaten Daten sind für sie vollständig verfügbar.
  • Vertrauenswürdige Ausführungsumgebung (Trusted Execution Environment, TEE): Daten und vertrauenswürdige Berechnungen, die in TEEs stattfinden, werden mithilfe verschiedener Technologien vor Angreifern geschützt. Daher erfordern die Berechnung und die Daten keinen zusätzlichen Schutz. Vorhandene TEEs können Projektadministratoren den Zugriff auf die darin enthaltenen Informationen erlauben. Wir schlagen benutzerdefinierte Funktionen vor, mit denen der Zugriff für einen Administrator verhindert und bestätigt werden kann.
  • Der Angreifer:Kann nebensächliche Informationen über den Nutzer haben und hat vollen Zugriff auf alle Informationen, die den TEE verlassen (z. B. die veröffentlichten Modellparameter).
  • Entwickler: Eine Person, die das Modell definiert und trainiert. Wird als nicht vertrauenswürdig eingestuft (und hat die volle Bandbreite der Möglichkeiten eines Angreifers).

Wir möchten ODP mit der folgenden Differential Privacy-Semantik entwerfen:

  • Vertrauensgrenze: Aus der Perspektive eines Nutzers besteht die Vertrauensgrenze aus dem eigenen Gerät des Nutzers und dem TEE. Alle Informationen, die diese Vertrauensgrenze überschreiten, sollten durch Differential Privacy geschützt werden.
  • Angreifer: Vollständiger Schutz durch Differential Privacy in Bezug auf den Angreifer. Jede Entität außerhalb der Vertrauensgrenze kann ein Angreifer sein (einschließlich des Entwicklers und anderer Nutzer, die potenziell zusammenarbeiten). Der Angreifer kann mit allen Informationen außerhalb der Vertrauensgrenze (z. B. dem veröffentlichten Modell), allen Seiteninformationen über den Nutzer und unendlichen Ressourcen keine zusätzlichen privaten Daten über den Nutzer ableiten, die nicht bereits in den Seiteninformationen enthalten sind, bis zu den vom Datenschutzbudget vorgegebenen Wahrscheinlichkeiten. Insbesondere bedeutet dies einen vollständigen Differential Privacy-Schutz in Bezug auf den Entwickler. Alle an den Entwickler weitergegebenen Informationen (z. B. trainierte Modellparameter oder aggregierte Inferenzen) sind durch Differential Privacy geschützt.

Parameter für lokale Modelle

Die bisherige Datenschutzsemantik berücksichtigt den Fall, dass einige der Modellparameter lokal auf dem Gerät sind, z. B. ein Modell, das eine Nutzer-Embedding enthält, die für jeden Nutzer spezifisch ist und nicht für alle Nutzer freigegeben wird. Bei solchen Modellen bleiben diese lokalen Parameter innerhalb der Vertrauensgrenze (sie werden nicht veröffentlicht) und erfordern keinen Schutz. Freigegebene Modellparameter werden veröffentlicht und durch Differential Privacy geschützt. Dies wird manchmal als Datenschutzmodell für Werbetafeln 4 bezeichnet.

Öffentliche Funktionen

In bestimmten Anwendungen sind einige Funktionen öffentlich. Bei einem Problem mit Filmempfehlungen sind beispielsweise die Merkmale eines Films (Regisseur, Genre oder Erscheinungsjahr) öffentliche Informationen und müssen nicht geschützt werden. Merkmale, die sich auf den Nutzer beziehen (z. B. demografische Informationen oder welche Filme sich der Nutzer angesehen hat), sind dagegen personenbezogene Daten und müssen geschützt werden.

Die öffentlichen Informationen werden als öffentliche Feature-Matrix formalisiert (im vorherigen Beispiel würde diese Matrix eine Zeile pro Film und eine Spalte pro Filmfeature enthalten), die für alle Parteien verfügbar ist. Der Algorithmus für den differenziellen Datenschutz kann diese Matrix verwenden, ohne sie schützen zu müssen. Weitere Informationen finden Sie unter 5. Die ODP-Plattform soll solche Algorithmen implementieren.

Ein Ansatz für den Datenschutz bei der Vorhersage oder Inferenz

Die Inferenzen basieren auf den Modellparametern und den Eingabemerkmalen. Die Modellparameter werden mit Differential Privacy-Semantik trainiert. Hier wird die Rolle von Eingabefeatures erläutert.

In einigen Anwendungsfällen, in denen der Entwickler bereits vollen Zugriff auf die bei der Inferenz verwendeten Funktionen hat, bestehen keine Datenschutzbedenken und das Inferenzergebnis ist für den Entwickler möglicherweise sichtbar.

In anderen Fällen (wenn bei der Inferenz verwendete Funktionen privat sind und nicht für den Entwickler zugänglich sind) kann das Inferenzergebnis für den Entwickler ausgeblendet werden. Beispielsweise kann die Inferenz (und alle nachfolgenden Prozesse, die das Inferenzergebnis verwenden) auf dem Gerät in einem vom Betriebssystem verwalteten Prozess und Anzeigebereich ausgeführt werden, mit eingeschränkter Kommunikation außerhalb dieses Prozesses.

Trainingsablauf

Gesamtarchitektur des Trainingssystems
Abbildung 1: Hochrangige Architektur des Trainingssystems.

Übersicht

In diesem Abschnitt finden Sie einen Überblick über die Architektur und den Ablauf des Trainings (siehe Abbildung 1). ODP implementiert die folgenden Komponenten:

  • Ein vertrauenswürdiger Distributor, z. B. federated select, vertrauenswürdiger Download oder Abruf privater Informationen, der die Rolle von Modellparametern für die Übertragung spielt. Es wird davon ausgegangen, dass der vertrauenswürdige Distributor jedem Client eine Teilmenge von Parametern senden kann, ohne zu verraten, welche Parameter von welchem Client heruntergeladen wurden. Durch diese „teilweise Übertragung“ kann das System den Speicherbedarf auf dem Gerät des Endnutzers minimieren: Anstatt eine vollständige Kopie des Modells zu senden, wird nur ein Bruchteil der Modellparameter an einen bestimmten Nutzer gesendet.

  • Ein vertrauenswürdiger Aggregator, der Informationen von mehreren Clients (z.B. Farbverläufe oder andere Statistiken) aggregiert, Rauschen hinzufügt und das Ergebnis an den Server sendet. Es wird davon ausgegangen, dass es zwischen dem Kunden und dem Aggregator sowie zwischen dem Kunden und dem Distributor vertrauenswürdige Kanäle gibt.

  • DP-Trainingsalgorithmen, die in dieser Infrastruktur ausgeführt werden. Jeder Trainingsalgorithmus besteht aus verschiedenen Berechnungen, die auf den verschiedenen Komponenten (Server, Client, Aggregator, Distributor) ausgeführt werden.

Ein typischer Trainingsdurchlauf besteht aus den folgenden Schritten:

  1. Der Server überträgt Modellparameter an den vertrauenswürdigen Distributor.
  2. Clientberechnung
    • Jedes Clientgerät empfängt das Broadcast-Modell (oder die für den Nutzer relevanten Parameter).
    • Jeder Client führt einige Berechnungen aus, z. B. die Berechnung von Gradienten oder anderen ausreichenden Statistiken.
    • Jeder Client sendet das Ergebnis der Berechnung an den vertrauenswürdigen Aggregator.
    • Der vertrauenswürdige Dienstleister erhebt, aggregiert und schützt die Statistiken von Kunden mithilfe geeigneter Mechanismen für den differenziellen Datenschutz und sendet das Ergebnis dann an den Server.
  3. Serverberechnung
  4. Der (nicht vertrauenswürdige) Server führt Berechnungen an den durch Differential Privacy geschützten Statistiken aus. Beispielsweise werden differenziell datenschützende aggregierte Gradienten verwendet, um die Modellparameter zu aktualisieren.

Faktorisierte Modelle und differenziell private alternierende Minimierung

Die ODP-Plattform soll differenzielle Privatsphäre-Trainingsalgorithmen für allgemeine Zwecke bereitstellen, die auf jede Modellarchitektur angewendet werden können (z. B. DP-SGD 6 7 8 oder DP-FTRL 9 10) sowie Algorithmen, die speziell auf faktorisierte Modelle ausgerichtet sind.

Faktorisierte Modelle sind Modelle, die in Untermodelle (sogenannte Encoder oder Türme) zerlegt werden können. Angenommen, Sie haben ein Modell vom Typ f(u(θu, xu), v(θv, xv)), bei dem u() Nutzermerkmale xu codiert (und die Parameter θu hat) und v() nicht von Nutzern stammende Merkmale xv codiert (und die Parameter θv hat). Die beiden Codierungen werden mit f() kombiniert, um die endgültige Modellvorhersage zu erhalten. In einem Modell für Filmvorschläge sind xu beispielsweise die Nutzermerkmale und xv die Filmmerkmale.

Solche Modelle eignen sich gut für die oben genannte verteilte Systemarchitektur, da sie die Funktionen für Nutzer und Nichtnutzer voneinander trennen.

Faktorisierte Modelle werden mithilfe der Differential Privacy Alternating Minimization (DPAM) trainiert. Dabei werden abwechselnd die Parameter θu (während θv fixiert ist) und umgekehrt optimiert. DPAM-Algorithmen bieten in einer Vielzahl von Umgebungen eine bessere Leistung 4 11, insbesondere bei öffentlichen Funktionen.

Verweise