Personalisierung auf dem Gerät – Personalisierung mit erweitertem Datenschutz

Diese technische Erläuterung soll im Android Open Source Project (AOSP) umgesetzt werden. Sie erläutert die Motivation hinter der On-Device-Personalisierung (ODP), die Designprinzipien für die Entwicklung, den Datenschutz über ein Vertraulichkeitsmodell und wie sie zu einem nachweislich privaten Erlebnis beiträgt.

Wir planen, dies zu erreichen, indem wir das Datenzugriffsmodell vereinfachen und dafür sorgen, dass alle Nutzerdaten, die die Sicherheitsgrenze überschreiten, auf der Ebene einzelner Nutzer (Nutzer, Nutzer, Modellinstanz) unterschiedlich privat sind (im Text unten manchmal auf Nutzerebene abgekürzt).

Sämtlicher Code, der sich auf potenzielle Endnutzerdaten bezieht, die von den Geräten der Endnutzer ausgehen, ist Open Source und kann von externen Entitäten überprüfbar sein. In den frühen Phasen unseres Vorschlags versuchen wir, Interesse zu wecken und Feedback für eine Plattform zu sammeln, die Möglichkeiten zur On-Device-Personalisierung bietet. Stakeholder wie Datenschutzexperten, Fachkräfte für Datenanalyse und Sicherheitsexperten sind dazu eingeladen, mit uns in Kontakt zu treten.

Vision

Die On-Device-Personalisierung dient dazu, die Daten von Endnutzern vor Unternehmen zu schützen, mit denen sie noch nicht interagiert haben. Unternehmen können ihre Produkte und Dienstleistungen weiterhin für Endnutzer anpassen (z. B. mit entsprechend anonymisierten und differenzierten privaten Modellen für maschinelles Lernen), können aber nicht die genauen Anpassungen sehen, die für einen Endnutzer vorgenommen wurden. Dies hängt nicht nur von der Anpassungsregel des Geschäftsinhabers ab, sondern auch von der individuellen Endnutzereinstellung, es sei denn, es gibt direkte Interaktionen zwischen dem Unternehmen und dem Endnutzer. Wenn ein Unternehmen Modelle für maschinelles Lernen oder statistische Analysen erstellt, versucht das ODP, diese mithilfe der entsprechenden Differential Privacy-Mechanismen korrekt zu anonymisieren.

Unser aktueller Plan sieht vor, ODP in mehreren Meilensteinen zu testen und die folgenden Funktionen abzudecken. Außerdem können Interessierte weitere Funktionen oder Workflows konstruktiv vorschlagen, um diese Untersuchung voranzutreiben:

1. Eine Sandbox-Umgebung, in der die gesamte Geschäftslogik enthalten und ausgeführt wird, sodass eine Vielzahl von Endnutzersignalen in die Sandbox gelangen und gleichzeitig die Ausgaben begrenzt werden.

2. Datenspeicher mit Ende-zu-Ende-Verschlüsselung für:

   1. Nutzersteuerungen und andere nutzerbezogene Daten. Diese können vom Endnutzer bereitgestellt oder erfasst und von Unternehmen abgeleitet werden, mit TTL-Kontrollen (Time to Live), Löschen von Richtlinien, Datenschutzerklärungen usw.
   2. Unternehmenskonfigurationen ODP bietet Algorithmen zur Komprimierung oder Verschleierung dieser Daten.
   3. Ergebnisse werden verarbeitet. Mögliche Ergebnisse:
      1. Werden in späteren Verarbeitungsrunden als Eingaben verwendet,
      2. Sie werden gemäß den entsprechenden Differential Privacy-Mechanismen verrauscht und auf entsprechende Endpunkte hochgeladen.
      3. Werden über den vertrauenswürdigen Uploadvorgang in Trusted Execution Environments (TEE) hochgeladen, auf denen Open-Source-Arbeitslasten mit geeigneten zentralen Differential Privacy-Mechanismen ausgeführt werden.
      4. Wird Endnutzern angezeigt.

3. APIs für folgende Zwecke:

   1. Aktualisieren Sie 2(a) im Batch oder inkrementell.
   2. Aktualisierung 2(b) regelmäßig, entweder als Batch oder inkrementell.
   3. Laden Sie 2(c) mit entsprechenden Rauschmechanismen in vertrauenswürdigen Aggregationsumgebungen hoch. Solche Ergebnisse können für die nächsten Verarbeitungsrunden zu 2(b) werden.

Designprinzipien

ODP hat drei Säulen: Datenschutz, Fairness und Nutzen.

Hohes Datenmodell für verbesserten Datenschutz

ODP folgt dem Prinzip Privacy by Design und ist standardmäßig auf den Schutz der Privatsphäre der Endnutzer ausgerichtet.

Bei ODP wird die Personalisierungsverarbeitung auf das Gerät eines Endnutzers verlagert. Dieser Ansatz sorgt für ein Gleichgewicht zwischen Datenschutz und Nutzen, da die Daten so viele wie möglich auf dem Gerät verbleiben und nur bei Bedarf außerhalb des Geräts verarbeitet werden. ODP konzentriert sich auf:

• Gerätesteuerung über Endnutzerdaten, auch wenn diese das Gerät verlassen. Ziele müssen attestierte vertrauenswürdige Ausführungsumgebungen sein, die von öffentlichen Cloud-Anbietern angeboten werden, die über ODP erstellten Code ausführen.
• Überprüfung des Geräts, was mit den Endnutzerdaten geschieht, wenn sie das Gerät verlassen. ODP stellt föderiertes Open-Source-Computing-Arbeitslasten bereit, um geräteübergreifendes maschinelles Lernen und statistische Analysen für die von ihnen angewendeten Lösungen zu koordinieren. Das Gerät eines Endnutzers bestätigt, dass solche Arbeitslasten unverändert in vertrauenswürdigen Ausführungsumgebungen ausgeführt werden.
• Garantierter technischer Datenschutz (z. B. Aggregation, Rauschen, Differential Privacy) von Ausgaben, die die gerätegesteuerte/überprüfbare Grenze überschreiten.

Die Personalisierung ist gerätespezifisch.

Darüber hinaus müssen Unternehmen Datenschutzmaßnahmen ergreifen, die die Plattform berücksichtigen sollte. Dazu müssen Geschäftsdaten Rohdaten auf ihren jeweiligen Servern gespeichert werden. Um dies zu erreichen, verwendet ODP das folgende Datenmodell:

1. Jede Rohdatenquelle wird entweder auf dem Gerät oder serverseitig gespeichert, um lokales Lernen und Inferenz möglich zu machen.
2. Wir stellen Algorithmen zur Verfügung, um die Entscheidungsfindung über mehrere Datenquellen hinweg zu erleichtern, z. B. das Filtern zwischen zwei unterschiedlichen Speicherorten oder Trainings oder Inferenzen aus verschiedenen Quellen.

In diesem Zusammenhang könnte es einen Turm für Unternehmen und einen Turm für Endnutzer geben:

Der Business Tower enthält Daten, die vom Unternehmen vor der Personalisierung generiert wurden. Über ODP müssen Unternehmen die Inhaberschaft dieser Informationen behalten, damit nur autorisierte Geschäftspartner darauf zugreifen können.
Der Endnutzer-Mast besteht aus vom Endnutzer bereitgestellten Daten (z. B. Kontoinformationen und Einstellungen), gesammelten Daten im Zusammenhang mit den Interaktionen eines Endnutzers mit seinem Gerät und abgeleiteten Daten (z. B. Interessen und Präferenzen), die vom Unternehmen abgeleitet werden. Abgeleitete Daten überschreiben keine direkten Deklarationen von Nutzern.

In einer cloudzentrierten Infrastruktur werden dagegen alle Rohdaten vom Endnutzer-Tower auf die Server des Unternehmens übertragen. Umgekehrt bleiben in einer geräteorientierten Infrastruktur alle Rohdaten vom Endnutzer-Tower an ihrem Ursprung, während die Daten des Unternehmens auf Servern gespeichert bleiben.

Die On-Device-Personalisierung kombiniert das Beste aus beiden Welten, da nur attestierter Open-Source-Code für die Verarbeitung von Daten aktiviert ist, die sich auf Endnutzer in TEEs beziehen können, die privatere Ausgabekanäle verwenden.

Inklusives Engagement der Öffentlichkeit für gerechte Lösungen

ODP zielt darauf ab, eine ausgewogene Umgebung für alle Teilnehmer in einem vielfältigen Ökosystem zu gewährleisten. Wir sind uns der Komplexität dieses Systems bewusst, das aus verschiedenen Akteuren besteht, die unterschiedliche Dienste und Produkte anbieten.

ODP bietet APIs an, die von Entwicklern und den von ihnen vertretenen Unternehmen implementiert werden können. Die On-Device-Personalisierung ermöglicht eine nahtlose Integration dieser Implementierungen und das Verwalten von Releases, Monitoring, Entwicklertools und Feedbacktools. Die On-Device-Personalisierung schafft keine konkrete Geschäftslogik, sondern dient als Katalysator für Kreativität.

ODP könnte mit der Zeit mehr Algorithmen bereitstellen. Die Zusammenarbeit mit der Plattform ist von entscheidender Bedeutung, um das richtige Maß an Features zu bestimmen und gegebenenfalls eine angemessene Obergrenze für Geräteressourcen für jedes teilnehmende Unternehmen festzulegen. Wir erwarten Feedback von der Plattform, das uns hilft, neue Anwendungsfälle zu erkennen und zu priorisieren.

Entwickler-Dienstprogramm zur Verbesserung der Nutzererfahrung

Mit ODP gibt es keinen Verlust von Ereignisdaten oder Beobachtungsverzögerungen, da alle Ereignisse lokal auf Geräteebene aufgezeichnet werden. Es gibt keine Verbindungsfehler und alle Ereignisse sind einem bestimmten Gerät zugeordnet. Daher bilden alle beobachteten Ereignisse von Natur aus eine chronologische Abfolge, in der die Interaktionen des Nutzers wiedergegeben werden.

Durch diesen vereinfachten Prozess müssen Daten nicht zusammengeführt oder neu angeordnet werden, was einen verlustfreien Zugriff auf Nutzerdaten ermöglicht – nahezu in Echtzeit. Dies wiederum kann den Nutzen erhöhen, den Endnutzer bei der Interaktion mit datengestützten Produkten und Dienstleistungen wahrnehmen, was möglicherweise zu einer höheren Zufriedenheit und sinnvolleren Erfahrungen führt. Mit ODP können sich Unternehmen effektiv an die Bedürfnisse ihrer Nutzer anpassen.

Das Datenschutzmodell: Datenschutz durch Vertraulichkeit

In den folgenden Abschnitten wird das Modell des Verbraucher-Produzenten als Grundlage für diese Datenschutzanalyse und die Unterschiede zwischen dem Datenschutz in der Rechenumgebung und der Genauigkeit der Ausgabe erörtert.

Das Modell von Verbrauchern und Herstellern als Grundlage für diese Datenschutzanalyse

Wir verwenden das Verbraucher-Producer-Modell, um die Datenschutzgarantien durch Vertraulichkeit zu prüfen. Berechnungen in diesem Modell werden als Knoten in einem gerichteten azyklischen Graphen (Directed Acyclic Graph, DAG) dargestellt, der aus Knoten und Teilgrafiken besteht. Jeder Rechenknoten hat drei Komponenten: verbrauchte Eingaben, erzeugte Ausgaben und die Berechnung der Zuordnung von Eingaben zu Ausgaben.

Eine Grafik, die das Nutzer-Producer-Modell veranschaulicht. Dieser Graph hat zwei Rechenknoten. Die Ausführungssequenz ist Knoten 1 -> Knoten 2. Knoten 1 wird zuerst ausgeführt. Er verbraucht zwei Anfangseingaben: Eingabe 1 und Eingabe 2. Knoten 1 erzeugt Ausgabe 1. Knoten 2 verarbeitet die Ausgabe von Knoten 1 und eine Anfangseingabe: Eingabe 3. Die Ausgabe 2 ist die Ausgabe. Ausgabe 2 ist auch die Endausgabe dieser Grafik.

Bei diesem Modell wird der Datenschutz für alle drei Komponenten angewendet:

• Eingabeschutzeinstellungen: Knoten können zwei Arten von Eingaben haben. Wenn eine Eingabe von einem Vorgängerknoten generiert wird, gelten bereits die Datenschutzgarantien für die Ausgabe dieses Vorgängers. Andernfalls müssen die Richtlinien für eingehenden Daten-Traffic mithilfe der Richtlinien-Engine gelöscht werden.
• Datenschutz bei der Ausgabe: Die Ausgabe muss möglicherweise privatisiert werden, wie z. B. die von Differential Privacy (DP) bereitgestellt wird.
• Vertraulichkeit der Rechenumgebung. Die Berechnung muss in einer sicher versiegelten Umgebung erfolgen, in der sichergestellt ist, dass niemand Zugriff auf Zwischenzustände innerhalb eines Knotens hat. Zu den Technologien, die dies ermöglichen, gehören föderiertes Computing, hardwarebasierte vertrauenswürdige Ausführungsumgebungen (Trusted Execution Environments, TEE), sichere Multi-Party-Berechnungen (Multi-Party Computation, sMPC), homomorphe Verschlüsselung (HPE) und mehr. Dabei ist zu beachten, dass zwischengeschaltete Bundesstaaten durch Vertraulichkeit geschützt sind und alle Ausgaben, die über die Vertraulichkeitsgrenze hinausgehen, durch Differential Privacy-Mechanismen geschützt werden müssen. Zwei erforderliche Anforderungen sind:
  • die Vertraulichkeit der Umgebungen gewährleistet, damit nur erklärte Ausgaben die Umgebung verlassen
  • Integrität, wodurch korrekte Abzüge der ausgegebenen Datenschutzanforderungen von den eingegebenen Datenschutzanforderungen möglich sind. Mit solides Verhalten können Datenschutzeigenschaften über einen DAG nach unten weitergegeben werden.

Ein privates System wahrt die Vertraulichkeit der Eingabe, der Rechenumgebung und der Ausgabe. Die Anzahl der Anwendungen von Differential Privacy-Mechanismen kann jedoch reduziert werden, indem mehr Verarbeitungen in einer vertraulichen Rechenumgebung versiegelt werden.

Dieses Modell bietet zwei wesentliche Vorteile. Erstens können die meisten Systeme, groß wie klein, als DAG dargestellt werden. Zweitens bieten die Eigenschaften Post-Processing [Abschnitt 2.1] und Zusammensetzung Lemma 2.4 in The Complexity of Differential Privacy leistungsstarke Tools zur Analyse des (Worst-Case-) Kompromisses in Bezug auf Datenschutz und Genauigkeit eines gesamten Diagramms:

• Die Nachbearbeitung garantiert, dass eine Menge nach dem Privatisieren nicht mehr als „Nicht privatisiert“ gekennzeichnet werden kann, wenn die ursprünglichen Daten nicht noch einmal verwendet werden. Solange alle Eingaben für einen Knoten privat sind, ist seine Ausgabe unabhängig von ihren Berechnungen privat.
• Die erweiterte Zusammensetzung sorgt dafür, dass, wenn jeder Grafikteil DP ist, auch der gesamte Graph die e und explore der Endausgabe eines Graphen um etwa ≤ | | h begrenzt, vorausgesetzt, ein Graph hat inline-Einheiten und die Ausgabe jeder Einheit ist (div, rseits) - DP.

Diese beiden Eigenschaften ergeben zwei Designprinzipien für jeden Knoten:

• Property 1 (aus der Post-Processing): Wenn alle Eingaben eines Knotens alle DP sind, ist die Ausgabe DP, die jede beliebige im Knoten ausgeführte Geschäftslogik berücksichtigt und die „geheimen Saucen“ von Unternehmen unterstützt.
• Property 2 (aus erweiterter Zusammensetzung): Wenn die Eingaben eines Knotens nicht alle DP-konform sind, muss die Ausgabe DP-konform gemacht werden. Wenn es sich bei einem Berechnungsknoten um einen Rechenknoten handelt, der in vertrauenswürdigen Ausführungsumgebungen ausgeführt wird und der von der On-Device-Personalisierung bereitgestellte Open-Source-Arbeitslasten und -Konfigurationen ausführt, sind engere DP-Grenzen möglich. Andernfalls muss für die On-Device-Personalisierung möglicherweise der Worst-Case-DP-Grenzwert verwendet werden. Aufgrund von Ressourceneinschränkungen werden vertrauenswürdige Ausführungsumgebungen, die von einem Anbieter öffentlicher Clouds angeboten werden, zuerst priorisiert.

Vergleich von Datenschutz in der Computing-Umgebung und Genauigkeit der Ausgabe

Künftig liegt der Fokus der On-Device-Personalisierung darauf, die Sicherheit von vertraulichen Rechenumgebungen zu verbessern und sicherzustellen, dass Zwischenzustände unzugänglich bleiben. Dieser Sicherheitsprozess, der als Versiegelung bezeichnet wird, wird auf Teilgrafikebene angewendet, sodass mehrere Knoten zusammen DP-konform gemacht werden können. Das bedeutet, dass Property 1 und Property 2, die zuvor erwähnt wurden, auf untergeordneter Grafikebene gelten.

Ein Diagramm mit 7 Knoten wird in 2 Teilgrafiken und einen Knoten aufgeteilt. In diesem Beispiel hat jede Teilgrafik drei Knoten. Wenn die Ausführung der einzelnen Teilgrafiken vor Angreifern abgeschirmt ist, müssen nur Ausgabe 3 und Ausgabe 6, also die Ergebnisse der Teilgrafiken, in DPF eingebunden werden.
Die endgültige Grafikausgabe, Ausgabe 7, wird pro Komposition in DP aufgenommen. Das bedeutet, dass es für dieses Diagramm insgesamt 2 DP geben wird, im Vergleich zu 3 lokalen DPs, wenn keine Versiegelung verwendet wurde.

Im Wesentlichen wird dadurch die Implementierung von Central DP ermöglicht, d. h., die Ausgabe einer versiegelten Umgebung ist DP-konform, wodurch die Genauigkeit im Vergleich zu Local DP (d. h. die einzelnen Eingaben DP-konform) verbessert werden kann. Dieses Prinzip basiert auf der Betrachtung von FCs, TEEs, sMPCs und HPEs als Datenschutztechnologien. Weitere Informationen finden Sie in Kapitel 10 des Artikels Die Komplexität von Differential Privacy.

Ein gutes, praktisches Beispiel ist Modelltraining und Inferenz. In den folgenden Diskussionen wird davon ausgegangen, dass (1) die Trainingspopulation und die Inferenzpopulation sich überschneiden und (2) sowohl Funktionen als auch Labels private Nutzerdaten darstellen. Wir können DP auf alle Eingaben anwenden:

Lokales DP: Private Features von Property 1 + Private Labels -> Privates Modell. (Property 1) Privates Modell + private Funktionen -> private Inferenz.
Bei der On-Device-Personalisierung kann lokale DP auf Nutzerlabels und Funktionen angewendet werden, bevor sie an Server gesendet werden. Dieser Ansatz stellt keine Anforderungen an die Ausführungsumgebung des Servers oder dessen Geschäftslogik.

Central DP: (Property 2) Alternativ können Sie DP während des Modelltrainings anwenden, während Features und Labels präzise bleiben. In diesem Szenario kann der Modellinhaber das Modell zur Inferenz an einen anderen Ort übertragen. Um den Datenschutz während der Ableitung zu wahren, müssen die in das private Modell eingegebenen Features jedoch gemäß Property 1 ebenfalls DP-konform sein.

Sie können die Inferenzgenauigkeit weiter verbessern, indem Sie Training und Ableitung versiegeln. Dadurch können präzise Features in das private Modell eingespeist werden.

Wenn Sie noch einen Schritt weiter gehen, können Sie auch die endgültige Inferenz schließen. In diesem Fall hat auch der Modelleigentümer keinen Zugriff auf die Inferenz.
Dies ist das aktuelle Design der On-Device-Personalisierung.

Nachweislich privat

Die On-Device-Personalisierung ist nachweislich privat. So lässt sich überprüfen, was auf den Geräten der Nutzer passiert. ODP erstellt den Code, der die Daten verarbeitet, die die Geräte der Endnutzer verlassen, und verwendet die RFC 9334-Remote-ATtestation-Prozedur (RATS) von NIST, um zu bestätigen, dass dieser Code auf einem mit dem Confidential Computing Consortium konformen Server ohne Berechtigungen unverändert ausgeführt wird. Diese Codes werden als Open Source zur Verfügung gestellt und können transparent überprüft werden, um Vertrauen aufzubauen. Solche Maßnahmen können Einzelpersonen die Gewissheit geben, dass ihre Daten geschützt sind, und Unternehmen können einen Ruf auf der Grundlage einer soliden Datenschutzgrundlage aufbauen.

Ein weiterer wichtiger Aspekt der On-Device-Personalisierung ist, die Menge der erfassten und gespeicherten privaten Daten zu reduzieren. Es erfüllt dieses Prinzip durch den Einsatz von Technologien wie föderiertes Computing und Differential Privacy und ermöglicht die Aufdeckung wertvoller Datenmuster, ohne vertrauliche Details oder identifizierbare Informationen preiszugeben.

Ein Audit-Trail, in dem Aktivitäten im Zusammenhang mit der Datenverarbeitung und -freigabe protokolliert werden, ist ein weiterer wichtiger Aspekt des überprüfbaren Datenschutzes. Auf diese Weise können wir Prüfberichte erstellen und Sicherheitslücken identifizieren, was unser Engagement für den Datenschutz unterstreicht.

Wir bitten um eine konstruktive Zusammenarbeit mit Datenschutzexperten, Behörden, Branchen und Einzelpersonen, um das Design und die Implementierungen kontinuierlich zu verbessern.

Die folgende Grafik zeigt den Codepfad für die geräteübergreifende Aggregation und das Rauschen nach Differential Privacy.

Struktur des Federated Compute-Dienstes, der sowohl föderiertes Lernen als auch föderierte Analysen verarbeitet. Unverschlüsselte, unverschlüsselte Daten werden nur auf dem Gerät (rote Linie) verarbeitet. Die Verarbeitungsergebnisse werden verschlüsselt hochgeladen, sowohl während der Übertragung als auch im inaktiven Zustand (die blaugrünen Linien). Nur für die On-Device-Personalisierung erstellte, geräteübergreifende Open-Source-Aggregations- und Noise-Arbeitslast hat nach erfolgreicher Attestierung durch mehrere Drittanbieter-Koordinatoren Zugriff auf das unverschlüsselte Geräte-Rohergebnis. Nachdem Rauschen gemäß den Differential Privacy-Mechanismen innerhalb der vertrauenswürdigen Ausführungsumgebung richtig angewendet wurde, können alle nachgelagerten Datenflüsse unverschlüsselt sein (orangefarbene Linien).

Hochwertiges Design

Wie kann Datenschutz durch Vertraulichkeit umgesetzt werden? Im Allgemeinen dient eine von ODP erstellte Richtlinien-Engine als Kernkomponente, die jeden Knoten/Teildiagramm überwacht und den DP-Status ihrer Ein- und Ausgaben verfolgt:

• Aus der Sicht der Richtlinien-Engine werden Geräte und Server gleich behandelt. Geräte und Server, auf denen dieselbe Richtlinien-Engine ausgeführt wird, gelten als logisch identisch, sobald ihre Richtlinien-Engines gegenseitig attestiert wurden.
• Auf Geräten wird die Isolation durch AOSP-isolierte Prozesse (oder pKVM langfristig, wenn die Verfügbarkeit hoch wird) erreicht. Auf Servern basiert die Isolierung auf einer „vertrauenswürdigen Partei“, also einem TEE und anderen bevorzugten technischen Dichtungslösungen, einer vertraglichen Vereinbarung oder beidem.

Mit anderen Worten: Alle versiegelten Umgebungen, in denen die Plattformrichtlinien-Engine installiert und ausgeführt wird, werden als Teil unserer Trusted Computing Base (TCB) betrachtet. Mit dem TCB können Daten ohne zusätzliches Rauschen übertragen werden. DP muss angewendet werden, wenn Daten das TCB verlassen.

Das übergeordnete Design der On-Device-Personalisierung integriert effektiv zwei wesentliche Elemente:

• Eine Architektur mit gekoppelten Prozessen zum Ausführen der Geschäftslogik
• Richtlinien und eine Richtlinien-Engine zur Verwaltung von eingehendem Datenverkehr, ausgehendem Datenverkehr und zugelassenen Vorgängen.

Dieses zusammenhängende Design bietet Unternehmen gleiche Wettbewerbsbedingungen, in denen sie ihren proprietären Code in einer vertrauenswürdigen Ausführungsumgebung ausführen und auf Nutzerdaten zugreifen können, die den entsprechenden Richtlinienprüfungen unterzogen wurden.

In den folgenden Abschnitten werden diese beiden wichtigen Aspekte näher erläutert.

Gekoppelte-Prozess-Architektur zum Ausführen der Geschäftslogik

Mit der On-Device-Personalisierung wird in AOSP eine gepaarte Prozessarchitektur eingeführt, um den Datenschutz für Nutzer und die Datensicherheit während der Ausführung der Geschäftslogik zu verbessern. Diese Architektur besteht aus:

• ManagingProcess. Durch diesen Prozess werden isolierte Prozesse erstellt und verwaltet. So bleiben sie auf Prozessebene isoliert und der Zugriff ist auf APIs auf der Zulassungsliste und keine Netzwerk- oder Laufwerksberechtigungen beschränkt. Der ManagingProcess übernimmt die Erfassung aller Geschäftsdaten sowie Endnutzerdaten und Löschung der Richtlinien für den Geschäftscode und überträgt sie in die IsolatedProcesses zur Ausführung. Außerdem vermittelt er die Interaktion zwischen IsoltedProcesses und anderen Prozessen wie „system_server“.

• IsolatedProcess. Dieser Prozess wird als isoliert bezeichnet (isolatedprocess=true im Manifest) und erhält Geschäftsdaten, durch Richtlinien geklärte Endnutzerdaten und Geschäftscode vom ManagingProcess. Sie ermöglichen es dem Geschäftscode, mit seinen Daten und den durch Richtlinien geklärten Endnutzerdaten zu arbeiten. IsolatedProcess kommuniziert sowohl für eingehenden als auch für ausgehenden Traffic ausschließlich mit dem ManagingProcess, ohne zusätzliche Berechtigungen.

Die gekoppelte Prozessarchitektur bietet die Möglichkeit einer unabhängigen Überprüfung der Datenschutzrichtlinien für Endnutzerdaten, ohne dass Unternehmen ihre Geschäftslogik oder ihren Code als Open-Source-Software veröffentlichen müssen. Da der ManagingProcess die Unabhängigkeit von IsolatedProcesses aufrechterhalten und die IsolatedProcesses die Geschäftslogik effizient ausführen, sorgt diese Architektur für eine sicherere und effizientere Lösung, um den Datenschutz für Nutzer während der Personalisierung zu wahren.

Die folgende Abbildung zeigt diese gekoppelte Prozessarchitektur.

Die Entität, die die Adopter-App erstellt, kann, muss aber nicht dieselbe juristische Person sein wie die Entität, die die Adopter-APK-Datei im Diagramm erstellt. Die Entität, die das „Adopter-APK“ erstellt, ist identisch mit der Entität, die für „Adopter Local Store“ (Lokales Geschäft) im Diagramm verantwortlich ist.

Richtlinien und Richtlinien-Engines für Datenvorgänge

Mit der On-Device-Personalisierung wird eine Ebene für die Erzwingung von Richtlinien zwischen der Plattform und der Geschäftslogik eingeführt. Ziel ist es, eine Reihe von Tools zur Verfügung zu stellen, mit denen Endnutzer- und Geschäftsfunktionen zentralisierten und umsetzbaren Richtlinienentscheidungen zugeordnet werden. Diese Richtlinien werden dann umfassend und zuverlässig über alle Abläufe und Unternehmen hinweg erzwungen.

In der gekoppelten Prozess-Architektur befindet sich die Richtlinien-Engine innerhalb des ManagingProcess und überwacht den ein- und ausgehenden Traffic von Endnutzer- und Geschäftsdaten. Außerdem werden dem IsolatedProcess-Vorgang Vorgänge auf der Zulassungsliste hinzugefügt. Zu den Abdeckungsbereichen gehören beispielsweise die Berücksichtigung der Endnutzersteuerung, der Schutz von Kindern, die Verhinderung der Weitergabe von Daten ohne Einwilligung und der Datenschutz für Unternehmen.

Diese Architektur für die Richtlinienerzwingung umfasst drei Arten von Workflows, die genutzt werden können:

• Lokal initiierte Offline-Workflows mit Kommunikationen der Trusted Execution Environment (TEE):
  • Datendownloads: vertrauenswürdige Downloads
  • Datenuploadabläufe: vertrauenswürdige Transaktionen
• Lokal initiierte Online-Workflows:
  • Bereitstellungsabläufe in Echtzeit
  • Inferenzflüsse
• Lokal initiierte Offline-Workflows:
  • Optimierungsabläufe: On-Device-Modelltraining, implementiert über föderiertes Lernen (FL)
  • Berichterstattungsabläufe: geräteübergreifende Aggregation, implementiert über föderierte Analysen (FA)

Die folgende Abbildung zeigt die Architektur aus der Perspektive von Richtlinien und Richtlinien-Engines.

Die Richtlinien-Engine befindet sich in der Mitte des Designs. Beispiele (keine vollständige Aufzählung):

• Herunterladen: 1 -> 2 -> 4 -> 7 -> 10 -> 11 -> 3
• Auslieferung: 1 + 3 -> 4 -> 6 -> 9 -> 11 -> 3
• Optimierung: 2 (stellt Schulungsplan zur Verfügung) -> 1 + 3 -> 4 -> 5 -> 8 -> 11 -> 2
• Berichte: 3 (für einen Aggregationsplan) -> 1 + 3 -> 4 -> 5 -> 8 -> 11 -> 2

Insgesamt sorgt die Einführung der Ebene für die Durchsetzung von Richtlinien und der Richtlinien-Engine in der gekoppelten Prozessarchitektur der On-Device-Personalisierung für eine isolierte und datenschutzfreundliche Umgebung für die Ausführung der Geschäftslogik und bietet gleichzeitig kontrollierten Zugriff auf erforderliche Daten und Vorgänge.

Mehrschichtige API-Oberflächen

Die On-Device-Personalisierung bietet interessierten Unternehmen eine mehrschichtige API-Architektur. Die oberste Schicht besteht aus Anwendungen, die für bestimmte Anwendungsfälle erstellt wurden. Potenzielle Unternehmen können ihre Daten mit diesen Anwendungen, den sogenannten Top-Layer-APIs, verbinden. Die APIs der obersten Ebene basieren auf den APIs der mittleren Ebene.

Wir gehen davon aus, dass im Laufe der Zeit weitere Top-Layer-APIs hinzugefügt werden. Wenn für einen bestimmten Anwendungsfall keine Top-Layer-API verfügbar ist oder vorhandene Top-Layer-APIs nicht flexibel genug sind, können Unternehmen die Mid-Layer APIs direkt implementieren, die Leistung und Flexibilität durch Programmieren von Primitiven bieten.

Fazit

Die On-Device-Personalisierung ist ein Forschungsvorschlag in einem frühen Stadium, um das Interesse und Feedback für eine langfristige Lösung zu wecken, die Bedenken im Hinblick auf den Datenschutz für Endnutzer mit den neuesten und besten Technologien beschäftigt, die voraussichtlich einen hohen Nutzen bringen.

Wir möchten mit Stakeholdern wie Datenschutzexperten, Fachkräften für Datenanalyse und potenziellen Endnutzern in Kontakt treten, um sicherzustellen, dass ODP ihre Anforderungen erfüllt und ihre Bedenken ausräumen kann.