Don’t scan random QR-codes

Portrait of Dave Borghuis, for my Shoot ALL the Hackers! project. Foto by dvanzuijlekom

Hi, so you scanned my QR code. I am a friendly guy so nothing bad happened, but an evil person could do harm to your phone or go to a bad website. So next time think before scanning a random QR code from an untrusted source.

If you want to check a possible unknown url/qr code you could use https://www.url2png.com/ to see what the site is.

Greetings,
Dave

Bezwaar gemeente Enschede

Gemeente Enschede heeft (zoals al aangegeven bij bekendmaking boete) bezwaar ingediend tegen besluit van AP.

Kort samengevat gaat gemeente volledig tegen het besluit in. Gemeente Enschede geeft in hun bezwaarschrift met 10 argumenten aan waarom zij de boete niet zouden moeten ontvangen. Meest tekende vind ik het argument dat er niet voldoende (technisch) onderzocht word en dat er aannames gemaakt zijn. Als je het rapport leest vind ik het juist wel goed technisch onderlegt. Er word gekeken wat er op de acces point zelf gebeurt en er is zelfs gekeken naar de broncode van het programma die deze opstuurt naar de server. Naar mijn inzicht kun je niet veel verder gaan dan dat.

Ik ben niet thuis in rechtelijke processen en hoe deze verlopen, maar ik krijg wel een beetje de indruk dat gemeente Enschede hier alles uit de kast haalt en tegen de muur gooit in de hoop dat er iets blijft plakken. In artikel ‘tijdschrijft voor internetrecht’ verscheen artikel waarin rechtelijk naar deze situatie gekeken werd en AP gelijk werd gegeven mbt de opgelegde boete.

Dit bezwaar word in eerste instantie behandeld door AP zelf, als hierover een uitspraak komt zul je het natuurlijk van me horen.

RMC : “This is fine”

Dit artikel is aanvulling op mijn vorige artikel over boete AP aan de gemeente Enschede.

Mijn conclusie is dat ondanks alle beloftes van RMC de gegevens NIET anoniem zijn. Indien de gegevens echt anoniem zou zijn kun je niet leefpatronen uit de data halen. Het feit dat Autoriteit Persoonsgegeven (AP) in hun rapport heeft aangetoond dat dit wel kan (voor 4 personen, o.a. een nachtelijke wandelaar) geeft aan dat de ‘CittyTraffic methode’ niet afdoende is om de gegevens te anonimiseren. Bovendien moet privacy belang worden afgewogen tegen belang van bijhouden statistieken. Hierbij geeft AP aan dat je onbespied moet kunnen rond bewegen, dus wifitracking niet is toegestaan.

RMC geeft aan dat men niet de methode heeft aangepast sinds 1 januari 2019, dus de situatie nu is nog gelijk aan wat AP heeft onderzocht en in hun rapport hebben aangegeven.

Het lijkt me dat gemeenten die de wifi tracking van RMC (en andere soortgelijke partijen) gebruiken nog eens goed kijken naar de uitslag van AP en zich kritisch opstellen naar RMC. Deze partij levert wel de dienst maar krijgen niet te boete, de gemeente krijgt deze en zij zijn ook de partij die nu risico op de boete lopen.

RMC heeft naar aanleiding van uitspraken AP een FAQ gemaakt. Naar mijn mening word het wel erg positief voorgesteld voor RMC, dus hieronder herhaal ik de vragen waarbij ik commentaar heb.

Korte samenvatting :

  • Gegevens worden niet voor 24 uur maar uiteindelijk voor 6 maanden opgeslagen.
  • Sensor staat op een specifieke lokatie, de wifi gegevens kun je hiermee combineren.
  • Van MAC adres word een hash gemaakt van 9 posities. Deze is nog steeds uniek genoeg om een telefoon (en dus persoon) te volgen, wat AP dan ook voor 4 personen heeft gedaan (vanaf pg 48 rapport). Zie ook artikel AP over hashes.

FAQ RMC nav uitspraak AP

Bezoekerstellingen middels wifi, hoe werkt dat?

Eigenlijk is de methode vergelijkbaar met de ouderwetse handklikker. Wij tellen en turven, maar dan automatisch aan de hand van wifi-signalen. Alleen als wifi op een smartphone staat ingeschakeld wordt deze dus geteld.

De wifi-sensoren registreren alle passanten die een apparaat bij zich hebben en daarop wifi aan hebben staan (het apparaat zendt regelmatig zogenaamde probe requests). De wifi-sensor registreert het MAC-adres, tijdstip en signaalsterkte. Dus niet de locatie.

Sensor staat op locatie, dus deze is wel bekend en word later in de statistieken ook hiermee gekoppeld.

Het MAC-adres wordt op de sensor gepseudonimiseerd.

Hash naar 12 posities

Als de sensor gedurende een bepaalde tijd geen signaal meer ontvangt, dan wordt de status aangepast. De data worden met vertraging doorgestuurd naar een centrale server waar de data worden geanonimiseerd en verder worden verwerkt om tot tellingen te komen.

Dezelfde hash maar dan 9 posities (laatste 3 posities verwijderd). Nog steeds uniek

De bewerkingen worden slechts gedaan om te komen tot het aantal bezoekers. De data worden op geen andere wijze bewerkt en/of geanalyseerd en niet langer dan noodzakelijk opgeslagen maar nooit langer dan 24 uur.

Dagtabel is max 24 uur, deze word overgezet naar database waar het 6 maanden wordt opgeslagen.

De tellingen van Citytraffic zijn vergelijkbaar met de methode hoe files in Nederland worden gemeten. De methode voldoet aan alle Europese wetgeving.

Waar worden de verzamelde gegevens voor gebruikt?

De gegevens kunnen worden gebruikt om de drukte in een winkelstraat te meten. Dit levert hele relevante en noodzakelijke informatie op in het kader van openbare bestuur en veiligheid. Het is informatie die door zowel lokale als nationale overheidsorganen wordt gebruikt, zeker bij de bestrijding van de coronapandemie.

Verzamelen van gegevens moet worden afgewogen met belang privacy burgers. AP concludeert dat privacy gegeven zwaarder wegen dan belangen van gemeente. Bovendien zijn er andere privacy vriendelijke methoden beschikbaar, wifitracking is niet de enige manier om bezoekersaantallen te verkrijgen.

Deze gegevens worden ook gebruikt door retailers die vergelijkingen maken met hun eigen bezoekersaantallen of beter personeel willen plannen.

Op basis van deze informatie kan er worden besloten om de toegang tot een winkelstraat tijdelijk te beperken, wanneer blijkt dat het te druk wordt, of worden winkeltijden in algemene zin aangepast

Wat is het verschil tussen wifi-tracking en wifi-tellen?

Bij wifi­-tracking worden individuen gevolgd, aaneengesloten in tijd en plaats. Een wi­fi-telling is gericht op het tellen van groepen op een bepaald moment op een bepaalde plaats. Het verschil tussen wifi­-tracking en wi­fi-telling is simpel: Passanten worden niet gevolgd, maar geteld. Er is niet bekend wie zij zijn, waar zij wonen, waar zij naar toe gaan en welke winkels zij binnen gaan. Buiten het bereik (20meter) van de sensor wordt niets gemeten.

De telefoon kan worden gevolgd door de stad omdat die een uniek (hash) nummer krijgt. Iedere sensor waar deze langs komt krijgt deze hetzelfde hash en dus zou je hem kunnen volgen. AP geeft 4 voorbeelden in rapport dat ze aan hand van de data mensen kunnen volgen.

Hoe anonimiseren jullie de telgegevens?

Om te voorkomen dat een MAC-adres kan worden herleid naar één specifiek apparaat, wordt dit bij telling direct omgezet naar een ander willekeurig nummer op de sensor.

Een MAC adres word omgezet naar hash, hiermee heb je nog steeds een uniek nummer. Iedere keer als je de hash uitrekent van MAC krijg je dezelfde uitkomst, dus kun je terugkijken in de database of je het eerder gezien hebt. Op deze manier kunnen ze zien of je een nieuwe bezoeker bent. Je kunt dezelfde hash terug zijn bij andere sensors, zelfs in andere steden waar RMC deze methode gebruikt. Zo zou je een bezoeker in zowel Enschede als Hengelo terug kunnen zien.

Hierdoor versturen de sensoren nooit MAC-adressen naar de server waar de ruwe tellingen worden verwerkt. CityTraffic werkt alleen met deze niet bestaande nummers. Zodra dit nummer aankomt op de server, wordt het geanonimiseerd.

Hash word word afgeknipt van 12 naar 9 posities, hiermee is het nog steeds uniek.

Dat betekent dat het voor de tweede keer wordt veranderd. We kunnen daarna nooit het nummer meer herleiden naar één apparaat.

Een hash werkt inderdaad maar 1 kant op, maar geeft wel altijd hetzelfde resultaat. Je kunt dus wel kijken of een bepaalde MAC adres dezelfde hash geeft en zo later koppelen met de gegevens in de database. Ik snap hier niet de opmerking ‘tweede keer wordt veranderd’, er word een hash uitgerekend en als het naar server gestuurd worden de laatste 3 posities afgeknipt.

Tot slot wordt de informatie maximaal 24 uur bewaard. De methode voldoet daarmee aan alle Europese wetgeving.

De hash van 9 posities word inderdaad eerst 24 uur opgeslagen in een tijdelijke tabel, deze worden dan dagelijks omgezet naar definitieve database waarin het 6 maanden in opgeslagen blijft.

Wat is de reden dat de AP een boete heeft opgelegd in de zaak rondom wifi-tellingen?

De AP is van mening dat de gemeente zonder grondslag indirecte persoonsgegevens (Mac-adressen) heeft verwerkt van eigenaren/gebruikers van mobiele apparaten waarop de wifi stond ingeschakeld in de binnenstad van Enschede, wifitracking genaamd door de AP. De gemeente Enschede heeft bezwaar aangetekend tegen dit besluit.

We zijn zeer ongelukkig met de boete voor een van onze opdrachtgevers en vinden deze disproportioneel. Het bezwaar van de Gemeente Enschede tegen dit besluit wordt door ons ondersteund. Het tellen van passanten is, zeker in tijden van een pandemie, van groot maatschappelijk belang.

Tellen moet worden afgewogen tegen privacy belang. Dat we nu in periode van covid zitten veranderd dit niet.

Tellen op basis van wifi is daarmee een privacy-veilige en nauwkeurige manier om bijvoorbeeld de drukte in een winkelstraat te meten. Een MAC-adres is niet direct te herleiden naar een individu. Gemeente Enschede telt en volgt niet!

Gegevens zijn wel te traceren naar personen, AP heeft aan de hand van data 4 leefpatronen gemaakt. Als je bekend bent met leefpatronen zou je via een camera of ter plekke kunnen kijken wie dit is. Cittytrafic methode volgt telefoons (en hiermee personen)

Welk standpunten heeft de Gemeente Enschede ingenomen?

De gemeente kan zich niet vinden in deze uitspraak en beraadt zich op eventuele vervolgstappen. De gemeente Enschede neemt de privacy en de bescherming van persoonsgegevens van haar inwoners zeer serieus. Bij de opdrachtverlening voor de wifimetingen in 2017 is binnen het kader van de destijds geldende privacywet- en regelgeving gewerkt. Toen een jaar later de Algemene Verordening Gegevensbescherming (AVG) werd ingevoerd, is actief gehandeld om ook aan de AVG te voldoen. De Autoriteit Persoonsgegevens gaat uit van een theoretisch scenario dat mogelijk individuen zouden kunnen worden geïdentificeerd. De gemeente is van mening dat identificatie van individuen aan de hand van de verwerkte data uit de anonieme wifimeting niet mogelijk is.

“Wij voelen ons ten onrechte gestraft voor iets dat wij niet beoogden en wat ook feitelijk niet is gebeurd. Het waarborgen van de privacy van onze binnenstadbezoekers is altijd een voorwaarde geweest. Bezoekerstellingen zijn nodig om het effect van investeringen en beleid in je stad te meten. Het kunnen monitoren van de drukte in je stad is nu actueler dan ooit, en wij zijn geblinddoekt. Extra wrang is dat bij de Autoriteit Persoonsgegevens nu een door de MOA – expertise center voor marktonderzoek – opgestelde gedragscode voor statistische wifitellingen ter goedkeuring is voorgelegd. De Autoriteit Persoonsgegevens is dus aan de ene kant aan het meedenken, terwijl het aan de andere kant een zware boete uitdeelt.”

Het is voorgelegd, maar ivm onderzoek gaf AP geen antwoord. Brief AP 30 Nov 2018 wifitracking alleen onder specifieke voorwaarden is toegestaan. Volgens gemeente ‘expert’ geraadpleegd die heeft beoordeeld dat het goed was. Het is mij niet duidelijk welke expert dit was en hoe deze evaluatie heeft plaatsgevonden. Als de expert iemand van RMC was krijg je natuurlijk ‘slager keurt zijn eigen vlees’ en is de uitkomst alles behalve objectief. Als op dit punt de gemeente kritisch was geweest hadden ze kunnen inzien dat de privacy van de burgers niet gewaarborgd kon worden en wellicht gestopt met de wifitracking.

Is wifitellen nu verboden in Nederland?

Nee. Wifitellen – volledigheidshalve  “statistisch passantenonderzoek met behulp van een wifi-signaal” genoemd – is toegestaan, mits er goed wordt uitgelegd waarvoor het nodig is en de persoonsgegevens geanonimiseerd zijn. In een brief aan de VNG gaf toenmalig minister Dekker aan dat hiervan sprake kan zijn als toepassing van deze methode nodig is voor het handhaven van de veiligheid of het bewaken van de openbare orde. Dit wordt ook onderschreven in de meest recente uitspraak van de Autoriteit Persoonsgegevens.

Volgens brief AP 30 November 2018 alleen in uitzonderlijke omstandigheden. Denk aan evenementen waarbij belangrijk is om aan crowdcontrol te doen. Dat is dan voor een beperkt gebied voor een beperkte periode. Dit is heel wat anders dan personen 24/7 in gehele binnenstad te volgen, waarvoor deze uitspraak ligt van AP dat dit niet mag.

Wat betekent deze uitspraak voor andere gemeenten die gebruikmaken van wifitellen?

Als uitvoerder garandeert Bureau RMC dat de huidige Citytraffic telmethode technisch voldoet aan alle huidige wet- en regelgeving. Telgegevens worden, nadat ze zijn geanonimiseerd,

AP heeft aan de hand van de gegevens database van 4 personen leefpatronen kunnen bepalen. Indien gegevens echt geanonimiseerd waren had je dit niet kunnen doen. Conclusie is dus dat gegevens NIET geanonimiseerd zijn!

niet langer dan 24 uur bewaard.

Ze staan max 24 uur in dagtabel, gegevens worden dagelijks omgezet in de database waar ze 6 maanden blijven opgeslagen.

Hiermee wordt voldaan aan de AVG voor de verwerking van persoonsgegevens.

Volgens AP niet, vandaar de boete

Opdrachtgevers dienen ook te voldoen aan de AVG. Dat houdt onder andere in dat:

  • Een wettelijke grondslag is bepaald en dat dit goed is vastgelegd. Zie artikel 6, lid 1e op pagina 36.
  • Organisaties die wifi-tellingen inzetten, passanten en/of bezoekers hierover helder dienen te informeren.
  • De bewaartermijn is afgestemd op het doel van de meting.
  • De persoonsgegevens privacy proof worden verwerkt in overeenstemming met de verwerkersovereenkomst en de daaraan ten grondslag liggende wettelijke bepalingen.
  • Er een verwerkersovereenkomst is. Neem gerust contact met ons op als er geen verwerkersovereenkomst is zodat we u kunnen helpen.

Zie hier voorbeelden die kunnen worden gebruikt: VNG en MOA 

Gaat Bureau RMC haar methode veranderen naar aanleiding van de uitspraak in Enschede?

Op dit moment is daar geen reden toe. Bureau RMC behandelt alle gegevens als persoonsgegevens en handelt in lijn met de gedragscode die is opgesteld door de MOA, brancheorganisatie voor marktonderzoekbureaus. Onze methode is privacy proof.

Vind AP niet, zie 4 voorbeelden van persoenen.

Zodra deze gedragscode of andere vorm van wetgeving vereisen dat de meetmethodes aangepast moeten worden, dan zullen we dit uiteraard doen.

Graag, ik zie jullie nieuwe methode graag tegemoet.

Uitslag AP handhavingsverzoek

Na 1017 dagen (2 jaar, 9 maand en 12 dagen) krijg ik eindelijk antwoord op mijn handhavingsverzoek aan Autoriteit Persoonsgegevens (AP). Kort samengevat lijkt AP me in alle punten gelijk te geven en geeft de gemeente Enschede een bestuurlijke boete van € 600.000 . gemeente gaat hierin nog wel in beroep, maar de uitspraak van AP is vandaag officieel gepubliceerd. Al met al ben ik vanaf 24 Oktober 2017 hiermee bezig geweest, dus 1283 dagen, (3 jaar en 6 maanden)

Mijn mening over rapport AP

Volledig rapport kun je downloaden via AP.

Zelf ben ik blij dat deze uitspraak er ligt. De boete was niet mijn doelstelling, ik wou alleen dat gemeente Enschede / Bureau RMC (marketing bedrijf dat de uitvoering doet en rapporten maakt) zou stoppen met de wifi tracking. De boete laat wel zien dat AP van mening is dat dit een ernstige overtreding is. Persoonlijke gegevens (hash MAC + locatie + datum / tijd) word voor 6 maanden opgeslagen zonder dat hiervoor een noodzaak is, een ernstige overtreding van de privacy van Enschedese burgers.

Met deze uitspraak ga ik van uit dat veel gemeenten per direct zullen stoppen met wifi tracking. Een mooie overwinning voor de privacy in heel Nederland en wellicht ook in Europa (Ik ga de europese Piraten hierover informeren).

Hieronder vind je uitleg over het gehele proces en meer inhoudelijk commentaar van mij.

Verkort historisch overzicht

Volledige dossier kun je hier vinden, hieronder staan de belangrijkste gebeurtenissen.

Op 6 september 2017 start gemeente Enschede met wifi tracking om dagelijkse bezoekersaantallen te verkrijgen. De gemeente wil met deze gegevens zien welke maatregelen welk effect hebben en de ondernemers over bezoekersaantallen informeren.

Vanaf het begin zijn hierbij vragen gesteld in verband met privacy. Raadsleden van CDA en SP stelden vragen en ik ging ook in gesprek met de gemeente. Naar mijn mening was het volgen van mensen 24/7 in de stad een grove inbreuk van de privacy. In de stad moet je onbespied kunnen rondbewegen, zonder dat je zelf hiervoor maatregelen moet nemen (zoals wifi op je telefoon uitzetten). Indien men wifi-tracking in een winkel toepast kan men er nog voor kiezen om die winkel niet in te gaan, de keuze om bijvoorbeeld de binnenstad niet in te gaan is wel een hele grote beperking in je vrijheden.

Op 10 november 2017 had ik een klacht bij de gemeente ingediend, dit gaf niet mijn beoogde resultaat. Op 17 juli 2018 heb ik een handhavingsverzoek ingediend bij autoriteit persoonsgegevens.

Op 30 november 2018 heeft AP aan alle gemeentes een brief gestuurd dat “wifi-tracking alleen in uitzonderlijke omstandigheden zijn toegestaan “. Naar aanleiding hiervan had gemeente Enschede de wifi tracking tijdelijk gestopt. Na aanpassing in het systeem (volgens RMC is er overgegaan van pseudonimiseren naar anonimiseren) word de wifi-tracking vanaf 1 januari 2019 in Gemeente Enschede weer voortgezet.

Vandaag 29 april 2021 is rapport van AP gepubliceerd waarbij ik in al mijn punten gelijk word gegeven. gemeente Enschede krijgt een boete opgelegd van € 600.000

Enkele punten uit rapport handhavingsverzoek

  • Gemeente was van mening dat het aanspraak kon maken op ‘gerechtvaardigd belang’ en daardoor via wifi-tracking statistieken zou mogen bijhouden. Echter volgens AP moet dit worden afgewogen tegen belang van privacy van de burgers, AP is van mening dat statistieken op een minder privacy ingrijpende manier ook bijgehouden kan worden en dat de burger zich onbespied door de stad moet kunnen bewegen.
  • Gemeente Enschede wordt door zijn active rol gezien als verwerkingsverantwoordelijke en dus ook verantwoordelijk voor wat er met alle data gebeurt. Deze verantwoordelijkheid kan men dus niet eenvoudig contractueel doorschuiven naar uitvoerende partijen. De gemeente had moeten nagaan of de privacy voldoende werd gewaarborgd door de gebruikte technieken. Gemeente heeft dit nagelaten en op vertrouwd dat de leverancier dit naar behoren regelt.
  • Ook na ‘anonimiseren’ zijn de gegevens persoonsgegeven volgens AP. Dit wordt ook heel mooi aangetoond door de analyse door AP dat enkele leefpatronen uit de data kon worden gedestilleerd (zie vanaf pg. 47).

    Dus ondanks alle beloftes van RMC is de “CityTraffic-methode” dus geen goede manier om gegevens te anonimiseren. (Zie ook mijn opmerking bij techniek)
  • Opmerkelijke feit : er word verwezen naar “Breyer” veroordeling (zoek op ECLI:EU:C:2016:779), dit ging of een dynamisch IP-adres een persoonsgegeven is. Patrick Breyer is tevens een Piraat en zit nu in het Europese parlement. Mooie bevestiging dat er meer piraten voor privacy opkomen.

Over de gebruikte technieken

Ondanks vele vragen aan RMC is me tot nu toe nooit echt duidelijk geworden hoe men precies de hash berekende of hoe de pseudonimiseerde gegevens worden geanonimiseerd. Door het rapport van AP is het eindelijk meer duidelijk wat er gebeurt. Hieronder beschrijf ik kort de stappen die RMC met de data uitvoerde.

Op een consumenten Wifi router is openWRT geïnstalleerd en wordt met behulp van ‘airodump-ng’ bijgehouden welke MAC-adressen er voorbij komen. Deze gegevens word naar een eigen geschreven stukje software gestuurd, berekend de hash (12 tekens lang) en verstuurt dit naar de server als het MAC-adres voor de eerste keer gezien wordt en als het MAC-adres langer dan 2 minuten niet meer gezien is.

Van de binnengekomen hash op de server worden de laatste 3 tekens verwijderd (‘geanonimiseerd’) en opgeslagen in een tijdelijke tabel. Deze wordt dagelijks overgezet naar de database na het filteren op de opt-out adressen en de bewonersfilters. Hierin blijven de gegevens 6 maanden staan. Vanuit deze database worden dan de diverse rapportages gemaakt voor gemeente Enschede.

Opmerkingen over de techniek:

  • Berekening van hash (eigen methode gebaseerd op sha256) is nog steeds onduidelijk, maar dit maakt voor de discussie niet uit. Wat wel belangrijk is dat de hash volgens de ‘CityTraffic Methode’ 12 tekens lang is, terwijl normaal een sha256 een string geeft van 64 tekens. Een normaal MAC adres is ook 12 tekens lang, maar dat zal vast toeval zijn.
  • Voor het anonimiseren van de gegevens verwijdert men de laatste 3 tekens, dus van 12 tekens naar 9 tekens. Er word nergens duidelijk gemaakt waarom dit voldoende zou moeten zijn (bijvoorbeeld door middel van onderzoek privacy expert) om te anonimiseren. Zie ook de blogpost van AP over afknippen van hashes. In een semi-onderzoek van mezelf zou je minimaal naar 4 tekens of minder moeten gaan. Disclaimer, ook dit geeft nog steeds geen 100% garantie dat gegevens dan anoniem zijn!!
  • De bewonersfilters word er dagelijks gekeken of hash van MAC word gezien tussen 5:00-7:00 EN 22:00-24:00. Als je op een van deze tijdstippen dus niet thuis bent of je MAC-adres word niet gezien kom je alsnog in de database terecht.

Wat had men kunnen doen?

Goed anonimiseren van data is een vakgebied, door een beetje te rommelen met getallen of een string in te korten ben je er niet. Er zijn genoeg gevallen bekend dat men een database geanonimiseerd en gepubliceerd heeft en dat wetenschappers er toch weer personen uit konden identificeren, helemaal als je dit kunt combineren met andere data. Zie de onderstaande tips dan ook niet als een officieel advies, raadpleeg een expert als je hiermee bezig gaat! Dit gezegd hebbende toch wat tips die ik zelf zo kan bedenken :

  • Je zou alleen de drukte van betreffende acces point kunnen versturen naar database. Omdat dit alleen een totaal is en geen persoonsgegeven (MAC/hash) is privacy dan geen problemen meer.
  • Voor heel Enschede (en Nederland) is er 1 methode gebruikt om hash te berekenen. Hierdoor kan men 1 persoon over een periode van 6 maanden volgen (door Nederland). Men zou een ‘salt’ kunnen gebruiken die per lokatie en/of dag wijzigt. Hierdoor zou men een persoon voor max. 1 dag kunnen volgen. Nadeel is natuurlijk wel dat men niet meer kan zien of een bezoeker eerder is geweest.
  • Indien men een hash gebruikt deze inkorten naar 4 tekens of minder, waardoor je ‘collissions’ krijgt en dus mensen bij elkaar optelt en daardoor niet individueel meer zijn te volgen.
  • Andere methode gebruiken dan wifi-tracking, genoemd wordt infrarood telling maar er zijn vast wel meerdere anonieme technieken te bedenken. Hierin had ik in start de project ook suggesties gedaan aan gemeente Enschede.

Reactie op commentaar gemeente Enschede

Inmiddels heeft gemeente Enschede reactie gegeven op besluit, hier wil ik graag even op ingaan.

Ze geven aan dat ze graag eerst een waarschuwing zouden willen krijgen.

Eerste signaal was de vragen over privacy van SP en CDA (en mij) tijdens de invoering, dan weet je dat je zorgvuldig hiermee om moet gaan. Daarna heb ik een klacht ingediend bij de gemeente, waar niks uitkwam. Vervolgens hebben alle gemeenten in Nederland op 30 november 2018 een brief ontvangen van AP, waarin aangegeven word dat wifi tracking alleen in uitzonderlijke gevallen mocht. Naar aanleiding van deze brief heeft de gemeente de wifi tracking inderdaad tijdelijk gestopt, maar men heeft er voor gekozen om (na aanpassingen van leverancier) weer verder te gaan met wifi-tracking. Was men op dat moment niet doorgegaan met de wifi tracking hadden ze waarschijnlijk ook geen boete gekregen.

Tevens geeft de gemeente aan dat men wifi tracking nodig heeft om een innovatieve stad te kunnen zijn, een ‘smart city’. Ik heb geen bezwaren tegen het idee om een stad slim te maken, maar zorg er dan wel voor dat de privacy van je burgers heel goed gewaarborgd word. Met andere woorden, je kunt prima innoveren EN privacy veilig zijn, dat zijn geen tegengestelde waarden.

In de media

GOGBOT 2020

Mijn CoronaTeller is te bekijken tijdens de GOGBOT 2020 expositie. Ik sta in het programma genoemd (als nummer 14). De GOGBOT is tot zondag open, let er wel op dat ivm Corona je een ticket moet hebben.

De foto met getal 1971 is dus het aantal unieke beacons die de CoronaTeller al gezien heeft, dat is dus sinds woensdag avond. Als iemand gezien word en een uur later terug komt wordt deze dus 2x geteld, ik kan niet bijhouden wie ik al wel of niet gezien heb. Dit getal is wel hoger dan wat ik zou inschatten.

CoronaTeller / CoronaCounter

Ik heb op 16 Aug de CoronaTeller gepubliceerd en gepost op de sociale media. Vooral via Twitter krijg ik hierover de nodige vragen, aangezien 280 tekens een beetje weinig is om alles uit te leggen deze blog. Mocht er in de toekomst meer vragen komen zal ik deze post verder aanvullen.

Eerst korte uitleg wat de CoronaMelder op de telefoon doet. Het zend meerdere keren per seconde een beacon (uniek nummer, afgeleid van geheime key). Deze key kan ik via een Raspberry Pi ontvangen en “leuke dingen” mee doen. In mijn geval tel ik het aantal unieke beacons die ik ontvang over de afgelopen 5 minuten. Hiermee kan ik zien hoeveel telefoons de CoronaMelder app op te telefoon hebben staan. Voor de volledige werking van de CoronaMelder zie mijn vorige blog post.

Een beacon is dus een ‘random’ getal waaruit verder niks valt af te leiden. Volgens het protocol wordt deze iedere 10-25 minuten opnieuw gegenereerd. Tevens kun je zien hoe sterk iemand binnen komt, maar hier doe ik niks mee. De Pi houd verder geen gegevens bij in een database of via internet/cloud, alles word in geheugen gedaan en is weg als je de Pi uitdoet/reset.

Is een beacon een ID ?

Een beacon is dus geen ID, hiervoor wordt deze te vaak veranderd. Mocht je het toch voor elkaar krijgen om een beacon aan een persoon te koppelen kun je na iedere nieuw gegenereerde beacon (dus 10-25 min) opnieuw beginnen.

Word er ander gegevens bijgehouden?

Kort antwoordt, NEE. Dus ook geen locatiedata, persoonsgegevens zoals naam, email telefoonnummer, etc etc. Op de telefoon wordt alleen de beacons die deze gezien heeft over de laatste 14 dagen opgeslagen. Aan de hand hiervan kan de telefoon bepalen of je risico loopt, zie ook mijn blog over de technische details.

Batterij gebruik

De CoronaMelder maakt gebruik van BLE 4, dit is het laatste bluetooth protocol dat zeer energie efficiënt kan werken. In de praktijk zou je dus niet veel merken van de app, anders probeer het uit je kunt de app altijd weer verwijderen.

Spookmeldingen

Eens in de maand geeft de CoronaMelder een overzicht van totaal aantal meldingen. Als je hier op klik kom je in de app terecht. Ook kun je in je OS zelf een lijstje zien waarop de ziektemeldingen wordt opgehaald. Beide meldingen zijn dus geen meldingen dat je mogelijk geïnfecteerd bent. Deze ziet er als volgt uit :

De CoronaTeller wordt getoond tijdens de Gogbot 2020 expositie.

Wifi tracking – verweer gemeente Enschede

Ik heb 3 Juni bericht van AP ontvangen dat het onderzoek is afgerond en dat het rapport nu bij de gemeente Enschede ligt zodat zij hun reactie / verweer kunnen geven.

Als deze reactie door het AP is ontvangen zullen zij een eindrapport maken waarin een eindconclusie te vinden is. Deze zal dan ook openbaar zijn.

Met andere woorden het lijkt er op dat na 2 jaar het einde van dit proces in zicht is. De bal ligt nu bij de gemeente Enschede en zou niet zo heel lang moeten duren voordat zij een reactie hebben geformuleerd (hopelijk hooguit een paar maanden).

Corona App

Interview met Rico Brouwer / potkaars

In de huidige COVID-19 pandemie is een nieuw idee ontstaan om een ‘Corona app’ te ontwikkelen. Hierbij zeggen veel mensen dat dit een inbraak op je privacy is, wat begrijpelijk is maar niet helemaal klopt.

Disclaimer : Dit hele blog post belicht vooral de technische kant van een corona app en of dit privacy veilig kan. Er spelen in de maatschappij ook vele andere aspecten zoals sociale kwesties of algemene gezondheidszorg, deze belicht ik hier niet.

Contactonderzoek

Wat nu na een geconstateerde corona besmetting gebeurt is dat de GGD een contact onderzoek uitvoert. Hiermee wordt nagegaan welke contacten de patiënt heeft gehad over de afgelopen 14 dagen en deze personen worden benaderd om uitleg te geven over de mogelijke besmetting en wat ze kunnen doen om verdere verspreiding te voorkomen. Vooral al je al maatregelen kunt nemen voordat een potentieel geïnfecteerde persoon symptomen vertoond kan op de vrij snel een drastisch verschil maken in de uiteindelijke aantallen corona patiënten.

Je kunt je voorstellen dat de patiënt niet altijd een volledige lijst van personen kan geven en dat hierdoor mogelijke besmette personen buiten het blikveld van de gezondheids organisatie vallen.

Ter ondersteuning van de contact onderzoek zou men een app kunnen ontwikkelen die specifiek deze taak ondersteund. Een groep van slimme onderzoekers hebben hiervoor het privacy vriendelijke DP-3T protocol bedacht. Het klinkt heel tegenstrijdig maar ik zal proberen het hier uit te leggen hoe dit werkt.

In de cartoon hebben we dus Alice (de corona besmette patient) en Bob (die bij haar in de buurt is geweest, en dus mogelijk besmet).

De techniek achter 3DP-TD

Op iedere telefoon die hieraan meedoet wordt een dagelijkse sleutel gemaakt die de basis vormt voor een ‘random’* getal dat iedere paar minuten anders is. Deze random getallen worden uitgezonden en de app luistert of hij deze getallen hoort. Op de telefoon wordt een lijst bijgehouden van de ‘random’ getallen die hij heeft gehoord.

Indien Alice ziek wordt en naar de arts/ziekenhuis gaat en na controle positief blijkt te zijn, krijgt ze een code waarmee ze kan melden dat ze ziek is. (Dit om spam en misbruik te voorkomen). Alleen op dit moment wordt haar lijst van dagelijkse sleutels naar de server gestuurd. Er word verder geen andere data verstuurd zoals locatie data, gebruikers gegevens etc.

De andere telefoons halen dagelijks lijst op met mensen die gemeld zijn. In het voorbeeld krijgt Bob dus lijst van de dagelijkse sleutels van Alice. Met deze lijst kan de telefoon van Bob de ‘random’ nummers van Alice berekenen en kijken of deze gezien zijn. De telefoon kan aan de hand van aantal criteria (afstand, duur contact, aantal keer gezien) bepalen of Bob ook risico loopt. Indien dit te laag is krijgt Bob niks te zien, als dit hoog is krijgt Bob een melding. Op deze manier kan Bob zien dat hij potentieel besmet is en eventueel maatregelen nemen. Dit zou kunnen bestaan uit een paar dagen thuis blijven of (als er genoeg testcapaciteit is) een test te laten doen. Vooral omdat Bob deze melding krijgt voordat hij zelf ziek is zou daarmee veel besmettingen voorkomen kunnen worden.

Het enige wat dus naar de server gaat en centraal gebeurt is het ontvangen en versturen van de dagelijkse sleutels van een besmet persoon. Het bepalen of je wel/niet besmet bent gebeurt op je eigen telefoon en is volgens het 3DP-TD protocol niet inzichtelijk door overheid, verzekeringsmaatschappij of wie dan ook. En ja je zou indien je een melding krijg niks op uit doen, er is geen enkele manier om maatregelen af te dwingen.

In mijn optiek zou een op deze manier gemaakte Corona App kunnen helpen op de corona te bestrijden. Het is natuurlijk geen wondermiddel, we zullen nog steeds onze handen moeten wassen, social distancing en testen. Maar het kan wel een middel zijn om de huidige lockdown minder strikt te maken en hopelijk een stapje te maken naar normale samenleving.

Opmerkingen

Punten in lijn van het https://www.veiligtegencorona.nl/ manifest (die ik volledig ondersteun) :

  • Het 3DP-TD protocol ziet er goed uit, maar uiteindelijk ligt het aan de uitvoering of het echt privacy proof is. Met open source code zou je dit kunnen controleren.
  • Deelname moet volledig vrijwillig zijn.

Bluetooth lijkt een geschikte manier om te kijken of iemand bij je in de buurt zit, maar er zijn genoeg situaties te bedenken dat de app wel een code ziet maar dat er geen sprake is van contact. Zo gaat een bluetooth signaal door glas en muren maar een virus niet. Andersom kan de virus nog op een deurkruk zitten van corona besmet persoon die 5 minuten eerder daar was maar dat zal de app natuurlijk niet zien. De app zou hooguit een indicatie kunnen geven of je besmet bent, de werkelijkheid kan natuurlijk altijd anders zijn.

Op 10 April werd bekend dat Apple en Google API functies in hun mobiel besturingssysteem opnemen om dit protocol te ondersteunen. Hiermee wordt het voor de ontwikkelaars een heel stuk makkelijker om een app op de juiste manier veilig te implementeren. Dit zal dan uitsluitend actief op je telefoon worden na toestemming. Ieder land zal wel een eigen app moeten ontwikkelen, vooral het gedeelte van krijgen code en wat te doen als je besmet bent zal per land verschillend zijn.

Volgens inschattingen moet 60% vd bevolking hieraan mee doen om succesvol te zijn. Dit is best wel een hoog percentage en stel dat het allemaal doorgaat ben ik erg benieuwd of we dit halen. Dat google/apple nu ook samenwerkt maakt de kans wel aanzienlijk groter.

Criteria van wanneer Bob wel of niet een melding moet krijgen staat nu nog niet vast en zou door de overheid ism RIVM etc bepaald moeten worden. In het voorstel van DP3-TP staan meer parameters waar men van af zou kunnen wijken, bv hoe vaak je een nieuwe ‘random’ nummer krijgt e.d. Dit zijn onderdelen die dus tijdens de implementatie van de app moet gaan bepalen.

* In dit artikel wordt ‘random’ gebruikt omdat het niet een echt willekeurig getal is maar iets wat berekend wordt door middel van aantal waarden (o.a. je dagelijkse sleutel). Omdat dit berekende waarden zijn kan de telefoon van Bob dezelfde berekening uitvoeren en controleren of de codes van Alice gezien zijn.