Differential Privacy für die On-Device-Personalisierung

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

Differential Privacy

Differential Privacy 1 ist ein weithin übernommener Datenschutzstandard in der statistischen Datenanalyse und beim maschinellen Lernen 2 3. Informell besagt sie, dass ein Angreifer aus der Ausgabe eines Differential-Private-Algorithmus fast das Gleiche über einen Nutzer lernt, unabhängig davon, ob sein Datensatz im zugrunde liegenden Datensatz enthalten ist oder nicht. Dies impliziert einen starken Schutz für Einzelpersonen: Alle Rückschlüsse auf eine Person können nur auf aggregierte Eigenschaften des Datasets zurückzuführen sein, die mit oder ohne den Datensatz dieser Person vorliegen würden.

Im Kontext des maschinellen Lernens ist die Ausgabe des Algorithmus als Parameter des trainierten Modells zu betrachten. Der Ausdruck fast das gleiche Ergebnis wird mathematisch durch zwei Parameter quantifiziert (kaufen, Deltas und Deltas berechnen), wobei iere in der Regel eine kleine Konstante ist und Delta ≪1/(Anzahl der Nutzer).

Datenschutzsemantik

Mit dem ODP-Design soll dafür gesorgt werden, dass jeder Trainingslauf auf (Seiten-, ?-)Nutzerebene differenziert privat bleibt. Im Folgenden wird beschrieben, wie wir diese Semantik erreichen.

Bedrohungsmodell

Wir definieren die verschiedenen Parteien und geben Annahmen zu den einzelnen Parteien an:

  • Nutzer:Der Nutzer, dem das Gerät gehört und der Nutzer der vom Entwickler bereitgestellten Produkte oder Dienstleistungen ist. Die personenbezogenen Daten sind für ihn selbst uneingeschränkt zugänglich.
  • Vertrauenswürdige Ausführungsumgebung (Trusted Execution Environment, TEE): Daten und vertrauenswürdige Berechnungen innerhalb von TEE werden mithilfe verschiedener Technologien vor Angreifern geschützt. Daher erfordern die Berechnung und die Daten keinen zusätzlichen Schutz. Bestehende TEEs können ihren Projektadministratoren Zugriff auf die darin enthaltenen Informationen gewähren. Wir schlagen benutzerdefinierte Funktionen vor, mit denen Administratoren verhindern können, dass sie Zugriff haben.
  • Der Angreifer:Hat möglicherweise Nebeninformationen über den Nutzer und hat uneingeschränkten Zugriff auf alle Informationen, die das TEE verlässt (z. B. die veröffentlichten Modellparameter).
  • Entwickler:Einer, der das Modell definiert und trainiert. als nicht vertrauenswürdig eingestuft wird (und alle Möglichkeiten eines Angreifers hat)

Wir möchten ODP mit der folgenden Semantik des Differential Privacy entwickeln:

  • Vertrauensgrenze:Aus Sicht eines Nutzers besteht die Vertrauensgrenze aus dem Gerät des Nutzers und dem TEE. Alle Informationen, die diese Vertrauensgrenze überschreiten, sollten durch Differential Privacy geschützt werden.
  • Angreifer:vollständiger Differential Privacy in Bezug auf den Angreifer. Jede Entität außerhalb der Vertrauensgrenze kann ein Angreifer sein. Dazu gehören der Entwickler und andere Nutzer, die möglicherweise zusammenstoßen. Der Angreifer kann angesichts aller Informationen außerhalb der Vertrauensgrenze (z. B. des veröffentlichten Modells), etwaiger Nebeninformationen über den Nutzer und unendlichen Ressourcen keine weiteren privaten Daten über den Nutzer ableiten (abgesehen von den Daten, die bereits in den Seiteninformationen enthalten sind), bis zu den Chancen des Datenschutzbudgets. Dies beinhaltet insbesondere den vollen Differential Privacy-Schutz gegenüber dem Entwickler. Alle Informationen, die an den Entwickler weitergegeben werden, z. B. trainierte Modellparameter oder aggregierte Inferenzen, werden unter Differential Privacy geschützt.

Lokale Modellparameter

Die bisherige Datenschutzsemantik eignet sich auch für den Fall, dass einige Modellparameter lokal auf dem Gerät sind, z. B. bei einem Modell, das eine Nutzereinbettung enthält, die für jeden Nutzer spezifisch ist und nicht von mehreren Nutzern verwendet wird. Bei solchen Modellen verbleiben diese lokalen Parameter innerhalb der Vertrauensgrenze (sie werden nicht veröffentlicht) und müssen nicht geschützt werden, während freigegebene Modellparameter veröffentlicht werden (und durch Differential Privacy geschützt werden). Dies wird manchmal auch als Datenschutzmodell für Billboards bezeichnet4.

Öffentliche Funktionen

Bei bestimmten Anwendungen sind einige der Funktionen öffentlich. Bei einem Problem mit einer Filmempfehlung sind beispielsweise die Merkmale eines Films (Regisseur, Genre oder Erscheinungsjahr des Films) öffentliche Informationen und müssen nicht geschützt werden. Funktionen mit Bezug auf den Nutzer (z. B. demografische Informationen oder die Filme, die der Nutzer angesehen hat) hingegen sind privat und müssen geschützt werden.

Die öffentlichen Informationen werden als Public-Feature-Matrix formalisiert (im vorherigen Beispiel würde diese Matrix eine Zeile pro Film und eine Spalte pro Filmfeature enthalten), die allen Parteien zur Verfügung steht. Der differenzielle private Trainingsalgorithmus kann diese Matrix verwenden, ohne sie schützen zu müssen, siehe Beispiel 5. Die ODP-Plattform plant, solche Algorithmen zu implementieren.

Ein Ansatz zum Datenschutz bei Vorhersagen oder Inferenzen

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

Wenn der Entwickler bereits vollen Zugriff auf die in der Inferenz verwendeten Funktionen hat, gibt es in einigen Anwendungsfällen keine Datenschutzbedenken hinsichtlich der Inferenz und das Inferenzergebnis kann für den Entwickler sichtbar sein.

In anderen Fällen (wenn die in der Inferenz verwendeten Funktionen privat und für den Entwickler nicht zugänglich sind) kann das Inferenzergebnis für den Entwickler ausgeblendet werden. Das kann beispielsweise passieren, wenn die Inferenz (und alle nachgelagerten Prozesse, die das Inferenzergebnis verwenden) auf dem Gerät, in einem Prozess und Anzeigebereich des Betriebssystems mit eingeschränkter Kommunikation außerhalb dieses Prozesses ausgeführt wird.

Trainingsablauf

Allgemeine Architektur des Trainingssystems
Abbildung 1:Allgemeine Architektur des Trainingssystems

Überblick

Dieser Abschnitt gibt einen Überblick über die Architektur und den Ablauf des Trainings (siehe Abbildung 1). Das ODP umfasst die folgenden Komponenten:

  • Ein vertrauenswürdiger Vertriebspartner, z. B. föderierte Auswahl, vertrauenswürdiger Download oder das Abrufen privater Informationen, der die Rolle der Parameter für das Broadcasting-Modell übernimmt. Es wird davon ausgegangen, dass der vertrauenswürdige Distributor eine Teilmenge von Parametern an jeden Client senden kann, ohne anzugeben, welche Parameter von welchem Client heruntergeladen wurden. Durch diese „teilweise Übertragung“ kann das System den Platzbedarf auf dem Endnutzergerät minimieren: Statt eine vollständige Kopie des Modells zu senden, wird nur ein Teil der Modellparameter an einen bestimmten Nutzer gesendet.

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

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

Eine typische Trainingsrunde besteht aus den folgenden Schritten:

  1. Der Server sendet Modellparameter an den vertrauenswürdigen Distributor.
  2. Clientberechnung
    • Jedes Clientgerät empfängt das Broadcast-Modell (oder eine Teilmenge der für den Nutzer relevanten Parameter).
    • Jeder Client führt eine Berechnung durch (z. B. Berechnung von Gradienten oder anderen ausreichenden Statistiken).
    • Jeder Client sendet das Ergebnis der Berechnung an den vertrauenswürdigen Aggregator.
    • Der vertrauenswürdige Aggregator erfasst, aggregiert und schützt die Statistiken von Clients mit geeigneten Differential Privacy-Mechanismen und sendet das Ergebnis dann an den Server.
  3. Serverberechnung
  4. Der (nicht vertrauenswürdige) Server führt Berechnungen mit den Differential Privacy-geschützten Statistiken aus (z. B. verwendet Differential private aggregierte Gradienten zur Aktualisierung der Modellparameter).

Fakultierte Modelle und differenziell private alternierende Minimierung

Die ODP-Plattform plant, differenzielle private Trainingsalgorithmen für allgemeine Zwecke zur Verfügung zu stellen, die auf jede Modellarchitektur wie DP-SGD6 7 8 oder DP-FTRL 9 10 sowie auf faktorisierte Modelle angewendet werden können.

Faktorisierte Modelle sind Modelle, die in Untermodelle (Encoder oder Towers) zerlegt werden können. Stellen Sie sich beispielsweise ein Modell der Form f(u(θu, xu), v(θv, xv)) vor, bei dem u() die Nutzermerkmale xu codiert (und die Parameter θu hat) und v() die Nicht-Nutzerfunktionen xv codiert (und die Parameter θv hat). Die beiden Codierungen werden mithilfe von f() kombiniert, um die endgültige Modellvorhersage zu erstellen. In einem Modell für Filmempfehlungen sind beispielsweise xu die Nutzermerkmale und xv die Filmmerkmale.

Solche Modelle eignen sich gut für die oben erwähnte verteilte Systemarchitektur, da sie die Funktionen von Nutzern und anderen Nutzern voneinander trennen.

Faktorisierte Modelle werden unter Verwendung von Differentially Private Alternating Minimization (DPAM) trainiert. Dabei werden die Parameter θu (während θv festgelegt) optimiert und umgekehrt. Algorithmen für die Datenverarbeitung sind in verschiedenen Szenarien nachweislich nützlicher.4 11, insbesondere bei öffentlichen Funktionen.

Verweise