Personalisierung auf dem Gerät – Personalisierung mit erweitertem Datenschutz

Diese technische Erläuterung, die für die Implementierung im Android Open Source Project (AOSP) vorgesehen ist, befasst sich mit den Gründen für die On-Device-Personalisierung (ODP), den Designprinzipien, die bei der Entwicklung zugrunde liegen, dem Datenschutz durch das Vertraulichkeitsmodell und wie sie zu einer nachweislich privaten Nutzung beiträgt.

Wir möchten dies erreichen, indem wir das Datenzugriffsmodell vereinfachen und dafür sorgen, dass alle Nutzerdaten, die die Sicherheitsgrenze überschreiten, auf Nutzer-, Nutzer-Adopter- und Modellinstanzebene (in diesem Dokument manchmal zu Nutzerebene verkürzt) differenzenziell geschützt sind.

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 ein, sich mit uns auszutauschen.

Vision

Die On-Device-Personalisierung soll die Daten von Endnutzern vor Unternehmen schützen, mit denen sie 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 generiert 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 zu berücksichtigen: Wir laden interessierte Personen auch ein, konstruktiv zusätzliche Funktionen oder Workflows vorzuschlagen, um diese Erkundung voranzutreiben:

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

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

   1. Nutzereinstellungen und andere nutzerbezogene Daten Dazu gehören von Endnutzern bereitgestellte oder von Unternehmen erhobene und abgeleitete Daten sowie TTL-Einstellungen (Time to Live), Löschrichtlinien, Datenschutzrichtlinien und mehr.
   2. Unternehmenskonfigurationen ODP bietet Algorithmen zum Komprimieren oder Verschleieren dieser Daten.
   3. Ergebnisse der Geschäftsverarbeitung. Das können folgende Ergebnisse sein:
      1. Sie werden in späteren Verarbeitungsrunden als Eingaben verwendet.
      2. Wird durch entsprechende Differential Privacy-Mechanismen ausgegeben und auf qualifizierte Endpunkte hochgeladen.
      3. Sie werden mit dem vertrauenswürdigen Uploadvorgang in vertrauenswürdige Ausführungsumgebungen (Trusted Execution Environments, TEE) hochgeladen, in denen Open-Source-Arbeitslasten mit geeigneten zentralen Mechanismen zur differenziellen Privatsphäre ausgeführt werden.
      4. Wird Endnutzern angezeigt.

3. APIs für:

   1. Aktualisieren Sie 2(a) per 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 in den nächsten Verarbeitungsrunden zu 2(b) werden.

Zeitachse

Dies ist der aktuelle Plan für das Testen von ODP in der Betaversion. Der Zeitplan kann sich ändern.

Feature	1. Halbjahr 2025	3. Quartal 2025
On-Device-Training und -Inferenz	Wenden Sie sich an das Privacy Sandbox-Team, um mögliche Optionen für ein Pilotprojekt in diesem Zeitraum zu besprechen.	Einführung auf geeigneten Android-Geräten mit T oder höher

Designprinzipien

Das ODP zielt auf drei Säulen ab: Datenschutz, Fairness und Nutzen.

Turm-Datenmodell für verbesserten Datenschutz

ODP folgt dem Prinzip Privacy by Design und wurde so konzipiert, dass der Schutz der Privatsphäre der Endnutzer standardmäßig gewährleistet ist.

Bei ODP wird untersucht, wie die Personalisierungsverarbeitung auf das Gerät eines Endnutzers verschoben wird. Bei diesem Ansatz werden Datenschutz und Nutzen in Einklang gebracht, indem Daten so weit wie möglich auf dem Gerät verbleiben und nur bei Bedarf außerhalb des Geräts verarbeitet werden. ODP konzentriert sich auf:

• Gerätekontrolle über Endnutzerdaten, auch wenn diese das Gerät verlassen. Ziele müssen attestierte Trusted Execution Environments von Anbietern öffentlicher Clouds sein, 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 für föderiertes Computing bereit, um geräteübergreifendes maschinelles Lernen und statistische Analysen für seine Nutzer 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.

Die Personalisierung ist daher gerätespezifisch.

Darüber hinaus benötigen Unternehmen Datenschutzmaßnahmen, die von der Plattform berücksichtigt werden sollten. Dazu müssen Rohdaten auf den 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, was lokales Lernen und Inferenzen ermöglicht.
2. Wir stellen Algorithmen bereit, die die Entscheidungsfindung über mehrere Datenquellen hinweg erleichtern, z. B. das Filtern zwischen zwei unterschiedlichen Datenspeicherorten oder das Training oder die Inferenz über verschiedene Quellen hinweg.

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. ODP fordert Unternehmen auf, die Inhaberschaft dieser Informationen zu behalten, damit nur autorisierte Geschäftspartner darauf zugreifen können.
Der Endnutzer-Tower besteht aus Daten, die vom Endnutzer bereitgestellt werden (z. B. Kontoinformationen und Steuerelemente), erfassten Daten zu 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 die direkten Deklarationen von Nutzern nicht.

Zum Vergleich: In einer cloudbasierten Infrastruktur werden alle Rohdaten aus dem Endnutzer-Tower auf die Server des Unternehmens übertragen. In einer geräteorientierten Infrastruktur verbleiben dagegen alle Rohdaten aus dem Endnutzer-Tower an ihrem Ursprung, während die Daten des Unternehmens weiterhin auf Servern gespeichert werden.

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

Inklusive öffentliche Beteiligung für gleichberechtigte 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 Dienstleistungen 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 eine 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.

Entwickler-Dienstprogramm für eine verbesserte Nutzererfahrung

Bei der ODP-Methode gehen keine Ereignisdaten verloren und es gibt keine Verzögerungen bei der Beobachtung, da alle Ereignisse lokal auf Geräteebene erfasst werden. Es treten keine Fehler beim Beitritt auf und alle Ereignisse sind einem bestimmten Gerät zugeordnet. So bilden alle beobachteten Ereignisse eine natürliche chronologische Abfolge, die die Interaktionen der Nutzer widerspiegelt.

Durch diesen vereinfachten Prozess müssen Daten nicht zusammengeführt oder neu angeordnet werden, sodass Nutzerdaten nahezu in Echtzeit und verlustfrei zugänglich sind. Dies wiederum kann 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 Unternehmen sich effektiv an die Anforderungen ihrer Nutzer anpassen.

Das Datenschutzmodell: Datenschutz durch Vertraulichkeit

In den folgenden Abschnitten wird das Verbraucher-Produzenten-Modell als Grundlage dieser Datenschutzanalyse und der Datenschutz in der Rechenumgebung im Vergleich zur Ausgabegenauigkeit erläutert.

Das Verbraucher-Produzenten-Modell als Grundlage dieser Datenschutzanalyse

Wir verwenden das Modell „Verbraucher-Produzent“, um die Datenschutzgarantien für den Datenschutz durch Vertraulichkeit zu untersuchen. 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 Nutzer-Ersteller-Modell veranschaulicht. Diese Grafik hat zwei Berechnungsknoten. Die Ausführungssequenz ist Node 1 -> Node 2. Knoten 1 wird zuerst ausgeführt. Es werden zwei Eingaben benötigt: Eingabe 1 und Eingabe 2. Knoten 1 erzeugt 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 dieses Diagramms.

In 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, gelten bereits die Datenschutzgarantien für die Ausgabe 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 sie von Differential Privacy (DP) bereitgestellt wird.
• Vertraulichkeit der Verarbeitungsumgebung: Die Berechnung muss in einer sicher abgeschotteten Umgebung erfolgen, damit niemand Zugriff auf Zwischenzustände innerhalb eines Knotens hat. Zu den Technologien, die dies ermöglichen, gehören föderierte Berechnungen (FC), hardwarebasierte Trusted Execution Environments (TEE), sichere Multi-Party-Berechnungen (sMPC) und homomorphe Verschlüsselung (HPE). Dabei ist zu beachten, dass der Datenschutz zwischengeschaltete Staaten und alle Ausgaben, die die Vertraulichkeitsgrenze überschreiten, durch Differential Privacy-Mechanismen geschützt werden muss. Zwei erforderliche Ansprüche sind:
  • Vertraulichkeit von Umgebungen, damit nur deklarierte Ausgaben die Umgebung verlassen, und
  • Verständlichkeit, sodass die ausgegebenen Datenschutzansprüche korrekt von den 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 Eingaben und die Verarbeitungsumgebung sowie den Datenschutz für Ausgaben. Die Anzahl der Anwendungen von Mechanismen der Differential Privacy kann jedoch reduziert werden, indem mehr Verarbeitung in einer vertraulichen Rechenumgebung erfolgt.

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

• Durch die Nachbearbeitung wird sichergestellt, dass eine Quantität, die einmal anonymisiert wurde, nicht mehr de-anonymisiert 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 Endausgabe eines Diagramms effektiv um etwa √β begrenzt, vorausgesetzt, der Graph hat β-Einheiten und die Ausgabe jeder Einheit ist (, DBM)-DP.

Diese beiden Eigenschaften führen zu zwei Designprinzipien für jeden Knoten:

• Eigenschaft 1 (Aus der Nachbearbeitung): Wenn die Eingaben eines Knotens vollständig datensensitiv sind, ist auch seine Ausgabe datensensitiv. Dies ermöglicht die Ausführung beliebiger Geschäftslogik im Knoten und unterstützt die „Geheimrezepte“ von Unternehmen.
• 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 einer vertrauenswürdigen Ausführungsumgebung ausgeführt wird und Open-Source-Arbeitslasten und ‑konfigurationen von On-Device-Personalisierungen ausführt, sind engere DP-Grenzwerte möglich. Andernfalls müssen für die On-Device-Personalisierung möglicherweise die Worst-Case-DP-Grenzwerte verwendet werden. Aufgrund von Ressourceneinschränkungen werden Trusted Execution Environments, die von einem Public-Cloud-Anbieter angeboten werden, zuerst priorisiert.

Datenschutz bei der Computing-Umgebung vs. Ausgabegenauigkeit

Künftig liegt der Schwerpunkt der On-Device-Personalisierung auf der Verbesserung der Sicherheit vertraulicher Rechenumgebungen und darauf, dass Zwischenzustände nicht zugänglich sind. Dieser Sicherheitsvorgang, der als Versiegelung bezeichnet wird, wird auf Subgraphebene angewendet. So können mehrere Knoten gleichzeitig DP-konform gemacht werden. 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 zum lokalen Datenverarbeitungsprogramm verbessern kann (d. h., die einzelnen Eingaben sind DP-konform). Dieses Prinzip liegt der Einstufung von FC, TEEs, sMPCs und HPEs als Datenschutztechnologien zugrunde. Siehe Kapitel 10 in The Complexity of Differential Privacy.

Ein gutes, praktisches Beispiel sind Modelltraining und Inferenz. In den folgenden Erläuterungen wird davon ausgegangen, dass (1) die Trainingspopulation und die Inferenzpopulation sich überschneiden und (2) sowohl Merkmale als auch Labels personenbezogene 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 Funktionen -> private Inferenz.
Bei der On-Device-Personalisierung kann lokale datenschutzfreundliche Datenverarbeitung 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 Funktionen 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 Genauigkeit der Inferenz weiter verbessern, indem Sie das Training und die Inferenz 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.
Das ist das aktuelle Design für die On-Device-Personalisierung.

Nachweislich vertraulich

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. Durch solche Maßnahmen können Einzelpersonen darauf vertrauen, dass ihre Daten geschützt sind, und Unternehmen können sich einen Ruf auf der Grundlage einer soliden Datenschutzgrundlage etablieren.

Ein weiterer wichtiger Aspekt der On-Device-Personalisierung ist die Reduzierung der Menge an privaten Daten, die erhoben und gespeichert werden. Dieses Prinzip wird durch die Verwendung von Technologien wie föderiertem Computing und Differential Privacy eingehalten. So können wertvolle Datenmuster ermittelt werden, ohne dass sensible Details oder personenidentifizierbare Informationen offengelegt werden.

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 möchten mit Datenschutzexperten, Behörden, Branchen und Einzelpersonen konstruktiv zusammenarbeiten, um das Design und die Implementierung kontinuierlich zu verbessern.

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

Struktur des Federated Compute-Dienstes, der sowohl föderiertes Lernen als auch föderierte Analysen verarbeitet. Nicht verschlüsselte, nicht gefilterte Daten werden nur auf dem Gerät verarbeitet (rote Linie). Die Verarbeitungsergebnisse werden verschlüsselt hochgeladen, sowohl während der Übertragung als auch im Ruhezustand (hellgrüne Linien). 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).

Grobkonzept

Wie kann der Datenschutz durch Vertraulichkeit gewährleistet werden? Im Großen und Ganzen dient eine von ODP erstellte Richtlinien-Engine, die in einer abgeschotteten Umgebung ausgeführt wird, als Kernkomponente, die jeden Knoten/Subgraphen überwacht und gleichzeitig 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 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 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). Mit dem TCB können Daten ohne zusätzliches Rauschen übertragen werden. Die Datenverarbeitung muss angewendet werden, wenn Daten nicht mehr im TCB enthalten sind.

Das allgemeine Design der On-Device-Personalisierung integriert zwei wichtige Elemente:

• Eine Architektur mit zwei Prozessen für die Ausführung 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.

Paarprozessarchitektur für die Ausführung 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. Dabei werden IsolatedProcesses erstellt und verwaltet, die auf Prozessebene isoliert bleiben. Der Zugriff ist auf APIs auf der Zulassungsliste beschränkt und es gibt keine Netzwerk- oder Laufwerkberechtigungen. Der ManagingProcess kümmert sich um die Erhebung aller Geschäftsdaten und Endnutzerdaten und prüft, ob sie für den Geschäftscode zulässig sind. Anschließend werden sie zur Ausführung an die IsolatedProcesses übergeben. Außerdem vermittelt es die Interaktion zwischen IsolatedProcesses und anderen Prozessen wie system_server.

• IsolatedProcess. 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 es dem Geschäftscode, mit seinen Daten und den gemäß den Richtlinien freigegebenen Endnutzerdaten zu arbeiten. Der IsolatedProcess kommuniziert sowohl für den Eingang als auch für den Ausgang ausschließlich mit dem ManagingProcess, ohne zusätzliche Berechtigungen.

Die Architektur mit gekoppelten Prozessen bietet die Möglichkeit zur unabhängigen Überprüfung von 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 aufrechterhält und die IsolatedProcesses die Geschäftslogik effizient ausführen, bietet diese Architektur eine sicherere und effizientere Lösung zur Wahrung des Datenschutzes für 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. Das Rechtssubjekt, das die „Adopter-APK“ erstellt, ist dasselbe wie das Rechtssubjekt, dem der „Adopter Local Store“ in der Grafik gehört.

Richtlinien und Richtlinien-Engines für Datenvorgänge

Die On-Device-Personalisierung führt eine Richtliniendurchsetzungsebene zwischen der Plattform und der Geschäftslogik ein. Ziel ist es, eine Reihe von Tools bereitzustellen, mit denen Endnutzer- und Geschäftssteuerungen in zentralisierte und umsetzbare Richtlinienentscheidungen abgebildet werden. Diese Richtlinien werden dann umfassend und zuverlässig auf alle Abläufe und Unternehmen angewendet.

Bei der Architektur mit gekoppelten Prozessen befindet sich die Richtlinien-Engine im ManagingProcess, der den Datenfluss von Endnutzer- und Geschäftsdaten überwacht. Außerdem werden dem IsolatedProcess Vorgänge aus der Zulassungsliste zur Verfügung gestellt. 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):
  • Datendownload-Abläufe: vertrauenswürdige Downloads
  • Datenupload-Abläufe: vertrauenswürdige Transaktionen
• Lokal initiierte Online-Workflows:
  • Bereitstellungsabläufe in Echtzeit
  • Inferenzflüsse
• Lokal initiierte Offline-Workflows:
  • Optimierungsabläufe: On-Device-Modelltraining, das über Federated Learning (FL) implementiert wird
  • Berichtsabläufe: Geräteübergreifende Aggregation über Federated Analytics (FA)

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

Die Richtlinien-Engine steht im Mittelpunkt des Designs. Beispiele (keine vollständige Liste):

• Download: 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 (Aggregationsplan bereitstellen) -> 1 + 3 -> 4 -> 5 -> 8 -> 11 -> 2

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

Mehrere 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 entwickelt 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 wir voraussichtlich weitere APIs der obersten Schicht hinzufügen. 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 Anfangsphase, mit dem Interesse und Feedback zu einer langfristigen Lösung eingeholt werden soll, die Bedenken der Endnutzer in Bezug auf den Datenschutz mit den neuesten und besten Technologien angeht, die voraussichtlich einen hohen Nutzen bieten.

Wir möchten mit Stakeholdern wie Datenschutzexperten, Datenanalysten und potenziellen Endnutzern zusammenarbeiten, um sicherzustellen, dass ODP ihren Anforderungen entspricht und ihre Bedenken ausräumt.