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 w ramach modelu poufności oraz sposób zapewniania możliwej do zweryfikowania prywatności użytkowania.

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 skrócone do poziomu użytkownika).

Cały kod związany z potencjalnym ruchem wychodzącym danych użytkowników z urządzeń użytkowników będzie miał charakter open source i będzie mógł być weryfikowany 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.

Przetwarzanie obrazu

Personalizacja na urządzeniu ma chronić informacje użytkowników przed firmami, z którymi się nie kontaktowali. Firmy mogą w dalszym ciągu dostosowywać swoje produkty i usługi pod kątem użytkowników (np. stosując odpowiednio zanonimizowane i różnicowe modele prywatnych systemów uczących się), ale nie będą widzieć dokładnych dostosowań wprowadzonych dla użytkownika końcowego (zależy to nie tylko od reguły dostosowania wygenerowanej przez właściciela firmy, ale także od indywidualnych preferencji użytkownika), chyba że nastąpi bezpośrednia interakcja między firmą a użytkownikiem. Jeśli firma tworzy modele systemów uczących się lub analizy statystyczne, ODP stara się zapewnić ich prawidłową anonimizację przy użyciu 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 zasugerowania dodatkowych funkcji lub przepływów pracy, które pomogą w rozwijaniu tej eksploracji:

1. Środowisko piaskownicy, w którym zawarta jest cała logika biznesowa, co umożliwia dostęp do niej wielu różnym sygnałom od użytkowników, a jednocześnie ogranicza ilość 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 firmy. ODP udostępnia algorytmy do kompresowania lub zaciemniania tych danych.
   3. Wyniki przetwarzania danych biznesowych. Mogą to być:
      1. Wykorzystane jako dane wejściowe w późniejszych rundach przetwarzania
      2. Zahaszowana zgodnie z odpowiednimi mechanizmami prywatności różnicowej i przesyłana 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. Aktualizuj 2(a) zbiorczo lub stopniowo.
   2. Okresowo aktualizuj punkt 2(b) – 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).

Zasady projektu

Istnieją 3 filary, na których ODP stara się znaleźć równowagę: prywatność, uczciwość i użyteczność.

Model danych z szkieletami zapewniającymi lepszą ochronę prywatności

ODP jest zgodny z zasadami Privacy by Design, a zaprojektowano je z myślą o domyślnej ochronie prywatności użytkowników.

ODP bada przenoszenie przetwarzania personalizacji na urządzenie użytkownika. Takie podejście łączy prywatność i przydatność, przechowując dane na urządzeniu w maksymalnym możliwym zakresie i przetwarzając je poza urządzeniem 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.
• weryfikację na urządzeniu, co dzieje się z danymi użytkownika po opuszczeniu urządzenia; ODP udostępnia zbiory zadań sfederowanych w obliczeniach open source, aby koordynować pracę systemów uczących się na różnych urządzeniach i analizować statystyki na potrzeby użytkowników. Urządzenie użytkownika będzie potwierdzać, że takie zbiory zadań są wykonywane w niezmodyfikowanych zaufanych środowiskach wykonawczych.
• Gwarancja prywatności technicznej (np. agregacja, szum, prywatność różnicowa) danych wyjściowych, które opuszczają granicę kontrolowanej przez urządzenie lub możliwą do zweryfikowania.

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

Firmy wymagają też środków ochrony prywatności, na które powinna odpowiadać platforma. Wiąże się to z utrzymywaniem nieprzetworzonych danych biznesowych na odpowiednich serwerach. W tym celu ODP stosuje ten model danych:

1. Każde nieprzetworzone źródło danych będzie przechowywane na urządzeniu lub po stronie serwera, co umożliwi lokalne uczenie się i wnioskowanie.
2. Udostępnimy algorytmy, które ułatwią podejmowanie decyzji z wielu źródeł danych, na przykład przez filtrowanie 2 odmiennych lokalizacji danych albo trenowanie i wnioskowanie z różnych źródeł.

W tym kontekście może to być wieża biznesowa i wieża dla użytkowników końcowych:

Business Tower zawiera dane wygenerowane przez firmę przed personalizacją. ODP prosi firmy o zachowanie prawa własności do tych informacji, dzięki czemu mają do nich dostęp tylko autoryzowani partnerzy biznesowi.
Wieża użytkowników składa się z danych dostarczonych przez użytkownika (np. informacji o koncie i elementów sterujących), zebranych danych związanych z interakcjami użytkownika z urządzeniem oraz danych pochodnych (np. zainteresowań i preferencji) wywnioskowanych przez firmę. Dane wywnioskowane 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. I odwrotnie, w infrastrukturze skoncentrowanej na urządzeniach wszystkie nieprzetworzone dane z maszyny użytkownika pozostają w swoim źródle, a dane firmy pozostają na serwerach.

Personalizacja na urządzeniu łączy to, co najlepsze w obu tych rozwiązaniach, ponieważ umożliwia przetwarzanie danych na platformie TEE na podstawie potwierdzonego kodu open source przy użyciu bardziej prywatnych kanałów wyjściowych.

Zaangażowanie publiczne w zakresie integracji społecznej w zakresie sprawiedliwych rozwiązań

ODP stara się zapewnić zrównoważone środowisko dla wszystkich uczestników zróżnicowanego ekosystemu. Zdajemy sobie sprawę z zawiłości tego ekosystemu, który obejmuje różnych graczy oferujących odmienne usługi i produkty.

Aby inspirować do innowacji, ODP oferuje interfejsy API, które mogą wdrażać przez deweloperów i reprezentowane przez nich firmy. Personalizacja na urządzeniu ułatwia płynną integrację tych implementacji, a jednocześnie pozwala zarządzać wersjami, monitorowaniem, narzędziami dla programistów i narzędziami do przesyłania opinii. Personalizacja na urządzeniu nie tworzy określonej logiki biznesowej – raczej stymuluje kreatywność.

ODP może z czasem zaoferować 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ędzia dla programistów zwiększające wygodę użytkowników

Użycie ODP nie wiąże się z utratą danych o zdarzeniach ani z opóźnieniami 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 potrzebę łączenia danych lub ich zmiany, co pozwala na dostęp do danych użytkowników niemal w czasie rzeczywistym i bez utraty danych. To z kolei może zwiększyć użyteczność, jaką użytkownicy postrzegają podczas korzystania z produktów i usług opartych na danych, co może prowadzić do wzrostu ich zadowolenia i wartościowych doświadczeń. Dzięki ODP firmy mogą skutecznie dostosowywać się do potrzeb użytkowników.

Model prywatności: prywatność przez poufność

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-producenta, który stanowi podstawę tej analizy prywatności;

Zastosowamy model konsument-producent, aby zbadać gwarancje prywatności dotyczące prywatności przez poufność. 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 komponenty: wykorzystane dane wejściowe, wygenerowane dane wyjściowe i dane wejściowe mapowania obliczeniowego 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. Potrzebuje 2 wejściowych danych wejściowych: wejścia 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 to również ostateczny wynik tego wykresu.

W tym modelu ochrona prywatności obejmuje wszystkie 3 elementy:

• Prywatność wejściowa. Węzły mogą mieć 2 typy danych wejściowych. 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ść w ramach ochrony poufności przez stany pośredniczące oraz wszystkie dane wyjściowe wychodzące poza granicę poufności nadal muszą być chronione przez mechanizmy prywatności różnicowej. Wymagane są 2 roszczenia:
  • poufność środowisk, dzięki czemu tylko zadeklarowane dane wyjściowe
  • rzetelność, która umożliwia dokładne odliczenie wyjściowej skargi dotyczącej prywatności od danych wejściowych roszczeń dotyczących prywatności. Dźwięk umożliwia propagację właściwości prywatności w DAG-u.

System prywatny zapewnia prywatność danych wejściowych, poufność środowiska obliczeniowego i prywatność danych wyjściowych. Liczbę zastosowań mechanizmów prywatności różnicowej można jednak zmniejszyć, jeśli zabezpieczysz więcej procesów w poufnym środowisku obliczeniowym.

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 DP dotyczące przetwarzania i dokładności Lemma 2.4 w artykule „Złożoność prywatności różnicowej” oferują zaawansowane narzędzia do analizowania równowagi między prywatnością a dokładnością (w najgorszym przypadku) na całym wykresie:

• To gwarancja, że sprywatyzowana ilość nie może być „nieprywatowana”, jeśli oryginalne dane nie zostaną użyte ponownie. Dopóki wszystkie dane wejściowe węzła są prywatne, jego dane wyjściowe pozostają prywatne, niezależnie od wykonania obliczeń.
• Zaawansowana kompozycja gwarantuje, że jeśli każda część wykresu to DP, cały wykres jest również, co w praktyce ogranicza wynik automatycznie i wyniku wykresu, odpowiednio do wartości É√√, przy założeniu, że wykres zawiera jednostki ΋, a wynik każdej z nich to ("}, zer)-DP.

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

• Usługa 1 (z przetwarzania po przetwarzaniu), jeśli dane wejściowe węzła to DP, dane wyjściowe to DP, obsługująca dowolną logikę biznesową wykonywaną w węźle i obsługę „tajnych sosów” biznesowych.
• Usługa 2 (z zaawansowanej kompozycji), jeśli dane wejściowe węzła nie obejmują wszystkich procesów przetwarzania danych, jego dane wyjściowe muszą być zgodne z DP. Jeśli węzeł obliczeniowy działa w zaufanych środowiskach wykonawczych i wykonuje zadania i konfiguracje typu 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 progów DP. Ze względu na ograniczenia zasobów na początku będą miały priorytet dla zaufanych środowisk wykonawczych oferowanych 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ń, nazywany uszczelnianiem, zostanie zastosowany na poziomie podgrafu, co pozwoli zapewnić zgodność wielu węzłów jednocześnie z DP. Oznacza to, że wspomniane wcześniej usługa 1 i usługa 2 mają zastosowanie na poziomie podgrafu.

Podział grafu z 7 węzłami 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 zabezpieczone przed przeciwnikami, tylko Dane wyjściowe 3 i Wyniki 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 w przypadku tego wykresu będzie widoczne 2 rozdzielczości podstawowe. W porównaniu z 3 łącznymi (lokalnymi) wartościami DP, jeśli nie użyto uszczelnienia.

Zasadniczo dzięki ochronie środowiska obliczeniowego i wyeliminowaniu możliwości dostępu do danych wejściowych grafu lub podgrafu oraz stanów pośrednich umożliwia to wdrożenie Central DP (czyli dane wyjściowe z zabezpieczonego środowiska są zgodne z zasadami przetwarzania danych), co może poprawić dokładność w porównaniu z lokalnymi DP (czyli danymi wejściowymi do poszczególnych danych). Ta zasada stoi za traktowaniem 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 modelu i wnioskowanie. 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.

Central DP: (usługa 2) możesz też zastosować DP podczas trenowania modelu, zachowując dokładność cech i etykiet. 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.

Przechodząc o krok dalej, możesz też zadbać o ostateczne wnioski. W tym przypadku właściciel modelu też nie ma dostępu do wnioskowania.
To obecny projekt personalizacji na urządzeniu.

Potwierdzona 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. Kody te będą dostępne na zasadach open source i będą dostępne do przejrzystej weryfikacji, co pozwoli budować zaufanie. Takie środki zaradcze dają użytkownikom pewność, że ich dane są chronione, a firmy mogą budować reputację w oparciu o solidne podstawy ochrony prywatności.

Zmniejszenie ilości zbieranych i przechowywanych danych prywatnych to kolejny ważny 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ę.

Innym kluczowym aspektem możliwej do zweryfikowania prywatności jest prowadzenie rejestru kontrolnego, w którym działania związane z przetwarzaniem i udostępnianiem danych są rejestrowane. 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 przedstawia ścieżkę kodu agregacji danych na różnych urządzeniach i szumu w odniesieniu do prywatności różnicowej.

Struktura usługi Federated Compute, która obsługuje zarówno sfederowane uczenie się, jak i sfederowaną analizę danych. 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 ochrony prywatności różnicowej w zaufanym środowisku wykonawczym wszystkie późniejsze przepływy danych 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 perspektywy silnika 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). Z TCB dane mogą się propagować bez dodatkowego szumu. 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.

Spójny projekt zapewnia firmom równe szanse, dzięki którym mogą uruchomić swój zastrzeżony kod w zaufanym środowisku wykonawczym i uzyskać dostęp do danych użytkownika, które przeszły odpowiednie testy zgodności z zasadami.

Dalej omówimy te 2 kluczowe aspekty.

Architektura sparowanego procesu do wykonywania logiki biznesowej

Personalizacja na urządzeniu wprowadza w AOSP architekturę sparowanych procesów, aby zwiększyć prywatność użytkowników i bezpieczeństwo danych podczas wykonywania logiki biznesowej. Architektura ta składa się z tych elementów:

• Proces zarządzania. Proces ten tworzy izolację procesów i zarządza nimi, zapewniając, że są one odizolowane na poziomie procesu z dostępem ograniczonym do interfejsów API z listy dozwolonych, a bez uprawnień do sieci lub dysku. 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. Dodatkowo pośredniczy w interakcji między IsolatedProcesses z 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 platformę ManagingProcess, która pozwala chronić prywatność użytkowników podczas personalizacji.

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

Element, który jest autorem „aplikacji użytkowej”, może, ale nie musi, być tym samym podmiotem co pakiet „apk apk” na wykresie. Podmiot, który jest autorem pliku „Plik APK użytkownika”, jest taki sam jak ten, który jest właścicielem „Sklepu lokalnego użytkownika” na wykresie.

Mechanizmy zasad i 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 sparowanego procesu mechanizm zasad znajduje się w ramach procesuManagingProcess, który nadzoruje ruch przychodzący i wychodzący danych użytkowników oraz firmowych baz danych. 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.

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

• Inicjowane lokalnie przepływy pracy offline z komunikacją w ramach zaufanego środowiska wykonawczego 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 zaimplementowane za pomocą sfederowanego uczenia się
  • Procesy raportowania: agregacja danych z różnych urządzeń zaimplementowana za pomocą sfederowanej analityki (FA)

Poniższy rysunek przedstawia architekturę z perspektywy zasad i silników zasad.

Mechanizm zasad znajduje się w podstawach projektu. Wybrane przykłady:

• Pobierz: 1 -> 2 -> 4 -> 7 -> 10 -> 11 -> 3
• Wyświetlanie: 1 + 3 -> 4 -> 6 -> 9 -> 11 -> 3
• Optymalizacja: 2 (przedstawia plan szkoleniowy) -> 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, a jednocześnie zapewniające kontrolowany dostęp do niezbędnych danych i operacji.

Warstwowe platformy interfejsu API

Personalizacja na urządzeniu to wielowarstwowa architektura interfejsów API dla zainteresowanych firm. Górna warstwa zawiera aplikacje stworzone z myślą o konkretnych przypadkach użycia. Potencjalne firmy mogą połączyć swoje dane z tymi aplikacjami, nazywanymi interfejsami API Top-Layer. Interfejsy API najwyższego poziomu są oparte na interfejsach API pośredniej.

Z czasem planujemy dodać więcej interfejsów 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 kwestie związane z prywatnością użytkowników za pomocą najnowszych i najlepszych technologii, które zgodnie z oczekiwaniami przyniosą 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.