Personalizzazione sul dispositivo: personalizzazione con protezione della privacy avanzata

Destinato a essere implementato nell'Android Open Source Project (AOSP), questa spiegazione tecnica illustra la motivazione alla base della personalizzazione on-device (ODP), i principi di progettazione alla base del suo sviluppo, la privacy tramite un modello di riservatezza e il modo in cui contribuisce a garantire un'esperienza verificabile privata.

Intendiamo raggiungere questo obiettivo semplificando il modello di accesso ai dati e assicurandoci che tutti i dati degli utenti che lasciano il confine di sicurezza siano differenziati in modo privato a livello di utente (utente, utente, modello_instance) (talvolta abbreviata a livello di utente nel testo riportato di seguito).

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

Visione artificiale

La personalizzazione sul dispositivo è progettata per proteggere le informazioni degli utenti finali dalle attività con cui non hanno interagito. Le attività commerciali possono continuare a personalizzare i propri prodotti e servizi per gli utenti finali (ad esempio utilizzando modelli di machine learning in modo appropriato anonimizzati e con privacy differenziata), 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 dalle preferenze del singolo utente finale), a meno che non ci siano interazioni dirette tra l'attività e l'utente finale. Se un'azienda produce modelli di machine learning o analisi statistiche, ODP cercherà di assicurarsi che tali modelli siano adeguatamente anonimizzati utilizzando i meccanismi di privacy differenziale appropriati.

Il nostro piano attuale prevede di esplorare l'ODP in più traguardi, per includere le seguenti caratteristiche e funzionalità. 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 sandbox in cui tutta la logica di business viene contenuta ed eseguita, consentendo a una moltitudine di indicatori degli utenti finali di entrare nella sandbox, limitando al contempo gli output.

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

   1. Controlli utente e altri dati correlati agli utenti. Potrebbero essere forniti dall'utente finale o raccolti e dedotti dalle aziende, insieme ai controlli della durata (TTL), all'eliminazione dei criteri, alle norme sulla privacy e altro ancora.
   2. Configurazioni aziendali. ODP fornisce algoritmi per comprimere o offuscare questi dati.
   3. Risultati dell'elaborazione aziendale. Questi risultati possono essere:
      1. Utilizzati come input nelle fasi di elaborazione successive
      2. Nominato in base ai meccanismi di privacy differenziale appropriati e caricato negli endpoint idonei.
      3. Caricato con un flusso di caricamento affidabile in ambienti di esecuzione attendibili (TEE) che eseguono carichi di lavoro open source con meccanismi di privacy differenziale centrale appropriati
      4. Mostrato agli utenti finali.

3. API progettate per:

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

Design principles

Sono tre i pilastri che l'ODP cerca di bilanciare: privacy, equità e utilità.

Modello dei dati elevato per una maggiore protezione della privacy

ODP segue Privacy by Design ed è progettato pensando alla protezione della privacy dell'utente finale come impostazione predefinita.

ODP esplora lo spostamento dell'elaborazione della personalizzazione sul dispositivo di un utente finale. Questo approccio bilancia la privacy e l'utilità mantenendo i dati sul dispositivo per quanto possibile e elaborandoli al di fuori del dispositivo solo quando necessario. L'ODP si concentra su:

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

Di conseguenza, la personalizzazione sarà specifica per il dispositivo.

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

1. Ogni origine dati non elaborata viene archiviata sul lato dispositivo o sul server, in modo da consentire l'apprendimento e l'inferenza locali.
2. Forniremo algoritmi per facilitare il processo decisionale su più origini dati, ad esempio l'applicazione di filtri tra due posizioni di dati diverse oppure l'addestramento o l'inferenza su varie fonti.

In questo contesto, potrebbero essere presenti una torre aziendale e una torre per gli utenti finali:

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

Per fare un confronto, in un'infrastruttura basata sul cloud, tutti i dati non elaborati provenienti dalla torre dell'utente finale vengono trasferiti ai server dell'azienda. Al contrario, in un'infrastruttura incentrata sui dispositivi, tutti i dati non elaborati della torre dell'utente finale rimangono nella sua origine, mentre i dati dell'azienda rimangono archiviati sui server.

La personalizzazione on-device combina il meglio di entrambi i mondi consentendo solo a codice open source attestato di elaborare dati che potenzialmente potrebbero essere correlati agli utenti finali nei TEE utilizzando canali di output più privati.

Impegno pubblico inclusivo per soluzioni eque

L'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 diversi soggetti che offrono servizi e prodotti distinti.

Per ispirare l'innovazione, ODP offre API che possono essere implementate dagli sviluppatori e dalle aziende che rappresentano. La personalizzazione on-device facilita l'integrazione perfetta di queste implementazioni durante la gestione delle release, del monitoraggio, degli strumenti per sviluppatori e degli strumenti di feedback. La personalizzazione sul dispositivo non crea una logica di business concreta; serve piuttosto da catalizzatore della creatività.

ODP potrebbe offrire più algoritmi nel corso del tempo. La collaborazione con l'ecosistema è fondamentale per determinare il giusto livello di funzionalità e stabilire potenzialmente un limite di risorse del dispositivo ragionevole per ogni attività partecipante. Prevediamo feedback dall'ecosistema per aiutarci a riconoscere e prioritizzare i nuovi casi d'uso.

Utilità per sviluppatori per esperienze utente migliorate

Con ODP non si verificano perdite di dati sugli eventi o ritardi nell'osservazione, poiché tutti gli eventi vengono registrati localmente a livello di dispositivo. Non ci sono errori di partecipazione e tutti gli eventi vengono 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 riorganizzare i dati, consentendo un'accessibilità dei dati utente quasi in tempo reale e senza perdita di dati. A sua volta, questo 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 loro utenti.

Il modello di privacy: la privacy attraverso la riservatezza

Le sezioni seguenti discutono del modello consumer-producer come base per questa analisi della privacy e della precisione dell'output dell'ambiente di calcolo.

Modello consumatore-produttore come base di questa analisi della privacy

Utilizzeremo il modello consumer-producer per esaminare le garanzie di privacy previste dalla privacy tramite riservatezza. I calcoli in questo modello sono rappresentati come nodi in 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 mapping degli input agli output.

Un grafico che illustra il modello consumatore-produttore. Questo grafico ha 2 nodi di calcolo. La sequenza di esecuzione è 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. Produce 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:

• Inserisci privacy. I nodi possono avere due tipi di input. Se un input è generato da un nodo predecessore, ha già le garanzie di privacy di output del predecessore. In caso contrario, gli input devono cancellare i criteri di traffico in entrata utilizzando il motore dei criteri.
• Privacy dell'output. L'output potrebbe dover essere privatizzato, come quello fornito dalla privacy differenziale (DP).
• Riservatezza dell'ambiente di calcolo. Il calcolo deve avvenire in un ambiente sigillato in modo sicuro, per garantire che nessuno abbia accesso agli stati dell'intermediario all'interno di un nodo. Le tecnologie che supportano questa funzionalità includono Federated Computations (FC), Trusted Execution Environments (TEE) basati su hardware, sMPC (Secure Multi-Party Computation), crittografia omomorfica (HPE) e altro ancora. Vale la pena notare che la privacy tramite gli stati degli intermediari e tutti gli output che escono dai confini di riservatezza devono comunque essere protetti dai meccanismi di privacy differenziale. Due dichiarazioni obbligatorie sono:
  • riservatezza degli ambienti, assicurando che solo gli output dichiarati lascino l'ambiente
  • Solidezza, per detrazioni accurate delle rivendicazioni sulla privacy in output dalle rivendicazioni sulla privacy di input. La solidità consente la propagazione di un DAG delle proprietà di privacy.

Un sistema privato mantiene la privacy dell'input, la riservatezza dell'ambiente di calcolo e la privacy degli output. Tuttavia, il numero di applicazioni dei meccanismi di privacy differenziale può essere ridotto sigillando una maggiore elaborazione in un ambiente di calcolo riservato.

Questo modello offre due vantaggi principali. Primo, quasi tutti i sistemi, grandi e piccoli, possono essere rappresentati come DAG. In secondo luogo, le proprietà Post-elaborazione [Sezione 2.1] e la composizione Lemma 2.4 nella complessità della privacy differenziale conferiscono strumenti potenti per analizzare il compromesso (caso peggiore) in termini di privacy e accuratezza per un intero grafico:

• La post-elaborazione garantisce che, una volta privatizzata una quantità, non potrà più essere "privata" se i dati originali non vengono utilizzati di nuovo. Finché tutti gli input per un nodo sono privati, il suo output è privato, indipendentemente dai calcoli.
• La composizione avanzata garantisce che, se ogni parte del grafico è DP, anche il grafico complessivo, limitando efficacemente i valori SUM e DR dell'output finale di un grafico di circa Consenti_e, supponendo che un grafico abbia unità KB e l'output di ogni unità sia (L, β) -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, l'output è DP, che soddisfa qualsiasi logica di business arbitraria eseguita nel nodo e supporta le "salse segrete" delle attività.
• Proprietà 2 (Da composizione avanzata) se gli input di un nodo non sono tutti DP, l'output deve essere reso conforme a DP. Se un nodo di calcolo viene eseguito in ambienti di esecuzione attendibili e che esegue configurazioni e carichi di lavoro open source forniti dalla personalizzazione on-device, sono possibili limiti di DP più ristretti. In caso contrario, la personalizzazione sul dispositivo potrebbe dover utilizzare limiti peggiori DP. A causa dei vincoli delle risorse, gli ambienti di esecuzione attendibili offerti da un cloud provider pubblico avranno inizialmente la priorità.

Privacy dell'ambiente di calcolo e accuratezza dell'output

Pertanto, la personalizzazione on-device si concentrerà sul miglioramento della sicurezza degli ambienti di calcolo riservati e sul garantire che gli stati intermedi rimangano inaccessibili. Questo processo di sicurezza, noto come sealing, verrà applicato a livello di sottografico, consentendo a più nodi di rendere contemporaneamente conformi a DP. Ciò significa che la proprietà 1 e la proprietà 2 menzionata in precedenza si applicano a livello di sottografico.

Suddivisione di un grafico con 7 nodi in 2 sottografi e 1 nodo. In questo esempio, ogni sottografico ha 3 nodi. Se l'esecuzione di ogni sottografico è bloccata dagli avversari, solo l'output 3 e l'output 6, ovvero i risultati dei sottografi, devono essere modificati.
Naturalmente l'output del grafico finale, l'output 7, è DP per composizione. Ciò significa che per questo grafico saranno presenti in totale 2 proprietari dei dati, rispetto ai 3 proprietari totali (locali) se non è stata utilizzata alcuna isolamento.

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

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

DP locale: caratteristiche private della proprietà 1 + etichette private -> modello privato. (proprietà 1) Modello privato + funzionalità private -> Inferenza privata.
La personalizzazione on-device può applicare il DP locale a etichette e funzionalità utente prima di inviarle ai server. Questo approccio non impone alcun requisito all'ambiente di esecuzione del server o alla sua logica di business.

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

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

Un passo in più e puoi sigillare anche l'inferenza finale. In questo caso, nemmeno il proprietario del modello ha accesso all'inferenza.
Questo è l'attuale design per la personalizzazione sul dispositivo.

Verifica privatamente privata

La personalizzazione on-device mira a essere verificabile come privata. La verifica si concentra sulla verifica di ciò che accade sui dispositivi degli utenti. ODP autore del codice che elabora i dati in uscita dai dispositivi degli utenti finali e utilizzerà l'architettura RATS (Remote ATtestation ProcedureS) RFC 9334 del NIST per attestare che questo codice viene eseguito senza modifiche in un server senza privilegi di amministratore conforme al Confidential Computing Consortium. Questi codici saranno open source e accessibili per una verifica trasparente al fine di creare fiducia. Queste misure possono conferire agli individui la sicurezza della protezione dei propri dati e le aziende possono creare una reputazione basata su solide basi di assicurazione della privacy.

La riduzione della quantità di dati privati raccolti e archiviati è un altro aspetto fondamentale della personalizzazione on-device. Aderisce a questo principio adottando tecnologie come il calcolo federato e la privacy differenziale, che consentono di rivelare modelli di dati preziosi senza esporre dettagli individuali sensibili o informazioni identificabili.

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

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

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

Struttura del servizio di computing federato, 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 in modo criptato, sia in transito sia at-rest (le linee di colore verde acqua). Solo il carico di lavoro per il rumore e l'aggregazione tra dispositivi open source autorizzata per la personalizzazione on-device ha accesso al risultato non criptato del dispositivo non elaborato, dopo l'attestazione riuscita con i coordinatori di più parti. Una volta applicato correttamente il rumore per i 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 basata sulla riservatezza? A livello generale, un motore dei criteri creato da ODP e in esecuzione in un ambiente chiuso funge da componente di base che supervisiona ogni nodo/sottografo e monitora lo stato DP degli input e degli output:

• Dal punto di vista del motore dei criteri, i dispositivi e i server vengono trattati allo stesso modo. I dispositivi e i server che eseguono lo stesso motore dei criteri vengono considerati logicamente identici una volta che i relativi motori dei criteri sono stati reciprocamente attestati.
• 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 sigillatura tecnica preferite, un accordo contrattuale o entrambi.

In altre parole, tutti gli ambienti sigillati che installano ed eseguono il motore dei criteri della piattaforma sono considerati parte del nostro Trusted Computing Base (TCB). I dati possono propagare senza rumore aggiuntivo con il TCB. quando i dati lasciano il TCB.

Il design di alto livello della personalizzazione on-device integra in modo efficace due elementi essenziali:

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

Questo design coeso offre alle aziende condizioni di parità in cui eseguire il loro codice proprietario in un ambiente di esecuzione affidabile e accedere ai dati utente che hanno superato gli opportuni controlli dei criteri.

Le sezioni seguenti tratteranno questi due aspetti fondamentali.

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

La personalizzazione on-device introduce un'architettura con processi associati in AOSP per migliorare la privacy dell'utente e la sicurezza dei dati durante l'esecuzione della logica di business. Questa architettura è costituita da:

• Gestione del processo. Questo processo crea e gestisce IsolatedProcesses, garantendo che rimangano isolati a livello di processo con accesso limitato alle API incluse nella lista consentita e nessuna autorizzazione di rete o disco. Il ManagingProcess gestisce la raccolta di tutti i dati aziendali, tutti i dati degli utenti finali e i criteri li cancellano per il codice aziendale, inserendoli in 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 dai criteri e codice aziendale dal ManagingProcess. Consentono al codice aziendale di operare sui suoi dati e sui dati dell'utente finale cancellati dalle norme. IsolatedProcess comunica esclusivamente con ManagingProcess sia in entrata che in uscita, senza autorizzazioni aggiuntive.

L'architettura con processi associati offre l'opportunità di verificare in modo indipendente le norme sulla privacy dei dati degli utenti finali senza richiedere alle aziende di rendere open source la logica o il codice di business. Grazie al ManagingProcess che mantiene l'indipendenza di IsolatedProcesses e agli IsolatedProcesses, che eseguono in modo efficiente la logica di business, questa architettura garantisce una soluzione più sicura ed efficiente per preservare la privacy dell'utente durante la personalizzazione.

La figura seguente mostra questa architettura di processi accoppiati.

L'entità che crea l'"App Adopter" può o meno essere la stessa entità dell'"apk Adopter" nel grafico. L'entità che è l'autore dell'"APK Adopter" è la stessa che possiede il "Negozio locale Adopter" nel grafico.

Criteri e motori dei criteri per le operazioni sui dati

La personalizzazione on-device introduce un livello di applicazione dei criteri tra la piattaforma e la logica di business. L'obiettivo è fornire una serie di strumenti che mappano i controlli aziendali e degli utenti finali in decisioni centralizzate e strategiche. Queste norme vengono quindi applicate in modo completo e affidabile nei vari flussi e nelle varie attività.

Nell'architettura con processo accoppiato, il motore dei criteri risiede all'interno diManagingProcess, supervisionando l'ingresso e l'uscita dei dati dell'utente finale e dell'azienda. Fornirà anche a IsolatedProcess le operazioni incluse nella lista consentita. Le aree di copertura di esempio includono il rispetto del controllo dell'utente finale, la protezione dei minori, la prevenzione della condivisione di dati senza consenso e la privacy aziendale.

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

• Flussi di lavoro offline avviati a livello locale con comunicazioni TEE (Trusted Execution Environment):
  • Flussi di download di dati: download attendibili
  • Flussi di caricamento dati: transazioni attendibili
• Flussi di lavoro online avviati a livello locale:
  • Flussi di pubblicazione in tempo reale
  • Flussi di inferenza
• Flussi di lavoro offline avviati localmente:
  • Flussi di ottimizzazione: addestramento del modello on-device 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 dei criteri.

Il motore dei criteri si trova al centro della progettazione. Esempi (elenco non esaustivo):

• Scarica: 1 -> 2 -> 4 -> 7 -> 10 -> 11 -> 3
• Porzione: 1 + 3 -> 4 -> 6 -> 9 -> 11 -> 3
• Ottimizzazione: 2 (fornisce un piano di addestramento) -> 1 + 3 -> 4 -> 5 -> 8 -> 11 -> 2
• Report: 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 dei processi accoppiati della personalizzazione on-device garantisce un ambiente isolato e incentrato sulla tutela della privacy per l'esecuzione della logica di business, fornendo al contempo un accesso controllato ai dati e alle operazioni necessari.

Piattaforme API a più livelli

La personalizzazione on-device offre un'architettura API a più livelli per le aziende interessate. Il livello superiore consiste in applicazioni create per casi d'uso specifici. Le potenziali aziende possono collegare i propri dati a queste applicazioni, note come API di primo livello. Le API di primo livello sono basate sulle API di livello intermedio.

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

Conclusione

La personalizzazione on-device è una proposta di ricerca in fase iniziale per sollecitare interesse e feedback su una soluzione a lungo termine che affronta i problemi di privacy degli utenti finali con le tecnologie migliori e più recenti che si prevede apporteranno molta utilità.

Desideriamo coinvolgere gli stakeholder, come esperti della privacy, analisti di dati e potenziali utenti finali, per garantire che la piattaforma ODP soddisfi le loro esigenze e risponda alle loro preoccupazioni.