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

Wyjaśnienie techniczne ma zostać wdrożone w ramach projektu Android Open Source Project (AOSP). Wyjaśnia ono powody stojące za personalizacją na urządzeniu, zasady jej projektowania, zasady ochrony prywatności stosowane w modelu poufności oraz to, w jaki sposób pomaga zapewnić weryfikowalną prywatność.

Planujemy to osiągnąć, upraszczając model dostępu do danych i zapewniając, że wszystkie dane użytkowników, które opuszczają granicę zabezpieczeń, są różnie prywatne na poziomie poszczególnych użytkowników (użytkowników, adeptów, model_instancji) (w tym dokumencie są czasem skracane do poziomu użytkownika).

Cały kod związany z potencjalnym przesyłaniem danych użytkowników na ich urządzeniach będzie dostępny na licencji open source i sprawdzalny przez podmioty zewnętrzne. Na początkowych etapach naszej propozycji zależy nam na wzbudzeniu zainteresowania i zbieraniu opinii na temat platformy, która ułatwia personalizację na urządzeniu. Zapraszamy do współpracy zainteresowane osoby, 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 anonimizowanych i zabezpieczonych modelami prywatności 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.

Obecnie planujemy zbadać ODP w kilku etapach, które obejmują poniższe 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órej 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. W pełni zaszyfrowane magazyny danych dla:

   1. Kontrola użytkowników i inne dane związane z użytkownikiem. Dane te mogą być przekazywane przez użytkowników lub zbierane i uzyskiwane przez firmy wraz z ustawieniami czasu życia danych (TTL), zasadami usuwania danych, polityką prywatności i innymi opcjami.
   2. Konfiguracje firm. ODP udostępnia algorytmy do kompresowania lub zaciemniania tych danych.
   3. Wyniki przetwarzania danych biznesowych. Wyniki mogą być następujące:
      1. są używane jako dane wejściowe w kolejnych etapach przetwarzania;
      2. Zahaszowane zgodnie z odpowiednimi mechanizmami prywatności różnicowej i przesyłane do kwalifikujących się punktów końcowych.
      3. Przesyłanie przy użyciu zaufanego procesu przesyłania do zaufanych środowisk wykonawczych (TEE), w których działają zadania open source, z odpowiednimi centralnymi mechanizmami prywatności różnicowej.
      4. Wyświetlana użytkownikom.

3. Interfejsy API zaprojektowane pod kątem:

   1. Aktualizowanie 2(a) zbiorczo lub przyrostowo.
   2. Aktualizuj dane 2(b) okresowo, zbiorczo lub stopniowo.
   3. Prześlij punkt 2(c) z odpowiednimi mechanizmami szumu w zaufanych środowiskach agregacji. W kolejnych rundach oceny te wyniki mogą mieć stan 2(b).

Oś czasu

To jest bieżący 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 wdrożenia pilotażowego 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 Privacy by Design, a zaprojektowaliśmy je z myślą o ochronie prywatności 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 nad danymi użytkownika na urządzeniu, nawet gdy opuszcza ono urządzenie. Miejsca docelowe muszą mieć akredytowane zaufane środowiska wykonawcze oferowane przez dostawców chmury publicznej, którzy używają kodu opracowanego 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 różnych urządzeniach. Urządzenie użytkownika będzie potwierdzać, że takie zbiory zadań są wykonywane w niezmodyfikowanych zaufanych środowiskach wykonawczych.
• Gwarantowana prywatność techniczna (np. agregacja, szum, prywatność różnicowa) danych, które opuszczają granicę kontrolowaną przez urządzenie lub weryfikowalną przez urządzenie.

Oznacza to, że personalizacja będzie działać na konkretnym urządzeniu.

Firmy wymagają też środków ochrony prywatności, które powinna uwzględniać platforma. Wiąże się to z utrzymywaniem 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 na podstawie różnych źródeł.

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

Business Tower zawiera dane wygenerowane przez firmę przed personalizacją. 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 związane z interakcjami 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 skoncentrowanej na chmurze wszystkie nieprzetworzone dane z wieży użytkowników końcowych są przesyłane na serwery firm. Z kolei w infrastrukturze skoncentrowanej na urządzeniu wszystkie dane źródłowe z wieżych danych użytkownika 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, umożliwiając przetwarzanie danych, które może mieć związek z użytkownikami końcowymi, 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ń

ODP stara się zapewnić zrównoważone środowisko dla wszystkich uczestników 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, które reprezentują. Personalizacja na urządzeniu ułatwia integrację tych implementacji przy zarządzaniu wersjami, monitorowaniem, narzędziami dla programistów i narzędziami do przesyłania 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 całym ekosystemem jest niezbędna do określenia odpowiedniego poziomu funkcji i potencjalnie ustanowienia rozsądnego limitu zasobów urządzeń w przypadku każdej firmy uczestniczącej w programie. Oczekujemy opinii z ekosystemu, aby łatwiej rozpoznawać nowe przypadki użycia i nadawać im priorytety.

Narzędzie dla programistów zwiększające wygodę użytkowników

W przypadku ODP nie dochodzi do utraty danych o zdarzeniach ani opóźnień w obserwacji, ponieważ wszystkie zdarzenia są rejestrowane lokalnie na poziomie urządzenia. Nie występują żadne błędy dołączania, a wszystkie zdarzenia są powiązane z konkretnym urządzeniem. W efekcie wszystkie zaobserwowane zdarzenia w naturalny sposób tworzą sekwencję chronologiczną, która odzwierciedla 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. To z kolei może zwiększyć użyteczność postrzeganą przez użytkowników podczas korzystania z produktów i usług opartych na danych, co potencjalnie może prowadzić do wzrostu zadowolenia i wartościowych doświadczeń. Dzięki ODP firmy mogą skutecznie dostosowywać się do potrzeb użytkowników.

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

W poniższych sekcjach omawiamy model konsument-producenta, który stanowi podstawę tej analizy prywatności, oraz porównanie prywatności w środowisku obliczeniowym z dokładnością 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 na ukierunkowanym grafie acyklicznym (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 ilustrujący model konsument-producent. Ten wykres ma 2 węzły obliczeniowe. Sekwencja wykonania to Węzeł 1 -> Węzeł 2. Węzeł 1 uruchamia się jako pierwszy. Używa 2 pierwotnych danych wejściowych: danych wejściowych 1 i 2. Węzeł 1 generuje dane wyjściowe 1. Węzeł 2 pobiera dane wyjściowe węzła 1 i początkowe dane wejściowe: dane wejściowe 3. Generuje wyjście 2. Dane wyjściowe 2 są też ostatecznym wynikiem tego wykresu.

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

• Prywatność wejściowa. Węzły mogą mieć 2 typy wejść. Jeśli dane wejściowe są generowane przez węzeł poprzedni, mają już gwarancje prywatności wyjściowej danych tego poprzednika. W przeciwnym razie dane wejściowe muszą czyścić zasady ruchu przychodzącego za pomocą mechanizmu zasad.
• Prywatność danych wyjściowych Być może dane wyjściowe trzeba prywatyzować, np. w ramach ochrony prywatności różnicowej (DP).
• Poufność środowiska obliczeniowego. Obliczanie musi odbywać się w bezpiecznie zabezpieczonym środowisku, które uniemożliwia innym dostęp do stanów pośrednich w węźle. Technologie, które to umożliwiają, to m.in. sfederowane obliczenia (FC), sprzętowe zaufane środowiska wykonawcze (TEE), bezpieczne przetwarzanie wielostronne (sMPC) i szyfrowanie homomorficzne (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ść środowisk, dzięki czemu tylko zadeklarowane dane wyjściowe
  • rzetelność, która umożliwia dokładne odliczenie wygenerowanych roszczeń dotyczących prywatności z wejściowych roszczeń dotyczących prywatności. 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, zarówno dużych, jak i małych, można przedstawić jako DAG-i. Po drugie: materiały i kompozycja po przetwarzaniu [Sekcja 2.1] Lemma 2.4 w artykule „Złożoność prywatności różnicowej umożliwiają zaawansowane narzędzia do analizowania równowagi między prywatnością a dokładnością na całym wykresie:

• 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 dwie właściwości przekładają się na dwie 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 zaufanych środowiskach wykonawczych i wykonuje zadania i konfiguracje na licencji open source dostarczane przez personalizację na urządzeniu, możliwe są węższe 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 wyjściowych

Od tej pory personalizacja na urządzeniu będzie koncentrować się na zwiększaniu bezpieczeństwa poufnych środowisk obliczeniowych i zapewnieniu niedostępności stanów pośrednich. 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 1 i właściwość 2 mają zastosowanie na poziomie podgrafu.

Podzielanie grafu o 7 węzłach na 2 podgrafy 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 przeciwnikami, tylko Dane wyjściowe 3 i Dane wyjściowe 6 muszą zostać ujęte w podgrafy.
Oczywiście końcowy wynik wykresu, Dane wyjściowe 7, podlega podziałowi DP na poszczególne kompozycje. Oznacza to, że na tym wykresie będą 2 DP, w porównaniu z 3 (lokalnymi) DP, jeśli nie zastosowano uszczelniania.

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 Złożoności prywatności różnicowej.

Dobrym, praktycznym przykładem jest trenowanie i wykorzystywanie modelu. W dyskusjach poniżej przyjęto, że (1) populacja trenowana i populacja wnioskowania nakładają się na siebie oraz (2) obie funkcje i etykiety stanowią prywatne dane użytkownika. Możemy zastosować DP do wszystkich danych wejściowych:

Lokalny DP: funkcje prywatne usługa 1 + etykiety prywatne -> model prywatny. (usługa 1) Model prywatny + funkcje prywatne -> wnioskowanie prywatne.
Personalizacja na urządzeniu może zastosować lokalny DP do etykiet i funkcji użytkownika przed wysłaniem ich na serwery. Takie podejście nie nakłada żadnych wymagań dotyczących środowiska wykonawczego serwera ani jego logiki biznesowej.

Centralny DP: (właściwość 2) możesz też zastosować DP podczas trenowania modelu, zachowując przy tym dokładność cech i etykietek. W takiej sytuacji właściciel modelu może przenieść model do wnioskowania w innym miejscu. Aby jednak zachować prywatność podczas wnioskowania, funkcje wprowadzane do modelu prywatnego muszą być też zgodne z DP zgodnie z usługą 1.

Możesz jeszcze bardziej poprawić dokładność wnioskowania, uszczelniając trenowanie i wnioskowanie. Dzięki temu możesz przekazywać precyzyjne funkcje do modelu prywatnego.

Możesz też zastosować ostateczne zatwierdzenie. W tym przypadku właściciel modelu też nie ma dostępu do wnioskowania.
To obecny projekt personalizacji na urządzeniu.

Weryfikowalna prywatność

Personalizacja na urządzeniu z myślą o weryfikowaniu prywatności. Skupia się on na sprawdzeniu, co dzieje się poza urządzeniami użytkownika. ODP utworzy kod, który przetwarza dane opuszczające urządzenia użytkowników, i użyje architektury zdalnej ATtestation (RATS) RFC 9334 firmy NIST, aby potwierdzić, że taki kod działa bez zmian na zgodnym z konsorcjum Confidential Computing serwerze z cofniętym uprawnieniem administratora instancji. Te kody będą dostępne jako oprogramowanie open source i umożliwią przejrzystą weryfikację, co pozwoli 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. Jest zgodna z tą zasadą, wdrażając technologie takie jak sfederowane obliczenia obliczeniowe i prywatność różnicowa (prywatność różnicowa), które umożliwiają ujawnianie cennych wzorców danych bez ujawniania poufnych danych osobowych 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. Dzięki temu możemy tworzyć raporty kontrolne i identyfikować luki w zabezpieczeniach, co odzwierciedla nasze zaangażowanie w ochronę prywatności.

Prosimy o konstruktywną współpracę ekspertów ds. prywatności, organów władzy, branż i osób z branży, co pomoże nam stale ulepszać projekty i implementacje.

Wykres poniżej pokazuje ścieżkę kodu do agregacji danych z różnych urządzeń i dodawania szumu zgodnie z zasadami prywatności różnicowej.

Struktura usługi Federated Compute, która obsługuje zarówno sfederowane uczenie się, jak i sfederowane statystyki. Niezaszyfrowane, niezakłócone dane są przetwarzane tylko na urządzeniu (czerwona linia). Wyniki przetwarzania są przesyłane zaszyfrowane zarówno podczas przesyłania, jak i spoczynku (niebieskie linie). Do niezaszyfrowanego nieprzetworzonego wyniku urządzenia po zatwierdzeniu atestu przez wielu koordynatorów dostęp jest dostępny tylko z autoryzowaną personalizacją na urządzeniu, udostępnianą na zasadach open source agregację danych na różnych urządzeniach i zadaniach szumu. 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 wysokiego poziomu

Jak można wdrożyć ochronę prywatności przez poufność? Ogólnie rzecz biorąc, utworzony przez ODP silnik zasad, który działa w szczelnie zabezpieczonym środowisku, jest podstawowym komponentem nadzorującym każdy węzeł/podgraf, jednocześnie śledząc stan DP jego danych wejściowych i wyjściowych:

• Z punktu widzenia mechanizmu zasad urządzenia i serwery są traktowane tak samo. Urządzenia i serwery z identycznym mechanizmem zasad są uważane logicznie za identyczne po tym, jak ich silniki zasad zostały wzajemnie poświadczone.
• Na urządzeniach izolacja jest osiągana za pomocą procesów izolowanych od AOSP (w dłuższej perspektywie pKVM, gdy dostępność jest wysoka). W przypadku serwerów odizolowanie wymaga od „zaufanej strony”, czyli rozwiązania TEE i innych preferowanych rozwiązań technicznych, umowy umownej lub obu tych rozwiązań.

Oznacza to, że wszystkie zamknięte środowiska, które instalują i uruchamiają silnik zasad platformy, są uważane za część naszej platformy Trusted Computing Base (TCB). Dane mogą być propagowane bez dodatkowego szumu dzięki TCB. Należy zastosować DP, gdy dane opuszczają TCB.

Ogólne ustawienia personalizacji na urządzeniu łączą w sobie 2 ważne elementy:

• Architektura sparowanego procesu do wykonywania logiki biznesowej
• Zasady i silnik zasad do zarządzania danymi przychodzącymi, wychodzącymi i dozwolonych operacji.

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 parami procesów, aby zwiększyć prywatność użytkowników i bezpieczeństwo danych podczas wykonywania logiki biznesowej. Ta architektura składa się z:

• Proces zarządzania. Ten proces tworzy procesy izolowane i zarządza nimi, zapewniając ich izolację na poziomie procesu z dostępem ograniczonym do interfejsów API na liście dozwolonych oraz bez uprawnień sieciowych ani dyskowych. Proces zarządzania zbiera wszystkie dane biznesowe, dane użytkowników i zasady, czyszczą je pod kątem kodu biznesowego, a następnie przekazuje je do procesu IsolatedProcesses w celu wykonania. Ponadto pośredniczy w interakcjach między IsolatedProcesses a innymi procesami, takimi jak system_server.

• IsolatedProcess. Ten proces jest oznaczony jako izolowany (w pliku manifestu: isolatedprocess=true) i otrzymuje firmowe dane, oczyszczone z zasad dane użytkowników oraz kod biznesowy z ManagingProcess. Umożliwiają kodowi biznesowemu operowanie na danych i danych użytkowników oczyszczonych z zasad. W przypadku ruchu przychodzącego i wychodzącego metoda IsolatedProcess komunikuje się wyłącznie z ManagingProcess, bez żadnych dodatkowych uprawnień.

Architektura połączonych procesów umożliwia niezależną weryfikację polityki prywatności danych użytkowników bez konieczności udostępniania na licencji open source logiki lub kodu biznesowego. Dzięki utrzymaniu niezależności procesu IsolatedProcess i efektywnemu wykonywaniu logiki biznesowej przez ManagingProcess, która pozwala zachować prywatność użytkowników podczas personalizacji,

Poniższy rysunek przedstawia tę architekturę połączonych procesów.

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ą. Celem jest udostępnienie zestawu narzędzi do mapowania ustawień użytkownika i firmy na scentralizowane, praktyczne decyzje dotyczące zasad. Zasady te są potem kompleksowo i skutecznie egzekwowane w różnych procesach i firmach.

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. Dostarczy również operacje z listy dozwolonych do IsolatedProcess. Przykładowe obszary obejmują ochronę użytkowników, ochronę dzieci, zapobieganie udostępnianiu danych osobom, które nie wyraziły na to 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):
  • Procesy pobierania danych: zaufane pobieranie
  • Procesy przesyłania danych: zaufane transakcje
• Przepływy pracy online inicjowane lokalnie:
  • Procesy wyświetlania reklam w czasie rzeczywistym
  • Przepływy wnioskowania
• Przepływy pracy inicjowane lokalnie:
  • Procesy optymalizacji: trenowanie modelu na urządzeniu za pomocą uczenia federacyjnego (FL).
  • Sekwencje raportowania: agregacja danych na różnych urządzeniach zaimplementowana za pomocą zfederowanych usług Analytics (FA)

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

Mechanizm zasad znajduje się w podstawach projektu. Przykłady (niepełna lista):

• Pobieranie: 1 -> 2 -> 4 -> 7 -> 10 -> 11 -> 3
• Wyświetlanie: 1 + 3 -> 4 -> 6 -> 9 -> 11 -> 3
• Optymalizacja: 2 (zawiera plan treningowy) -> 1 + 3 -> 4 -> 5 -> 8 -> 11 -> 2
• Raportowanie: 3 (obejmuje plan agregacji) -> 1 + 3 -> 4 -> 5 -> 8 -> 11 -> 2

Ogólnie rzecz biorąc, wprowadzenie warstwy egzekwowania zasad i mechanizmu zasad w architekturze sparowanego procesu personalizacji na urządzeniu zapewnia odizolowane, chroniące prywatność środowisko do wykonywania logiki biznesowej, zapewniając przy tym kontrolowany dostęp do niezbędnych danych i operacji.

Warstwowe platformy interfejsu API

Personalizacja na urządzeniu udostępnia ustrukturyzowaną architekturę interfejsu API zainteresowanym firmom. Górna warstwa zawiera aplikacje stworzone z myślą o konkretnych przypadkach użycia. Potencjalne firmy mogą łączyć swoje dane z tymi aplikacjami, które nazywamy interfejsami API najwyższego poziomu. Interfejsy API najwyższego poziomu są tworzone przy użyciu interfejsów API pośredniej.

Z czasem planujemy dodawać kolejne interfejsy API najwyższego poziomu. Gdy interfejs API Top-layer nie jest dostępny w konkretnych zastosowaniach lub jeśli istniejące interfejsy API tej warstwy nie są wystarczająco elastyczne, firmy mogą bezpośrednio wdrożyć interfejsy API Mid-Layer, które zapewniają wydajność i elastyczność dzięki podstawowym elementom programowania.

Podsumowanie

Personalizacja na urządzeniu to pomysł badawczy na wczesnym etapie, którego celem jest pozyskanie zainteresowania i opinii nad długoterminowym rozwiązaniem, które rozwiązuje problemy związane z prywatnością użytkowników za pomocą najnowszych i najlepszych technologii, które zgodnie z oczekiwaniami będą przynosić duże możliwości.

Chcemy współpracować z zainteresowanymi osobami, takimi jak eksperci w zakresie ochrony prywatności, analitycy danych i potencjalni użytkownicy, aby mieć pewność, że ODP spełnia ich potrzeby i rozwiązuje ich obawy.