Personalizacja na urządzeniu – personalizacja z silniejszą ochroną prywatności

Ten poradnik techniczny, który ma być wdrożony w Projekcie Android Open Source (AOSP), omawia motywację stojącą za personalizacją na urządzeniu (ODP), zasady projektowania, które kierują jej rozwojem, ochronę prywatności zapewnianą przez model poufności oraz to, jak pomaga ona zapewnić prywatność, którą można zweryfikować.

Planujemy to osiągnąć, upraszczając model dostępu do danych i zapewniając, że wszystkie dane użytkownika, które opuszczają granicę zabezpieczeń, są chronione na poziomie (użytkownik, użytkownik, instancja modelu) (w tym dokumencie czasem w tym dokumencie skrótowo nazywane poziomem użytkownika).

Cały kod związany z potencjalnym przesyłaniem danych użytkowników z ich urządzeń będzie dostępny na licencji open source i sprawdzalny przez podmioty zewnętrzne. Na wczesnych etapach wdrażania naszej propozycji chcemy wzbudzać zainteresowanie i zbierać opinie na temat platformy, która ułatwia personalizację na urządzeniu. Zapraszamy do współpracy zainteresowane strony, takie jak eksperci ds. prywatności, analitycy danych i specjaliści ds. bezpieczeństwa.

Vision

Personalizacja na urządzeniu ma na celu ochronę informacji użytkowników przed firmami, z którymi nie mieli oni kontaktu. Firmy mogą nadal dostosowywać swoje produkty i usługi do użytkowników (np. za pomocą odpowiednio zanonimizowanych i zabezpieczonych modelami prywatności różnicowej modeli systemów uczących się), ale nie będą mogły zobaczyć dokładnych dostosowań wprowadzonych dla użytkownika (zależy to nie tylko od reguły dostosowywania wygenerowanej przez właściciela firmy, ale też od preferencji użytkownika), chyba że dojdzie do bezpośredniej interakcji między firmą a użytkownikiem. Jeśli firma tworzy modele uczenia maszynowego lub analizy statystyczne, ODP dopilnuje, aby były one odpowiednio anonimizowane za pomocą odpowiednich mechanizmów prywatności różnicowej.

Nasz obecny plan zakłada, że będziemy testować ODP w ramach wielu etapów, obejmujących te funkcje: Zachęcamy też zainteresowane osoby do konstruktywnego sugerowania dodatkowych funkcji lub procesów roboczych, które pomogą nam w dalszym badaniu tego tematu:

  1. Środowisko piaskownicy, w którym cała logika biznesowa jest zawarta i wykonana, co umożliwia wprowadzenie do piaskownicy wielu sygnałów od użytkowników, przy jednoczesnym ograniczeniu wyników.
  2. Magazyny danych w pełni zaszyfrowane:

    1. Ustawienia użytkownika i inne dane związane z użytkownikiem. Dane te mogą być dostarczane przez użytkowników lub zbierane i wywnioskowane przez firmy, a także mogą obejmować ustawienia dotyczące czasu życia (TTL), zasady wymazywania, zasady dotyczące prywatności i inne.
    2. Konfiguracje biznesowe. ODP udostępnia algorytmy do kompresji i zaciemniania tych danych.
    3. Wyniki przetwarzania danych biznesowych. Wyniki mogą być następujące:
      1. wykorzystywane jako dane wejściowe w kolejnych rundach przetwarzania,
      2. Zaszyfrowane zgodnie z odpowiednimi mechanizmami prywatności różnicowej i przesłane do kwalifikujących się punktów końcowych.
      3. Przesłane za pomocą zaufanej procedury przesyłania do zaufanych środowisk wykonawczych (TEE) z obciążeniami typu open source z odpowiednimi centralnymi mechanizmami prywatności różnicowej.
      4. Wyświetlany użytkownikom.
  3. Interfejsy API służące do:

    1. Aktualizacja 2(a), zbiorczo lub stopniowo.
    2. Aktualizuj dane z 2 b okresowo, zbiorczo lub stopniowo.
    3. Przesyłanie 2 c) z odpowiednimi mechanizmami generowania szumu w zaufanych środowiskach agregacji. Takie wyniki mogą stać się 2(b) w kolejnych rundach przetwarzania.

Oś czasu

To jest aktualny plan testowania wersji beta ODP. Harmonogram może ulec zmianie.

Funkcja H1 2025 III kwartał 2025 r.
Szkolenie i wykonywanie wniosków na urządzeniu Skontaktuj się z zespołem Piaskownicy prywatności, aby omówić potencjalne opcje pilotażowe w tym czasie. Rozpoczęcie wdrażania na odpowiednich urządzeniach z Androidem T+.

Zasady projektowania

ODP ma 3 filary, które pozwalają zachować równowagę: prywatność, uczciwość i przydatność.

Model danych typu „wieża” zapewniający lepszą ochronę prywatności

ODP jest zgodny z zasadami prywatności w projektowaniu i domyślnie chroni prywatność użytkowników.

ODP bada możliwość przeniesienia przetwarzania personalizacji na urządzenie użytkownika. Takie podejście zapewnia równowagę między prywatnością a użytecznością, ponieważ dane są przechowywane na urządzeniu w jak największym stopniu, a poza nim przetwarzane tylko w razie potrzeby. ODP koncentruje się na:

  • kontrola urządzenia nad danymi użytkownika, nawet gdy opuści on urządzenie; Miejsca docelowe muszą być poświadczonymi zaufane środowiska wykonania oferowane przez dostawców publicznych usług w chmurze, w których działa kod napisany przez ODP.
  • Możliwość weryfikacji na urządzeniu tego, co dzieje się z danymi użytkownika, gdy opuszczają one urządzenie. ODP udostępnia oparte na federacji obliczenia typu open source, aby koordynować systemy uczące się i analizy statystyczne na wielu urządzeniach. Urządzenie użytkownika będzie potwierdzać, że takie zadania są wykonywane w zaufanym środowisku wykonawczym bez zmian.
  • Gwarantowana prywatność techniczna (np. agregacja, szum, prywatność różnicowa) danych, które opuszczają granicę kontrolowaną przez urządzenie lub weryfikowalną przez urządzenie.

W konsekwencji personalizacja będzie zależeć od urządzenia.

Firmy wymagają też środków ochrony prywatności, które platforma powinna uwzględniać. Oznacza to przechowywanie nieprzetworzonych danych biznesowych na odpowiednich serwerach. Aby to osiągnąć, ODP stosuje ten model danych:

  1. Każde źródło danych nieprzetworzonych będzie przechowywane na urządzeniu lub po stronie serwera, co umożliwi uczenie się i wyciąganie wniosków lokalnie.
  2. Dostarczymy algorytmy ułatwiające podejmowanie decyzji na podstawie wielu źródeł danych, np. filtrowanie między dwoma różnymi lokalizacjami danych lub trenowanie i wyciąganie wniosków z różnych źródeł.

W tym kontekście mogą występować wieże biznesowe i wieże użytkowników końcowych:

Wieża biznesowa i wieża użytkowników
Wieża biznesowa zawiera dane wygenerowane przez firmę przed zastosowaniem personalizacji. ODP prosi firmy o zachowywanie tych informacji, aby mieć pewność, że będą one dostępne tylko dla autoryzowanych partnerów biznesowych.
Wieża użytkownika zawiera dane przekazane przez użytkownika (np. informacje o koncie i ustawienia), zebrane dane dotyczące interakcji użytkownika z urządzeniem oraz dane pochodne (np. zainteresowania i preferencje) wywnioskowane przez firmę. Wywnioskowane dane nie zastępują bezpośrednich deklaracji użytkownika.

Dla porównania w infrastrukturze opartej na chmurze wszystkie dane nieprzetworzone z wieżyny użytkownika końcowego są przenoszone na serwery firmowe. Z kolei w infrastrukturze skoncentrowanej na urządzeniu wszystkie dane nieprzetworzone z wieżych informacji o użytkownikach pozostają w miejscu ich pochodzenia, a dane firmy są przechowywane na serwerach.

Personalizacja na urządzeniu łączy w sobie to, co najlepsze z obu światów, ponieważ umożliwia przetwarzanie danych, które może mieć związek z użytkownikami, tylko za pomocą potwierdzonego kodu open source w ramach TEE z użyciem prywatnych kanałów wyjściowych.

Uwzględnianie opinii publicznej w procesie wypracowania sprawiedliwych rozwiązań

Celem ODP jest zapewnienie zrównoważonego środowiska dla wszystkich uczestników w ramach zróżnicowanego ekosystemu. Zdajemy sobie sprawę, że jest to złożony ekosystem, w którym działają różne podmioty oferujące różne usługi i produkty.

Aby zachęcać do innowacji, ODP udostępnia interfejsy API, które mogą być wdrażane przez programistów i przedstawicieli firm, w których pracują. Personalizacja na urządzeniu ułatwia płynną integrację tych implementacji podczas zarządzania wersjami, monitorowania, narzędzi dla programistów i narzędzi do zbierania opinii. Personalizacja na urządzeniu nie tworzy żadnej konkretnej logiki biznesowej, lecz służy jako katalizator kreatywności.

ODP może z czasem oferować więcej algorytmów. Współpraca z ekosystemem jest niezbędna do określenia odpowiedniego poziomu funkcji i możliwego ustanowienia rozsądnego limitu zasobów urządzeń dla każdej firmy uczestniczącej w programie. Liczymy na opinie z ekosystemu, które pomogą nam rozpoznać nowe przypadki użycia i ustalić ich priorytety.

Narzędzie dla deweloperów poprawiające wrażenia użytkowników

W przypadku ODP nie dochodzi do utraty danych zdarzeń ani opóźnień w obserwacji, ponieważ wszystkie zdarzenia są rejestrowane lokalnie na poziomie urządzenia. Nie ma błędów łączenia, a wszystkie zdarzenia są powiązane z konkretnym urządzeniem. W efekcie wszystkie obserwowane zdarzenia tworzą naturalną chronologiczną sekwencję odzwierciedlającą interakcje użytkownika.

Ten uproszczony proces eliminuje konieczność złączania i przestawiania danych, umożliwiając dostęp do danych użytkowników w czasie zbliżonym do rzeczywistego i bez utraty jakości. Może to zwiększyć użyteczność, jaką użytkownicy końcowi dostrzegają w produktach i usługach opartych na danych, co może przełożyć się na większą satysfakcję i bardziej satysfakcjonujące wrażenia. Dzięki ODP firmy mogą skutecznie dostosowywać się do potrzeb użytkowników.

Model prywatności: prywatność dzięki poufności

W następnych sekcjach omawiamy model konsumenta i producenta jako podstawę tej analizy prywatności oraz ochronę prywatności w środowisku obliczeniowym a dokładność danych wyjściowych.

Model konsumenta i producenta jako podstawa analizy ochrony prywatności

Użyjemy modelu konsument-producent, aby sprawdzić, czy zapewnienia dotyczące prywatności są zgodne z zasadami poufności. Obliczenia w tym modelu są reprezentowane jako węzły w kierowanym, acyklicznym grafu (DAG), który składa się z węzłów i podgrafów. Każdy węzeł obliczeniowy ma 3 elementy: zużyte dane wejściowe, wygenerowane dane wyjściowe i obliczenia mapujące dane wejściowe na dane wyjściowe.

Wykres przedstawiający model konsumenta–producenta.
Wykres przedstawiający model konsumenta-producenta. Ten wykres ma 2 węzły obliczeniowe. Sekwencja wykonania to węzeł 1 -> węzeł 2. Węzeł 1 jest pierwszym, który zostanie wykonany. Funkcja ta wymaga 2 danych wejściowych: danych wejściowych 1 i 2. Węzeł 1 generuje Dane wyjściowe 1. Węzeł 2 wykorzystuje dane wyjściowe węzła 1 i dane wejściowe: dane wejściowe 3. Wynikiem jest Dane wyjściowe 2. Dane wyjściowe 2 są też ostatecznym wynikiem tego wykresu.

W tym modelu ochrona prywatności dotyczy wszystkich 3 komponentów:

  • Prywatność danych wejściowych. Węzły mogą mieć 2 typy wejść. Jeśli dane wejściowe są generowane przez węzeł poprzednik, mają już gwarancje prywatności danych wyjściowych tego węzła. W przeciwnym razie dane muszą spełniać zasady dotyczące wprowadzania danych za pomocą mechanizmu zasad.
  • Prywatność danych wyjściowych. Dane wyjściowe mogą wymagać prywatności, np. zapewnianej przez prywatność różnicową (DP).
  • Poufność środowiska obliczeniowego. Obliczenia muszą być wykonywane w bezpiecznym, hermetycznym środowisku, aby nikt nie miał dostępu do stanów pośrednich w węźle. Dotyczy to m.in. obliczeń federacyjnych, sprzętowego zaufanego środowiska wykonawczego (TEE), bezpiecznych obliczeń wielostronnych (sMPC) i szyfrowania homomorficznego (HPE). Warto zauważyć, że prywatność zapewniana przez zabezpieczenia poufności w stanach pośrednich i wszystkie dane wyjściowe wychodzące poza granicę poufności muszą być chronione przez mechanizmy prywatności różnicowej. Te 2 wymagania dotyczące roszczeń:
    • poufność środowiska, która zapewnia, że z otoczenia wychodzą tylko zadeklarowane dane wyjściowe;
    • poprawność, która umożliwia dokładne wyprowadzanie twierdzeń dotyczących prywatności na wyjściu na podstawie twierdzeń dotyczących prywatności na wejściu; Soundness umożliwia propagowanie właściwości prywatności w DAG.

System prywatny zapewnia prywatność danych wejściowych, poufność środowiska obliczeniowego i prywatność danych wyjściowych. Liczba zastosowań mechanizmów ochrony prywatności różnicowej może jednak zostać zmniejszona przez przeniesienie większej części przetwarzania do środowiska obliczeń poufnych.

Ten model ma 2 główne zalety. Po pierwsze, większość systemów, dużych i małych, może być reprezentowana jako DAG. Po drugie, prywatność różnicowa zapewnia oraz składowe w artykule „Złożoność prywatności różnicowej” lemmaty 2.4, które stanowią skuteczne narzędzia do analizowania (w najgorszym przypadku) kompromisu między prywatnością a dokładnością w przypadku całego grafu:

  • Przetwarzanie wsteczne gwarantuje, że po zanonimizowaniu ilości nie można jej „odzanonimizować”, jeśli pierwotne dane nie zostaną ponownie użyte. Dopóki wszystkie dane wejściowe węzła są prywatne, jego dane wyjściowe są prywatne, niezależnie od obliczeń.
  • Zaawansowana kompozycja gwarantuje, że jeśli każda część wykresu jest DP, to cały wykres również jest DP, co skutecznie ogranicza ε i δ końcowego wyniku wykresu odpowiednio do ε√κ, przy założeniu, że wykres ma κ jednostek, a wynik każdej z nich jest (ε, δ)-DP.

Te 2 właściwości przekładają się na 2 zasady projektowania dla każdego węzła:

  • Właściwość 1 (z post-processingu) – jeśli wszystkie wejścia węzła to DP, jego wyjście to DP, uwzględniając dowolną dowolną logikę biznesową wykonywaną w węźle i wspierającą „tajne składniki” firm.
  • Właściwość 2 (z poziomu złożonej kompozycji) – jeśli wejścia węzła nie są zgodne z DP, jego wyjście musi być zgodne z DP. Jeśli węzeł obliczeniowy działa w zaufanym środowisku wykonawczym i wykonuje konfiguracje oraz zadania dostarczane przez personalizację na urządzeniu w ramach open source, możliwe są ciaśniejsze granice DP. W przeciwnym razie personalizacja na urządzeniu może wymagać użycia najgorszych granic DP. Ze względu na ograniczenia zasobów początkowo priorytet będą miały zaufane środowiska wykonawcze oferowane przez dostawcę chmury publicznej.

Prywatność środowiska obliczeniowego a dokładność danych

Od teraz personalizacja na urządzeniu będzie się koncentrować na zwiększaniu bezpieczeństwa poufnych środowisk przetwarzania danych i zapewnianiu, że stany pośrednie pozostaną niedostępne. Ten proces zabezpieczeń, zwany uszczelnianiem, zostanie zastosowany na poziomie podgrafu, co pozwoli na dostosowanie wielu węzłów do zgodności z DP. Oznacza to, że wspomniane wcześniej właściwości 1właściwość 2 mają zastosowanie na poziomie podgrafu.

Podziel wykres z 7 węzłami na 2 podwykresy i 1 węzeł. W tym przykładzie każdy podgraf ma 3 węzły. Jeśli wykonanie każdego podgrafu jest chronione przed przeciwnikiem, tylko Dane wyjściowe 3 i Dane wyjściowe 6, czyli wyniki podgrafów, muszą być szyfrowane.
Oczywiście dane wyjściowe końcowego grafu, czyli Dane wyjściowe 7, są szyfrowane zgodnie z każdą kompozycją. Oznacza to, że na tym wykresie będą 2 DP. W przypadku braku uszczelnienia będzie ich łącznie 3 (lokalne).

W podstawie chodzi o zabezpieczenie środowiska obliczeniowego i wyeliminowanie możliwości uzyskania przez przeciwników dostępu do danych wejściowych i stanów pośrednich grafu lub podgrafu. Umożliwia to implementację centralnej DP (czyli wyjście z hermetycznego środowiska jest zgodne z DP), co może zwiększyć dokładność w porównaniu z lokalną DP (czyli poszczególne dane wejściowe są zgodne z DP). Ta zasada leży u podstaw rozważania FC, TEE, sMPC i HPE jako technologii ochrony prywatności. Zapoznaj się z rozdziałem 10 książki The Complexity of Differential Privacy (Złożoność prywatności różnicowej).

Dobrym, praktycznym przykładem jest trenowanie i wykonywanie wnioskowania na podstawie modelu. W dalszej części artykułu zakładamy, że (1) populacja treningowa i populacja inferencyjna się na siebie nakłada, (2) zarówno cechy, jak i etykiety stanowią prywatne dane użytkownika. Możemy zastosować DP do wszystkich danych wejściowych:

Personalizacja na urządzeniu może stosować lokalną personalizację do etykiet i funkcji użytkownika przed wysłaniem ich na serwery.
Lokalny DP: funkcje prywatne właściwości 1 i etykiety prywatne -> model prywatny. (property 1) Prywatny model + prywatne funkcje -> prywatne wnioskowanie.
Personalizacja na urządzeniu może stosować lokalny DP do etykiet i funkcji użytkownika przed wysłaniem ich na serwery. Takie podejście nie narzuca żadnych wymagań dotyczących środowiska wykonania serwera ani jego logiki biznesowej.
W tym scenariuszu właściciel modelu może przenieść model do użycia w innym miejscu.
Centralny DP: (właściwość 2) możesz też zastosować DP podczas trenowania modelu, zachowując przy tym dokładność cech i etykietek. W tym scenariuszu właściciel modelu może przenieść model do użycia w innym miejscu. Jednak aby zachować prywatność podczas wnioskowania, cechy wprowadzane do modelu prywatnego muszą być zgodne z zasadami DP zgodnie z właściwością 1.
poprawa dokładności wnioskowania przez uszczelnianie trenowania i wyciągania wniosków;
Dokładność wnioskowania możesz jeszcze bardziej zwiększyć, stosując technikę uszczelniania podczas trenowania i wyodrębniania. Dzięki temu można przekazywać do modelu prywatnego dokładne cechy.
Uszczelnienie końcowego wniosku.
Możesz też zastosować ostateczne zatwierdzenie. W takim przypadku właściciel modelu również nie ma dostępu do wnioskowania.
To jest obecny projekt personalizacji na urządzeniu.

Weryfikowalna prywatność

Personalizacja na urządzeniu ma być weryfikowalnie prywatna. Skupia się na weryfikacji tego, co dzieje się poza urządzeniami użytkowników. ODP napisze kod, który przetwarza dane wychodzące z urządzeń użytkowników końcowych, i użyje specyfikacji NIST 9334 RFC 9334 Remote ATtestation procedureS (RATS) Architecture, aby potwierdzić, że kod ten jest uruchamiany bez modyfikacji na serwerze z ograniczonymi uprawnieniami administratora instancji, który jest zgodny ze specyfikacją Confidential Computing Consortium. Te kody będą dostępne w źródle otwartym i umożliwią przejrzystą weryfikację, aby budować zaufanie. Takie środki mogą zapewnić użytkownikom pewność, że ich dane są chronione, a firmy mogą budować swoją reputację na solidnych podstawach zapewnienia prywatności.

Zmniejszenie ilości zbieranych i przechowywanych danych prywatnych to kolejny kluczowy aspekt personalizacji na urządzeniu. Dotyczy to stosowania technologii takich jak sfederowane przetwarzanie i prywatność różnicowa, które umożliwiają ujawnianie wartościowych wzorców danych bez ujawniania poufnych szczegółów dotyczących poszczególnych osób lub informacji umożliwiających identyfikację.

Prowadzenie ścieżki kontrolnej, która rejestruje działania związane z przetwarzaniem i udostępnianiem danych, to kolejny kluczowy aspekt weryfikowalnej prywatności. Umożliwia to tworzenie raportów kontrolnych i identyfikowanie luk w zabezpieczeniach, co pokazuje nasze zaangażowanie w ochronie prywatności.

Prosimy o konstruktywną współpracę z ekspertami ds. prywatności, organami państwowymi, branżami i osobami prywatnymi, abyśmy mogli stale ulepszać projektowanie i wdrażanie.

Poniższy wykres pokazuje ścieżkę kodu służącą do agregacji danych z różnych urządzeń i dodawania szumu zgodnie z zasadami prywatności różnicowej.

Struktura usługi Federated Compute
Struktura usługi Federated Compute, która obsługuje zarówno sfederowane uczenie się, jak i sfederowane statystyki. Nieszyfrowane dane bez dodania szumu są przetwarzane tylko na urządzeniu (czerwona linia). Wyniki przetwarzania są przesyłane w zaszyfrowanej postaci zarówno podczas przesyłania, jak i przechowywania (linie w kolorze turkusowym). Do nieszyfrowanych danych wyjściowych urządzenia w postaci nieprzetworzonej ma dostęp tylko autoryzowana przez koordynatorów z wielu firm usługa tworzenia spersonalizowanych treści na urządzeniu, która łączy dane z różnych urządzeń i dodaje do nich szum. Po prawidłowym zastosowaniu szumu zgodnie z mechanizmami prywatności różnicowej w środowisku zaufanego wykonywania wszystkie strumienie danych na wyjściu mogą być niezaszyfrowane (linie pomarańczowe).

Projektowanie ogólne

Jak można wdrożyć ochronę prywatności poprzez poufność? Ogólnie mówiąc, silnik zasad opracowany przez ODP, który działa w zamkniętym środowisku, jest głównym komponentem nadzorującym każdy węzeł lub podgraf, a także śledzący stan DP ich wejść i wyjść:

  • Z punktu widzenia mechanizmu zasad urządzenia i serwery są traktowane tak samo. Urządzenia i serwery z identycznym silnikiem zasad są uznawane za logicznie identyczne, gdy ich silniki zasad zostały wzajemnie zweryfikowane.
  • Na urządzeniach izolacja jest osiągana za pomocą procesów izolowanych AOSP (lub pKVM w długim okresie, gdy dostępność jest wysoka). W przypadku serwerów izolacja opiera się na „uczciwej stronie”, która jest albo TEE, albo innymi preferowanymi rozwiązaniami technicznymi, umową lub obydwoma tymi rozwiązaniami.

Innymi słowy, wszystkie hermetyczne środowiska, w których instalowany i uruchamiany jest silnik platformy do obsługi zasad, są uznawane za część naszej Trusted Computing Base (TCB). Dane mogą być propagowane bez dodatkowego szumu dzięki TCB. DP musi być stosowany, gdy dane opuszczają TCB.

Ogólny projekt personalizacji na urządzeniu skutecznie łączy 2 elementy:

  • Architektura z podwójnym procesem do wykonywania logiki biznesowej
  • Zasady i mechanizm zarządzania przepływem danych oraz dozwolonymi operacjami.

Ta spójna architektura zapewnia firmom równe szanse, ponieważ mogą one uruchamiać swój zastrzeżony kod w zaufanym środowisku wykonawczym i mieć dostęp do danych użytkownika, które przeszły odpowiednie kontrole zasad.

W kolejnych sekcjach omówimy te 2 kluczowe aspekty.

Architektura z podwójnym procesem do wykonywania logiki biznesowej

Personalizacja na urządzeniu wprowadza w AOSP architekturę z sparowanymi procesami, aby zwiększyć prywatność użytkowników i bezpieczeństwo danych podczas wykonywania logiki biznesowej. Ta architektura składa się z:

  • ManagingProcess. Ten proces tworzy procesy izolowane i zarządza nimi, zapewniając ich izolację na poziomie procesów z dostępem ograniczonym do interfejsów API na liście dozwolonych oraz bez uprawnień do sieci ani dysku. Proces zarządzający zajmuje się zbieraniem wszystkich danych biznesowych, wszystkich danych użytkownika i zasad, a następnie czyści je dla kodu biznesowego, przesyłając je do procesów izolowanych do wykonania. Ponadto pośredniczy w interakcjach między IsolatedProcesses a innymi procesami, takimi jak system_server.

  • IsolatedProcess. Ten proces jest oznaczony jako odizolowany (isolatedprocess=true w pliku manifestu) i odbiera dane biznesowe, dane użytkownika zatwierdzone przez zasady oraz kod biznesowy od procesu zarządzającego. Umożliwiają one kodom biznesowym korzystanie z danych firmy i danych użytkowników, na które zezwalają zasady. Proces odizolowany komunikuje się wyłącznie z procesem zarządzającym zarówno w przypadku przychodzących, jak i wychodzących połączeń, bez dodatkowych uprawnień.

Architektura z sparowanymi procesami umożliwia niezależną weryfikację zasad prywatności danych użytkowników bez konieczności udostępniania przez firmy ich kodu lub logiki biznesowej. Proces zarządzający zapewnia niezależność procesów izolowanych, a procesy te skutecznie wykonują logikę biznesową. Dzięki temu architektura zapewnia bezpieczniejsze i skuteczniejsze rozwiązanie do ochrony prywatności użytkowników podczas personalizacji.

Na rysunku poniżej widać architekturę pary procesów.

Podmiot, który jest autorem „Adopter App”, może, ale nie musi być tym samym podmiotem, który jest autorem „Adopter apk” na wykresie.
Podmiot, który jest autorem „Aplikacji dla użytkowników”, może, ale nie musi być tym samym podmiotem, który jest autorem „pliku APK dla użytkowników” na wykresie. Entia, która jest autorem „Adopter apk”, jest taka sama jak ta, która jest właścicielem „Adopter Local Store” na diagramie.

Zasady i silniki zasad dotyczące operacji na danych

Personalizacja na urządzeniu wprowadza warstwę egzekwowania zasad między platformą a logiką biznesową. Naszym celem jest udostępnienie zestawu narzędzi, które pozwolą mapować ustawienia użytkownika i firmy na scentralizowane i możliwe do wdrożenia zasady. Te zasady są następnie kompleksowo i skutecznie egzekwowane w przypadku wszystkich procesów i firm.

W architekturze z sparowanymi procesami mechanizm zasad znajduje się w procesie zarządzającym i odpowiada za napływ i wypływ danych użytkowników i firm. Będzie on również dostarczać operacje z dozwolonej listy do IsolatedProcess. Przykładowe obszary objęte ochroną to m.in. przestrzeganie zasad dotyczących kontroli użytkowników, ochrona dzieci, zapobieganie udostępnianiu danych bez zgody oraz prywatność w firmie.

Architektura egzekwowania zasad obejmuje 3 typy przepływów pracy, które można wykorzystać:

  • Lokalnie inicjowane przepływy pracy offline z komunikacją w zaufanym środowisku wykonawczym (TEE):
    • Przepływy pobierania danych: zaufane pliki do pobrania
    • Przesyłanie danych: zaufane transakcje
  • Lokalnie inicjowane przepływy pracy online:
    • Przepływy danych służące do wyświetlania reklam w czasie rzeczywistym
    • Przepływy wnioskowania
  • Lokalnie inicjowane przepływy pracy offline:
    • Procesy optymalizacji: trenowanie modelu na urządzeniu za pomocą uczenia federacyjnego (FL).
    • Sekwencje raportowania: agregacja danych z różnych urządzeń zaimplementowana za pomocą zfederowanych usług Analytics (FA)

Rysunek poniżej przedstawia architekturę z perspektywy zasad i silników zasad.

Silnik zasad znajduje się w centrum projektu.
Mechanizm zasad jest centralnym elementem projektu. Przykłady (niepełna lista):
  • Pobieranie: 1 -> 2 -> 4 -> 7 -> 10 -> 11 -> 3
  • Obsługa: 1 + 3 -> 4 -> 6 -> 9 -> 11 -> 3
  • Optymalizacja: 2 (zawiera plan szkoleniowy) -> 1 + 3 -> 4 -> 5 -> 8 -> 11 -> 2
  • Raportowanie: 3 (zawiera plan agregacji) -> 1 + 3 -> 4 -> 5 -> 8 -> 11 -> 2

Wprowadzenie warstwy egzekwowania zasad i silnika zasad w ramach architektury pary procesów w ramach personalizacji na urządzeniu zapewnia środowisko odizolowane i chroniące prywatność, w którym można wykonywać logikę biznesową, zapewniając jednocześnie kontrolowany dostęp do niezbędnych danych i operacji.

Warstwowe interfejsy API

Personalizacja na urządzeniu udostępnia ustrukturyzowaną architekturę interfejsu API zainteresowanym firmom. Najwyższa warstwa składa się z aplikacji stworzonych do konkretnych zastosowań. Potencjalne firmy mogą łączyć swoje dane z tymi aplikacjami, czyli interfejsami API najwyższego poziomu. Interfejsy API najwyższego poziomu są tworzone na podstawie interfejsów API pośredniego poziomu.

Z czasem planujemy dodawać kolejne interfejsy API najwyższego poziomu. Jeśli interfejs API najwyższego poziomu nie jest dostępny w przypadku konkretnego zastosowania lub jeśli istniejące interfejsy API najwyższego poziomu nie są wystarczająco elastyczne, firmy mogą bezpośrednio wdrażać interfejsy API pośredniego poziomu, które zapewniają moc i elastyczność dzięki prymitywom programowania.

Podsumowanie

Personalizacja na urządzeniu to propozycja badań na wczesnym etapie, która ma na celu zachęcić do zainteresowania się długoterminowym rozwiązaniem i przesłanie opinii na jego temat. Rozwiązanie to ma rozwiązywać problemy związane z prywatnością użytkowników, wykorzystując najnowsze i najlepsze technologie, które mają zapewnić wysoką użyteczność.

Chcemy współpracować z zainteresowanymi podmiotami, takimi jak eksperci ds. prywatności, analitycy danych i potencjalni użytkownicy, aby zapewnić, że ODP spełnia ich potrzeby i rozwiązuje ich wątpliwości.