Personalisierung auf dem Gerät – Personalisierung mit erweitertem Datenschutz

In dieser technischen Erläuterung, die für die Implementierung im Open-Source-Projekt für Android (Android Open Source Project, AOSP) vorgesehen ist, werden die Motivation hinter der On-Device Personalization (ODP), die Designprinzipien, die ihre Entwicklung leiten, ihr Datenschutzmodell für Vertraulichkeit und die Art und Weise, wie sie dazu beiträgt, eine nachweislich private Nutzung zu gewährleisten, erläutert.

Wir planen, dies zu erreichen, indem wir das Datenzugriffsmodell vereinfachen und dafür sorgen, dass alle Nutzerdaten, die die Sicherheitsgrenze verlassen, auf Ebene von (Nutzer, Adopter, Modellinstanz) differenziell privat sind (in diesem Dokument manchmal auf Nutzerebene verkürzt).

Der gesamte Code, der sich auf den potenziellen Abfluss von Endnutzerdaten von den Geräten der Endnutzer bezieht, ist Open Source und kann von externen Stellen überprüft werden. In der Anfangsphase unseres Vorschlags möchten wir Interesse wecken und Feedback zu einer Plattform sammeln, die Möglichkeiten zur Personalisierung auf dem Gerät bietet. Wir laden Interessengruppen 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. mithilfe von angemessen anonymisierten und differenziell privaten Machine-Learning-Modellen. Sie können jedoch nicht sehen, welche Anpassungen für einen Endnutzer vorgenommen wurden. Das hängt nicht nur von der vom Geschäftsinhaber generierten Anpassungsregel, sondern auch von den individuellen Einstellungen des Endnutzers ab, es sei denn, es gibt direkte Interaktionen zwischen dem Unternehmen und dem Endnutzer. Wenn ein Unternehmen Machine-Learning-Modelle oder statistische Analysen erstellt, sorgt ODP dafür, dass sie mithilfe der entsprechenden Differential Privacy-Mechanismen ordnungsgemäß anonymisiert werden.

Wir planen, ODP in mehreren Meilensteinen zu untersuchen, die die folgenden Funktionen und Funktionalitäten abdecken. Wir laden Interessierte außerdem ein, konstruktiv zusätzliche Funktionen oder Arbeitsabläufe vorzuschlagen, um diese Untersuchung voranzutreiben:

1. Eine Sandbox-Umgebung, in der die gesamte Geschäftslogik enthalten ist und ausgeführt wird. So können viele Endnutzersignale in die Sandbox gelangen, während die Ausgaben begrenzt werden.

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

   1. Nutzersteuerelemente und andere nutzerbezogene Daten. Diese Daten können von Endnutzern bereitgestellt oder von Unternehmen erhoben und abgeleitet werden. Außerdem können sie über TTL-Einstellungen (Time-to-Live), Löschrichtlinien, Datenschutzrichtlinien usw. verwaltet werden.
   2. Geschäftskonfigurationen. ODP bietet Algorithmen zum Komprimieren oder Verschleiern dieser Daten.
   3. Ergebnisse der geschäftlichen Verarbeitung. Diese Ergebnisse können Folgendes sein:
      1. Sie werden in späteren Verarbeitungsrunden als Eingaben verwendet.
      2. Sie werden mit geeigneten Differential Privacy-Mechanismen mit Rauschen versehen und zu entsprechenden Endpunkten hochgeladen.
      3. Hochgeladen über den vertrauenswürdigen Upload-Ablauf in vertrauenswürdige Ausführungsumgebungen (Trusted Execution Environments, TEEs), in denen Open-Source-Arbeitslasten mit geeigneten zentralen Mechanismen für differenzielle Datenschutz ausgeführt werden
      4. Wird Endnutzern angezeigt.

3. APIs für folgende Zwecke:

   1. Aktualisieren Sie 2(a) im Batch- oder inkrementellen Verfahren.
   2. Aktualisieren Sie 2(b) regelmäßig, entweder im Batch- oder im inkrementellen Verfahren.
   3. Upload 2(c) mit geeigneten Rauschmechanismen in vertrauenswürdigen Aggregationsumgebungen. 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 Betaphase. Die Zeitachse kann sich ändern.

Feature	H1 2025	3. Quartal 2025
Training und Inferenz auf dem Gerät	Wenden Sie sich an das Privacy Sandbox-Team, um mögliche Pilotprojekte für diesen Zeitraum zu besprechen.	Die Einführung auf berechtigten Android T+-Geräten beginnt.

Designprinzipien

ODP soll drei Säulen in Einklang bringen: Datenschutz, Fairness und Nützlichkeit.

Gestapeltes Datenmodell für verbesserten Datenschutz

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

Bei ODP wird die Verarbeitung der Personalisierung auf das Gerät eines Endnutzers verlagert. Bei diesem Ansatz werden Datenschutz und Nützlichkeit in Einklang gebracht, indem 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:

• Endnutzerdaten auf dem Gerät kontrollieren, auch wenn sie das Gerät verlassen. Zielorte müssen attestierte Trusted Execution Environments sein, die von Public-Cloud-Anbietern bereitgestellt werden, auf denen ODP-Code ausgeführt wird.
• Geräteüberprüfbarkeit von Endnutzerdaten, wenn sie das Gerät verlassen. ODP bietet Open-Source-Arbeitslasten für föderiertes Computing, 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 unverändert in vertrauenswürdigen Ausführungsumgebungen ausgeführt werden.
• Garantierter technischer Datenschutz (z. B. Aggregation, Rauschen, Differential Privacy) von Ausgaben, die die vom Gerät kontrollierte/überprüfbare Grenze verlassen.

Die Personalisierung ist daher gerätespezifisch.

Außerdem benötigen Unternehmen Datenschutzmaßnahmen, die von der Plattform berücksichtigt werden sollten. Dazu gehört, dass Rohdaten auf den jeweiligen Servern gespeichert werden. Dazu wird in ODP das folgende Datenmodell verwendet:

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

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

Zum Vergleich: In einer cloudzentrierten Infrastruktur werden alle Rohdaten vom Endnutzerturm auf die Server der Unternehmen übertragen. In einer gerätezentrierten Infrastruktur bleiben alle Rohdaten aus dem Endnutzerturm an ihrem Ursprungsort, während die Daten des Unternehmens auf Servern gespeichert bleiben.

Die On-Device-Personalisierung kombiniert die Vorteile beider Ansätze, indem nur bestätigter Open-Source-Code Daten verarbeiten darf, die möglicherweise mit Endnutzern in Verbindung stehen. Die Verarbeitung erfolgt in TEEs über private Ausgabekanäle.

Inklusive öffentliche Beteiligung für gerechte Lösungen

Das ODP soll für alle Teilnehmer in einem vielfältigen Ökosystem ein ausgewogenes Umfeld 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, die von Entwicklern und den Unternehmen, die sie vertreten, implementiert werden können. Die On-Device-Personalisierung ermöglicht die nahtlose Integration dieser Implementierungen und gleichzeitig die Verwaltung von Releases, Monitoring, Entwicklertools und Feedback-Tools. Die On-Device-Personalisierung erstellt keine konkrete Geschäftslogik, sondern dient als Katalysator für Kreativität.

Im Laufe der Zeit könnten weitere Algorithmen in ODP verfügbar sein. Die Zusammenarbeit mit dem Ökosystem ist unerlässlich, um das richtige Maß an Funktionen zu ermitteln und möglicherweise eine angemessene Obergrenze für Geräteressourcen für jedes teilnehmende Unternehmen festzulegen. Wir hoffen auf Feedback aus dem Ökosystem, damit wir neue Anwendungsfälle erkennen und priorisieren können.

Entwicklertools für eine bessere Nutzererfahrung

Bei ODP gehen keine Ereignisdaten verloren und es kommt zu keinen Beobachtungsverzögerungen, da alle Ereignisse lokal auf Geräteebene erfasst werden. Es gibt keine Fehler beim Beitreten und alle Ereignisse sind einem bestimmten Gerät zugeordnet. Daher bilden alle beobachteten Ereignisse eine chronologische Reihenfolge, die die Interaktionen des Nutzers widerspiegelt.

Durch diesen vereinfachten Prozess müssen Daten nicht mehr zusammengeführt oder neu angeordnet werden. So können Nutzerdaten nahezu in Echtzeit und ohne Datenverlust abgerufen werden. Dies kann wiederum den Nutzen steigern, den Endnutzer bei der Nutzung datengesteuerter Produkte und Dienste wahrnehmen, was möglicherweise zu einer höheren Zufriedenheit und aussagekräftigeren Erfahrungen führt. Mit ODP können Unternehmen sich effektiv an die Bedürfnisse ihrer Nutzer anpassen.

Das Datenschutzmodell: Datenschutz durch Vertraulichkeit

In den folgenden Abschnitten wird das Consumer-Producer-Modell als Grundlage dieser Datenschutzanalyse sowie der Datenschutz der Rechenumgebung im Vergleich zur Ausgabegenauigkeit erläutert.

Verbraucher-Erzeuger-Modell als Grundlage dieser Datenschutzanalyse

Wir werden das Consumer-Producer-Modell verwenden, um die Datenschutzgarantien von 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 Untergraphen besteht. Jeder Berechnungsknoten hat drei Komponenten: verarbeitete Eingaben, erstellte Ausgaben und die Berechnung, die Eingaben in Ausgaben umwandelt.

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

• Datenschutz bei Eingaben: Knoten können zwei Arten von Eingaben haben. Wenn eine Eingabe von einem Vorgängerknoten generiert wird, hat sie bereits die Datenschutzgarantien für die Ausgabe dieses Vorgängers. Andernfalls müssen Eingaben die Richtlinien für den Datenzugriff mithilfe der Richtlinien-Engine erfüllen.
• Datenschutz bei der Ausgabe Die Ausgabe muss möglicherweise anonymisiert werden, z. B. durch Differential Privacy (DP).
• Vertraulichkeit der Rechenumgebung. Die Berechnung muss in einer sicher abgeschirmten Umgebung erfolgen, damit niemand Zugriff auf Zwischenzustände innerhalb eines Knotens hat. Dazu gehören unter anderem Federated Computations (FC), hardwarebasierte Trusted Execution Environments (TEE), Secure Multi-Party Computation (sMPC) und homomorphe Verschlüsselung (HPE). Es ist wichtig zu beachten, dass die Privatsphäre durch Vertraulichkeitsschutzmaßnahmen für Zwischenzustände und alle Ausgaben, die die Vertraulichkeitsgrenze verlassen, weiterhin durch Differential Privacy-Mechanismen geschützt werden muss. Zwei erforderliche Behauptungen sind:
  • Vertraulichkeit von Umgebungen, sodass nur deklarierte Ausgaben die Umgebung verlassen, und
  • Fundiertheit, die genaue Ableitungen von Behauptungen zur Ausgabeprivatsphäre aus Behauptungen zur Eingabeprivatsphäre ermöglicht. Die Fundiertheit ermöglicht die Weitergabe von Datenschutzattributen in einem DAG.

Ein privates System schützt die Privatsphäre der Eingaben, die Vertraulichkeit der Rechenumgebung und die Privatsphäre der Ausgaben. Die Anzahl der Anwendungen von Differential Privacy-Mechanismen kann jedoch verringert werden, indem mehr Verarbeitung in einer vertraulichen Rechenumgebung erfolgt.

Dieses Modell bietet zwei Hauptvorteile. Erstens können die meisten Systeme, ob groß oder klein, als DAG dargestellt werden. Zweitens bieten die Eigenschaften von DP für die Nachbearbeitung [Abschnitt 2.1] und die Zusammensetzung Lemma 2.4 in The Complexity of Differential Privacy leistungsstarke Tools zur Analyse des (Worst-Case-)Datenschutz- und Genauigkeitskompromisses für einen gesamten Graphen:

• Durch die Nachbearbeitung wird sichergestellt, dass eine Menge, die einmal anonymisiert wurde, nicht mehr „anonymisiert“ werden kann, wenn die Originaldaten nicht noch einmal verwendet werden. Solange alle Eingaben für einen Knoten privat sind, ist auch die Ausgabe privat, unabhängig von den Berechnungen.
• Die erweiterte Komposition garantiert, dass der Gesamtgraph DP ist, wenn jeder Graphabschnitt DP ist. Dadurch werden ε und δ der endgültigen Ausgabe eines Graphen effektiv auf etwa ε√κ begrenzt, wobei davon ausgegangen wird, dass ein Graph κ Einheiten hat und die Ausgabe jeder Einheit (ε, δ)-DP ist.

Aus diesen beiden Eigenschaften ergeben sich zwei Designprinzipien für jeden Knoten:

• Property 1 (aus der Nachbearbeitung): Wenn die Eingaben eines Knotens alle DP sind, ist auch die Ausgabe DP. So wird beliebige Geschäftslogik berücksichtigt, die im Knoten ausgeführt wird, und die „Geheimrezepte“ von Unternehmen werden unterstützt.
• Property 2 (From Advanced Composition): Wenn die Eingaben eines Knotens nicht alle DP-konform sind, muss seine Ausgabe DP-konform sein. Wenn ein Rechenknoten in Trusted Execution Environments ausgeführt wird und Open-Source-Arbeitslasten und -Konfigurationen aus On-Device Personalization ausführt, sind strengere DP-Grenzen möglich. Andernfalls müssen für die On-Device-Personalisierung möglicherweise DP-Grenzwerte für den Worst-Case verwendet werden. Aufgrund von Ressourcenbeschränkungen werden Trusted Execution Environments, die von einem Public-Cloud-Anbieter angeboten werden, anfangs priorisiert.

Datenschutz der Rechenumgebung im Vergleich zur Genauigkeit der Ausgabe

Ab sofort konzentriert sich die On-Device-Personalisierung darauf, die Sicherheit vertraulicher Rechenumgebungen zu verbessern und dafür zu sorgen, dass Zwischenzustände nicht zugänglich bleiben. Dieser als „Sealing“ bezeichnete Sicherheitsprozess wird auf der Ebene des Untergraphen angewendet, sodass mehrere Knoten gemeinsam datenschutzkonform gemacht werden können. Das bedeutet, dass die oben erwähnten Property 1 und Property 2 auf der Ebene des Teilgraphen gelten.

Durch die Sicherung der Rechenumgebung und die Beseitigung von Möglichkeiten für Angreifer, auf die Ein- und Zwischenzustände eines Diagramms oder Unterdiagramms zuzugreifen, wird die Implementierung von zentraler DP ermöglicht. Das bedeutet, dass die Ausgabe einer versiegelten Umgebung DP-konform ist, was die Genauigkeit im Vergleich zur lokalen DP verbessern kann, bei der die einzelnen Eingaben DP-konform sind. Dieses Prinzip liegt der Betrachtung von FC, TEEs, sMPCs und HPEs als Datenschutztechnologien zugrunde. Weitere Informationen finden Sie in Kapitel 10 von The Complexity of Differential Privacy.

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

Nachweislich vertraulich

Die Personalisierung auf dem Gerät soll nachweislich vertraulich sein. Der Fokus liegt auf der Überprüfung von Vorgängen, die nicht auf den Geräten der Nutzer stattfinden. ODP erstellt den Code, der die Daten verarbeitet, die die Geräte der Endnutzer verlassen, und verwendet die RFC 9334 RATS-Architektur (Remote ATtestation procedureS) des NIST, um zu bestätigen, dass dieser Code unverändert auf einem Server ausgeführt wird, der dem Confidential Computing Consortium entspricht und auf dem die Instanzadministratorrechte entfernt wurden. Diese Codes werden als Open Source veröffentlicht und sind für eine transparente Überprüfung zugänglich, um Vertrauen aufzubauen. Solche Maßnahmen können Einzelpersonen das Vertrauen geben, dass ihre Daten geschützt sind, und Unternehmen können sich einen guten Ruf aufbauen, der auf einer soliden Grundlage für den Datenschutz beruht.

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 Federated Compute und Differential Privacy eingehalten. So können wertvolle Datenmuster aufgedeckt werden, ohne sensible 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 nachweisbaren Datenschutzes. So können Prüfberichte erstellt und Sicherheitslücken identifiziert werden. Das unterstreicht unser Engagement für den Datenschutz.

Wir bitten Datenschutzexperten, Behörden, Branchen und Einzelpersonen um konstruktive Zusammenarbeit, damit wir das Design und die Implementierungen kontinuierlich verbessern können.

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

Konzeption

Wie kann Datenschutz durch Vertraulichkeit umgesetzt werden? Im Wesentlichen ist eine von ODP entwickelte Richtlinien-Engine, die in einer versiegelten Umgebung ausgeführt wird, die Kernkomponente, die jeden Knoten/Untergraphen überwacht und den Datenschutzstatus der Ein- 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 isolierte AOSP-Prozesse (oder langfristig durch pKVM, sobald die Verfügbarkeit hoch ist) erreicht. Auf Servern beruht die Isolation auf einer „vertrauenswürdigen Partei“, die entweder ein TEE plus andere technische Versiegelungslösungen (bevorzugt), eine vertragliche Vereinbarung oder beides ist.

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

Das allgemeine Design der On-Device-Personalisierung umfasst zwei wesentliche Elemente:

• Architektur mit gekoppelten Prozessen für die Ausführung der Geschäftslogik
• Richtlinien und eine Richtlinien-Engine zum Verwalten von eingehenden und ausgehenden Daten sowie zulässigen Vorgängen.

Dieses einheitliche Design bietet Unternehmen faire Wettbewerbsbedingungen, da 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.

Paired-Process-Architektur für die Ausführung der Geschäftslogik

Bei der On-Device-Personalisierung wird eine Architektur mit zwei Prozessen in AOSP eingeführt, um den Datenschutz und die Datensicherheit bei der Ausführung der Geschäftslogik zu verbessern. Diese Architektur besteht aus:

• ManagingProcess. Bei diesem Prozess werden IsolatedProcesses erstellt und verwaltet, um sicherzustellen, dass sie auf Prozessebene isoliert bleiben und der Zugriff auf zugelassene APIs beschränkt ist und keine Netzwerk- oder Festplattenberechtigungen vorhanden sind. Der ManagingProcess übernimmt die Erhebung aller Geschäftsdaten und aller Endnutzerdaten und gibt sie für den Geschäftscode frei. Anschließend werden sie zur Ausführung an die IsolatedProcesses weitergeleitet. Außerdem wird die Interaktion zwischen IsolatedProcesses und anderen Prozessen wie system_server vermittelt.

• IsolatedProcess. Dieser Prozess ist als isoliert gekennzeichnet (isolatedprocess=true im Manifest) und empfängt Geschäftsdaten, richtlinienkonforme Endnutzerdaten und Geschäftscode vom ManagingProcess. Sie ermöglichen es dem Unternehmenscode, auf seine Daten und auf richtlinienkonforme Endnutzerdaten zuzugreifen. Der IsolatedProcess kommuniziert sowohl für eingehenden als auch für ausgehenden Traffic ausschließlich mit dem ManagingProcess. Es sind keine zusätzlichen Berechtigungen erforderlich.

Die Architektur mit zwei 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 zur Verfügung stellen 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 zum Schutz der Privatsphäre der Nutzer bei der Personalisierung.

Die folgende Abbildung zeigt diese Architektur mit gekoppelten Prozessen.

Richtlinien und Richtlinien-Engines für Datenvorgänge

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

In der Architektur mit gekoppelten Prozessen befindet sich die Richtlinien-Engine im ManagingProcess und überwacht den Ein- und Ausgang von Endnutzer- und Geschäftsdaten. Außerdem werden zulässige Vorgänge für den IsolatedProcess bereitgestellt. Beispiele für abgedeckte Bereiche sind die Einhaltung der Endnutzerkontrolle, der Kinderschutz, die Verhinderung der Weitergabe von Daten ohne Einwilligung und der Datenschutz für Unternehmen.

Diese Architektur zur Richtliniendurchsetzung umfasst drei Arten von Workflows, die genutzt werden können:

• Lokal initiierte Offline-Arbeitsabläufe mit Kommunikation über die vertrauenswürdige Ausführungsumgebung (Trusted Execution Environment, TEE):
  • Daten-Download-Abläufe: vertrauenswürdige Downloads
  • Abläufe zum Hochladen von Daten: vertrauenswürdige Transaktionen
• Lokal initiierte Online-Workflows:
  • Echtzeit-Bereitstellungsabläufe
  • Inferenzabläufe
• 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 der Perspektive von Richtlinien und Richtlinien-Engines.

Insgesamt sorgt die Einführung der Richtliniendurchsetzungsebene und der Richtlinien-Engine in der Architektur mit zwei Prozessen von On-Device Personalization für eine isolierte und datenschutzfreundliche Umgebung für die Ausführung von Geschäftslogik und bietet gleichzeitig kontrollierten Zugriff auf erforderliche Daten und Vorgänge.

Mehrschichtige API-Oberflächen

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

Im Laufe der Zeit werden wir voraussichtlich weitere Top-Layer-APIs hinzufügen. Wenn eine Top-Layer-API für einen bestimmten Anwendungsfall nicht verfügbar ist oder wenn vorhandene Top-Layer-APIs nicht flexibel genug sind, können Unternehmen die Mid-Layer-APIs direkt implementieren. Diese bieten Leistung und Flexibilität durch Programmierprimitive.

Fazit

Die On-Device-Personalisierung ist ein Vorschlag für eine Forschungsstudie in der Anfangsphase, mit dem wir Interesse und Feedback zu einer langfristigen Lösung einholen möchten, die die Datenschutzbedenken der Endnutzer mit den neuesten und besten Technologien berücksichtigt, 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 berücksichtigt.