Contact tracing via apps

Dit moet je weten

Quentin Braet
22 min readJun 9, 2020

Moet er een app komen om te helpen bij contact tracing? Het is een vraag die veel mensen bezig houdt en de gemoederen enorm beroert. Wat met mijn privacy? Werkt zoiets wel? Allemaal terechte vragen en bezorgdheden die mensen hebben. We moeten ook eerlijk zijn in deze discussie, op sommige vragen kunnen we helemaal nog geen antwoord geven, wie beweert dat wel al te kunnen, verliest voor mij alvast al zijn geloofwaardigheid. Laten we dus even alle ego’s opzij zetten en kijken naar wat we wel weten. Wat kan er vandaag? Welke afwegingen moeten we maken? Waar liggen de grenzen waar we niet over willen? En als we er voor gaan: hoe geven we dit de grootste kans op slagen?

Door de ogen van een app bouwer

Als het over nieuwe technologie en moeilijke privacy vraagstukken gaat, zijn er al snel veel luide roepers. Maar hoeveel van die mensen hebben effectief de mogelijkheden onderzocht tot in de technische details? Hoeveel mensen die die technische details begrijpen, hebben effectief voeling met dit soort applicaties lanceren? Hoeveel daarvan hebben praktische ervaring met de gebruikte technologie? Het spreekt voor zich dat het hier vaak om een minderheid gaat, met als gevolg dat er zich al snel veel onzin verspreidt.

De laatste 2 maand werd je dan ook om de oren geslagen met meningen over contact tracing via apps. Heel wat app initiatieven werden opgestart en zwaar onder de loep genomen. Toen ik zelf over die apps hoorde, was ik meteen geïnteresseerd. Afwegingen maken zoals bij dit vraagstuk nodig zijn, is de kern van mijn job. Wie mij kent, weet ook dat deze materie volledig in mijn comfort zone zit. Ben ik daarmee dé expert? Laat het me houden op: goed geplaatst om een gefundeerde kijk erop te geven en de feiten zelf te controleren.

Maar oordeel vooral zelf. Het ergste wat we kunnen doen is onze kritische blik verliezen en blindelings een app installeren. Ik ben er dan ook van overtuigd dat als je het op de juiste manier aanpakt en heel transparant bent in de werking ervan, je vanzelf het vertrouwen van de mensen krijgt. Toch als je oprecht een goed opgebouwde app hebt. Maar dan moet iedereen wel begrijpen waarover we praten. Mijn doel is dan ook niet om iemand te overtuigen, wel om te informeren en te helpen door de bomen het bos te zien.

Wat deel je en aan wie? Jij bepaalt!

We starten bij het begin: stel, de overheid kiest om een app te lanceren. Wat nu? Moet ik die installeren? Sommige mensen zouden dit inderdaad graag verplichten, en op zich, er valt ook iets te zeggen voor hun argumenten. Hoe meer mensen de app gebruiken, hoe meer Covid-19 gevallen we kunnen opsporen via de app.

De realiteit zal echter anders zijn, we leven nog altijd in België, waar we waarde hechten aan onze privacy, helemaal terecht ook als je het mij vraagt. Je zal dus als burger de vrije keuze krijgen, en net daar zit ook de eerste grote uitdaging voor deze app: hoe overtuig je genoeg mensen om de app te installeren en in te schakelen?

Het klinkt enorm logisch maar het wordt al snel vergeten: de app kan uiteraard enkel detecteren dat je in aanraking gekomen bent met een Covid-19 geval, als die persoon de app ook gebruikte. Welk percentage van de bevolking we minimum moeten bereiken om de app nuttig te laten zijn, kan eigenlijk niemand zeggen. Er circuleren verschillende percentages, maar er is nog geen wetenschappelijke consensus over. Daarnaast blijft het uiteraard koffiedik kijken, want deze situatie is voor iedereen nieuw. Daarom zie ik deze percentages voorlopig nog niet als doel op zich. Het enige wat ik hier zelf uit haal, is dat je zoveel mogelijk mensen mee wil krijgen, en dat is voorlopig dus ook het belangrijkste doel: meer gebruikers overtuigen is altijd beter.

Wie vertrouw je?

Maar hoe krijg je al die mensen zo ver om die app te installeren? Net als bij elke andere app zal de gebruiker hier voor zichzelf een kosten baten analyse maken, sommige mensen gaan daar snel over, anderen gaan hier heel doordacht te werk, zeker bij dit soort apps. Welke technische oplossing we straks ook kiezen, deze zal heel bepalend zijn in hoeveel mensen je kan overtuigen om de app te gebruiken. De technische oplossing staat dus echt niet los van de aantrekkingskracht op de app, en dat moeten heel wat mensen dringend beginnen beseffen. Een niet verwaarloosbaar deel van de bevolking zal de app enkel installeren als de security en privacy van het systeem zo waterdicht mogelijk zijn, vanaf ze hier gaten in kunnen schieten, heeft dit een negatief effect op de verspreiding van de app. Laat mij bij deze dan ook pleiten om de app enkel te promoten met transparante objectieve feiten en niet met loze beloftes. De werking van de app moet 100% openbaar en controleerbaar zijn, enkel zo kan je de criticasters hun argumenten objectief weerleggen.

En dat brengt ons bij de hamvraag wie vertrouw je? Transparantie is mooi, maar deze app verzamelt persoonlijke informatie, je wil niet dat die zomaar openbaar gegooid kan worden. Er zijn 2 dingen die je kan doen om dit te voorkomen:

  1. Zo weinig mogelijk persoonlijke info verzamelen, wat er niet is, kan niet gestolen worden.
  2. Beperken wie deze persoonlijke informatie in handen kan krijgen.

Het tweede puntje klinkt simpel maar is het niet altijd. Zoals we bij de technische oplossingen gaan zien, kunnen we niet altijd garanderen dat alle info geheim blijft. Er moet altijd een partij zijn die de info verwerkt en samenbrengt. Wie deze partij is, is een potentieel discussiepunt, maar deze partij zal je wel moeten vertrouwen, vanaf er iemand (ook al is het een medewerker van deze partij) aan de data kan, is er een potentieel risico dat deze persoon de data misbruikt of lekt.

Het enige alternatief waarbij je dit kan voorkomen is in een zero trust systeem waarbij je letterlijk niemand hoeft te vertrouwen. Maar dit bereiken is in sommige gevallen gewoon technisch onmogelijk. In deze ideale situatie moet je in alle lagen van je systeem beveiliging inbouwen, en dit kan niet zomaar achteraf. Security is zoals gewapend beton: je moet bij het ontwerp van je systeem al bepalen hoeveel staal er in moet zitten om het sterk genoeg te maken, achteraf staal in de kern toevoegen is onmogelijk. Er zijn wel hacks mogelijk om toch achteraf nog dingen te verstevigen, maar dat is een duct tape methode: het ziet er niet uit, en het risico blijft dat het vroeg of laat toch als een kaartenhuisje ineen valt omdat de kern het alsnog begeeft.

Wat is het doel?

Zoals vaak zijn er meerdere opties om je doel te bereiken. Alles begint dus met een duidelijk doel te formuleren voor die app, en eerlijk, het was zeker in het begin nog niet helemaal duidelijk wat het doel van die app moest zijn, waardoor er een wildgroei aan opties kwam. Er waren eigenlijk 2 grote strekkingen:

  • Is het een app die je rechtstreekse contacten met andere gebruikers detecteert, zodat je zo achteraf bij een vastgestelde besmetting in die contact geschiedenis kan gaan kijken wie een potentieel risico loopt.
  • Of is het een app die in kaart brengt waar een besmet iemand overal geweest is, om zo te bepalen welke plekken gevaarlijk zijn en dat zo terug te koppelen naar andere gebruikers die op dezelfde plaats geweest zijn? In dit geval kan je ook omgevingstransmissie in rekening brengen, waarbij je een risico loopt door dezelfde objecten aan te raken als een besmet persoon, maar niet noodzakelijk op hetzelfde moment in dezelfde ruimte was.

Op het eerste zicht zijn dit 2 heel gelijkaardige apps, maar technisch gezien is het een wereld van verschil. Kort gezegd moet je om het eerste doel te bereiken veel minder data over je gebruikers verzamelen, wat de risico’s dus beperkt.

Wat kan je met een smartphone doen?

In de veronderstelling dat iemand zijn smartphone met de app altijd bij zich heeft, zijn er eigenlijk twee dingen die je kan doen om te bepalen of iemand op dezelfde plaats was als iemand anders.

Locatie tracking via GPS

Je laat de app continu je locatie traceren en houdt dit bij. Ergens in het systeem wordt dan jouw locatie geschiedenis vergeleken met alle besmette gevallen om zo te kijken of je op een bepaald moment risico gelopen hebt. Als je er van uit gaat dat wanneer mensen op anderhalve meter afstand blijven er eigenlijk geen risico is, moet je al continu de GPS data opvragen. En zelfs deze is maar tot op een aantal meter nauwkeurig. Deze technologie is trouwens ook enkel bruikbaar buitenshuis, binnen kan je soms resultaten krijgen, maar heel accuraat zijn die zeker niet.

De locatie tracking methode is ook de enige die min of meer kan weten waar je potentieel de besmetting opliep. Ondanks de risico’s die daaraan verbonden zijn, kan dit heel nuttige info zijn om ook mensen die de app niet hebben te waarschuwen over besmettingshaarden, of deze op zijn minst in kaart te brengen.

Een groot technisch nadeel van GPS is echter wel dat deze relatief veel batterij van je toestel verbruikt. Als je een nauwkeurigheid van 5 meter voor elke meting wil bereiken, kunnen zelfs de beste optimalisaties er niet voor zorgen dat je niet al snel 10% en meer van je batterij per dag kwijt raakt aan deze app.

De grote uitdaging hier is dat je door GPS coördinaten op te slaan, eigenlijk perfect weet waar die persoon overal geweest is en dus relatief makkelijk iemand zijn identiteit eruit kan afleiden. Wie dus toegang moet hebben tot deze GPS data, wordt een cruciaal vraagstuk in dit opzet.

Overzicht van de locatie tracking methode

Contact tracing via Bluetooth

Een alternatief systeem maakt gebruik van de Bluetooth functionaliteit van je toestel. In dit geval registreer je enkel wanneer iemand binnen de anderhalve meter in de buurt geweest is. Je kan de app continu een Bluetooth signaal laten uitzenden dat door de andere app gebruikers kan opgepikt worden. Ook hiermee is het moeilijk om een correcte inschatting te maken van wanneer iemand exact anderhalve meter van jou verwijderd is, maar het verschil in signaalsterkte wanneer je op 1 of 5 meter van elkaar verwijderd staat, is wel heel duidelijk van elkaar te onderscheiden aangezien die signalen snel afzwakken.

De contact tracing methode geeft je eigenlijk enkel aan dat je met iemand in contact geweest bent, de app weet hiermee niet noodzakelijk waar dit gebeurde. In essentie heb je dit ook niet nodig om contact tracing te laten werken, maar daardoor wordt het wel onmogelijk om globaal besmettingshaarden in kaart te brengen zoals bij de GPS methode.

Doordat de smartphone hier zelf signalen uitzendt en ontvangt, zal deze technologie ook indoor werken, zoals bijvoorbeeld in supermarkten, waar de kans op besmetting ook reëel is. Een ander praktisch voordeel aan dit opzet is dat je gebruik kan maken van de Bluetooth Low Energy (BLE) specificaties. Goed nieuws voor je batterij dus, in principe zou je nauwelijks mogen merken dat je een app met deze technologie geïnstalleerd hebt staan.

De grote uitdaging bij deze technologie zit hem in wat de apps moeten uitzenden via Bluetooth. De naïeve aanpak zou zijn om hier gewoon een uniek nummer per gebruiker uit te zenden, maar ook dat maakt je heel kwetsbaar om “gevolgd” te kunnen worden door externen, iedereen met de juiste tools kan dat signaal gewoon oppikken. Hoe je dit veilig aanpakt is de kern van de uitdagingen bij deze technologie.

Overzicht contact tracing methode

Hoe verbind je de apps met elkaar?

Nu we de basis van de app technologie beschreven hebben, wordt het tijd om de complete oplossingen te bekijken die op tafel liggen en hoe die systemen er ruwweg uitzien. De bedoeling is zeker niet alle mogelijke oplossingen uit te leggen, maar de generieke ideeën te schetsen en hun belangrijkste risico’s aan te halen. Dat risico zal namelijk evenredig zijn met de hoeveelheid mensen die dit type app vrijwillig zal willen installeren.

De server als doorgeefluik

We hebben er tot nu toe nog niet bij stilgestaan, maar de app is hier maar één aspect van het verhaal, er is meer nodig om die apps informatie met elkaar te laten uitwisselen: een server die al die apps met elkaar verbindt en de benodigde informatie uitwisselt.

In de schema’s hierboven hebben we bewust nog niet bepaald welke taken in de app verwerkt worden en welke op de server, daar zijn immers heel wat varianten op te bedenken. Het is belangrijk om te zien dat voor beide technologieën geldt dat er ontmoetingen tussen 2 personen moeten gezocht worden. Wie deze berekening doet, heeft dus sowieso informatie over hoe deze match tussen twee personen tot stand kwam.

Eigenlijk zijn er maar 2 mogelijkheden

  1. Centralisatie: iedereen stuurt zijn info door naar de server en die doet de berekening.
  2. Decentralisatie: je houdt je eigen data zelf bij op je smartphone, enkel besmette mensen wordt expliciet gevraagd om hun gegevens te delen. Deze gegevens worden dan gepubliceerd naar alle andere apps zodat die voor zichzelf kunnen bepalen of ze een risico lopen.
Schematische voorstelling centralisatie
Schematische voorstelling decentralisatie

Beide systemen hebben hun zwakke plekken, de centralisatie manier geeft best veel info over alle gebruikers aan de partij die de server beheert. Je moet die partij dan wel vertrouwen dat ze hier correct mee omgaan en niemand ongeoorloofd deze gegevens zal gebruiken. De decentralisatie manier geeft dan weer gegevens van besmette personen door aan alle andere gebruikers. De grote vraag is dus welke data hier doorgegeven zal worden en hoe risicovol dat is.

Bescherm de server

Het is belangrijk om te beseffen dat alle info die over de server gaat, in principe kwetsbaar is en beschermd moet worden. Je kan data op servers best goed afschermen van ongeoorloofd gebruik, zeker van buitenaf, maar ook voor bijvoorbeeld medewerkers van het bedrijf zelf die deze servers beheert. Maar ergens is er altijd iemand die die rechten toekent en dus zichzelf meer rechten kan geven. Wie controleert die persoon? De overheid?

Sommige mensen zullen zeggen dat je eigenlijk zelfs de overheid niet mag vertrouwen, het is niet omdat de overheid vandaag deze data niet opeist en gebruikt voor andere doelen, dat dat morgen niet het geval kan zijn. De enige manier om je daar tegen te beschermen, is door simpelweg te vermijden dat je interessante data opslaat, privacy en security by design zoals we in vaktermen zouden zeggen.

In het zero trust scenario dat hierboven al beschreven werd, wil je er eigenlijk niet van uit gaan dat de informatie die op deze servers passeert veilig afgeschermd is. Als je dit wil bereiken, kan je dat enkel doen door ervoor te zorgen dat als er toch iemand deze data kan inkijken, hij er eigenlijk niks mee is omdat er niks uit af te leiden valt.

Een minder vergaande manier om de data toch veiliger te behandelen, is door ze maar zo lang te bewaren als ze nodig is. Opnieuw: data die er niet meer is, kan niet gestolen worden. Het wordt eigenlijk afgedwongen door de GDPR regelgeving dat gegevens maar een beperkte tijd mogen worden bijgehouden en dat dit duidelijk moet zijn voor de gebruiker. Maar ook hier is het moeilijk om staalharde garanties af te dwingen die niemand in twijfel kan trekken.

Combinaties tussen technologie en verwerking

Combineren we de technologische mogelijkheden op smartphones, met de mogelijkheden van waar we verwerking van de data kunnen laten plaatsvinden, dan komen we uit op onderstaande tabel met alle opties.

De mogelijke combinaties voor technologieën vs waar de verwerking gebeurt

De opties voor GPS gebaseerde oplossingen

Matching op de server (centralisatie)
Het idee hier is dat je je complete locatie geschiedenis doorstuurt naar de server en de server gaat berekenen waar je met een besmet persoon in contact gekomen bent. Het is vrij duidelijk dat de organisatie die de server beheert, in principe in staat is om die locatiedata in te kijken. Ook al is die anoniem aan het systeem toegevoegd, toch moet je met locatie data niet veel moeite doen om te achterhalen van wie die komt. Vaak volstaat het om te kijken waar die persoon zich ‘s nachts bevindt om zijn adres te vinden. De rest is dan kinderspel.

Voor de kenners: er zijn wel manieren om die locatie data om te vormen naar onbegrijpbare informatie met behulp van location hashing. Zo zorg je ervoor dat er niet langer leesbare coördinaten op de server terecht komen. Al is dit maar een kleine verbetering aan het systeem, je kan heel makkelijk een hoop Belgische coördinaten door hetzelfde hashing mechanisme sturen en zo toch weer bij de originelen uitkomen.

In dit geval moet je dus de partij die de server beheert echt wel vertrouwen dat ze goed omgaan met de data. Een positief punt is wel dat je via de data die in de app zelf zit, weinig tot geen aanvallen kan opzetten. De server is hier het zwakke punt.

Matching op de smartphone (decentralisatie)
De enige manier om je locatie geschiedenis niet te hoeven doorsturen, is door je gegevens lokaal op je toestel te houden en daar de besmette locaties gaat vergelijken met jouw geschiedenis. Daarvoor moeten natuurlijk wel de besmette coördinaten gekend zijn op de server, mensen die dus besmet geraakt zijn, moeten in dit geval wel hun locatie data delen. Laten we er van uit gaan dat hier wel heel duidelijke toestemming voor wordt gegeven, zoals opgelegd door GDPR.

Maar ook hier, hoe je die data van besmette gebruikers ook omvormt of encrypteert, uiteindelijk moeten de ontvangende apps in staat zijn om die data te vergelijken met hun eigen verzamelde coördinaten. Met een beetje moeite kan je dus van al die besmette gebruikers hun locaties toch weer afleiden.

In dit geval krijgt letterlijk iedereen die de app gebruikt in essentie de locatie data van besmette personen. Dit maakt dat deze methode een enorm risico inhoudt en de app zelf heel kwetsbaar wordt.

De opties voor Bluetooth gebaseerde systemen

Aangezien je bij het contact tracing systeem via Bluetooth eigenlijk continu een signaal uitstuurt met je smartphone, is dit ook meteen een zwakke plek. De grote vraag is: wat ga je versturen? Je kan hier niet zomaar iets persoonlijk de lucht in sturen en hopen dat niemand die gegevens actief gaat verzamelen. Eigenlijk wil je iets de lucht in sturen dat compleet willekeurig is en niet aan jou als persoon te linken is. Maar ook als je continu hetzelfde bericht uitstuurt, ben je kwetsbaar, ook al is dat bericht willekeurig gegenereerd. Eens iemand weet welk bericht bij jou hoort, kan hij je met de juiste tools in principe volgen.

Matching op de server (centralisatie)

In dit geval moet de server dus eigenlijk weten wie welk bericht de lucht in stuurde, op elk mogelijk tijdstip van de dag. Alle apps zullen er dus voor moeten zorgen dat al hun uitgezonden berichten geregistreerd staan onder hun gebruiker op de server.

Wanneer een andere app dan zo een bericht oppikt, stuurt die dat gewoon naar de server en gaat die bepalen of je bericht matcht met een andere gebruiker zijn uitgezonden berichten.

Dit geeft duidelijk aan dat je hier opnieuw de server moet vertrouwen dat hij op een correcte manier met deze data omgaat.

Matching op de smartphone (decentralisatie)

Hier volgen we weer het systeem dat enkel besmette mensen hun gegevens doorgeven aan alle andere apps. In dit geval zijn “die gegevens” alle mogelijke berichten die andere apps kunnen ontvangen hebben van de besmette app gebruiker. In dit systeem is het belangrijk dat die berichten niet gelinkt kunnen worden aan gebruikers. Dit is gelukkig mogelijk, in tegenstelling tot bij de GPS methode.

Het probleem bij GPS is dat we coördinaten doorsturen om mee te vergelijken, en die inherent terug te leiden zijn tot een persoon. Komt ook nog eens bij dat iedereen die op dezelfde locatie staat, (min of meer) dezelfde coördinaten gaat versturen.

Bij Bluetooth hoeft dat niet, hier kan je eigenlijk iets compleet willekeurig genereren op je smartphone, en dat daar ook houden. Dit noemen we hier een ID. Als je ervoor zorgt dat je niet dit ID uitstuurt, maar iets dat je eruit afleidt, en dat daarbovenop die afgeleide niet terug te vertalen is naar het ID, heb je in principe een veilig bericht om uit te sturen. Dat bericht kan je dan niet aan jou linken zonder dat je het ID weet dat op de smartphone verborgen zit.

Apps die dit bericht ontvangen, slaan dit gewoon op. Op dat moment kunnen ze er nog niks mee aanvangen. Maar wanneer iemand besmet is, zal die gevraagd worden zijn IDs toch te uploaden naar de server en zullen die verspreid worden over andere apps. Op dat moment kunnen die apps in hun geschiedenis gaan kijken om te zien of ze deze IDs hier in herkennen en dus met deze besmette persoon in aanraking gekomen zijn.

In dit systeem heeft de server dus veel minder kennis over de besmettingen, de cruciale persoonsdata zit op de smartphone van de gebruikers. Een voorbeeld van een initiatief die deze manier van werken volgt is DP3T.

Combinaties

Over de combinatie van Bluetooth en GPS data kunnen we kort zijn: dit systeem is zo sterk als zijn zwakste schakel. In dit geval is dat eigenlijk GPS. Hoe anoniem je Bluetooth data ook is, vanaf je GPS locaties gaat verzamelen en de twee aan elkaar gaat koppelen, ondermijn je de sterke punten van de Bluetooth methode.

Wat is dat initiatief van Apple en Google?

Apple en Google brachten onlangs hun “Exposure notification” systeem uit. Eigenlijk is dit een voorbeeld van een gedecentraliseerde Bluetooth oplossing. Het probleem dat de 2 bedrijven hier proberen op te lossen is vooral technisch: op dit moment is het heel moeilijk/onmogelijk om met de bestaande Bluetooth functionaliteit op Android en iOS een systeem te maken dat stabiel werkt en compatibel is met beide platformen. Ik zou zelfs zo ver durven gaan als stellen dat Bluetooth contact tracing apps die niet via dit nieuw systeem werken, ofwel enorm veel batterij gaan verbruiken door de workarounds die ze moeten gebruiken om het werkend te krijgen (zoals bvb het scherm actief houden op iOS), ofwel technisch gewoon niet voldoende gaan werken door limitaties van apps wanneer ze in de achtergrond draaien.

Dit systeem verdient eigenlijk een blogpost op zich om de exacte werking uit te leggen. De volledige manier van werken is volledig openbaar gemaakt via Apple & Google hun eigen blogs en zou ons te ver brengen. Belangrijk om op te merken is wel dat Apple en Google hier echt hun best gedaan hebben om alle risico’s te beperken.

Een overheid moet dit systeem zelf inbouwen in een app. In die app moet de overheid zelf voor een systeem zorgen om mensen als besmet te aan te duiden (via lokale gezondheidsplatformen), op die manier voorkomen Apple/Google dat zij deze gezondheidsdata hoeven te kennen. De apps werken min of meer als volgt:

  • Op je device wordt een ID gegenereerd, dagelijks een ander, op een willekeurige manier. Er is dus geen enkele link met jou als persoon. Dit ID verlaat je device niet zolang je gezond blijft.
  • Uit dit ID worden de berichtjes afgeleid die via Bluetooth uitgezonden gaan worden. Uit die berichten kan je dat ID niet meer afleiden (voor de kenners: via hashing). Elke x minuten zal er een nieuw bericht afgeleid worden en zal je toestel dit nieuwe bericht beginnen uitsturen. Zo wordt het praktisch onmogelijk om dit signaal op te pikken van buiten af, en zo alsnog mensen voor langere tijd ongewenst te traceren.
  • Het zijn deze berichtjes die de ontvangende apps opslaan, hier zijn ze in principe nog niks mee.
  • Op het moment dat iemand (bevestigd) besmet is, wordt afgedwongen dat deze persoon expliciet de vraag krijgt of hij zijn IDs wil doorsturen. Geeft hij die toestemming, dan vertrekken zijn IDs via de server naar alle andere apps.
  • De IDs zijn, zoals reeds aangegeven, elke dag anders en zijn willekeurig gegenereerd. Er is dus eigenlijk geen enkele link met jou als persoon te leggen voor eender wie deze IDs ziet voorbij komen. Dat geldt dus ook voor de server.
  • De apps van gezonde gebruikers halen geregeld de besmette IDs op van de server, nu zij die IDs kennen, kunnen ze terug gaan kijken in de berichten die ze via Bluetooth ontvangen hebben. Op dit moment kunnen de apps gaan berekenen of de gebruiker risico gelopen heeft.

Er zijn nog een aantal bijkomstige zaken die ervoor zorgen dat dit systeem juist gebruikt wordt:

  • Enkel overheden mogen een app uitbrengen die hun systeem gebruikt
  • Die apps mogen geen Bluetooth of GPS permissies vragen, wat het dus onmogelijk maakt dat die apps toch stiekem nog extra data verzamelen.
  • De IDs blijven op je device, Apple en Google krijgen die niet in handen.
  • Een nieuwe regel dwingt ook af dat enkel overheden nog Covid apps mogen uitbrengen, of dat nu via hun exposure notification systeem is of een ander.

Apple en Google hebben enkel de werking openbaar gemaakt, niet de broncode. Dat geeft nog een zeker risico dat ze niet doen wat ze zeggen wat ze doen, maar het enige waar je ze eigenlijk echt op moet vertrouwen is dat zij die IDs niet aan je profiel koppelen en ze dus op je device blijven. Er zijn wel een aantal dingen die je kan doen om ze daarop in zekere mate te controleren. Alle andere componenten in het systeem zijn in principe veilig by design.

De enige partij die je dus bij hun systeem moet vertrouwen, zijn Apple en Google zelf. Maar laten we eerlijk zijn: die keuze om hen te vertrouwen heb je eigenlijk al gemaakt toen je je toestel met iOS of Android kocht. Het risico dat zij iets fout deden met je gegevens wordt hier niet groter door.

Maar wacht, er zijn toch al veel bedrijven die privacy gevoelige data hebben?

Klopt, als je nu gaat lopen met Runkeeper, gaat fietsen met Strava, of navigeert met Google Maps of Waze, je gegevens worden al verzameld. Maar je hebt uiteindelijk nog altijd zelf de keuze om deze diensten al dan niet te gebruiken. Als deze diensten een duidelijke winst opleveren, kan je bereid zijn bepaalde zaken op te geven.

Het opzet van de Covid app is lichtjes genuanceerder: als we veel gebruikers willen bereiken, moeten we zoveel mogelijk twijfel weghalen over hoe veilig deze is, op een objectieve manier. Reken er ook maar op dat er een push van de overheid en andere instanties komt om die app te installeren, ook al is die niet verplicht. Je zou kunnen zeggen dat hier dus een vorm van propaganda bij komt kijken die je richting de app pusht. Op zich geen probleem als het heel helder is wat de implicaties zijn van die app te gebruiken. Maar we weten allemaal hoe helder die risico’s door bovengenoemde bedrijven in het verleden al gecommuniceerd geweest zijn. Er zijn altijd risico’s waar lacherig over gedaan wordt, tot het zich in de praktijk voordoet. De veiligste assumptie? Wat gehackt of misbruikt kan worden, zal gehackt of misbruikt worden. Als je echt de grootst mogelijke groep gebruikers wil bereiken, zal je ook naar de meest kritische mensen hun bezorgdheden moeten luisteren.

Mijn conclusies

Alles hangt natuurlijk af van hoe je zelf staat tegenover alle instanties die je in elk scenario moet vertrouwen. Maar objectief gezien is de gedecentraliseerde Bluetooth aanpak veruit de veiligste waarin je het minste risico loopt en dus ook het minste aantal mensen/organisaties moet vertrouwen.

Als we dat even terugkoppelen naar ons doel van zoveel mogelijk mensen overtuigd te krijgen van de app, is dit ook meteen de aangewezen manier om zo weinig mogelijk mensen te laten afvallen door wantrouwen in de technologie. Meer nog: ik zou zeer sterk aanbevelen dat, als we voor een app kiezen, we hiervoor het Apple/Google exposure notification systeem gebruiken. Niet alleen om het lagere risico, maar ook omdat zij heel veel van de security en stabiliteit op zich nemen. Onderschat niet hoe complex het wordt om Bluetooth op een stabiele manier te implementeren voor alle mogelijke toestellen, of hoe makkelijk er kleine foutjes in de security mechanismes sluipen die grote gevolgen kunnen hebben. We hoeven het wiel hier echt niet opnieuw uit te vinden.

Verder beveel ik ook sterk aan om de functionaliteit van de app zo beperkt mogelijk te houden, hoe kleiner en lichter de app, hoe meer mensen deze gaan installeren. De broncode moet ook open source gemaakt worden en de uiteindelijke binaries mogen niet geobfusceerd worden, zodat mensen die dat willen, de code kunnen nakijken of de app zelf decompileren. Als er twijfels zijn bij de werking, kan iedereen die daar toe in staat is zelf de feiten gaan controleren. En wees maar zeker, ik zal dat doen. Dit alles draagt alleen maar bij aan een positief marketing verhaal.

Dat brengt ons bij de laatste vraag: moet er effectief een app komen?

Daarvoor wil ik nog even wijzen op het feit dat we hier enkel de technische correcte aanpak besproken hebben. Deze geeft op geen enkele manier een garantie dat, als deze correct geïmplementeerd is door de bouwers, deze app ook effectief gaat werken en een nut gaat hebben. Technologie kan niet altijd alles oplossen. Al is het in dit geval wel interessant om het te proberen. Er zijn geen precedenten die zouden kunnen bewijzen of ontkrachten dat dit gaat werken, we kunnen dus veel leren van de resultaten. Dit zal ervoor zorgen dat we in de toekomst hier een veel betere inschatting over kunnen maken.

En als we het proberen, moeten we het alle kansen geven. En dat betekent ook de belangrijkste richtlijnen volgen om het aantal gebruikers te kunnen maximaliseren. Het feit dat onze maatschappij wakker ligt van zijn privacy betekent ook dat we hiermee rekening moeten houden en dus voor de oplossing moeten gaan die hier het best op aansluit. We hebben nu gezien dat zo een technische oplossing er ook is, dus waar wachten we nog op? Als uit de resultaten blijkt dat deze oplossing toch onvoldoende effectief is, kunnen we nog discussiëren over al dan niet bepaalde risico’s voor onze privacy te aanvaarden. Maar laten we eerste alles uit de kast halen om het op deze manier te proberen, en dat zo snel mogelijk.

Voor een laatste keer: onderschat ook niet hoe belangrijk het is om zoveel mogelijk gebruikers te bereiken. Ik acht het vrij onwaarschijnlijk dat 60% van de burgers deze app vrijwillig zal (of zelfs kan) installeren, dit cijfer hoorde ik al vaak circuleren maar is naar mijn mening enorm onrealistisch. Naar mijn aanvoelen zal het al een succes zijn als we 20% kunnen bereiken. Elke gebruiker telt dus, vandaar mijn constante druk op al het wantrouwen richting de app op een objectieve manier wegwerken.

Dus samengevat: ja de app moet een kans krijgen, maar ik ga hem persoonlijk enkel installeren als het vertrouwen in de technologie en de instanties er achter goed zit. En die zekerheid heb ik nu enkel in een systeem met security en privacy by design, dus met een gedecentraliseerde Bluetooth oplossing en het exposure notification systeem van Apple/Google als basis. Kunnen andere oplossingen omdat ze mogelijks effectiever zijn? Misschien, maar dan moet ik mijn afweging opnieuw maken. Bewijs het dan met objectieve feiten en cijfers dat de meest risicoloze oplossing niet werkt, dan sta ik zeker open voor discussies.

Waar ik dan weer wel tegen ben, is een app die niet optimaal voldoet aan de vereisten die onze maatschappij stelt. Dan kan er evengoed geen app zijn en kunnen we ons de kost om die te bouwen best besparen.

Dus beste overheid, het wordt tijd dat ik mij tot u richt: als we een app willen gebruiken om die fameuze tweede golf in te dijken, begin er dan alstublieft vandaag aan en stel deze beslissing niet langer uit. Verschuil u niet achter politieke spelletjes en bevoegdheden. Als we voor de app gaan, dan moet die er nu echt gaan komen. Voer deze discussies dan ook eindelijk eens openlijk, zo zal je al heel wat twijfels vermijden. Transparantie begint bij stap 1.

Als laatste: dit artikel is op geen enkele manier gestuurd, aangevraagd of bepaald door één van mijn werkgevers gisteren, vandaag of morgen. Het is er vooral gekomen uit persoonlijke bezorgdheid over hoe we op dit moment in België met deze app situatie omgaan, zowel in de politiek, pers als op sociale media. Het idee blijft leven onder de oppervlakte, maar we hullen ons in stilzwijgen. Laten we deze discussie gewoon eens openlijk en fundamenteel voeren om tot een echte beslissing te komen, wat die ook moge zijn.

--

--