Blogs

Blog #3: Pragmatische privacy voor programmeurs

In deel 1 en 2 hebben we een eenvoudige Kitchen Sink app gemaakt om te laten zien hoe je op een pragmatische manier kunt omgaan met privacy, en in het bijzonder met de AVG. In dit deel proberen we een nogal vage eis uit AVG te tackelen: privacy by design.

Nog een beetje theorie

In het vorige deel hebben we zes verantwoordelijkheden van verwerkers van persoonsgegevens met betrekking tot de AVG besproken (rechtmatigheid, doelmatigheid, minimale gegevensverwerking, juistheid, opslagbeperking en integriteit & vertrouwelijkheid). Op dat moment lieten we een zevende verantwoordelijkheid links liggen: verantwoordingsplicht. Die wordt gespecificeerd als zowel het verantwoordelijk zijn dat de vorige zes worden uitgevoerd, als het kunnen aantonen dat dit het geval is.

De wettekst noemt vervolgens diverse maatregelen die je kunt of moet nemen. Veel hiervan, zoals contracten met bewerkers of een functionaris gegevensbescherming, zijn juridisch of organisatorisch van aard en zijn meer geschikt om elders te bespreken. Een van de maatregelen is echter zeer interessant voor ICT’ers: gegevensbescherming door ontwerp en standaardinstellingen (“data protection by design and default”).

Privacy door standaardinstellingen is een interessant concept: gegevens van personen worden beschermd zonder dat ze daar actief iets voor hoeven doen. Dit is mijns inziens grotendeels redundant met de rest van AVG, want de definitie verwijst vooral naar andere eisen, zoals doelbinding en opslagbeperking.

De definitie van privacy by design is, zoals veel juridische teksten, niet heel precies. Gelukkig heeft Privacy by Design (PbD), een van de inspiraties voor AVG, een nuttigere definitie. Deze 7 fundamentele principes uit de jaren ’90 stellen namelijk dat: “[privacy] is niet iets wat als een extraatje achteraf wordt toegevoegd”. Laten we kijken hoe we dit voor Kitchen Sink kunnen toepassen.

Increment 2 (vervolg)

In increment 2 begonnen we met een feature waarmee gebruikers hun postadres konden invullen. Dat stelt ons in staat ze een afdruk van een foto van een afvoerputje op te sturen. Deze adressen zijn persoonsgegevens, en vallen onder de AVG. We hebben een overzicht gemaakt van alle geldende principes, hoe we deze ingevuld hebben, en hoe we kunnen controleren dat deze invulling nog werkt (idealiter automatisch). Dat resulteerde in de volgende tabel:

Tabel 1
Principe Invulling Controle
Rechtmatigheid Contractuele verplichting Contract (foreign key)
Doelbinding Toegangsbeperking Test
Minimale gegevensverwerking PostNL adresvelden Test
Juistheid Validatie gebruikersinvoer Contract (kolomchecks)
Opslagbeperking Automatisch verwijderen Test
Opslagbeperking Rolling backups Test
Integriteit en vertrouwelijkheid HTTPS Test
Integriteit en vertrouwelijkheid Veilige componenten Test
Integriteit en vertrouwelijkheid Sterke authenticatie -

We gaan verder met deze aanpak, en voegen “privacy by design” toe als principe op de lijst. Hoe kunnen we deze eis invullen en controleren?

Tabel 2
Principe Invulling Controle
Privacy by design N.t.b. N.t.b.

Invulling

Iets “by design” doen wordt algemeen als een goed idee beschouwd, maar het ook uitvoeren is een ander verhaal. Er zijn geen duidelijke stappen of activiteiten die leiden tot dit doel. PbD helpt ons hier helaas niet. Het beste wat ze hebben is een documentatie-standaard, Privacy by Design for Software Engineers. Helaas is dit alleen een lijst van documentatie die geschreven zou moeten worden. Deze lijst komt niet alleen weinig agile over, hij is ook niet erg specifiek. Zo is een van de regels: “documentatie zal een privacy-architectuur bevatten”, maar nergens wordt uitgeweid over wat dat precies is, en hoe het er uit zou moeten zien.

Gelukkig zijn er ook meer concrete bronnen. ENISA, het agentschap van de EU voor netwerk- en informatiebeveiliging geeft een zeer goed overzicht van privacy by design. In het bijzonder presenteert het een instrument dat ideaal is voor ons doel: privacyontwerpstrategieën.

Deze strategieën zijn ontwikkeld door associate professor Hoekman, die daarover een uitstekend kort boek schreef. Hij identificeert 8 strategieën om met privacy om te gaan bij het ontwerpen. Deze kunnen we als controles opnemen in onze tabel, zodat we zeker weten dat we alle mogelijkheden van privacy by design hebben overwogen.

In verband met lengte ga ik hier alleen in op de eerste vier strategieën (Minimaliseer, Scheid, Abstraheer, Verberg). De andere vier zijn procesgeoriënteerde strategieën. Deze zijn zeker waardevol, maar ze zijn minder technisch gericht en overlappen bovendien met andere AVG-vereisten die we elders in deze serie behandelen. Dat wil niet zeggen dat ze bij elke ontwerp kunnen worden overgeslagen: ze gaan verder dan de wet, en bieden dus meer mogelijkheden tot privacy.

Strategie 1: Minimaliseer

In deel 2, spraken we al over minimaliseren van persoonsgegevens. We slaan alleen attributen op die we echt nodig hebben en alleen voor gebruikers die daadwerkelijk een foto willen. Maar we zouden nog verder kunnen gaan en overwegen of we überhaupt persoonsgegevens nodig hebben. Voor ons geval kan ik me niet bedenken hoe dit zou kunnen, maar in veel andere situaties is het wel degelijk mogelijk. Bijvoorbeeld, bij het maken van een mobiele applicatie voor iOS is het mogelijk om pushberichten te versturen naar gebruikers zonder dat je een telefoonnummer, Apple ID of ander persoonsgegeven nodig hebt. In plaats daarvan krijg je een token die je moet gebruiken om de berichten naar Apple te versturen, die vervolgens zorgt dat het op het juist apparaat wordt afgeleverd.

Een andere insteek is om gebruikers een alternatief te bieden waarbij ze hun persoonsgegevens niet hoeven te delen. Wellicht willen sommigen de foto’s persoonlijk komen afhalen bij mij thuis of, beter nog, een afhaalpunt bij hen in de buurt. Sommige bezorgdiensten bieden die mogelijkheid, en het is de moeite waard dit te overwegen. Natuurlijk heeft dit ook impact buiten privacy: wellicht is het duurder om zo’n dienst te gebruiken of worden gebruikers die ver van zo’n afhaalpunt wonen wel afgeschrikt.

Strategie 2: Scheid

Een ideale scheidingsstrategie zou zijn om de persoonsgegevens in het beheer van de eigenaar te laten en niet op onze servers. Dit lijkt me voor Kitchen Sink geen realistische optie, maar initiatieven zoals die van Tim Berners-Lee maken dat in de toekomst wellicht mogelijk.

Maar eenvoudigere scheidingsopties zijn ook nu al beschikbaar. We kunnen zorgen dat het deel van de app dat de adressen uit de database ophaalt afgezonderd is van de website. Ook kunnen we zorgen dat de database en de webserver door verschillende (fysieke of virtuele) servers worden gehost. Beide stappen zijn redelijk en eenvoudig te nemen.

Strategie 3: Abstraheer

Hoepman beschrijft abstraheren als het “uitzoomen” bij gegevens. Deze aanpak hebben we in deel 1 van de serie al toegepast, toen we een deel van IP-adressen weglieten, zodat we minder precieze gegevens hadden, maar voldoende voor onze verkeersanalyse.

Voor de adresgegevens die we verzamelen werkt zo’n aanpak niet: we hebben een exact adres nodig om de foto te kunnen bezorgen. Maar, stel dat we statistieken zouden willen bijhouden over waar we foto’s heen sturen, dan zouden we deze aanpak kunnen gebruiken, en bijvoorbeeld alleen de woonplaats of de provincie bewaren.

Strategie 4: Verberg

In Kitchen Sink hebben we al enkele stappen genomen om persoonsgegevens te verbergen. Toegang tot de gegevens is beperkt, alleen de persoon die daadwerkelijk de enveloppen verstuurt mag adressen uit de database lezen. Bovendien zijn de adressen niet gekoppeld aan andere persoonsgegevens (b.v. IP-adressen).

Meer verbergen is ook mogelijk: we zouden bijvoorbeeld de gegevens in de database kunnen versleutelen. Dat lijkt echter beperkt waardevol in ons geval, terwijl het de technische complexiteit wel verhoogt.

Samenvatting

Met de bovenstaande overwegingen kunnen we zeggen dat we geprobeerd hebben privacy by design toe te passen. Natuurlijk moeten we dit kunnen aantonen. Een linkje naar een ontwerpdocument met deze beslissingen en overwegingen is hiervoor afdoende. Dat kan een formeel document zijn, maar ook een wiki of een bestand met platte tekst.

Dit geeft ons de volgende tabel:

Tabel 3
Principe Invulling Controle
Privacy by design Checklist & documentatie

Minimaliseer
Scheid
Abstraheer
Verberg
Informeer
Geef controle
Dwing af
Toon aan

In het volgende deel van de serie gaan we verder met deze increment, want de rechten van de eigenaar van onze adresgegevens zijn nog niet geborgd.

Ondertussen zijn deze twee bronnen aanbevolen voor verdieping:

Over de auteur

Jeroen Heijmans is Java-developer bij het Rijks ICT Gilde (RIG). Bij het RIG krijgen onze collega's de tijd om hun vakkennis te delen binnen en buiten de Rijksoverheid. Jeroen deelt zijn kennis met andere Java-developers, engineers en programmeurs middels deze blog.

Reactie toevoegen

U kunt hier een reactie plaatsen. Ongepaste reacties worden niet geplaatst. Uw reactie mag maximaal 2000 karakters tellen.

Uw reactie mag maximaal 2000 karakters lang zijn.

Reacties

Er zijn nu geen reacties gepubliceerd.