De gemeente Enschede komt onder een boete van de Autoriteit Persoonsgegevens ter hoogte van 600.000 euro uit, las ik bij Nu.nl. Met behulp van sensoren werd tussen 2018 en 2020 gemeten hoe druk het in de binnenstad van Enschede was. De AP meende dat daarmee de AVG werd geschonden, de rechter oordeelt anders.
Bij wifi-tracking wordt het signaal van mobiele telefoons gebruikt om groepen mensen in de gaten te houden. In de praktijk gebruiken bedrijven deze techniek bijvoorbeeld in en rond winkelcentra of andere (semi-)openbare plekken. Meestal gaat het dan om via Bluetooth verkregen gegevens, maar ook Wifi signalen kunnen worden gebruikt om tot een identifier te komen.
De gemeente was erg boos over de boete. Ik citeer de wethouder:
Weliswaar was het niet de intentie van Enschede om mensen te volgen, maar het kon gewoon gebeuren bij lang genoeg tellen. De wethouder: “Het feit dat de AP die suggestie wel heeft gewekt in haar boetebesluit en in haar media-uitingen, vindt het college van Enschede zeer kwalijk”.Het achterliggende probleem was volgens mij een verschil van inzicht over de betekenis van “ik zie daar een mens, daar nog een mens en achterin twee mensen, er zijn dus vier mensen” versus “daar loopt Jentje Nijhuis en daar achterin Teun de Vries”. Dat laatste is evident een vorm van identificeren, maar bij “ik zie daar iemand” kun je je afvragen of dat wel hetzelfde niveau van identificatie is.
Voor de AVG maakt dit niet echt uit: ook “ik zie daar iemand” en daar bepaalde gegevens aan koppelen is een verwerking van persoonsgegevens. Dat je de naam uit het paspoort niet weet en redelijkerwijs niet kunt krijgen, is geen argument daar tegenin. Maar in deze zaak werden de nodige maatregelen genomen:
(…) dat in het kader van de beoogde passantentelling in de binnenstad van Enschede in de periode van 25 mei 2018 tot en met 30 april 2020 met tien sensoren het MAC-adres is opgevangen van eigenaren/gebruikers van mobiele apparaten waarop de wifi stond ingeschakeld. De MAC-adressen werden tijdelijk op het werkgeheugen van de sensor opgeslagen en vervolgens gehasht (gepseudonimiseerd), waarna het gehashte MAC-adres direct naar de server van PFM werd doorgestuurd. Op de server werden van het gehashte MAC-adres (sedert 1 januari 2019) de laatste drie karakters afgeknipt.Na die ene seconde in dat werkgeheugen bleef dus alleen een hash van het MAC-adres over, die na een paar seconden op de server drie karakters kwijt raakte, wat het reconstrueren van het MAC-adres nog knap ingewikkeld maakt. De vraag wordt dan serieus of zo’n gehandicapte hash nog wel telt als persoonsgegeven.
De rechter oordeelde in deze zaak van niet, omdat de AP een wel érg ingewikkelde bocht had gekozen:
12. De rechtbank constateert dat de AP haar besluiten in essentie heeft gebaseerd op de mogelijkheid voor eiser om natuurlijke personen aan de hand van gehashte, gepseudonimiseerde en afgeknipte MAC-adressen ter plaatse te identificeren. Hierbij gaat de AP in de genoemde manieren uit van de mogelijkheid dat een medewerker van de door eiser ingeschakelde bureaus of een medewerker van eiser zelf op enig moment in de vroege ochtend, als er weinig mensen op straat zijn, ter plaatse in staat zou kunnen zijn om vast te stellen dat een specifieke, unieke gebruiker van een mobiel apparaat zich binnen het bereik van een sensor bevindt en deze persoon dan mogelijk zou kunnen identificeren.Die motivatie is te weinig. De AP had moeten onderzoeken of dit redelijkerwijs te verwachten viel, of dat het ook daadwerkelijk zou gebeuren. Een zuiver theoretische route van identificatie is te weinig.
Interessanter was voor mij geweest als de AP had gesteld dat ook de gehandicapte hash nog een persoonsgegeven was. De kans dat twee mensen in Enschede aldaar passeren met MAC-adressen die hashen tot hetzelfde getal (de laatste drie tekens negerend) lijkt me namelijk minimaal, zodat die handi-hash volgens mij nog steeds een identifier is in die context. En nee, je weet niet het echte MAC-adres laat staan de paspoortnaam van de telefoonhouder, maar dat is dus irrelevant.
Arnoud
Een hash code is in praktisch uniek, zelfs als je wat tekens weg zou laten. Met zowel het originele als de verknipte variant kan je weinig tot niets, maar strict gezien kan het in deze context door het unieke karakter dan toch wel onder een persoonsgegeven geschaard worden.
Maar je kunt niet van een hashcode bij een persoon komen. Je kunt het niet omkeren (en het meet-bedrijf kan prima een geheim woord achter de MAC plakken om te zorgen dat jij ze niet kan uitrekenen). Ja, door iemand te volgen en dan in de database te kijken of die persoon dat patroon volgt. Maar de essentie van de AVG is toch dat je met een database vol identifiers mensen kunt identificeren, en niet dat je op toevalsbasis met veel werk de kans hebt dat je mogelijk één willekeurige, niet specifieke persoon misschien kunt terugleiden naar je database.
Mijn eerste vraag is “Welke hash functie is gebruikt?” Het maakt veel uit hoeveel bits overblijven na het afkappen van de laatste tekens. Een MAC is 48 bits groot, haal je die door MD5 heen dan krijg je een hash van 128 bits. Kap je de laatste 3 bytes af, dan houd je 104 bits over.
Wil je controleren of een bepaald toestel in jouw bijgehouden lijst voorkomt, dan kun je de MAC door de hele procedure halen en kijken of de afgekapte hash ergens in jouw tabel voorkomt; je bent, omdat je ten opzichte van de MAC extra bits hebt, vrijwel 100% zeker qua accuraatheid.
De analyse wordt wat anders als je na het weggooien van de laatste bits minder bits overhoudt dan het oorspronkelijke MAC had. De zekerheid van de match is dan minder dan 100%, maar als er na afkappen nog 32 bits over blijven (dit levert 4 miljard unieke codes op) dan kun je nog steeds met grote nauwkeurigheid een aan jou bekend MAC volgen.
Ja, in theorie zou het systeem gebruikt kunnen worden om iemand hinderlijk te volgen. Bij de basisopzet is wel gedacht aan privacy en met een paar procedurele maatregelen is het echt privacyvriendelijk te maken.
Hi Arnout. Je schrijft: “Voor de AVG maakt dit niet echt uit: ook “ik zie daar iemand” en daar bepaalde gegevens aan koppelen is een verwerking van persoonsgegevens. Dat je de naam uit het paspoort niet weet en redelijkerwijs niet kunt krijgen, is geen argument daar tegenin.”
Hoe verhoudt dit zich tot C-582/14 (Breyer) waar het HvJ concludeerde dat dynamische IP adressen geen persoonsgegevens zijn indien degene die ze verzamelt geen wettige en praktische mogelijkheden heeft om de betrokken persoon te identificeren?
Dat is een goede vraag. Ik denk dat het erin zit dat Breyer de Richtlijn betreft, en dat we nu met de AVG zitten waar een brédere definitie van persoonsgegevens zit.
Rl: “a) “persoonsgegevens”, iedere informatie betreffende een geïdentificeerde of identificeerbare natuurlijke persoon, hierna “betrokkene” te noemen; als identificeerbaar wordt beschouwd een persoon die direct of indirect kan worden geïdentificeerd, met name aan de hand van een identificatienummer of van een of meer specifieke elementen die kenmerkend zijn voor zijn of haar fysieke, fysiologische, psychische, economische, culturele of sociale identiteit;”
AVG: “1) “persoonsgegevens”: alle informatie over een geïdentificeerde of identificeerbare natuurlijke persoon (“de betrokkene”); als identificeerbaar wordt beschouwd een natuurlijke persoon die direct of indirect kan worden geïdentificeerd, met name aan de hand van een identificator zoals een naam, een identificatienummer, locatiegegevens, een online identificator of van een of meer elementen die kenmerkend zijn voor de fysieke, fysiologische, genetische, psychische, economische, culturele of sociale identiteit van die natuurlijke persoon;”
Ik zie hierin een uitbreiding: het hebben van enige ‘identificator’ is genoeg. Daarmee verschuift het IP-adres van een middel om tot identificatie te komen naar een identificator, oftewel onder de AVG héét jij 127.0.0.1.
Noch Breyer, noch enige andere uitspraak of guidelines of wat dan ook heeft ooit een uitspraak gedaan over wát een identificatie is. Ik krijg altijd de ondertoon dat men ergens toch vindt dat het moet gaan om je paspoortnaam, maar tegelijkertijd vindt men wel dat cookies persoonsgegevens zijn ook al zit daar normaal van alles in behálve je naam. Dus waarom is een cookie met “thx1137/interesse:auto’s,voetbal;salaris:40-80k;geslacht:man” wél een persoonsgegeven maar een logfile met “09Feb24-14:30 127.0.0.1 GET /” géén persoonsgegeven?
Wat ze ons bij de Master Gegevensbeschermingsrecht van de OU vertellen is dat de vraag of iets een persoonsgegeven is relatief is. Dus een datum (enkelvoud van meervoud data) kan voor de één wel een persoongeven zijn en voor de ander niet omdat het voor die ander niet mogelijk is om de gegevens te herleiden naar een uniek persoon. Zulks zou kunnen blijken uit de al eerder aangehaalde Breyer zaak, maar ook uit T-557/20 – SRB (GAR) v EDPS.
Met die logica in de hand zou ik de cookie “thx1137/interesse:auto’s,voetbal;salaris:40-80k;geslacht:man” geen persoonsgegevens noemen voor mij, want ik kan die verder niet koppelen aan een persoon. Het zou dan voor de web site beheerder wel een persoonsgegeven kunnen zijn, afhankelijk wat ze nog meer van mij weten.
Het cookie is toch gekoppeld aan een persoon? Je weet van alles over die persoon. De redenering die jij aanhaalt, veronderstelt dat je pas iemand identificeert als je een náám weet. Ik blijf er moeite mee houden dat dat de standaard moet zijn.
Ik snap deze nog steeds niet. Ik bedenk een willekeurig IP adres, hier: 188.17.4.51.
Alle IP adressen zijn ongeveer 4 jaar geleden uitgegeven, dus dit IP adres is toegekend en het is nu een persoonsgegeven.
Ik kan weliswaar niet achterhalen wie dit is, maar ergens kan iemand dit wel, dus ben ik nu in overtreding. En Arnoud ook omdat dit op zijn website staat.
Je moet onderscheid maken tussen pure identificatie en informatie die aan een persoon te koppelen is. Alleen “Jan Jansen” is een identificatie, maar “Jan Jansen winkelt bij de Lidl” is een persoonsgegeven, want het vertelt iets over Jan.
Op vergelijkbare wijze is het IP adres een “sleutel” waaraan een (of meer) persoon gekoppeld kan worden. Maar de kale sleutel zegt niets over deze persoon. Pas wanneer je informatie aan deze sleutel gaat toevoegen krijg je persoonsgegevens. In het geval van Enschede werden locatiegegevens aan een ethernetadres gekoppeld: MAC a:b:c:d:e:f is op j/m/d-u:m:s in de buurt van access point x.
(Voor het gemak negeer ik even het bestaan van dynamische IP allocatie.)
Ik denk dat dit juist extra goed aantoont dat het persoonsgegevens zijn, ook al voer je de beschreven bewerkingen er op uit. Het gaat daarbij niet om de lijst met hashes als startpunt en dat je daarmee vanalles kan gaan achterhalen. Of dat je van al die mensen de paspoortnaam wel of niet weet. Je moet het andersom bekijken: het startpunt is een bepaalde telefoon waarvan je dat wel weet. Als je die weet, kun je daarna over die persoon (telefoon) alle bewegingen reconstrueren, ook met deze aanpak.
Bijvoorbeeld als de politie/gemeentelijke opsporingsambtenaren/e.d. iemand verdenkt, dan kunnen ze met zekerheid diens specifieke macadres achterhalen. Dat macadres (gehasht, afgekapt) kun je naast de lijst leggen van de wifi-metingen waarna er met hoge zekerheid een match is. Dan weet je dus instantaan wanneer en waar die verdachte allemaal heeft rondgelopen. Dat lijkt mij inderdaad een grote inbreuk om dat ongericht allemaal te verzamelen.
Er zijn maximaal 2^48 MAC-adressen. Met enige moeite is die hash wel met brute force te inverteren.
Maar wat je nou daadwerkelijk meer als je een MAC-adres hebt ipv een hash ervan. Goed, het model van de telefoon, maar ook dan heb je geen naam. Zoals Thijs beschrijft ligt het echte gevaar erin dat als je een apparaat voor je hebt liggen, je kan achterhalen waar en wanneer die in Enschede is geweest (of eventueel zal komen), en dat doe je net zo goed met die hash als met het MAC-adres zelf.
(Anderzijds is het altijd wel goed te realiseren dat hashen bij een te kleine originele verzameling dingen geen enkel nut heeft.)
Dit is niet correct. Voor een MAC-adres worden 48 bits gebruikt, maar die kun je niet allemaal random kiezen. De eerste 24 bits bevatten speciale informatie, in de praktijk meestal een code voor de vendor of het hardware type van de netwerkchip. De laatste 24 bits zijn dan een serienummer voor de chip. Samen met de eerste 24 bits moet dat dan een uniek adres geven. De meeste serienummer-reeksen worden maar gedeeltelijk gebruikt. Ik schat dat voor iemand die de moeite neemt om een lijstje te maken van in gebruik zijnde nummerreeksen, het eenvoudig is om het aantal te proberen adressen terug te brengen tot ver onder de 2^35.
Een andere benadering is om domweg een lijstje te maken van alle MAC-adressen die je in Nederland tegenkomt. Dan hoef je nog maar zo’n 10 miljoen adressen te proberen. Maar ja, zo’n lijstje mag je volgens de trouwe lezers van dit blog niet bijhouden.
Ik meen van Arnoud vernomen te hebben dat een datum een persoonsgegeven kan zijn als de politie deze kan herleiden naar een persoon. Als de politie de database met hashes op kan vragen, dan kan deze mogelijk ook de gebruikte hashing code opvragen (zie bijvoorbeeld de Key Disclosure Law in Verenigd Koninkrijk).
In het scenario waar de politie toegang heeft tot de telefoon/MAC address van een verdachte, kan het a) direct vertalen naar hash middels de hashing code b) de telefoon nabij de tracker te plaatsen, en daarna de hash uit de database halen. Dus dan, hash of geen hash, het blijft een persoonsgegeven, want de politie kan zeggen: “De telefoon van verdachte was in de binnenstad vorige week zaterdag”?
Bluetooth en Wifi zijn duidelijk bedoeld voor internet-verbinden en koppelen van randapparatuur. Dit gebruiken voor tracken is eigenlijk misbruik. Je kan Bluetooth en Wifi wel uitzetten (soort van opt-out), maar dan werkt je telefoon niet meer met je koptelefoon. Je moet verzamelde gegevens gewoon gebruiken voor je doel en de gegevens zo snel mogelijk vernietigen als de verzamelstatistieken zijn gemaakt; en eigenlijk gewoon toestemming vragen (of tenminste melding maken a la “U wordt gefilmd”).
Er zijn andere methodes om dit gewoon goed te doen, recht te doen aan privacy en veiligheidsrisico’s, bijvoorbeeld differentiele privacy, bloom filters, gerandomiseerde en gesampelde verzameling en meer. Maar om technische redenen is dit is hier helemaal niet relevant! Om te tellen hoe veel MAC-adressen in de binnenstad zijn hoef je alleen maar een teller te hebben en niets op te slaan. Je gaat pas op slaan, als je return-visitors wil onderscheiden van unieke bezoekers, zodat je MAC-adressen kunt vergelijken. Maar iOS en Android (ruime meerderheid) doet al jaren aan MAC-randomisatie bij “proben”/checken welke netwerken of devices in de buurt zijn: De gemeente is dus unieke bezoekers ruim aan het overschatten en slaat gegevens op waar ze helemaal geen correcte statistiek uit kan halen!
Wil je weten hoeveel bezoekers in de binnenstad? Tel gewoon iedereen en sla alleen dat nummer op. Geen gezeur met privacy of gesjoemel met onjuiste hash truncatie zonder privacy garantie (die je wel met differentiele privacy hebt, maar dat is te moeilijk voor het marketing bureau dat deze techniek verkocht heeft). Wil je echt weten hoeveel return-bezoekers, dan moet je verdedigen waarom dat je daar dan een hele bak aan data-opslag mee nodig hebt. Is mogelijkheid tot de-anonimiseren of persoonsgegevens overhandigen dat waard? Voor mij niet! Houd gewoon een goede enquete tot deze statistisch representatief is voor al de bezoekers en vraag over herhaalbezoeken. Dan heb je toestemming. Je slaat niets op. Je hebt de correcte cijfers (niet de random MAC’s tellen als uniek), en met een kleine beloning voor meedoen geef je een redelijke vergoeding in ruil voor informatie, zonder het zomaar uit te lezen.
Boete niet broodnodig, maar in het zonlicht brengen en een berisping op zijn plaats. Dat de gemeente dan boos is en niet hand in eigen boezem steekt, is als een kind met een woedeaanval. Wachtwoorden of persoonsgegevens opslaan? Je hebt de verantwoording naar het vakgebied en naar de personen toe dat op een juiste en veilige manier te doen.
Privacy gaat er niet alleen om of ik uit de opgeslagen gegevens kan achterhalen welke persoon daarbij hoort, maar gaat er ook om dat als ik iets van iemand weet (in casu het MAC-adres van iemands telefoon) ik uit de opgeslagen gegevens kan achterhalen wat die persoon allemaal in Enchede gedaan heeft tussen 2018 en 2020. Ik mis dit tweede aspect in de discussie.