Violazione della privacy anche quando le domande con troppo pochi risultati vengono rifiutate

Penso che quello che il libro dice sia che se riesci a trovare una query così specifica che ci sono solo pochi risultati, puoi identificare un particolare target nel database.

Ad esempio, se un concessionario di automobili disponeva di un database di clienti e "anonimizzava" il database per includere solo codice di avviamento postale, marca, modello, anno, colore e stipendio, potresti trovare lo stipendio del tuo vicino se sai che comprato una macchina da quel rivenditore.

Ad esempio, puoi eseguire una query che seleziona lo stipendio di tutte le persone che possiedono una Volt 2012 Chevy verde nel tuo codice postale. Se hai solo una manciata di documenti che mostrano gli stipendi di 20K 30K 40K e 300K e sai che il tuo vicino è un avvocato di successo, puoi indovinare che ha lo stipendio di 300K.

Ma se il sistema ha rifiutato di mostrare meno di 100 risultati, è più difficile trovare il target come un set di risultati.

Risposta semplice:

Se è consentita una query SQL, puoi anche aumentare artificialmente il conteggio dei record facendo qualcosa come UNION SELECT myKnownRecord alla fine.

Risposta più generale:

Questo problema fa parte di una più ampia famiglia di strategie nota come de-anonimizzazione. Uno dei metodi per evitare la divulgazione involontaria quando altri metodi come l'applicazione di k-anonimato, l'aggregazione, l'arrotondamento e i dati di sfocatura o grossolanità non funzionano, stanno eliminando i risultati per i piccoli gruppi.

La ragione principale per cui questo metodo di restrizione delle query che risultano in intervalli limitati non funziona universalmente è che ci sono molti altri modi per ottenere un quadro completo di ciò che sta accadendo anche se non si guardano i risultati con meno di 5 voci.

Supponiamo di avere diversi criteri a, b e c. L'insieme A è l'insieme di tutti i record che soddisfano i criteri a, l'insieme A ∩ B è l'insieme di tutti i record che corrispondono ai criteri a e b (corrispondenti a un JOIN SQL o un'operazione simile), ecc.

Supponiamo che A ∩ B ∩ C sia un set abbastanza piccolo per identificare i record per il nostro obiettivo (A ∩ B ∩ C ha meno di cinque elementi). Tuttavia, un criterio di registrazione minimo ci impedisce di vedere direttamente A ∩ B ∩ C. Tuttavia, potremmo visualizzare A ∩ B, A ∩ C e A ∩ B, quindi fare manualmente un'unione di due di quelli per ottenere un'unione l'unione vogliamo A ∩ B ∩ C. Questo tuttavia, assumendo che il risultato desiderato sia unico. Se i record non sono univoci (affermano che sono voti delle lettere, categorie di reddito, risposte sì / no o una media basata sui record restituiti), il tuo non può fare join manuali e non riesco a pensare a un modo universale per ottieni i valori esatti.

Le unioni (outer join) potrebbero anche essere usate occasionalmente per aggirare questa strategia di protezione. Se sai che il tuo obiettivo è uno dei pochi membri del set A (forse perché i risultati per A erano nascosti) potremmo esaminare i risultati aggregati per AUC e qualsiasi risultato vicino allo 0% o 100% si applicherebbe al nostro target in A.

Un altro modo per aggirare questa protezione è usare altri risultati per sottrarre la nostra strada al risultato che vogliamo. Se sappiamo che ci sono 120 persone su 160 che hanno superato i voti nel set A, e 120 su 157 hanno voti in A ∩ B, quindi anche se A ∩ B '(A e non B) è nascosto perché troppo pochi risultati sappiamo già che nessuno sta passando in quel gruppo. Questo di solito può essere evitato se evitiamo la divulgazione di quante voci ci sono in ogni set, arrotondando le percentuali in modo aggressivo o raggruppando le percentuali in categorie ("< 5%" o 3% invece del 3,1%).

Per utilizzare un esempio (modificato da quello fornito dal National Center for Education Statistics), ad esempio una scuola rivela che solo un maschio americano indiano / Alaskan Native student è stato iscritto nel 2010. Se la scuola rivela il tasso di laurea per questo gruppo demografico, la privacy dell'individuo è stata compromessa. La privacy dello studente potrebbe anche essere violata se i gruppi complementari possono essere utilizzati per ottenere un quadro completo dello studente, come il tasso di laurea dello 0% per gli indiani d'America / Alaskan nativi o che tutti gli altri dati demografici ammontano al 100% dei laureati.

Per fornire un contesto, L. Sweeney di Carnegie Mellon ha fatto uno studio che ha concluso: "È stato scoperto che combinazioni di poche caratteristiche spesso si combinano in popolazioni per identificare in modo univoco o quasi unico alcuni individui. Chiaramente, i dati rilasciati contenenti tali informazioni su questi individui non devono essere considerati anonimi, tuttavia, la salute e altri dati specifici sono disponibili pubblicamente in questo modulo. sono alcuni risultati sorprendenti che utilizzano solo tre campi di informazione, anche se le versioni di dati tipici contengono molti più campi ... anche a livello di contea, {contea, genere, data di nascita} sono in grado di identificare in modo univoco il 18% della popolazione statunitense. In generale, sono necessarie poche caratteristiche per identificare in modo univoco una persona. " Identificazione personale e de-anonimizzazione è stata dimostrata per un database di transazioni con carta di credito che erano state ingenuamente anonimizzato. Quindi anche query così semplici come "tutti i record con questo genere, DOB e area geografica" o "le persone che hanno visitato questi quattro negozi di recente e hanno speso circa $ 50" rischiano di compromettere seriamente la privacy. Poiché questo tipo di documenti come data di nascita e città possono essere combinati per de-anonimizzare i dati, HIPAA, FERPA e standard simili sono scritti per limitare severamente ogni tipo di divulgazione di queste informazioni.

In breve, come Anupam Datta di CMU ha detto , "I meccanismi di anonimizzazione naïve non funzionano."

Selezionandolo solo tramite una query SQL, puoi controllare il suggerimento su questa domanda . Entrambe le risposte sono più o meno uguali ( JOIN , quando il tipo non è specificato, il valore predefinito è INNER JOIN nella maggior parte dei RDBMS comunque).

Questo è tuttavia un modo molto inefficiente di produrre risultati con un numero minimo di record. Molto più semplice, ma anche più veloce, sarebbe quello di verificare il numero richiesto di record prima di visualizzare i risultati nel codice generando front-end e quindi decidere se elencare i record corrispondenti o visualizzare un messaggio di errore non divulgativo.

Questo è più semplice perché non è necessario modificare le query SQL esistenti per soddisfare questo nuovo requisito, più veloce perché non esiste alcun collegamento interno per aggregare i set di risultati, e anche più conveniente poiché ti verrà richiesto di gestire entrambi i casi nel tuo codice di front-end comunque.

In sostanza, tutto ciò che devi fare è visualizzare lo stesso messaggio (o simile) quando la query restituisce meno di n record, come in precedenza con set di risultati vuoti.

Esempio indipendente dalla lingua:

query.run;
if (query.recordcount >= 6) {
  display_results(query);
} else {
  error(minimum_not_reached);
}

che sostituisce:

query.run;
if (query.recordcount > 0) {
  display_results(query);
} else {
  error(no_results);
}

Ovviamente il messaggio di errore restituito non dovrebbe rivelare i record minimi richiesti ed è probabilmente meglio mantenere minimum_not_reached uguale a no_results . Il che accade anche molto più comodo, se stai modificando un codice esistente, dato che richiede a malapena qualsiasi modifica (% da% di% a% di% di conversione).

A seconda dell'RDBMS in uso, questo potrebbe essere ottenuto anche con stored procedure ;)