Menu
Delen van dit artikel zijn gebaseerd op de uitgebreidere blog post: Differential Privacy and Information Theory, met name betreffende de link tussen differential privacy en informatie theorie.
Differential privacy is een (relatief) nieuwe methode om gevoelige gegevens te kunnen verwerken zonder dat de gevoelige informatie kan uitlekken. Dit artikel is een korte introductie die laat zien wat het is, hoe je kunt gebruiken, en waar je voor moet oppassen.
Er zijn al verscheidene pogingen geweest om gegevens te verwerken zonder gevoelige informatie uit te lekken, maar dat liep vaak slecht af. Zo heeft Netflix internationaal veel kritiek gekregen nadat ze het kijkgedrag van een groot aantal anonieme klanten hadden gepubliceerd. Deze dataset bleek namelijk genoeg detail te bevatten om de identiteit van veel mensen te achterhalen, en daarmee ook hun volledige kijkgeschiedenis [1].
Nog verontrustender zijn pogingen in de V.S. om geanonimiseerde medische gegevens beschikbaar te maken, ook deze bleken genoeg detail te bevatten om van publieke figuren, of op basis van korte krantenartikelen, de gegevens van verscheidene personen terug te vinden [2].
Differential privacy is een robuustere manier om de data af te schermen en zo de identiteit en informatie van personen te beschermen, zonder daarbij statistisch onderzoek al te veel in de weg te zitten. Dit bereikt differential privacy door ruis toe te voegen. Hierbij is de ruis zo afgesteld dat het effect van het veranderen van de gegevens van 1 persoon niet te onderscheiden is van het effect van de ruis. Dit afstellen gebeurt met twee parameters, ε en δ. Deze regelen hoeveel informatie nog door mag lekken door de ruis.
De parameter ε is de belangrijkste. Kort samengevat bepaalt de parameter ε hoeveel effect iemands gegevens mogen hebben op de verdeling van de ruis, in wiskundige termen mag een bepaalde uitkomst slechts eε keer waarschijnlijker worden (bij benadering een toename van 100ε procent) [3].
De parameter δ is later toegevoegd om de strenge eis die ε oplegt ‘iets’ af te kunnen zwakken. Samengevat komt het er op neer dat een kans van δ voor lief wordt genomen dat de strenge eisen die ε stelt aan de ruis worden overtreden en er toch meer informatie uitlekt. Zoals blijkt is dit niet helemaal zonder risico, met name omdat er geen grenzen worden gesteld aan de hoeveelheid informatie.
Onder andere Microsoft is actief bezig om in samenwerking met Harvard in het OpenDP project een implementatie te bouwen van deze technieken. Een van de onderdelen die hier uit kwam is de Smartnoise python module.
Smartnoise geeft een aantal voorbeelden die we hier kunnen reproduceren. Hiervoor zijn twee bestanden met test data nodig PUMS.csv en PUMS.yaml, en de volgende python modules:
pip install smartnoise-sql==0.2.9
pip install pandas==1.3.5
laten we dan gelijk maar de query die smartnoise als voorbeeld geeft uitproberen:
import snsql # Smartnoise-sql module
import pandas as pd
privacy = snsql.Privacy(epsilon=1.0, delta=0.01)
csv_path = ‘PUMS.csv’
meta_path = ‘PUMS.yaml’
pums = pd.read_csv(csv_path)
reader = snsql.from_df(pums, privacy=privacy, metadata=meta_path)
result = reader.execute(‘SELECT sex, AVG(age) AS age FROM PUMS.PUMS GROUP BY sex’)
Deze query geeft een schatting van de gemiddelde leeftijd per geslacht:
pd.DataFrame(result[1:], columns=result[0])
sex | age | |
|---|---|---|
0 | 0 | 43.767490 |
1 | 1 | 46.052734 |
En we kunnen ook zien hoe hoog de de parameters ε en δ nu daadwerkelijk zijn uitgevallen:
reader.odometer.spent
(3.0, 0.014950000000000019)
bij een volgende query lopen ze beide langzaam op:
result = reader.execute(‘SELECT educ AS education, AVG(income) AS income FROM PUMS.PUMS GROUP BY educ’)
pd.DataFrame(result[1:], columns=result[0])
education | income | |
|---|---|---|
0 | 1 | 18612.875000 |
1 | 2 | 61591.470588 |
2 | 3 | 8170.743590 |
3 | 4 | 11102.470588 |
4 | 5 | 21988.461538 |
5 | 6 | 39844.000000 |
6 | 7 | 33474.833333 |
7 | 8 | 25624.549020 |
8 | 9 | 23214.661692 |
9 | 10 | 25260.566667 |
10 | 11 | 21183.359756 |
11 | 12 | 44439.129870 |
12 | 13 | 51927.943820 |
13 | 14 | 61045.611111 |
14 | 15 | 82113.541667 |
15 | 16 | 107028.818182 |
reader.odometer.spent
(6.0, 0.024800500000000003)
Tot zover lijkt dit dus precies wat is beloofd, eenvoudige berekeningen werken en de hoeveelheid informatie die uitlekt is beperkt gebleven en inzichtelijk. Sterker nog deze techniek is algemeen genoeg om toe te passen op welke query we maar willen zonder dat we bang hoeven te zijn iemands gegevens te lekken.
Tenminste, daar lijkt het op. In werkelijkheid is een delta van rond de 0.015 toch nog best hoog. We hadden namelijk ook de volgende query kunnen uitvoeren:
reader = snsql.from_df(pums, privacy=privacy, metadata=meta_path)
result = reader.execute(‘SELECT pid, race, sex, married, age, income FROM PUMS.PUMS GROUP BY pid, race, sex, age, married, income’)
df = pd.DataFrame(result[1:], columns=result[0])
df = df.set_index(‘pid’).sort_values(‘pid’)
race | sex | married | age | income | |
|---|---|---|---|---|---|
pid | |||||
196 | 1 | 0 | False | 32 | 110300 |
287 | 2 | 1 | True | 53 | 0 |
329 | 1 | 0 | True | 82 | 138300 |
339 | 4 | 0 | False | 36 | 0 |
350 | 1 | 0 | False | 40 | 38000 |
521 | 4 | 1 | True | 45 | 0 |
541 | 3 | 1 | False | 40 | 17100 |
612 | 3 | 1 | False | 23 | 13000 |
716 | 4 | 1 | True | 35 | 26700 |
717 | 1 | 0 | True | 83 | 10800 |
736 | 1 | 0 | False | 37 | 152000 |
790 | 4 | 0 | False | 31 | 47000 |
828 | 3 | 1 | False | 41 | 38000 |
868 | 3 | 0 | True | 26 | 13000 |
931 | 3 | 0 | True | 29 | 17200 |
963 | 1 | 1 | True | 76 | 0 |
En dat lijkt er toch verdacht veel op dat er gegevens uitlekken. We kunnen het ook vergelijken met de originele dataset om vast te stellen dat het inderdaad de originele data is.
df.join(pums.set_index(‘pid’)[[‘race’, ‘sex’, ‘age’, ‘married’, ‘income’]],
rsuffix=’_original’)
race | sex | married | age | income | race_original | sex_original | age_original | married_original | income_original | |
|---|---|---|---|---|---|---|---|---|---|---|
pid | ||||||||||
196 | 1 | 0 | False | 32 | 110300 | 1 | 0 | 32 | 0 | 110300.0 |
287 | 2 | 1 | True | 53 | 0 | 2 | 1 | 53 | 1 | 0.0 |
329 | 1 | 0 | True | 82 | 138300 | 1 | 0 | 82 | 1 | 138300.0 |
339 | 4 | 0 | False | 36 | 0 | 4 | 0 | 36 | 0 | 0.0 |
350 | 1 | 0 | False | 40 | 38000 | 1 | 0 | 40 | 0 | 38000.0 |
521 | 4 | 1 | True | 45 | 0 | 4 | 1 | 45 | 1 | 0.0 |
541 | 3 | 1 | False | 40 | 17100 | 3 | 1 | 40 | 0 | 17100.0 |
612 | 3 | 1 | False | 23 | 13000 | 3 | 1 | 23 | 0 | 13000.0 |
716 | 4 | 1 | True | 35 | 26700 | 4 | 1 | 35 | 1 | 26700.0 |
717 | 1 | 0 | True | 83 | 10800 | 1 | 0 | 83 | 1 | 10800.0 |
736 | 1 | 0 | False | 37 | 152000 | 1 | 0 | 37 | 0 | 152000.0 |
790 | 4 | 0 | False | 31 | 47000 | 4 | 0 | 31 | 0 | 47000.0 |
828 | 3 | 1 | False | 41 | 38000 | 3 | 1 | 41 | 0 | 38000.0 |
868 | 3 | 0 | True | 26 | 13000 | 3 | 0 | 26 | 1 | 13000.0 |
931 | 3 | 0 | True | 29 | 17200 | 3 | 0 | 29 | 1 | 17200.0 |
963 | 1 | 1 | True | 76 | 0 | 1 | 1 | 76 | 1 | 0.0 |
toch is er niet veel van het ‘privacy-budget’ besteed
print(reader.odometer.spent)
(1.0, 0.014950000000000019)
Wat is hier aan de hand? Nou dit is dus een voorbeeld hoe δ aangeeft wat de kans mag zijn dat er toch gegevens uitlekken. We zien dat δ hier zo’n 1.5% is, en inderdaad zijn zo’n 1.5% van de rijen van de originele dataset uitgelekt. Het is natuurlijk altijd een afweging hoe hoog deze lat gelegd moet worden, maar in dit voorbeeld is de lat wel heel laag, zeker gezien het soort gegevens waar het over gaat.
Een hogere δ levert dus problemen op. Gelukkig is het niet nodig om deze δ erg hoog te zetten, sterker nog hij kan ook op 0 worden gezet. Dit maakt veel soorten bewerkingen echter wel heel moeilijk. Zo zijn er technieken om differential privacy te combineren met machine learning (zie bijvoorbeeld SA-DPSGD) maar die hebben over het algemeen wel een δ nodig die hoger is dan 0 (met name vanwege het gebruik van normaal verdeelde ruis, die veel fijnere eigenschappen heeft om mee te werken dan de laplaciaanse ruis die nodig is voor ε-privacy).
Een andere manier om tegen deze perikelen aan te kijken is dat δ simpelweg de verkeerde knop is om aan te draaien. Hoewel het vanuit een praktisch oogpunt wel handig kan zijn om soms iets meer informatie door te laten lekken bepaalt δ alleen maar hoe vaak dat mag voor komen, niet hoeveel informatie er mag uitlekken (mogelijk een gevolg van het feit dat differential privacy meestal niet vanuit een informatie theoretisch perspectief wordt bekeken).
Door op een informatie theoretisch manier naar privacy te kijken zijn er ook andere manieren mogelijk om de hoge eisen van differential privacy iets af te zwakken. Dit is ook de voornaamste conclusie van het artikel Differential Privacy and Information Theory, namelijk dat het prima mogelijk is om op een verantwoorde manier iets minder strenge eisen te hanteren zolang je de stromen van persoonlijke informatie in de gaten houdt en beperkt. Vanuit dit oogpunt is het ook wat duidelijker dat differential privacy een veilig manier is om persoons-gegevens te verwerken precies omdat het de persoons-informatie beschermt.
Dit perspectief sluit echter nog niet zo goed aan met dat van wetten zoals de AVG en GDPR. Deze hanteren termen als ‘gegevens’ ‘informatie’ en ‘verwerken’ ongehinderd door enige domeinkennis. Zo krijg je dat informatie gelijk word gesteld aan gegevens (feitelijk onjuist, een ge-encrypt bestand is een gegeven maar is niet informatief zonder de sleutel), en dat de wet grote moeite heeft om het verschil te duiden tussen gegevens die eenvoudig aan iemand te koppelen zijn (naam/adres) en gegevens die iemand wel uniek identificeren maar niet op eenvoudige wijze (bijv. vakantiedagen). Hiermee worden belangrijke eigenschappen van informatie zoals de ‘gegevensverwerking ongelijkheid’ (dat het verwerken van gegevens altijd minder informatie teruggeeft dan er origineel in zat) in het begrippenkader van de AVG totale onzin.
Maar hoewel je vanuit een natuurkundig perspectief zou kunnen beargumenteren dat alle gegevens die een datacentrum verwerkt uiteindelijk weglekken als restwarmte, is dit niet hoe de wet in de praktijk wordt toegepast. Vanuit praktisch oogpunt wordt het verwerken van bijvoorbeeld geaggregeerde en getransformeerde gegevens die niet meer te herleiden zijn naar een persoon wel degelijk toegestaan.
Echter ontstaan hierbij wel vragen, zoals hoeveel personen je moet aggregeren voordat een totaal ‘niet meer ter herleiden is naar een persoon’, met welke precisie je de cijfers mag rapporteren, en hoeveel gerelateerde gegevens je publiek kunt maken voordat het problematisch wordt. Om hier verstandige keuzes te maken en te voorkomen dat informatie lekt waar dat niet moet en toepassingen worden verboden waar dat niet hoeft is een techniek met een goed gefundeerde theorie als die van differential privacy noodzakelijk.
