Personalizzazione sul dispositivo: personalizzazione con protezione della privacy avanzata

bookmark_border Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Questo explainer tecnico, pensato per essere implementato nell'Android Open Source Project (AOSP), illustra la motivazione alla base della personalizzazione sul dispositivo (ODP), i principi di progettazione che guidano il suo sviluppo, la sua privacy tramite il modello di riservatezza e in che modo contribuisce a garantire un'esperienza verificabilmente privata.

Prevediamo di raggiungere questo obiettivo semplificando il modello di accesso ai dati e assicurandoci che tutti i dati utente che escono dal confine di sicurezza siano con privacy differenziale a livello di (utente, adottatore, model_instance) (a volte abbreviato in a livello di utente in questo documento).

Tutto il codice relativo alla potenziale esportazione dei dati degli utenti finali dai loro dispositivi 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 semplifichi le opportunità di personalizzazione sul dispositivo. Invitiamo stakeholder come esperti di privacy, analisti di dati e professionisti della sicurezza a collaborare con noi.

Vision

La personalizzazione on-device è 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 anonimizzati e con privacy differenziale), ma non potranno 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 esistano 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 vengano anonimizzati correttamente utilizzando i meccanismi di privacy differenziale appropriati.

Il nostro piano attuale è esplorare l'ODP in più traguardi, coprendo le seguenti funzionalità. Invitiamo inoltre le parti interessate a suggerire in modo costruttivo eventuali funzionalità o flussi di lavoro aggiuntivi per approfondire questa esplorazione:

1. Un ambiente in sandbox in cui è contenuta ed eseguita tutta la logica aziendale, che consente a una moltitudine di indicatori utente finali di entrare nella sandbox, limitando al contempo le uscite.

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 attività, insieme a controlli TTL (time to live), criteri di eliminazione, norme sulla privacy e altro ancora.
   2. Configurazioni dell'attività. ODP fornisce algoritmi per comprimere o offuscare questi dati.
   3. Risultati dell'elaborazione aziendale. Questi risultati possono essere:
      1. Utilizzati come input nelle fasi successive dell'elaborazione,
      2. Hanno subito l'applicazione di rumore in base a meccanismi di privacy differenziale appropriati e sono stati caricati in endpoint idonei.
      3. Caricamenti effettuati utilizzando il flusso di caricamento attendibile in ambienti di esecuzione affidabili (TEE) che eseguono carichi di lavoro open source con meccanismi di privacy differenziale centrali appropriati
      4. Mostrato agli utenti finali.

3. API progettate per:

   1. Aggiorna 2(a), collettivamente o in modo incrementale.
   2. Aggiorna 2(b) periodicamente, in blocco o in modo incrementale.
   3. Carica 2(c), con meccanismi di generazione di rumore appropriati in ambienti di aggregazione attendibili. Questi risultati possono diventare 2(b) per i prossimi round di elaborazione.

Cronologia

Questo è il piano attuale per i test dell'ODP in versione beta. Le tempistiche sono soggette a modifiche.

Design principles

L'ODP si basa su tre pilastri: privacy, equità e utilità.

Modello di dati a torre per una maggiore protezione della privacy

ODP segue il principio di privacy by design ed è progettato per proteggere la privacy degli utenti finali per impostazione predefinita.

ODP esplora il trasferimento dell'elaborazione della personalizzazione sul dispositivo di un utente finale. Questo approccio bilancia privacy e utilità mantenendo i dati sul dispositivo il più possibile ed elaborandoli al di fuori del dispositivo solo se necessario. L'ODP si concentra su:

• Controllo dei dati degli utenti finali da parte del dispositivo, anche quando vengono trasferiti al di fuori del dispositivo. Le destinazioni devono essere ambienti di esecuzione attendibili attestati offerti da fornitori di cloud pubblico che eseguono codice creato da ODP.
• Verificabilità del dispositivo in merito a cosa succede ai dati dell'utente finale se escono dal dispositivo. ODP fornisce carichi di lavoro di calcolo federato open source per coordinarsi con il machine learning cross-device e l'analisi statistica per i suoi adottanti. Il dispositivo di un utente finale attesterà che questi carichi di lavoro vengono eseguiti in Trusted Execution Environment non modificati.
• Privacy tecnica garantita (ad es. aggregazione, rumore, privacy differenziale) per gli output che superano il confine controllato/verificabile dal dispositivo.

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

Inoltre, le attività richiedono anche misure per la privacy, che la piattaforma dovrebbe affrontare. Ciò comporta la gestione dei dati aziendali non elaborati nei rispettivi server. Per farlo, 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 locale.
2. Forniremo algoritmi per facilitare il processo decisionale in più origini dati, ad esempio il filtraggio tra due posizioni di dati diverse o l'addestramento o l'inferenza in varie origini.

In questo contesto, potrebbero esserci una torre aziendale e una torre di utenti finali:

Per fare un confronto, in un'infrastruttura incentrata sul cloud, tutti i dati non elaborati della torre di utenti finali vengono trasferiti ai server delle aziende. Al contrario, in un'infrastruttura incentrata sui dispositivi, tutti i dati non elaborati della torre degli utenti finali rimangono alla loro origine, mentre i dati dell'attività rimangono archiviati sui server.

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

Coinvolgimento pubblico inclusivo per soluzioni eque

L'obiettivo dell'ODP è garantire un ambiente equilibrato per tutti i partecipanti all'interno di un ecosistema diversificato. Siamo consapevoli della complessità di questo ecosistema, costituito da diversi attori che offrono servizi e prodotti distinti.

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

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

Utilità per sviluppatori per esperienze utente migliorate

Con ODP non si verificano perdite di dati sugli eventi o ritardi di 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.

Questa procedura semplificata elimina la necessità di unire o riorganizzare i dati, consentendo l'accesso ai dati utente quasi in tempo reale e senza perdita di dati. Ciò può migliorare l'utilità percepita dagli utenti finali quando interagiscono con prodotti e servizi basati sui dati, con un potenziale aumento dei livelli di soddisfazione e di esperienze più significative. Con l'ODP, le attività possono adattarsi in modo efficace alle esigenze dei propri utenti.

Il modello di privacy: privacy tramite riservatezza

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

Modello consumatore-produttore alla base di questa analisi della privacy

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

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

• Privacy dei dati inseriti. I nodi possono avere due tipi di input. Se un input viene generato da un nodo precedente, dispone già delle garanzie di privacy in uscita del nodo precedente. In caso contrario, gli input devono rispettare le norme sull'ingresso dei dati utilizzando il motore delle norme.
• Privacy dell'output. L'output potrebbe dover essere privatizzato, ad esempio quello fornito dalla privacy differenziale (DP).
• Riservatezza dell'ambiente di calcolo. Il calcolo deve avvenire in un ambiente chiuso in modo sicuro, garantendo che nessuno abbia accesso agli stati intermedi all'interno di un nodo. Le tecnologie che lo consentono includono calcoli federati (FC), ambienti di esecuzione attendibili (TEE) basati su hardware, calcolo multipartito sicuro (sMPC), crittografia omomorfica (HPE) e altro ancora. È importante notare che la privacy tramite le salvaguardie della riservatezza gli stati intermedi e tutti gli output che escono dal confine della riservatezza devono comunque essere protetti dai meccanismi di privacy differenziale. Due claim obbligatori sono:
  • La riservatezza degli ambienti, garantendo che solo le uscite dichiarate lascino l'ambiente e
  • Solidità, che consente deduzioni accurate delle rivendicazioni della privacy in uscita dalle rivendicazioni della privacy in entrata. L'integrità consente la propagazione della proprietà della privacy in un DAG.

Un sistema privato garantisce la privacy degli input, la riservatezza dell'ambiente di calcolo e la privacy delle uscite. 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. Innanzitutto, la maggior parte dei sistemi, grandi e piccoli, puoi essere rappresentata come un 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:

• Il post-trattamento garantisce che, una volta privatizzata, una quantità non possa essere "deprivatizzata" se i dati originali non vengono riutilizzati. Se tutti gli input di un nodo sono privati, l'output è privato, indipendentemente dai calcoli.
• La composizione avanzata garantisce che, se ogni parte del grafo è DP, lo sia anche il grafo complessivo, limitando in modo efficace ε e δ dell'output finale di un grafo rispettivamente a circa ε√κ, assumendo che un grafo abbia κ unità e che l'output di ogni unità sia (ε, δ)-DP.

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

• Proprietà 1 (da post-elaborazione): se gli input di un nodo sono tutti DP, l'output è DP, supportando qualsiasi logica aziendale arbitraria eseguita nel nodo e le "ricette 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 è in esecuzione su ambienti di esecuzione attendibili ed esegue configurazioni e carichi di lavoro open source forniti da Personalizzazione sul dispositivo, sono possibili limiti di DP più stringenti. In caso contrario, la personalizzazione sul dispositivo potrebbe dover utilizzare limiti DP peggiori. A causa delle limitazioni delle risorse, inizialmente verrà data la priorità agli ambienti di esecuzione attendibile offerti da un provider cloud pubblico.

Privacy dell'ambiente di calcolo rispetto all'accuratezza dell'output

D'ora in poi, la personalizzazione on-device si concentrerà sul miglioramento della sicurezza degli ambienti di calcolo riservati e sull'assicurazione che gli stati intermedi rimangano inaccessibili. Questa procedura di sicurezza, nota come sigillatura, verrà applicata a livello di sottografo, consentendo di rendere conformi al DP più nodi contemporaneamente. Ciò significa che la proprietà 1 e la proprietà 2 menzionate in precedenza si applicano a livello di sottografo.

In sostanza, garantendo la sicurezza dell'ambiente di calcolo ed eliminando le opportunità per gli avversari di accedere agli input e agli stati intermedi di un grafo o di un sottografo, è possibile implementare il 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 FC, TEE, sMPC e HPE come tecnologie per la privacy. Consulta il capitolo 10 di The Complexity of Differential Privacy.

Un buon esempio pratico è l'addestramento e l'inferenza dei modelli. Le discussioni riportate di seguito assumeno che (1) la popolazione di addestramento e la popolazione di inferenza si sovrappongano e (2) sia le funzionalità che le etichette costituiscano dati utente privati. Possiamo applicare la crittografia lato client a tutti gli input:

Verificabilmente privata

La personalizzazione sul dispositivo ha lo scopo di essere privata in modo verificabile. Si concentra sulla verifica di ciò che accade al di fuori dei dispositivi degli utenti. ODP scriverà il codice che elabora i dati in uscita dai dispositivi degli utenti finali e utilizzerà l'architettura delle procedure di attribuzione remota (RATS) RFC 9334 del NIST per attestare che questo codice viene eseguito invariato in un server con accesso amministrativo dell'istanza deprivilegiato conforme al Confidential Computing Consortium. Questi codici saranno open source e accessibili per una verifica trasparente al fine di instaurare la fiducia. Queste misure possono dare alle persone la certezza che i loro dati sono protetti e le attività possono creare 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. Rispetta questo principio adottando tecnologie come il calcolo federato e la privacy differenziale, che consentono di rivelare schemi di dati preziosi senza esporre dettagli individuali sensibili o informazioni identificabili.

La gestione di una traccia di controllo che registri le attività relative all'elaborazione e alla condivisione dei dati è un altro aspetto chiave della privacy verificabile. In questo modo, è possibile creare report di controllo e identificare le vulnerabilità, a dimostrazione del nostro impegno in materia di privacy.

Chiediamo collaborazioni costruttive a esperti di privacy, autorità, settori e privati per aiutarci a migliorare continuamente il design e le implementazioni.

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

Design di alto livello

Come può essere implementata la privacy tramite la riservatezza? A livello generale, un motore di criteri creato da ODP che viene eseguito in un ambiente sigillato funge da componente di base che supervisiona ogni nodo/sottografo e monitora lo stato DP delle relative input e output:

• Dal punto di vista del motore delle norme, i dispositivi e i server vengono trattati allo stesso modo. I dispositivi e i server che eseguono lo stesso motore di criteri sono considerati logicamente identici dopo che i relativi motori di criteri sono stati mutualmente attestati.
• Sui dispositivi, l'isolamento viene ottenuto tramite processi AOSP isolati (o pKVM nel lungo periodo, quando la disponibilità diventa elevata). Sui server, l'isolamento si basa su una "parte attendibile", ovvero un TEE più altre soluzioni di sigillatura tecnica preferite, un contratto o entrambi.

In altre parole, tutti gli ambienti sigillati che installano ed eseguono il motore di criteri della piattaforma sono considerati parte della nostra Trusted Computing Base (TCB). I dati possono propagarsi senza ulteriore rumore con il TCB. La crittografia lato client deve essere applicata quando i dati escono dal TCB.

Il design di alto livello della personalizzazione sul dispositivo integra efficacemente due elementi essenziali:

• Un'architettura a processo accoppiato per l'esecuzione della logica di business
• Norme e un motore di criteri per la gestione delle operazioni di entrata, uscita e consentite dei dati.

Questo design coerente offre alle aziende un ambiente in cui possono eseguire il loro codice proprietario in un ambiente di esecuzione attendibile e accedere ai dati utente che hanno superato i controlli delle norme appropriati.

Le sezioni seguenti approfondiranno questi due aspetti chiave.

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

La personalizzazione on-device introduce un'architettura di processo accoppiato in AOSP per migliorare la privacy degli utenti e la sicurezza dei dati durante l'esecuzione della logica di business. Questa architettura è composta da:

• ManagingProcess. Questo processo crea e gestisce i processi isolati, assicurandone l'isolamento a livello di processo con accesso limitato alle API consentite e senza autorizzazioni di rete o disco. Il processo di gestione gestisce la raccolta di tutti i dati aziendali, di tutti i dati degli utenti finali e delle norme, li rimuove per il codice aziendale e li invia ai processi isolati per l'esecuzione. Inoltre, media l'interazione tra IsolatedProcesses e altri processi, come system_server.

• IsolatedProcess. Designata come isolata (isolatedprocess=true nel manifest), questa procedura riceve i dati aziendali, i dati degli utenti finali approvati dalle norme e il codice aziendale da ManagingProcess. Consentono al codice aziendale di operare sui propri dati e sui dati degli utenti finali approvati dalle norme. Il processo IsolatedProcess comunica esclusivamente con il processo ManagingProcess per le operazioni di entrata e di uscita, senza autorizzazioni aggiuntive.

L'architettura a processo accoppiato offre l'opportunità di verificare in modo indipendente le norme sulla privacy dei dati degli utenti finali senza richiedere alle attività di rendere open source la logica o il codice aziendale. Poiché il processo di gestione mantiene l'indipendenza dei processi isolati e questi ultimi eseguono in modo efficiente la logica di business, questa architettura garantisce una soluzione più sicura ed efficace per preservare la privacy degli utenti durante la personalizzazione.

La figura seguente mostra questa architettura di processo accoppiata.

Norme e motori di 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 un insieme di strumenti che mappano i controlli degli utenti finali e delle attività in decisioni sui criteri centralizzate e strategiche. Questi criteri vengono poi applicati in modo completo e affidabile a tutti i flussi e alle attività.

Nell'architettura a processo accoppiato, il motore dei criteri si trova all'interno di ManagingProcess, che supervisiona l'ingresso e l'uscita dei dati dell'utente finale e dell'azienda. Fornirà inoltre le operazioni consentite alla lista consentita a IsolatedProcess. Alcuni esempi di aree di copertura includono il rispetto del controllo da parte dell'utente finale, la protezione dei bambini, la prevenzione della condivisione di dati senza consenso e la privacy aziendale.

Questa architettura di applicazione delle norme comprende tre tipi di flussi di lavoro che possono essere sfruttati:

• Workflow offline avviati localmente con comunicazioni Trusted Execution Environment (TEE):
  • Flussi di download dei dati: download attendibili
  • Flussi di caricamento dei dati: transazioni attendibili
• Workflow online avviati localmente:
  • Flussi di pubblicazione in tempo reale
  • Flussi di inferenza
• Workflow offline avviati localmente:
  • Flussi di ottimizzazione: addestramento del modello on-device implementato tramite la formazione federata (FL)
  • Flussi di generazione di report: aggregazione cross-device implementata tramite Federated Analytics (FA)

La figura seguente mostra l'architettura dal punto di vista dei criteri e degli engine di criteri.

Nel complesso, l'introduzione del livello di applicazione dei criteri e del motore di criteri all'interno dell'architettura a processo accoppiato della Personalizzazione on-device garantisce un ambiente isolato e rispettoso della privacy per l'esecuzione della logica aziendale, fornendo al contempo accesso controllato ai dati e alle operazioni necessari.

API a più livelli

On-Device Personalization fornisce un'architettura API a più livelli per le attività interessate. Il livello superiore è costituito da applicazioni create per casi d'uso specifici. Le potenziali attività possono collegare i propri dati a queste applicazioni, note come API di primo livello. Le API di primo livello si basano sulle API di secondo livello.

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 sufficientemente flessibili, le attività possono implementare direttamente le API di secondo livello, che offrono potenza e flessibilità tramite le primitive di programmazione.

Conclusione

La personalizzazione sul dispositivo è una proposta di ricerca in fase iniziale per suscitare interesse e feedback su una soluzione a lungo termine che risolva i problemi di privacy degli utenti finali con le tecnologie più recenti e migliori che dovrebbero offrire un'elevata utilità.

Vorremmo interagire con stakeholder come esperti di privacy, analisti di dati e potenziali utenti finali per garantire che l'ODP soddisfi le loro esigenze e risponda ai loro dubbi.