Personalizzazione sul dispositivo: personalizzazione con protezione della privacy avanzata

Per essere implementata nell'Android Open Source Project (AOSP), questa spiegazione tecnica illustra le motivazioni alla base della personalizzazione on-device (ODP), i principi di progettazione che ne guidano lo sviluppo, la privacy attraverso un modello di riservatezza e il modo in cui contribuisce a garantire un'esperienza privata verificabile.

Intendiamo raggiungere questo obiettivo semplificando il modello di accesso ai dati e assicurando che tutti i dati utente che escono dai confini di sicurezza siano privati in modo differenziato a livello di singolo utente (utente, utilizzatore, modello_instance) (a volte abbreviati a livello di utente in questo documento).

Tutto il codice relativo al potenziale traffico in uscita dei dati degli utenti finali dai dispositivi degli utenti finali sarà open source e verificabile da entità esterne. Nelle prime fasi della nostra proposta, cerchiamo di generare interesse e raccogliere feedback per una piattaforma che offra opportunità di personalizzazione sul dispositivo. Invitiamo stakeholder come esperti di privacy, analisti di dati e professionisti della sicurezza a interagire con noi.

Vista

La personalizzazione sul dispositivo è progettata per proteggere le informazioni degli utenti finali dalle attività con cui non hanno interagito. Le attività possono continuare a personalizzare i propri prodotti e servizi per gli utenti finali (ad esempio utilizzando modelli di machine learning adeguatamente anonimizzati e privati in modo differenziato), ma non saranno in grado di vedere le personalizzazioni esatte apportate per un utente finale (che dipende non solo dalla regola di personalizzazione generata dal proprietario dell'attività, ma anche dalla preferenza del singolo utente finale), a meno che non vi siano interazioni dirette tra l'attività e l'utente finale. Se un'attività produce modelli di machine learning o analisi statistiche, ODP cercherà di garantire che siano adeguatamente anonimizzati utilizzando i meccanismi di privacy differenziale appropriati.

Il nostro piano attuale prevede di esplorare la strategia ODP in più traguardi, coprendo le caratteristiche e le funzionalità seguenti. Invitiamo inoltre le parti interessate a suggerire in modo costruttivo eventuali funzionalità o flussi di lavoro aggiuntivi per portare avanti questa esplorazione:

1. Un ambiente con sandbox in cui tutta la logica di business viene contenuta ed eseguita, consentendo a una moltitudine di indicatori dell'utente finale di accedere alla sandbox limitando gli output.

2. Datastore con crittografia end-to-end per:

   1. Controlli utente e altri dati correlati agli utenti. Questi dati potrebbero essere forniti dall'utente finale o raccolti e dedotti dalle aziende, insieme a controlli TTL (time to live), norme di cancellazione, norme sulla privacy e altro ancora.
   2. Configurazioni aziendali. ODP fornisce algoritmi per comprimere o offuscare questi dati.
   3. Risultati dell'elaborazione dell'attività. Questi risultati possono essere:
      1. Utilizzati come input nei cicli di elaborazione successivi,
      2. Rumore in base ai meccanismi di privacy differenziale adeguati e caricato su endpoint idonei.
      3. Caricato utilizzando il flusso di caricamento attendibile in Trusted Execution Environments (TEE) che esegue carichi di lavoro open source con appropriati meccanismi centrali di privacy differenziale
      4. Mostrato agli utenti finali.

3. API progettate per:

   1. Aggiornamento 2(a), in batch o in modo incrementale.
   2. Aggiorna 2(b) periodicamente, in batch o in modo incrementale.
   3. Carica 2(c), con meccanismi di rumore adeguati in ambienti di aggregazione attendibili. Tali risultati possono diventare 2(b) per i successivi cicli di elaborazione.

Design principles

Esistono tre pilastri che ODP cerca di bilanciare: privacy, equità e utilità.

Modello dei dati con più schemi per una maggiore protezione della privacy

La funzionalità ODP è conforme a Privacy by design ed è progettata con la protezione della privacy dell'utente finale come impostazione predefinita.

ODP trasferisce l'elaborazione della personalizzazione sul dispositivo di un utente finale. Questo approccio bilancia privacy e utilità mantenendo il più possibile i dati sul dispositivo ed elaborandoli al di fuori del dispositivo solo quando necessario. La strategia ODP si concentra su:

• Controllare i dati degli utenti finali da parte dei dispositivi, anche quando lasciano il dispositivo. Le destinazioni devono essere attestate come ambienti di esecuzione attendibili offerti da provider di servizi cloud pubblici che eseguono codice creato da ODP.
• Verificabilità del dispositivo di ciò che accade ai dati dell'utente finale se questi lasciano il dispositivo. ODP fornisce carichi di lavoro open source Federated Compute per coordinare il machine learning cross-device e l'analisi statistica per i suoi utenti. Il dispositivo di un utente finale attesta che questi carichi di lavoro vengono eseguiti in ambienti di esecuzione attendibili non modificati.
• Privacy tecnica garantita (ad esempio, aggregazione, rumore, privacy differenziale) degli output che escono dal confine controllato/verificabile dal dispositivo.

Di conseguenza, la personalizzazione sarà specifica in base al dispositivo.

Inoltre, le attività richiedono anche misure sulla privacy, che la piattaforma deve risolvere. Ciò comporta la conservazione di dati aziendali non elaborati nei rispettivi server. A questo scopo, ODP adotta il seguente modello di dati:

1. Ogni origine dati non elaborata verrà archiviata sul dispositivo o sul lato server, consentendo l'apprendimento e l'inferenza locali.
2. Forniremo algoritmi per facilitare il processo decisionale su più origini dati, ad esempio attraverso l'applicazione di filtri tra due posizioni di dati diverse o l'addestramento o l'inferenza tra diverse origini.

In questo contesto, potrebbero esserci una torre aziendale e una torre per l'utente finale:

La torre aziendale contiene dati generati dall'attività prima che avvenga la personalizzazione. ODP chiede alle aziende di mantenere la proprietà di queste informazioni, garantendo che solo i partner commerciali autorizzati possano accedervi.
Il grattacielo degli utenti finali è costituito dai dati forniti dall'utente finale (ad esempio informazioni e controlli dell'account), raccolti relativi alle interazioni di un utente finale con il suo dispositivo e da dati derivati (ad esempio interessi e preferenze) dedotti dall'attività. I dati dedotti non sovrascrivono le dichiarazioni dirette dell'utente.

Per fare un confronto, in un'infrastruttura incentrata sul cloud, tutti i dati non elaborati provenienti dal grattacielo dell'utente finale vengono trasferiti ai server delle aziende. Viceversa, in un'infrastruttura incentrata sui dispositivi, tutti i dati non elaborati provenienti dalla torre dell'utente finale rimangono nella loro origine, mentre i dati aziendali rimangono archiviati sui server.

La personalizzazione sul dispositivo combina il meglio di entrambi i mondi consentendo solo al codice attestato e open source di elaborare dati potenzialmente correlati agli utenti finali nei TEE che utilizzano canali di output più privati.

Coinvolgimento pubblico inclusivo per soluzioni eque

La piattaforma ODP mira a garantire un ambiente equilibrato per tutti i partecipanti all'interno di un ecosistema diversificato. Riconosciamo la complessità di questo ecosistema, composto da vari attori che offrono servizi e prodotti distinti.

Per stimolare l'innovazione, ODP offre API che possono essere implementate dagli sviluppatori e dalle aziende che rappresentano. La personalizzazione sul dispositivo facilita l'integrazione perfetta di queste implementazioni durante la gestione di release, monitoraggio, strumenti per sviluppatori e strumenti di feedback. La personalizzazione sul dispositivo non crea una logica di business concreta, ma funge da catalizzatore della creatività.

La modalità ODP potrebbe offrire più algoritmi con il passare del tempo. La collaborazione con l'ecosistema è essenziale per determinare il giusto livello di funzionalità e stabilire potenzialmente un ragionevole limite di risorse dei dispositivi per ogni attività partecipante. Anticipiamo i feedback dall'ecosistema per riconoscere e dare priorità ai nuovi casi d'uso.

Utilità degli sviluppatori per migliorare l'esperienza utente

Con ODP non c'è nessuna perdita di dati sugli eventi o ritardi nell'osservazione, poiché tutti gli eventi vengono registrati localmente a livello di dispositivo. Non ci sono errori di unione e tutti gli eventi sono associati a un dispositivo specifico. Di conseguenza, tutti gli eventi osservati formano naturalmente una sequenza cronologica che riflette le interazioni dell'utente.

Questo processo semplificato elimina la necessità di unire o riordinare i dati, consentendo un'accessibilità dei dati utente quasi in tempo reale e senza perdite. A sua volta, ciò può migliorare l'utilità percepita dagli utenti finali quando interagiscono con prodotti e servizi basati sui dati, portando potenzialmente a livelli di soddisfazione più elevati ed esperienze più significative. Con ODP, le aziende possono adattarsi in modo efficace alle esigenze dei propri utenti.

Il modello di privacy: privacy via riservatezza

Le sezioni seguenti illustrano il modello consumer-produttore come base di questa analisi della privacy e la privacy dell'ambiente di calcolo rispetto all'accuratezza dell'output.

Modello consumatore-produttore come base di questa analisi della privacy

Utilizzeremo il modello consumatore-produttore per esaminare le garanzie sulla privacy della privacy attraverso la riservatezza. I calcoli in questo modello sono rappresentati come nodi all'interno di un grafo diretto aciclico (DAG, Directed Acyclic Graph) composto da nodi e sottografi. Ogni nodo di calcolo ha tre componenti: input consumati, output prodotti e input di mappatura degli output.

Grafico che illustra il modello consumatore-produttore. Il grafico ha due nodi di calcolo. La sequenza di esecuzione è il nodo 1 -> nodo 2. Il nodo 1 è il primo a essere eseguito. Consuma 2 ingressi iniziali: Input 1 e Input 2. Il nodo 1 produce l'output 1. Il nodo 2 consuma l'output del nodo 1 e un input iniziale: Input 3. Genera l'output 2. L'output 2 è anche l'output finale di questo grafico.

In questo modello, la protezione della privacy si applica a tutti e tre i componenti:

• Privacy dell'input. I nodi possono avere due tipi di input. Se un input viene generato da un nodo predecessore, dispone già delle garanzie della privacy di output di quel predecessore. In caso contrario, gli input devono cancellare i criteri di traffico in entrata dei dati utilizzando il motore dei criteri.
• Privacy di output. Potrebbe essere necessario privatizzare l'output, ad esempio quello fornito dalla privacy differenziale (DP).
• Riservatezza dell'ambiente di calcolo. Il calcolo deve avvenire in un ambiente sicuro, garantendo che nessuno abbia accesso agli stati intermediari all'interno di un nodo. Le tecnologie che consentono questa funzionalità includono Federated Computation (FC), Trusted Execution Environments (TEE), secure Multi-Party Computation (sMPC), crittografia omomorfica (HPE) e altro ancora. Vale la pena notare che la privacy attraverso misure di salvaguardia della riservatezza degli stati intermediari e tutti gli output in uscita dal confine di riservatezza devono comunque essere protetti dai meccanismi della privacy differenziale. Due rivendicazioni obbligatorie sono:
  • la riservatezza degli ambienti, assicurando che solo gli output dichiarati escano
  • Solidità, che consente la detrazione accurata delle rivendicazioni per violazione della privacy in uscita dalle dichiarazioni sulla privacy inserite. La solidità consente la propagazione della proprietà della privacy in un DAG.

Un sistema privato mantiene la privacy degli input, la riservatezza dell'ambiente di calcolo e la privacy dell'output. Tuttavia, il numero di applicazioni dei meccanismi di privacy differenziale può essere ridotto sigillando più elaborazioni all'interno di un ambiente di calcolo riservato.

Questo modello offre due vantaggi principali. In primo luogo, la maggior parte dei sistemi, grandi e piccoli, può essere rappresentata come DAG. In secondo luogo, le proprietà Post-processing [Sezione 2.1] e composizione Lemma 2.4 della pagina La complessità della privacy differenziale di DP forniscono strumenti potenti per analizzare il compromesso in termini di privacy e accuratezza (nel peggiore dei casi) relativo a un intero grafico:

• La fase di post-elaborazione garantisce che, una volta privatizzata una quantità, questa non potrà essere "privata", se i dati originali non verranno riutilizzati. Finché tutti gli input per un nodo sono privati, il suo output è privato, indipendentemente dai suoi calcoli.
• La composizione avanzata garantisce che, se ogni parte del grafico è in formato DP, lo stesso vale per il grafico complessivo, che delimita di fatto l'output finale di un grafico ( Tasso e Π) di circa Aggregate, pertanto, supponendo che un grafico abbia unità μ e che l'output di ogni unità sia (Π, μ)-DP.

Queste due proprietà si traducono in due principi di progettazione per ciascun nodo:

• Proprietà 1 (da post-elaborazione) se gli input di un nodo sono tutti DP, il suo output è un DP, in grado di gestire qualsiasi logica di business arbitraria eseguita nel nodo e supportare i "condimenti segreti" delle aziende.
• Proprietà 2 (da composizione avanzata) se gli input di un nodo non sono tutti DP, il suo output deve essere reso conforme a DP. Se un nodo di calcolo è uno in esecuzione in Trusted Execution Environments ed esegue configurazioni e carichi di lavoro open source forniti dalla personalizzazione sul dispositivo, sono possibili limiti DP più stretti. In caso contrario, la personalizzazione sul dispositivo potrebbe dover utilizzare i limiti DP i peggiori. A causa dei limiti di risorse, gli ambienti di esecuzione attendibili offerti da un provider cloud pubblico avranno inizialmente la priorità.

Privacy dell'ambiente di calcolo e accuratezza dell'output

D'ora in poi, la personalizzazione sul dispositivo si concentrerà sul miglioramento della sicurezza degli ambienti di calcolo riservati e sul garantire che gli stati intermedi restino inaccessibili. Questo processo di sicurezza, noto come sealing, verrà applicato a livello di sottografo, consentendo di rendere conformi DP a più nodi insieme. Ciò significa che la proprietà 1 e la proprietà 2 indicate in precedenza si applicano a livello di grafico secondario.

Suddivisione di un grafico con sette nodi in due grafici secondari e un nodo. In questo esempio, ogni grafico secondario ha 3 nodi. Se l'esecuzione di ogni sottografo è protetta contro gli avversari, solo l'output 3 e l'output 6 e i risultati dei sottografici devono essere sottoposti a DP.
Ovviamente l'output finale del grafico, l'output 7, viene calcolato in base alla composizione. Ciò significa che ci saranno 2 DP complessivamente per questo grafico; rispetto alle 3 DP totali (locali) se non è stata utilizzata alcuna sigillatura.

In sostanza, proteggendo l'ambiente di calcolo ed eliminando le opportunità per gli aggressori di accedere agli input e agli stati intermedi di un grafico o sottografo, questo consente l'implementazione di DP centrale (ovvero l'output di un ambiente sigillato è conforme al DP), che può migliorare l'accuratezza rispetto al DP locale (ovvero, i singoli input sono conformi al DP). Questo principio è alla base della considerazione di tecnologie per la privacy come FC, TEE, sMPC e HPE. Consulta il Capitolo 10 in La complessità della privacy differenziale.

Un buon esempio pratico sono l'addestramento e l'inferenza del modello. Le discussioni seguenti presuppongono che (1), la popolazione di addestramento e la popolazione di inferenza si sovrappongano, e (2), sia le caratteristiche che le etichette costituiscono dati utente privati. Possiamo applicare il DP a tutti gli input:

DP locale: funzionalità private proprietà 1 + etichette private -> modello privato. (proprietà 1) Modello privato + caratteristiche private -> inferenza privata.
La personalizzazione sul dispositivo può applicare una DP locale alle etichette e alle caratteristiche degli utenti prima di inviarle ai server. Questo approccio non impone alcun requisito sull'ambiente di esecuzione del server o sulla sua logica di business.

DP centrale: (proprietà 2), in alternativa, puoi applicare una DP durante l'addestramento del modello, mantenendo precise le caratteristiche e le etichette. In questo scenario, il proprietario del modello può trasferire il modello per l'inferenza altrove. Tuttavia, per mantenere la privacy durante l'inferenza, anche le caratteristiche inserite nel modello privato devono essere conformi alla DP, per proprietà 1.

Puoi migliorare ulteriormente l'accuratezza dell'inferenza sigillando l'addestramento e l'inferenza. Ciò consente di inserire caratteristiche precise nel modello privato.

Facendo un ulteriore passo in avanti, puoi anche sigillare l'inferenza finale. Anche in questo caso, il proprietario del modello non ha accesso all'inferenza.
Questo è l'attuale design della personalizzazione sul dispositivo.

Verificabile come privata

La personalizzazione sul dispositivo mira a garantire la privacy in modo verificabile. L'obiettivo è verificare ciò che accade sui dispositivi degli utenti. ODP autorizzerà il codice che elabora i dati che lasciano i dispositivi degli utenti finali e utilizzerà l'architettura RFC 9334 Remote ATtestation ProcedureS (RATS) del NIST per attestare che questo codice è in esecuzione non modificato in un server con privilegi di amministratore delle istanze conforme a Confidential Computing Consortium. Questi codici saranno open source e accessibili per la verifica trasparente al fine di creare fiducia. Queste misure possono dare ai privati la sicurezza che i loro dati siano protetti e le aziende possono stabilire una reputazione basata su una solida base di garanzia della privacy.

La riduzione della quantità di dati privati raccolti e archiviati è un altro aspetto fondamentale della personalizzazione sul dispositivo. Aderisce a questo principio adottando tecnologie come il computing federato e la privacy differenziale, consentendo la rivelazione di pattern di dati preziosi senza esporre dettagli individuali sensibili o informazioni identificabili.

Mantenere un audit trail che registri le attività relative all'elaborazione e alla condivisione dei dati è un altro aspetto chiave della privacy verificabile. Ciò consente la creazione di report di controllo e l'identificazione delle vulnerabilità, dimostrando il nostro impegno per la privacy.

Chiediamo collaborazioni costruttive da parte di esperti di privacy, autorità, settori e individui per aiutarci a migliorare continuamente la progettazione e le implementazioni.

Il grafico seguente mostra il percorso del codice per l'aggregazione e il rumore cross-device in base alla privacy differenziale.

Struttura del servizio Federated Compute, che gestisce sia l'apprendimento federato che l'analisi federata. I dati non criptati e privi di rumore vengono elaborati solo sul dispositivo (linea rossa). I risultati dell'elaborazione vengono caricati criptati, sia in transito sia at-rest (le linee color verde acqua). Solo il carico di lavoro di aggregazione cross-device e di creazione di personalizzazione sul dispositivo open source ha accesso al risultato non criptato del dispositivo, dopo l'attestazione con esito positivo con coordinatori di più parti. Una volta che il rumore viene applicato correttamente in base ai meccanismi di privacy differenziale all'interno del Trusted Execution Environment, tutti i flussi di dati a valle possono essere non criptati (le linee arancioni).

Design di alto livello

Come si può implementare la privacy tramite riservatezza? A livello generale, un motore dei criteri creato da ODP e eseguito in un ambiente chiuso funge da componente principale che supervisiona ogni nodo/sottografo e tiene traccia dello stato DP dei relativi input e output:

• Dal punto di vista del motore dei criteri, dispositivi e server vengono considerati allo stesso modo. I dispositivi e i server che eseguono lo stesso motore dei criteri sono considerati logicamente identici dopo che i relativi motori dei criteri sono stati attestati a vicenda.
• Sui dispositivi, l'isolamento viene ottenuto tramite processi isolati AOSP (o pKVM a lungo termine quando la disponibilità diventa elevata). Sui server, l'isolamento si basa su una "parte attendibile", ovvero un TEE e altre soluzioni di connessione tecnica preferite, un accordo contrattuale o entrambi.

In altre parole, tutti gli ambienti chiusi che installano ed eseguono il motore dei criteri della piattaforma sono considerati parte della nostra Trusted Computing Base (TCB). I dati possono propagarsi senza ulteriore rumore con il TCB. Il DP deve essere applicato quando i dati escono dal TCB.

Il design generale della personalizzazione sul dispositivo integra efficacemente due elementi essenziali:

• Un'architettura a processi accoppiati per l'esecuzione della logica di business
• Criteri e un motore di criteri per la gestione dei dati in entrata, in uscita e le operazioni consentite.

Questo design coeso offre alle aziende una condizione di parità in cui possono eseguire il loro codice proprietario in un ambiente di esecuzione affidabile e accedere ai dati utente che hanno superato i controlli delle norme appropriati.

Le seguenti sezioni approfondiranno questi due aspetti chiave.

Architettura a processi accoppiati per l'esecuzione della logica di business

La personalizzazione sul dispositivo introduce un'architettura a processi accoppiati in AOSP per migliorare la privacy dell'utente e la sicurezza dei dati durante l'esecuzione della logica di business. Questa architettura è composta da:

• Processo di gestione. Questo processo crea e gestisce gli IsolatedProcessi, garantendo che rimangano isolati a livello di processo con accesso limitato alle API nella lista consentita e nessuna autorizzazione di rete o disco. Il metodo ManagingProcess gestisce la raccolta di tutti i dati aziendali, tutti i dati degli utenti finali e i criteri li cancellano per il codice aziendale, trasferendoli agli IsolatedProcesses per l'esecuzione. Inoltre, media l'interazione tra IsolatedProcesses e altri processi, come system_server.

• IsolatedProcess. Designato come isolato (isolatedprocess=true nel manifest), questo processo riceve dati aziendali, dati dell'utente finale cancellati in base ai criteri e codice aziendale da ManagingProcess. Consentono al codice aziendale di operare sui suoi dati e su quelli degli utenti finali cancellati dalle norme. IsolatedProcess comunica esclusivamente con ManagingProcess sia per il traffico in entrata che per quello in uscita, senza ulteriori autorizzazioni.

L'architettura con processi combinati offre l'opportunità di una verifica indipendente delle norme sulla privacy dei dati degli utenti finali senza richiedere alle aziende di rendere open source la logica o il codice di business. Con il metodo ManagementProcess che mantiene l'indipendenza degli IsolatedProcessi e l'esecuzione efficiente della logica di business da parte degli IsolatedProcessi, questa architettura garantisce una soluzione più sicura ed efficiente per preservare la privacy degli utenti durante la personalizzazione.

La figura seguente mostra questa architettura di processo abbinato.

L'entità che autore dell'"App Adottatore" può essere o meno la stessa entità che crea l'"APK Adottatore" nel grafico. L'entità che autore dell'"APK adozione" è la stessa del "negozio locale per adozione" nel grafico.

Criteri e motori dei criteri per le operazioni sui dati

La personalizzazione sul dispositivo introduce un livello di applicazione dei criteri tra la piattaforma e la logica di business. L'obiettivo è fornire una serie di strumenti che riconoscano i controlli aziendali e degli utenti finali in modo da prendere decisioni centralizzate e fruibili sui criteri. Queste politiche vengono quindi applicate in modo completo e affidabile ai flussi e alle aziende.

Nell'architettura a processi accoppiati, il motore dei criteri risiede all'interno del ManagingProcess, supervisionando l'ingresso e l'uscita dei dati dell'utente finale e aziendali. Fornirà inoltre a IsolatedProcess anche le operazioni consentite. Esempi di aree di copertura includono il rispetto del controllo per gli utenti finali, la protezione dei minori, la prevenzione della condivisione dei dati senza consenso e la privacy aziendale.

Questa architettura di applicazione dei criteri comprende tre tipi di flussi di lavoro che possono essere sfruttati:

• Flussi di lavoro offline avviati localmente con comunicazioni TEE (Trusted Execution Environment):
  • Flussi di download dei dati: download attendibili
  • Flussi di caricamento dei dati: transazioni attendibili
• Flussi di lavoro online avviati localmente:
  • Flussi di distribuzione in tempo reale
  • Flussi di inferenza
• Flussi di lavoro offline avviati localmente:
  • Flussi di ottimizzazione: addestramento del modello sul dispositivo implementato tramite Federated Learning (FL)
  • Flussi di report: aggregazione cross-device implementata tramite Federated Analytics (FA)

La figura seguente mostra l'architettura dal punto di vista dei criteri e dei motori delle policy.

Policy Engine si trova al centro della progettazione. Esempi (elenco non esaustivo):

• Scarica: 1 -> 2 -> 4 -> 7 -> 10 -> 11 -> 3
• Porzioni: 1 + 3 -> 4 -> 6 -> 9 -> 11 -> 3
• Ottimizzazione: 2 (fornisce un piano di allenamento) -> 1 + 3 -> 4 -> 5 -> 8 -> 11 -> 2
• Reporting: 3 (fornisce un piano di aggregazione) -> 1 + 3 -> 4 -> 5 -> 8 -> 11 -> 2

Nel complesso, l'introduzione del livello di applicazione dei criteri e del motore dei criteri nell'architettura a processi accoppiati della personalizzazione sul dispositivo garantisce un ambiente isolato e che tutela la privacy per l'esecuzione della logica di business, fornendo al contempo accesso controllato ai dati e alle operazioni necessari.

Superfici API a livelli

La personalizzazione sul dispositivo offre un'architettura API a più livelli per le aziende interessate. Il livello superiore è costituito da applicazioni create per casi d'uso specifici. Le potenziali aziende possono connettere i propri dati a queste applicazioni, note come API di livello superiore. Le API di livello superiore si basano sulle API di livello medio.

Nel tempo, prevediamo di aggiungere altre API di primo livello. Quando un'API di livello superiore non è disponibile per un determinato caso d'uso o quando le API di livello superiore esistenti non sono abbastanza flessibili, le aziende possono implementare direttamente le API di livello intermedio, che forniscono potenza e flessibilità attraverso primitive di programmazione.

Conclusione

La personalizzazione sul dispositivo è una proposta di ricerca in fase iniziale per sollecitare interesse e feedback su una soluzione a lungo termine che risponda ai dubbi sulla privacy dell'utente finale con le tecnologie più recenti e migliori che si prevede supportino un'elevata utilità.

Vorremmo collaborare con stakeholder come esperti di privacy, analisti di dati e potenziali utenti finali per garantire che ODP soddisfi le loro esigenze e risponda alle loro preoccupazioni.