Personalisierung auf dem Gerät – Personalisierung mit erweitertem Datenschutz

Diese technische Erläuterung soll im Android Open Source Project (AOSP) implementiert werden. In dieser technischen Erläuterung werden die Motivation hinter der On-Device-Personalisierung (ODP), die Designprinzipien, die der Entwicklung zugrunde liegen, sowie der Datenschutz mithilfe des Vertraulichkeitsmodells erläutert. Außerdem wird erläutert, wie dadurch eine nachweislich private Nutzung gewährleistet wird.

Zu diesem Zweck möchten 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 (in diesem Dokument manchmal auf Nutzerebene abgekürzt).

Der gesamte Code, der sich auf den potenziellen ausgehenden Traffic von Endnutzerdaten bezieht, ist Open Source und kann von externen Stellen verifiziert werden. In den frühen Phasen unseres Vorschlags möchten wir Interesse wecken und Feedback für eine Plattform einholen, die On-Device-Personalisierung ermöglicht. Wir laden Stakeholder wie Datenschutzexperten, Datenanalysten und Sicherheitsexperten dazu ein, mit uns in Kontakt zu treten.

Vision

Die Personalisierung auf dem Gerät wurde entwickelt, um 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 differenziellen privaten Modellen für maschinelles Lernen), können jedoch nicht die genauen Anpassungen sehen, die für einen Endnutzer vorgenommen wurden (dies ist nicht nur von der Anpassungsregel abhängig, die vom Geschäftsinhaber erstellt wurde, sondern auch von der individuellen Einstellung des Endnutzers), 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 mithilfe der entsprechenden Differential Privacy-Mechanismen sicherzustellen, dass diese ordnungsgemäß anonymisiert werden.

Derzeit planen wir, ODP in mehreren Meilensteinen zu untersuchen und dabei die folgenden Funktionen und Funktionalitäten abzudecken. Außerdem laden wir interessierte Parteien ein, konstruktive zusätzliche Funktionen oder Workflows für diese Untersuchung vorzuschlagen:

1. Eine Sandbox-Umgebung, in der die gesamte Geschäftslogik enthalten und ausgeführt wird, die es einer Vielzahl von Endnutzersignalen ermöglicht, in die Sandbox zu gelangen, während die Ausgaben begrenzt sind.

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

   1. Nutzereinstellungen und andere nutzerbezogene Daten. Diese können vom Endnutzer bereitgestellt oder von Unternehmen gesammelt und abgeleitet werden, sowie TTL-Einstellungen (Time to Live), das Löschen von Richtlinien, Datenschutzrichtlinien und mehr.
   2. Unternehmenskonfigurationen. ODP bietet Algorithmen zur Komprimierung oder Verschleierung dieser Daten.
   3. Ergebnisse der Geschäftsverarbeitung. Beispiele für Ergebnisse:
      1. in späteren Verarbeitungsrunden als Eingabe aufgenommen,
      2. Wird gemäß den entsprechenden Differential Privacy-Mechanismen ausgegeben und auf die berechtigten Endpunkte hochgeladen.
      3. werden mithilfe des vertrauenswürdigen Uploadablaufs in Trusted Execution Environments (TEE) hochgeladen, in denen Open-Source-Arbeitslasten mit entsprechenden zentralen Differential Privacy-Mechanismen ausgeführt werden.
      4. Wird Endnutzern angezeigt.

3. APIs für:

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

Designprinzipien

Das ODP soll das Gleichgewicht zwischen drei Säulen halten: Datenschutz, Fairness und Nutzen.

Turm-Datenmodell für verbesserten Datenschutz

ODP entspricht Privacy by Design und ist standardmäßig mit dem Datenschutz für Endnutzer ausgelegt.

Bei ODP wird untersucht, wie die Personalisierungsverarbeitung auf das Gerät eines Endnutzers verschoben wird. Dieser Ansatz schafft ein Gleichgewicht zwischen Datenschutz und Nutzen, da Daten so weit wie möglich auf dem Gerät gespeichert und nur bei Bedarf außerhalb des Geräts verarbeitet werden. ODP konzentriert sich auf Folgendes:

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

Folglich ist die Personalisierung gerätespezifisch.

Darüber hinaus fordern Unternehmen auch Datenschutzmaßnahmen, die auf der Plattform berücksichtigt werden sollten. Dies beinhaltet die Verwaltung von Geschäftsdaten auf ihren jeweiligen Servern. Um dies zu erreichen, verwendet ODP das folgende Datenmodell:

1. Jede Rohdatenquelle wird entweder auf dem Gerät oder serverseitig gespeichert, was lokales Lernen und Inferenz ermöglicht.
2. Wir stellen Algorithmen zur Verfügung, die die Entscheidungsfindung über mehrere Datenquellen hinweg erleichtern, z. B. das Filtern zwischen zwei unterschiedlichen Datenstandorten oder Training oder Inferenz über verschiedene Quellen hinweg.

In diesem Zusammenhang könnte es einen Business Tower und einen Endnutzerturm geben:

Der Business Tower enthält Daten, die vom Unternehmen vor der Personalisierung generiert wurden. ODP bittet Unternehmen, die Inhaberschaft an diesen Informationen zu behalten, sodass nur autorisierte Geschäftspartner darauf zugreifen können.
Der Endnutzer-Turm besteht aus Daten, die der Endnutzer zur Verfügung stellt (z. B. Kontoinformationen und Einstellungen), erhobene Daten zu den Interaktionen eines Endnutzers mit seinem Gerät und davon abgeleiteten Daten (z. B. Interessen und Präferenzen), die vom Unternehmen abgeleitet werden. Abgeleitete Daten überschreiben die direkten Deklarationen von Nutzern nicht.

Zum Vergleich: In einer cloudzentrierten Infrastruktur werden alle Rohdaten vom Endnutzer-Turm auf die Server der Unternehmen übertragen. Umgekehrt verbleiben in einer geräteorientierten Infrastruktur alle Rohdaten vom Endnutzer-Turm am Ursprung, während die Daten des Unternehmens auf Servern gespeichert bleiben.

Die On-Device-Personalisierung kombiniert das Beste aus beiden Welten, indem nur attestierten Open-Source-Code zur Verarbeitung von Daten aktiviert wird, die das Potenzial haben, sich auf Endnutzer in TEEs über mehr private Ausgabekanäle zu beziehen.

Inklusives öffentliches Engagement für gerechte Lösungen

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

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

Das ODP könnte im Laufe der Zeit weitere Algorithmen zur Verfügung stellen. Die Zusammenarbeit mit dem Ökosystem ist von entscheidender Bedeutung, um das richtige Funktionsniveau zu bestimmen und möglicherweise eine angemessene Obergrenze für Geräteressourcen für jedes teilnehmende Unternehmen festzulegen. Wir rechnen mit Feedback aus der Branche, damit wir neue Anwendungsfälle erkennen und priorisieren können.

Entwicklerdienstprogramm für eine verbesserte Nutzererfahrung

Bei ODP kommt es zu keinem Verlust von Ereignisdaten oder Beobachtungsverzögerungen, da alle Ereignisse lokal auf Geräteebene aufgezeichnet werden. Es gibt keine Fehler bei der Teilnahme und alle Ereignisse sind einem bestimmten Gerät zugeordnet. Infolgedessen bilden alle beobachteten Ereignisse natürlich eine chronologische Abfolge, die die Interaktionen der Nutzer widerspiegelt.

Bei diesem vereinfachten Prozess müssen Daten nicht zusammengeführt oder neu angeordnet werden, sodass Nutzerdaten nahezu in Echtzeit und verlustfrei zugänglich sind. Dies kann wiederum den Nutzen steigern, den Endnutzer bei der Interaktion mit datengesteuerten Produkten und Diensten wahrnehmen, was potenziell zu einer höheren Zufriedenheit und einem sinnvolleren Nutzererlebnis führt. Mit ODP können sich Unternehmen effektiv an die Anforderungen ihrer Nutzenden anpassen.

Das Datenschutzmodell: Datenschutz durch Vertraulichkeit

In den folgenden Abschnitten wird das Nutzererstellermodell als Grundlage dieser Datenschutzanalyse und der Datenschutz für die Rechenumgebung im Vergleich zur Ausgabegenauigkeit erläutert.

Verbraucher-Produzenten-Modell als Grundlage dieser Datenschutzanalyse

Wir verwenden das Modell „Verbraucherhersteller“, um die Datenschutzgarantien im Hinblick auf die 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 Teilgraphen besteht. Jeder Rechenknoten hat drei Komponenten: verbrauchte Eingaben, erzeugte Ausgaben und Berechnungszuordnungseingaben zu Ausgaben.

Ein Diagramm, das das Modell für Verbraucher und Hersteller veranschaulicht. Diese Grafik hat zwei Berechnungsknoten. Die Ausführungssequenz ist Node 1 -> Node 2. Knoten 1 wird als erster ausgeführt. Es werden zwei anfängliche Eingaben benötigt: Eingabe 1 und Eingabe 2. Knoten 1 erzeugt die Ausgabe 1. Knoten 2 verarbeitet die Ausgabe von Knoten 1 und eine erste Eingabe: Eingabe 3. Die Ausgabe 2 ist die Ausgabe. Ausgabe 2 ist auch die endgültige Ausgabe dieser Grafik.

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

• Datenschutz eingeben: Knoten können zwei Arten von Eingaben haben. Wenn eine Eingabe von einem Vorgängerknoten generiert wird, hat sie bereits die Datenschutzgarantien dieses Vorgängers. Andernfalls müssen Richtlinien für eingehenden Traffic mit der Richtlinien-Engine gelöscht werden.
• Ausgabedatenschutz: Die Ausgabe muss möglicherweise privatisiert werden, wie die von Differential Privacy (DP) bereitgestellt wird.
• Vertraulichkeit der Verarbeitungsumgebung: Die Berechnung muss in einer sicher abgedichteten Umgebung erfolgen, in der sichergestellt ist, dass niemand Zugriff auf Zwischenzustände innerhalb eines Knotens hat. Technologien, die dies ermöglichen, sind unter anderem föderierte Berechnungen (FC), hardwarebasierte Trusted Execution Environments (TEE), sichere Multi-Party-Computerverarbeitung (SMPC), homomorphic Encryption (HPE) und mehr. Dabei ist zu beachten, dass der Datenschutz zwischen den Staaten und allen Ausgaben, die die Vertraulichkeitsgrenze überschreiten, weiterhin durch Differential Privacy-Mechanismen geschützt wird. Zwei erforderliche Anforderungen sind:
  • Umgebungen werden vertraulich behandelt. Dadurch wird sichergestellt, dass nur deklarierte Ausgaben die Umgebung und
  • Verständlichkeit, sodass die erhobenen Datenschutzansprüche korrekt von Datenschutzansprüchen von eingegebenen Daten abgezogen werden können. Soundness ermöglicht die Weitergabe von Datenschutzeigenschaften in einem DAG.

Ein privates System wahrt den Datenschutz für Eingabedaten, die Vertraulichkeit der Rechenumgebung und die Vertraulichkeit der Ausgabe. Die Anzahl der Anwendungsmöglichkeiten von Differential Privacy-Mechanismen kann jedoch verringert werden, indem mehr Verarbeitungsabläufe in einer vertraulichen Rechenumgebung verhindert werden.

Dieses Modell bietet zwei wesentliche Vorteile. Die meisten großen und kleinen Systeme können als DAG dargestellt werden. Zweitens bieten die DP-Eigenschaften Nachbearbeitung [Abschnitt 2.1] und Zusammensetzung Lemma 2.4 in „The Complexity of Differential Privacy“ leistungsstarke Werkzeuge, um den (schlimmsten) Kompromiss zwischen Datenschutz und Genauigkeit für eine gesamte Grafik zu analysieren:

• Die Nachverarbeitung garantiert, dass eine Menge, die privatisiert wurde, nicht „nicht privatisiert“ werden kann, wenn die ursprünglichen Daten nicht noch einmal verwendet werden. Solange alle Eingaben für einen Knoten privat sind, bleibt seine Ausgabe unabhängig von seinen Berechnungen privat.
• Die erweiterte Zusammensetzung sorgt dafür, dass, wenn jeder Graphteil DP ist, auch der gesamte Graph die β und DBM der endgültigen Ausgabe eines Diagramms effektiv um etwa √β begrenzt, vorausgesetzt, der Graph hat β-Einheiten und die Ausgabe jeder Einheit ist (, δ)-DP.

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

• Property 1 (aus der Nachverarbeitung): Wenn alle Eingaben eines Knotens DP sind, ist die Ausgabe DP, die jede beliebige im Knoten ausgeführte Geschäftslogik unternimmt und die „Secret Saucs“ von Unternehmen unterstützt.
• Attribut 2 (aus erweiterter Zusammensetzung): Wenn die Eingaben eines Knotens nicht ausschließlich DP-konform sind, muss die Ausgabe DP-konform sein. Wenn ein Rechenknoten in vertrauenswürdigen Ausführungsumgebungen ausgeführt wird und von der On-Device-Personalisierung bereitgestellte Open-Source-Arbeitslasten und -Konfigurationen ausführt, sind strengere DP-Grenzen möglich. Andernfalls müssen für die On-Device-Personalisierung möglicherweise Worst-Case-DP-Grenzen verwendet werden. Aufgrund von Ressourceneinschränkungen haben vertrauenswürdige Ausführungsumgebungen, die von Anbietern öffentlicher Clouds angeboten werden, zuerst Vorrang.

Datenschutz bei der Computing-Umgebung vs. Ausgabegenauigkeit

Künftig liegt der Fokus bei der On-Device-Personalisierung darauf, die Sicherheit vertraulicher Rechenumgebungen zu verbessern und dafür zu sorgen, dass Zwischenzustände unzugänglich bleiben. Dieser Sicherheitsprozess, auch Versiegelung genannt, wird auf Teilgraphebene angewendet, damit mehrere Knoten gemeinsam DP-konform gemacht werden können. Das bedeutet, dass die zuvor erwähnten Eigenschaften 1 und Attribut 2 auch auf der Ebene der untergeordneten Grafik gelten.

Ein Diagramm mit 7 Knoten wird in zwei Teilgrafiken und einen Knoten aufgeteilt. Jeder Teilgraph hat in diesem Beispiel 3 Knoten. Wenn die Ausführung jedes Teilgraphen vor Angreifern geschützt ist, müssen nur Ausgabe 3 und Ausgabe 6 der Ausgabedaten der Teilgraphen zur Verfügung gestellt werden.
Natürlich wird die endgültige Ausgabe des Graphen, Ausgabe 7, pro Komposition DP-freigegeben. Das bedeutet, dass es für dieses Diagramm insgesamt 2 DPF gibt – verglichen mit 3 (lokalen) DPs, wenn keine Versiegelung verwendet wurde.

Im Wesentlichen ermöglicht dies durch Schützen der Rechenumgebung und Eliminierung der Möglichkeit für Angreifer, auf die Eingaben und Zwischenzustände eines Graphen oder Teilgraphen zuzugreifen, die Implementierung von zentralen Datenverarbeitungssystemen (d. h., die Ausgabe einer versiegelten Umgebung ist DP-konform), was die Genauigkeit im Vergleich zu lokalen Datenverarbeitungsplattformen verbessern kann (d. h., die einzelnen Eingaben sind DP-konform). Diesem Grundsatz liegt die Auffassung von FK, TEEs, sMPCs und HPEs als Datenschutztechnologien zugrunde. Weitere Informationen finden Sie in Kapitel 10 des Artikels The Complexity of Differential Privacy.

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

Lokales DP: Private Features für Property 1 + private Labels -> privates Modell. (Property 1) Privates Modell + private Features -> private Inferenz.
Bei der Personalisierung auf dem Gerät können lokale Daten auf Nutzerlabels und -funktionen angewendet werden, bevor sie an Server gesendet werden. Dieser Ansatz stellt keine Anforderungen an die Ausführungsumgebung des Servers oder seine Geschäftslogik.

Zentrales DP: (Attribut 2): Alternativ können Sie DP während des Modelltrainings anwenden, wobei Features und Labels präzise bleiben. In diesem Szenario kann der Modellinhaber das Modell zur Inferenz an eine andere Stelle übertragen. Damit der Datenschutz bei der Ableitung jedoch gewahrt bleibt, müssen die in das private Modell eingegebenen Features gemäß Property 1 ebenfalls DP-konform sein.

Sie können die Inferenzgenauigkeit weiter verbessern, indem Sie Training und Inferenzen 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 versiegelt. In diesem Fall hat auch der Modellinhaber keinen Zugriff auf die Inferenz.
Dies ist das aktuelle Design für die On-Device-Personalisierung.

Nachweislich privat

Die On-Device-Personalisierung soll nachweislich privat sein. Dabei wird geprüft, was auf den Geräten der Nutzenden passiert. Das ODP erstellt den Code, der die Daten verarbeitet, die die Geräte der Endnutzer verlassen, und verwendet die RATS-Architektur (RFC 9334) von NIST, um zu bestätigen, dass dieser Code unverändert auf einem konformen Server ohne Berechtigungen des Instanzadministrators ausgeführt wird, der dem Confidential Computing Consortium entspricht. Diese Codes sind als Open Source verfügbar 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 sich einen Ruf auf der Grundlage einer soliden Grundlage der Datenschutzgarantie etablieren.

Ein weiterer wichtiger Aspekt der On-Device-Personalisierung ist die Reduzierung der Menge an privaten Daten, die erhoben und gespeichert werden. Es hält sich an dieses Prinzip, indem es Technologien wie Federated Compute und Differential Privacy verwendet, die die Offenlegung wertvoller Datenmuster ermöglichen, ohne vertrauliche individuelle 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. Dies ermöglicht die Erstellung von Prüfberichten und die Identifizierung von Sicherheitslücken, die zeigen, wie sehr wir uns dem Datenschutz verpflichtet haben.

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

Das folgende Diagramm zeigt den Codepfad für geräteübergreifende Aggregation und Rauschen gemäß Differential Privacy.

Struktur des Federated Compute-Dienstes, der sowohl föderiertes Lernen als auch Federated Analytics verarbeitet. Unverschlüsselte, nicht verrauschte Daten werden nur auf dem Gerät verarbeitet (rote Linie). Die Verarbeitungsergebnisse werden sowohl bei der Übertragung als auch bei Inaktivität (blaugrüne Linien) verschlüsselt hochgeladen. Nur von der On-Device-Personalisierung erstellte, geräteübergreifende Open-Source-Aggregation und rauschende Arbeitslasten haben nach erfolgreicher Attestierung durch mehrere Koordinatoren Zugriff auf das unverschlüsselte unbearbeitete Geräteergebnis. Nachdem Rauschen gemäß Differential Privacy-Mechanismen richtig angewendet wurde, können alle nachgelagerten Datenflüsse innerhalb der vertrauenswürdigen Ausführungsumgebung entschlüsselt werden (die orangefarbenen Linien).

Übergeordnetes Design

Wie kann Datenschutz durch die Vertraulichkeit implementiert werden? Grundsätzlich dient eine von ODP erstellte Richtlinien-Engine, die in einer versiegelten Umgebung ausgeführt wird, als Kernkomponente, die jeden Knoten/Teilgraphen überwacht und den DP-Status seiner Eingaben und Ausgaben verfolgt:

• Aus Sicht der Richtlinien-Engine werden Geräte und Server gleich behandelt. Geräte und Server, auf denen die identische Richtlinien-Engine ausgeführt wird, werden als logisch identisch erachtet, sobald ihre Richtlinien-Engines gegenseitig attestiert wurden.
• Auf Geräten wird die Isolation durch AOSP-isolierte Prozesse (oder langfristig pKVM bei hoher Verfügbarkeit) erreicht. Auf Servern beruht die Isolation auf einer „vertrauenswürdigen Partei“, die entweder ein TEE und andere technische Abdichtlösungen, die bevorzugt werden, eine vertragliche Vereinbarung oder beides ist.

Mit anderen Worten: Alle abgeschirmten Umgebungen, die die Plattformrichtlinien-Engine installieren und ausführen, gelten als Teil unserer Trusted Computing Base (TCB). Daten können mit dem TCB ohne zusätzliche Rauschen weitergegeben werden. Die Datenverarbeitung muss angewendet werden, wenn Daten aus dem TCB entfernt werden.

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

• Architektur mit gekoppelten Prozessen zum Ausführen der Geschäftslogik
• Richtlinien und eine Richtlinien-Engine zum Verwalten eingehender und ausgehender Daten sowie zulässiger Vorgänge

Dieses kohärente Design bietet Unternehmen gleiche Bedingungen, in denen sie ihren proprietären Code in einer vertrauenswürdigen Ausführungsumgebung ausführen und auf Nutzerdaten zugreifen können, die entsprechende Richtlinienprüfungen bestanden haben.

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

Architektur mit gekoppelten Prozessen zum Ausführen der Geschäftslogik

Die On-Device-Personalisierung führt in AOSP eine Architektur mit gekoppelten Prozessen ein, um den Datenschutz für Nutzer und die Datensicherheit während der Ausführung der Geschäftslogik zu verbessern. Diese Architektur besteht aus:

• ManagingProcess. Bei diesem Prozess werden IsolatedProcesses erstellt und verwaltet. Dadurch bleiben sie auf Prozessebene isoliert und der Zugriff ist auf APIs auf der Zulassungsliste und ohne Netzwerk- oder Laufwerkberechtigungen beschränkt. Der ManagingProcess verwaltet die Erfassung aller Geschäftsdaten, aller Endnutzerdaten und der Richtlinien, die sie für den Geschäftscode löschen, und überträgt sie zur Ausführung in die IsolatedProcesses. Außerdem vermittelt er die Interaktion zwischen IsolatedProcesses und anderen Prozessen wie system_server.

• IsolatedProcess an. Dieser Prozess ist als isoliert gekennzeichnet (isolatedprocess=true im Manifest) und empfängt Geschäftsdaten, Endnutzerdaten, die anhand von Richtlinien gelöscht wurden, und Geschäftsdaten vom ManagingProcess. Sie ermöglichen dem Business Code, mit seinen Daten und richtlinienkonformen Endnutzerdaten zu arbeiten. Der IsolatedProcess kommuniziert sowohl für eingehenden als auch für ausgehenden Traffic ausschließlich mit dem ManagingProcess ohne zusätzliche Berechtigungen.

Die Architektur mit gekoppelten Prozessen bietet die Möglichkeit zur unabhängigen Überprüfung der Datenschutzrichtlinien für Endnutzer, ohne dass Unternehmen ihre Geschäftslogik oder ihren Code als Open Source veröffentlichen müssen. Da der ManagingProcess die Unabhängigkeit von IsolatedProcesses wahrt und die IsolatedProcesses die Geschäftslogik effizient ausführen, bietet diese Architektur eine sicherere und effizientere Lösung für den Schutz der Privatsphäre der Nutzer während der Personalisierung.

Die folgende Abbildung zeigt diese gepaarte Prozessarchitektur.

Die Entität, die die „Nutzer-App“ erstellt, kann, muss aber nicht dieselbe Entität sein wie die, die das Nutzer-APK im Diagramm erstellt hat. Die Entität, die das „Adopter-APK“ erstellt, ist dieselbe wie die Entität, die den „lokalen Nutzer-Shop“ im Diagramm besitzt.

Richtlinien und Richtlinien-Engines für Datenvorgänge

Durch die On-Device-Personalisierung wird eine Ebene für die Durchsetzung von Richtlinien zwischen der Plattform und der Geschäftslogik eingeführt. Ziel ist es, eine Reihe von Tools bereitzustellen, mit denen Endnutzer- und Geschäftskontrollen zentralisierte und umsetzbare Richtlinienentscheidungen zugeordnet werden können. Diese Richtlinien werden dann umfassend und zuverlässig für alle Abläufe und Unternehmen durchgesetzt.

In der Paar-Prozess-Architektur befindet sich die Richtlinien-Engine im ManagingProcess und überwacht den ein- und ausgehenden von Endnutzer- und Geschäftsdaten. Außerdem werden damit Vorgänge auf der Zulassungsliste für den IsolatedProcess bereitgestellt. Beispiele hierfür sind die Wahrung der Kontrolle durch Endnutzer, der Schutz von Kindern, die Vermeidung der Weitergabe von Daten ohne Einwilligung und der Datenschutz für Unternehmen.

Die Architektur zur Richtlinienerzwingung umfasst drei Arten von Workflows, die genutzt werden können:

• Lokal initiierte Offline-Workflows mit TEE-Kommunikation (Trusted Execution Environment):
  • Abläufe für den Datendownload: Vertrauenswürdige Downloads
  • Abläufe für den Datenupload: vertrauenswürdige Transaktionen
• Lokal initiierte Online-Workflows:
  • Bereitstellungsabläufe in Echtzeit
  • Inferenzflüsse
• Lokal initiierte Offline-Workflows:
  • Optimierungsabläufe: Modelltraining auf dem Gerät über Federated Learning (FL)
  • Berichterstellungsabläufe: über Federated Analytics (FA) implementierte geräteübergreifende Aggregation

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

Die Richtlinien-Engine befindet sich im Zentrum des Designs. Beispiele (nicht vollständig):

• Herunterladen: 1 -> 2 -> 4 -> 7 -> 10 -> 11 -> 3
• Auslieferung: 1 + 3 -> 4 -> 6 -> 9 -> 11 -> 3
• Optimierung: 2 (erstellt Schulungsplan) -> 1 + 3 -> 4 -> 5 -> 8 -> 11 -> 2
• Berichterstellung: 3 (erhält Aggregationsplan) -> 1 + 3 -> 4 -> 5 -> 8 -> 11 -> 2

Insgesamt wird durch die Einführung der Ebene für die Richtlinienerzwingung und der Richtlinien-Engine in der Paar-Prozess-Architektur der On-Device-Personalisierung eine isolierte und datenschutzfreundliche Umgebung für die Ausführung der Geschäftslogik und den kontrollierten Zugriff auf erforderliche Daten und Vorgänge gewährleistet.

Mehrschichtige API-Oberflächen

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

Im Laufe der Zeit werden voraussichtlich weitere APIs der obersten Ebene hinzugefügt. Wenn für einen bestimmten Anwendungsfall keine Top-Layer-API oder vorhandene Top-Layer-APIs nicht flexibel genug sind, können Unternehmen die Mid-Layer-APIs direkt implementieren. Sie bieten Leistung und Flexibilität durch Programmierprimitive.

Fazit

Die On-Device-Personalisierung ist ein Forschungsvorschlag in der Frühphase, um Interesse und Feedback für eine langfristige Lösung zu erbitten, die mit den neuesten und besten Technologien, die voraussichtlich einen hohen Nutzen bringen, dem Datenschutz von Endnutzern gerecht wird.

Wir möchten gern mit Stakeholdern wie Datenschutzexperten, Datenanalysten und potenziellen Endnutzern zusammenarbeiten, um sicherzustellen, dass ODP ihren Anforderungen und Bedenken gerecht wird.