Privacy wordt bij de ontwik­ke­ling van software nog te vaak behan­deld als iets dat later wel kan worden geregeld. Eerst wordt een appli­catie gebouwd, worden databronnen gekop­peld en worden eventueel AI-modellen toege­voegd. Daarna kijkt iemand welke priva­cy­maat­re­gelen nog nodig zijn. Volgens Katha­rine Jarmul is dat precies de verkeerde volgorde. Privacy moet vanaf het eerste ontwerp onder­deel zijn van de techni­sche keuzes die devel­o­pers maken. Ze gaf hierover een presen­tatie tijdens de Nextcloud Commu­nity Confe­rentie die afgelopen dagen in b erlijn werd georganiseerd.

Jarmul is gespe­ci­a­li­seerd in privacy en security binnen machine learning, AI en data science. Ze schreef ook het boek Practical Data Privacy, waarin ze laat zien hoe priva­cy­tech­nieken daadwer­ke­lijk kunnen worden toege­past in data- en AI-systemen. In haar presen­tatie draaide het vooral om een eenvoudig uitgangs­punt: privacy is niet alleen een kwestie voor juristen, compli­ance-afdelingen of securi­ty­spe­ci­a­listen. Ook devel­o­pers bepalen met hun archi­tec­tuur en code hoeveel privacy gebrui­kers uitein­de­lijk hebben. Dat idee staat bekend als privacy by design.

Privacy als onderdeel van het ontwerp

Privacy by design betekent dat bescher­ming van persoons­ge­ge­vens vanaf het begin wordt meege­nomen bij het ontwerpen van een systeem. Dus niet eerst alle mogelijke data verza­melen en later proberen die gegevens af te schermen, maar al tijdens het ontwerp vragen stellen als: hebben we deze infor­matie eigen­lijk nodig? Waar wordt zij opgeslagen? Hoe lang bewaren we haar? Wie kan erbij? En wat gebeurt er wanneer een gebruiker zijn toestem­ming intrekt?

Het concept gaat terug op het werk van de Canadese privacy-expert Ann Cavou­kian. Een belang­rijk uitgangs­punt daarbij is dat privacy de standaard­in­stel­ling moet zijn. Een gebruiker zou niet eerst een lange lijst instel­lingen hoeven doorlopen om zichzelf enigs­zins te beschermen. Een systeem moet standaard zo weinig mogelijk persoon­lijke infor­matie verza­melen en delen.

Dat klinkt logisch, maar is voor devel­o­pers niet altijd eenvoudig. Jarmul wees in haar presen­tatie op een interes­sant verschil. Priva­cy­prin­cipes zijn vaak breed gefor­mu­leerd en daardoor open voor inter­pre­tatie. Engineers zijn juist gewend te werken met duide­lijke speci­fi­ca­ties, beper­kingen en ontwerpen. Een opdracht als “respec­teer de privacy van de gebruiker” is moeilijk recht­streeks om te zetten in code. De uitda­ging is daarom om algemene priva­cy­prin­cipes te vertalen naar concrete techni­sche beslissingen.

Begin met de vraag welke data echt nodig is

Een van de belang­rijkste maatre­gelen die devel­o­pers kunnen nemen, is verras­send eenvoudig: minder data gebruiken. Bij nieuwe toepas­singen ontstaat gemak­ke­lijk de neiging om zoveel mogelijk infor­matie te verza­melen. Data die vandaag niet nodig is, zou morgen misschien van pas kunnen komen. Zeker rond machine learning en AI is jaren­lang het idee ontstaan dat meer trainings­data vrijwel automa­tisch beter is.

Vanuit priva­cy­oog­punt ontstaat daarmee echter ook een groter risico. Data die nooit is verza­meld, kan immers ook niet uitlekken, worden misbruikt of voor een onver­wacht ander doel worden ingezet. Privacy by design betekent daarom dat devel­o­pers al tijdens het ontwerp bekijken welke infor­matie werke­lijk noodza­ke­lijk is voor een bepaalde functie. Kun je een aanbe­ve­ling maken zonder een volledig gebrui­kers­pro­fiel op een centrale server op te bouwen? Moet een exacte locatie worden opgeslagen of is een minder nauwkeurig gebied voldoende? Moeten gegevens jaren­lang worden bewaard als ze na enkele dagen geen functie meer hebben? Dit wordt vaak aange­duid als datami­ni­ma­li­satie, aldus Jarmul.

Breng privacyrisico’s net zo in kaart als securityrisico’s

Ze liet ook zien dat devel­o­pers privacy veel syste­ma­ti­scher kunnen behan­delen. Een voorbeeld hiervan is LINDDUN, een methode voor privacy threat modeling. Het idee lijkt op threat modeling uit cyber­se­cu­rity. Devel­o­pers brengen vooraf in kaart hoe een systeem kan worden aange­vallen of misbruikt en bouwen daartegen maatre­gelen in. Alleen kijkt LINDDUN speci­fiek naar bedrei­gingen voor privacy, zoals het kunnen koppelen van gegevens aan één persoon, het verza­melen van meer infor­matie dan noodza­ke­lijk of het ongewenst openbaar maken van gegevens.

Daarmee wordt privacy ineens een stuk concreter. Een ontwik­kel­team hoeft niet alleen de abstracte vraag te beant­woorden of een systeem “voldoende priva­cy­vrien­de­lijk” is. Het team kan per compo­nent onder­zoeken welke gegevens binnen­komen, waar ze naartoe gaan en welke privacyrisico’s daarbij ontstaan.

Dat is vooral relevant bij AI. Machine-learning­mo­dellen verwerken soms enorme hoeveel­heden gegevens en kunnen in sommige gevallen zelfs infor­matie over hun trainings­data prijs­geven. Het beschermen van de oorspron­ke­lijke database is dan niet per definitie voldoende. Ook het model en de manier waarop gebrui­kers daarmee kunnen commu­ni­ceren moeten onder­deel zijn van de risicoanalyse.

Wie zit er eigenlijk aan tafel?

Privacy by design is volgens Jarmul boven­dien niet uitslui­tend een technisch probleem. Een van haar slides stelde een simpele maar belang­rijke vraag: wie zit er bij een teamver­ga­de­ring in de kamer en wie kan zich uitspreken? Bij het ontwerpen van een toepas­sing kunnen devel­o­pers, data scien­tists, product­ma­na­gers, securi­ty­spe­ci­a­listen en priva­cy­des­kun­digen allemaal vanuit een ander perspec­tief naar dezelfde functie kijken. Een product­ma­nager wil bijvoor­beeld zoveel mogelijk infor­matie om een dienst persoon­lijker te maken. Een data scien­tist ziet interes­sante mogelijk­heden om nieuwe modellen te trainen. Een priva­cy­des­kun­dige kan onder­tussen wijzen op de risico’s die daardoor ontstaan.

Juist die discussie moet vroeg plaats­vinden. Niet wanneer de appli­catie al bijna klaar is, maar op het moment dat nog kan worden besloten hoe gegevens worden verza­meld en verwerkt.

Local-first als technische keuze

Een ander onder­werp dat Jarmul aansnijdt is de local-first-beweging. Daarbij worden gegevens waar mogelijk op het apparaat van de gebruiker verwerkt en opgeslagen, in plaats van standaard naar een centrale cloudom­ge­ving te worden gestuurd. Dat kan een krach­tige priva­cy­maat­regel zijn, vertelde ze.

Neem een appli­catie die aanbe­ve­lingen doet. Technisch is het mogelijk om alle gebrui­kers­ge­ge­vens naar een server te sturen en daar een profiel samen te stellen. Maar wellicht kan een deel van die analyse ook lokaal op een laptop of smartphone plaats­vinden. Persoon­lijke gegevens hoeven dan helemaal niet naar de aanbieder te worden gestuurd. Dat betekent niet dat iedere toepas­sing volledig lokaal moet werken. Het betekent vooral dat devel­o­pers die mogelijk­heid bewust meenemen in hun ontwerp.

Hetzelfde geldt voor instel­lingen. Jarmul laat een voorbeeld zien waarbij gebrui­kers expli­ciet kunnen aangeven of gegevens mogen worden gedeeld, uitslui­tend lokaal mogen worden opgeslagen of helemaal niet mogen worden gebruikt. Wanneer een nieuwe functie wordt toege­voegd, krijgt de gebruiker opnieuw de mogelijk­heid om daarover te beslissen. Privacy wordt daarmee onder­deel van de gebruikerservaring.

Bouw de rechten van gebruikers in de software

Ook priva­cy­rechten moeten technisch uitvoer­baar zijn. Onder de Europese AVG hebben gebrui­kers onder meer het recht om hun persoons­ge­ge­vens in te zien, gegevens te laten corri­geren of verwij­deren, bezwaar te maken tegen verwer­king en onder bepaalde omstan­dig­heden hun gegevens mee te nemen naar een andere aanbieder. 

Dat klinkt in eerste instantie als een juridisch onder­werp. Maar uitein­de­lijk moet software deze rechten mogelijk maken. Kan een organi­satie bijvoor­beeld precies terug­vinden welke infor­matie over één persoon verspreid over verschil­lende databases staat? Kunnen die gegevens vervol­gens daadwer­ke­lijk worden verwij­derd? Wat gebeurt er met back-ups? En hoe werkt dat wanneer gegevens inmid­dels zijn gebruikt voor analy­tics of machine learning?

Wanneer daar pas over wordt nagedacht nadat een gebruiker een verwijd­er­ver­zoek heeft ingediend, kan het technisch bijzonder ingewik­keld worden. Privacy by design betekent daarom dat zulke mogelijk­heden al in de archi­tec­tuur worden meegenomen.

Privacy gaat uiteindelijk over mensen

Daarmee komt Jarmul uitein­de­lijk bij een bredere boodschap. Op een van haar laatste slides vatte ze die samen als: “Respec­ting privacy is putting humans first.” Dat betekent volgens haar niet alleen nadenken over onbekende eindge­brui­kers. Het gaat net zo goed over onszelf, vrienden, familie en colle­ga’s. Devel­o­pers maken voort­du­rend keuzes over techno­logie, software, modellen en datasets. Die keuzes bepalen mede welke wereld met die techno­logie wordt gebouwd.

Daarbij horen ook nieuwe priva­cy­tech­nieken. In Practical Data Privacy behan­delt Jarmul bijvoor­beeld technieken als diffe­ren­tial privacy, federated learning en encrypted computa­tion. Zulke methoden kunnen het mogelijk maken om analyses of machine learning uit te voeren zonder alle onder­lig­gende persoon­lijke gegevens centraal en onbevei­ligd samen te brengen.

Maar privacy by design begint niet bij ingewik­kelde crypto­grafie. Het begint veel eerder, bij simpele vragen in een ontwik­kel­team. Hebben we deze gegevens echt nodig? Kunnen we het met minder doen? Kan verwer­king lokaal plaats­vinden? Wie krijgt toegang? Kunnen gebrui­kers daadwer­ke­lijk bepalen wat er met hun infor­matie gebeurt? En kunnen we gegevens ook weer verwijderen?

Juist devel­o­pers hebben daardoor veel meer invloed op privacy dan misschien wordt gedacht. Iedere database, API, standaard­in­stel­ling en AI-pipeline bevat uitein­de­lijk keuzes over gegevens. Wie privacy pas na het program­meren toevoegt, moet achteraf proberen die keuzes te repareren. Wie privacy by design toepast, maakt ze vanaf het begin bewust.