Il concetto di privacy budget è fondamentale in ogni metodo di differential privacy, che sappiamo essere il sistema attraverso cui misurare un modo generico la fuoriuscita d’informazione privata da un dataset.
Abbiamo definito la differential privacy nel nostro post introduttivo, e quando nell’ultima riflessione sul PATE Framework, trattata qui, siamo entrati nuovamente in contatto con il concetto di privacy budget abbiamo reputato opportuno dedicargli uno spazio a sé.
Facciamo un rapido, nonché fondamentale, racap!
Ti svelo una regola fondamentale: privacy comes from uncertainty.
Sappiamo che la differential privacy si basa sull’aggiunta di rumore casuale (random noise) ai dati (sappi che non sempre è cosi, ma per il momento ci accontentiamo della definizione).
Un buon esempio è quello della perturbazione di un’immagine che, come puoi vedere sotto, diventa presto irriconoscibile. A questo punto preserviamo la privacy, incrementando l’anonimizzazione, riducendo però l’utilità del dato.
Si delinea quindi un compromesso, che abbiamo avuto modo di approfondire con il post sul Privacy-vs-Utility tradeoff, e che trovi qui!
Privacy budget & Epsilon
Devi sapere una cosa.
A livello matematico, il parametro che gestisce il compromesso tra privacy e utility è definito epsilon (ε).
Aldilà delle funzioni matematiche in cui è definito, è utile in casi applicativi e quindi va conosciuto.
Cerchiamo di capire come funziona.
Ora, le cose si complicano un pochino.
Saremmo tutti molto felici se bastasse semplicemente aggiungere del rumore casuale a garanzia di privacy.
Prendi un dataset, generi il rumore, lo applichi e dormi sogni tranquilli.
Limitandoci a questa operazione, ogni nuova query effettuata su un dataset ne ridurrebbe l’anonimizzazione.
Perché?
Il problema è di natura statistica: aggregando i risultati è possibile ricostruire i dati originali filtrando il rumore attraverso la media.
Come lo risolviamo?
Bellissima domanda!
Risposta breve? Fissiamo un limite al numero di query che un utente può compiere.
Noi amanti di eleganza e raffinatezza, preferiamo una risposta precisa e dettagliata, a una rozza, seppur breve spiegazione.
Una metafora
Allora lascia che ti accompagni in questa riflessione.
Metaforicamente parlando, creiamo una moneta che ci viene pagata a ogni interrogazione del dataset.
Il bello è che siamo la noi la banca che decide quant moneta immettere nel mercato, fornendo all’utente un budget.
Quando l’utente finisce il denaro, raggiungendo il budget, non può più acquistare l’informazione.
Ovviamente un’informazione precisa, fornita in risposta a una query, ha un costo per noi maggiore di una approssimativa, poiché diminuisce il livello di privacy nei dati trasmessi.
È però l’utente a decidere quanto sia disposto a pagare in funzione della precisione che intende ricevere.
Fuori di metafora, il parametro epsilon corrisponde al costo pagato che intacca il bilancio complessivo, il nostro privacy budget.
Tanto più piccolo è il valore di epsilon, quanto minore è l’accuratezza del risultato restituito, che sarà in questo caso fortemente perturbato dal rumore, per ben preservare la privacy.
Al contrario, un alto valore per epsilon fornirà un risultato più accurato, ma quindi meno protetto, con un livello di privacy inferiore.
Attenzione però: la metafora della “banca” è un po’ fuorviante.
Epsilon è proporzionale al tuo privacy budget.
Questo implica che tanto minore è il suo valore, quante meno volte avrai accesso ai dati.
In caso contrario, riusciresti a de-anonimizzare i dati.
Quindi puoi decidere di usare tutto il tuo budget per pochi dati precisi, o fare più query in cambio di minore accuratezza:
Per maggiori approfondimenti ti esorto a leggere l’articolo di Max Hansen, che impiega una metafora meno finanziaria della nostra ma senz’altro più utile.
Per il momento è tutto.
Un caldo abbraccio, Andrea.
