Personalizzazione sul dispositivo: personalizzazione con protezione della privacy avanzata

Destinato a essere implementato in Android Open Source Project (AOSP), questo explainer tecnico illustra la motivazione alla base della personalizzazione on-device (ODP), i principi di progettazione che ne guidano lo sviluppo, il modello di privacy tramite riservatezza e in che modo contribuisce a garantire un'esperienza verificabile e privata.

Prevediamo di raggiungere questo obiettivo semplificando il modello di accesso ai dati e assicurandoci che tutti i dati utente che escono dal perimetro di sicurezza siano differenzialmente privati a livello di (utente, adottante, istanza_modello) (a volte abbreviato in livello utente in questo documento).

Tutto il codice relativo alla potenziale 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 faciliti le opportunità di personalizzazione on-device. Invitiamo le parti interessate, 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à potrebbero 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 dipendono non solo dalla regola di personalizzazione generata dal proprietario dell'attività, ma anche dalle preferenze 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 vengano anonimizzati correttamente utilizzando i meccanismi di privacy differenziale appropriati.

Il nostro piano attuale prevede l'esplorazione di ODP in più milestone, che coprono 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 sandbox in cui è contenuta ed eseguita tutta la logica di business, che consente a una moltitudine di indicatori dell'utente finale di entrare nella sandbox limitando gli output.

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

   1. Controlli utente e altri dati correlati all'utente. Questi possono essere forniti dall'utente finale o raccolti e dedotti dalle aziende, insieme a controlli di durata (TTL), criteri di cancellazione, 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 nei round di elaborazione successivi,
      2. con rumore in base ai meccanismi di privacy differenziale appropriati e caricati negli endpoint idonei.
      3. Caricati utilizzando il flusso di caricamento attendibile in Trusted Execution Environments (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 il punto 2, in batch o in modo incrementale.
   2. Aggiorna periodicamente il punto 2(b), in batch o in modo incrementale.
   3. Carica 2(c), con meccanismi di rumore appropriati in ambienti di aggregazione attendibili. Questi risultati potrebbero diventare 2(b) per i cicli di elaborazione successivi.

Cronologia

Questo è il piano attuale di riferimento per il test di ODP in versione beta. La tempistica è soggetta a modifiche.

Funzionalità	H1 2025	T3 2025
Addestramento e inferenza sul dispositivo	Contatta il team di Privacy Sandbox per discutere le potenziali opzioni da testare durante questo periodo di tempo.	Inizia l'implementazione sui dispositivi Android T+ idonei.

Design principles

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

Modello di dati a torre per una maggiore protezione della privacy

ODP segue il principio della Privacy by Design ed è progettato con la protezione della privacy dell'utente finale come impostazione predefinita.

ODP sta valutando la possibilità di spostare l'elaborazione della personalizzazione sul dispositivo di un utente finale. Questo approccio bilancia privacy e utilità mantenendo i dati sul dispositivo il più possibile e trattandoli al di fuori del dispositivo solo quando necessario. L'ODP si concentra su:

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

Di conseguenza, la personalizzazione sarà specifica per dispositivo.

Inoltre, le attività richiedono anche misure per la privacy, che la piattaforma dovrebbe affrontare. Ciò comporta la manutenzione dei dati aziendali non elaborati nei rispettivi server. Per raggiungere questo obiettivo, ODP adotta il seguente modello dati:

1. Ogni origine dei dati non elaborati verrà archiviata sul dispositivo o sul lato server, consentendo l'apprendimento e l'inferenza locali.
2. Forniremo algoritmi per facilitare il processo decisionale in più origini dati, ad esempio il filtraggio tra due posizioni dei dati diverse o l'addestramento o l'inferenza in varie origini.

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

A titolo di confronto, in un'infrastruttura incentrata sul cloud, tutti i dati non elaborati della torre dell'utente finale vengono trasferiti ai server delle aziende. Al contrario, in un'infrastruttura incentrata sui dispositivi, tutti i dati non elaborati della torre dell'utente finale rimangono all'origine, mentre i dati dell'azienda rimangono archiviati sui server.

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

Coinvolgimento pubblico inclusivo per soluzioni eque

L'ODP mira a garantire un ambiente equilibrato per tutti i partecipanti all'interno di un ecosistema diversificato. Siamo consapevoli della complessità di questo ecosistema, che è 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 attività che rappresentano. La personalizzazione on-device facilita l'integrazione perfetta di queste implementazioni durante la gestione delle release, il monitoraggio, gli strumenti per sviluppatori e gli strumenti di feedback. La personalizzazione on-device non crea alcuna logica di business concreta, ma funge da catalizzatore per la creatività.

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

Utilità per sviluppatori per migliorare l'esperienza utente

Con ODP non si verifica alcuna perdita di dati sugli eventi o ritardi nell'osservazione, in quanto tutti gli eventi vengono registrati localmente a livello di dispositivo. Non sono presenti 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 riorganizzare i dati, consentendo l'accessibilità ai dati degli utenti quasi in tempo reale e senza perdita. 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 e a esperienze più significative. Con ODP, le attività possono adattarsi in modo efficace alle esigenze dei propri utenti.

Il modello di privacy: privacy tramite riservatezza

Le sezioni seguenti descrivono il modello consumer-producer 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 di privacy della privacy tramite 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 utilizzati, output prodotti e mappatura del calcolo degli input agli output.

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 precedente, ha già le garanzie di privacy dell'output di quel nodo. In caso contrario, gli input devono cancellare i dati in entrata utilizzando il motore delle norme.
• Privacy dell'output. L'output potrebbe dover essere reso privato, ad esempio quello fornito dalla privacy differenziale (DP).
• Riservatezza dell'ambiente di calcolo. Il calcolo deve avvenire in un ambiente sigillato in modo sicuro, garantendo che nessuno abbia accesso agli stati intermedi all'interno di un nodo. Le tecnologie che lo consentono includono Federated Computations (FC), Trusted Execution Environment (TEE) basati su hardware, Multi-Party Computation (sMPC) sicura, crittografia omomorfica (HPE) e altro ancora. È importante notare che la privacy tramite le misure di salvaguardia della riservatezza degli stati intermedi e di tutti gli output che escono dal limite di riservatezza deve comunque essere protetta dai meccanismi di privacy differenziale. Le due dichiarazioni obbligatorie sono:
  • Riservatezza degli ambienti, garantendo che solo gli output dichiarati lascino l'ambiente e
  • Correttezza, che consente deduzioni accurate delle rivendicazioni di privacy dell'output dalle rivendicazioni di privacy dell'input. La solidità consente la propagazione della proprietà di privacy in un DAG.

Un sistema privato mantiene la privacy dell'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 un maggior numero di elaborazioni all'interno di un ambiente di calcolo confidenziale.

Questo modello offre due vantaggi principali. Innanzitutto, la maggior parte dei sistemi, grandi e piccoli, può essere rappresentata come un DAG. In secondo luogo, le proprietà di post-elaborazione [sezione 2.1] e composizione del lemma 2.4 in The Complexity of Differential Privacy forniscono strumenti potenti per analizzare il compromesso tra privacy e precisione (nel caso peggiore) per un intero grafico:

• Il post-processing 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, anche il suo output è privato, indipendentemente dai calcoli.
• La composizione avanzata garantisce che se ogni parte del grafico è DP, lo è anche il grafico complessivo, limitando efficacemente ε e δ dell'output finale di un grafico di circa ε√κ, rispettivamente, 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 ogni nodo:

• Proprietà 1 (da post-elaborazione) se gli input di un nodo sono tutti DP, il suo output è DP, per adattarsi a qualsiasi logica di business arbitraria eseguita nel nodo e supportare le "ricette segrete" delle attività.
• 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 viene eseguito in ambienti di esecuzione attendibili ed esegue carichi di lavoro e configurazioni forniti da On-Device Personalization open source, sono possibili limiti di DP più rigorosi. In caso contrario, la personalizzazione on-device potrebbe dover utilizzare i limiti DP nel caso peggiore. A causa dei vincoli delle risorse, inizialmente verranno date priorità agli ambienti di esecuzione attendibili 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 confidenziale e sul garantire che gli stati intermedi rimangano inaccessibili. Questa procedura di sicurezza, nota come sigillatura, verrà applicata a livello di sottografo, consentendo di rendere conformi alla 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, proteggendo l'ambiente di calcolo ed eliminando le opportunità per gli avversari di accedere agli input e agli stati intermedi di un grafico o di un sottografo, ciò consente l'implementazione di DP centrale (ovvero l'output di un ambiente sigillato è conforme alla DP), il che può migliorare l'accuratezza rispetto alla DP locale (ovvero i singoli input sono conformi alla 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 del modello. Le discussioni riportate di seguito presuppongono che (1) la popolazione di addestramento e quella di inferenza si sovrappongano e (2) che sia le caratteristiche che le etichette costituiscano dati utente privati. Possiamo applicare DP a tutti gli input:

Privata in modo verificabile

La personalizzazione sul dispositivo mira a essere verificabile come privata. Si concentra sulla verifica di ciò che accade al di fuori dei dispositivi degli utenti. ODP creerà il codice che elabora i dati che escono dai dispositivi degli utenti finali e utilizzerà l'architettura RFC 9334 Remote ATtestation procedureS (RATS) del NIST per attestare che questo codice viene eseguito senza modifiche in un server con privilegi ridotti conforme al Confidential Computing Consortium. Questi codici saranno open source e accessibili per una verifica trasparente per creare fiducia. Queste misure possono dare agli individui la certezza che i loro dati siano protetti e le aziende possono stabilire la propria reputazione sulla base di una solida base di garanzia della privacy.

Ridurre la quantità di dati privati raccolti e archiviati è un altro aspetto fondamentale della personalizzazione on-device. Rispetta questo principio adottando tecnologie come il calcolo federato e la privacy differenziale, consentendo la rivelazione di preziosi pattern di dati senza esporre dettagli individuali sensibili o informazioni identificabili.

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

Chiediamo la collaborazione costruttiva di esperti di privacy, autorità, settori e privati per aiutarci a migliorare continuamente la progettazione e le implementazioni.

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

Progettazione di alto livello

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

• Dal punto di vista del motore delle norme, dispositivi e server vengono trattati allo stesso modo. I dispositivi e i server che eseguono lo stesso motore delle policy sono considerati logicamente identici una volta che i rispettivi motori delle policy sono stati attestati reciprocamente.
• Sui dispositivi, l'isolamento viene ottenuto tramite processi isolati AOSP (o pKVM a lungo termine una volta che la disponibilità diventa elevata). Sui server, l'isolamento si basa su una "parte attendibile", ovvero un TEE più altre soluzioni tecniche di sigillatura preferite, un accordo contrattuale o entrambi.

In altre parole, tutti gli ambienti sigillati che installano ed eseguono il motore delle norme della piattaforma sono considerati parte della nostra Trusted Computing Base (TCB). I dati possono propagarsi senza rumore aggiuntivo con TCB. La protezione dei dati deve essere applicata quando i dati escono dal TCB.

La progettazione di alto livello di Personalizzazione on-device integra efficacemente due elementi essenziali:

• Un'architettura a processi accoppiati per l'esecuzione della logica di business
• Norme e un motore delle norme per la gestione dell'importazione, dell'esportazione e delle operazioni consentite dei dati.

Questo design coeso offre alle aziende un campo di gioco equo in cui possono eseguire il proprio codice proprietario in un Trusted Execution Environment 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 elaborazione accoppiata in AOSP per migliorare la privacy degli utenti e la sicurezza dei dati durante l'esecuzione della logica di business. Questa architettura è costituita da:

• ManagingProcess. Questo processo crea e gestisce IsolatedProcesses, garantendo che rimangano isolati a livello di processo con accesso limitato alle API consentite e senza autorizzazioni di rete o disco. ManagingProcess gestisce la raccolta di tutti i dati aziendali, di tutti i dati degli utenti finali e delle norme li cancella per il codice aziendale e li inserisce 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 approvati dalle norme e codice aziendale da ManagingProcess. Consentono al codice aziendale di operare sui propri dati e sui dati degli utenti finali per i quali è stata verificata la conformità alle norme. IsolatedProcess comunica esclusivamente con ManagingProcess sia per l'ingresso che per l'uscita, senza autorizzazioni aggiuntive.

L'architettura a processi accoppiati offre l'opportunità di una verifica indipendente delle norme sulla privacy dei dati degli utenti finali senza richiedere alle attività di rendere open source la logica o il codice aziendale. Con ManagingProcess che mantiene l'indipendenza di IsolatedProcesses e IsolatedProcesses che esegue in modo efficiente la logica di business, 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 accoppiata.

Norme e motori delle norme per le operazioni sui dati

La personalizzazione on-device introduce un livello di applicazione delle norme tra la piattaforma e la logica di business. L'obiettivo è fornire un insieme di strumenti che mappano i controlli per gli utenti finali e le aziende in decisioni strategiche centralizzate e attuabili. Questi criteri vengono poi applicati in modo completo e affidabile a tutti i flussi e le attività.

Nell'architettura a processi accoppiati, il motore dei criteri si trova all'interno di ManagingProcess, che supervisiona l'ingresso e l'uscita dei dati aziendali e degli utenti finali. Fornirà anche le operazioni consentite a IsolatedProcess. Le aree di copertura di esempio includono il rispetto del controllo dell'utente finale, la protezione dei minori, la prevenzione della condivisione di dati non consensuale e la privacy aziendale.

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

• Flussi di lavoro offline avviati localmente con comunicazioni Trusted Execution Environment (TEE):
  • Flussi di download dei dati: download attendibili
  • Flussi di caricamento dei dati: transazioni attendibili
• Flussi di lavoro 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 Federated Learning (FL)
  • Flussi di report: aggregazione cross-device implementata tramite Federated Analytics (FA)

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

Nel complesso, l'introduzione del livello di applicazione dei criteri e del motore dei criteri nell'architettura di elaborazione accoppiata della personalizzazione on-device garantisce un ambiente isolato e rispettoso 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

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 connettere i propri dati a queste applicazioni, note come API di livello superiore. Le API del livello superiore si basano su quelle del livello intermedio.

Nel tempo, prevediamo di aggiungere altre API Top-layer. Quando un'API di livello superiore non è disponibile per un caso d'uso specifico o quando le API di livello superiore esistenti non sono abbastanza flessibili, le attività possono implementare direttamente le API di livello intermedio, che offrono 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 affronti i problemi di privacy dell'utente finale con le tecnologie più recenti e migliori che dovrebbero portare un'elevata utilità.

Vorremmo interagire con le parti interessate, come esperti di privacy, analisti di dati e potenziali utenti finali, per assicurarci che ODP soddisfi le loro esigenze e risponda ai loro dubbi.