De Nederlandse overheid wil de coronapandemie bestrijden met een 'corona-app'. En dat is eigenlijk het enige wat we tot nu toe weten. Over basale dingen, zoals pak 'm beet de werking ervan, wordt alleen nog maar gespeculeerd en minister De Jonge kon tot dusver niet meer uitleg geven dan dat de app 'waarschijnlijk via bluetooth' werkt. Eén ding is al wel zeker; een corona-app werkt alleen als die door veel burgers wordt gebruikt. Een meerderheid, welteverstaan, en dat bereik je alleen als je het verplicht stelt óf als twee grote spelers zich met de ontwikkeling bezighouden. Dat laatste is nu gebeurd. Google en Apple gaan samenwerken om een corona-trackingmethode aan Android en iOS toe te voegen.
De aankondiging kwam als een donderslag bij heldere hemel op Goede Vrijdag. De samenwerking is niet alleen raar, maar ook logisch, want samen domineren Google en Apple de markt voor besturingssystemen voor smartphones. Als er twee bedrijven zijn die dit samen kunnen oplossen, zijn zij het wel.
Contactonderzoek
De plannen van de twee techgiganten hebben veel weg van de manier waarop diverse overheden nu proberen het coronavirus tegen te gaan. Dat gebeurt op basis van contactonderzoek. Burgers krijgen dan een automatische melding als ze bij iemand in de buurt komen die symptomen van het virus heeft. De meest logische manier is om dat via locatiedata te doen, maar dat ziet niemand echt zitten, vanwege de hevige privacyimplicaties. Bovendien zit je dan met de precisie. Gps is buiten, onder ideale omstandigheden misschien net wel of net niet nauwkeurig genoeg, maar binnen heb je er geen fluit aan.
Er gaan daarom steeds meer stemmen op om contactonderzoek via bluetooth te doen. Dat is decentraler en daarom een stuk anoniemer. Bij bluetoothcontactonderzoek wisselen telefoons id's uit met andere telefoons in de buurt, die op de toestellen zelf worden opgeslagen. Komt het id overeen met het id van iemand die coronasymptomen heeft, dan krijgt de ontvanger een waarschuwing. Een probleem: dit systeem werkt volgens veel wetenschappers pas als minimaal zestig procent van een bevolkingsgroep de app heeft geïnstalleerd.
Daarom kan het veel toevoegen als zowel Apple als Google een dergelijke methode toevoegt aan zijn besturingssysteem. De vraag is alleen hoe de twee partijen dat kunnen doen op een manier die de privacy waarborgt. Omdat het gaat om een api, krijgen Google en Apple de data van contact-apps niet zelf in handen. De api zorgt alleen voor een koppeling tussen apps en apparaten. Heel waardevol is die data trouwens niet; het enige dat je krijgt, is een lijst willekeurige getallen. Een andere belangrijke waarborg is dat de locatie van gebruikers nergens centraal wordt opgeslagen.
Beperkingen
Bij het inzetten van bluetooth voor contactonderzoek gelden natuurlijk ook wat beperkingen. Voorkomen moet worden dat iedereen een melding krijgt als hij of zij binnen het bluetoothbereik van een ander is geweest zonder elkaar te kunnen besmetten. Dat is mogelijk door aan de hand van de sterkte van het signaal de afstand tot een apparaat te schatten. Elementen die besmetting tegenhouden, zoals muren, verzwakken vaak ook het signaal. Daarnaast moeten de telefoons vermoedelijk een bepaalde periode bij elkaar in de buurt zijn voordat ze id's uitwisselen. Op die manier is het niet zo erg als er iemand met het virus onder de leden langs je huis fietst.
De bedoeling is dat als iemand positief wordt getest op het coronavirus of symptomen daarvan toont, dat wordt ingevoerd in een app. Dat moet worden gedaan of op z'n minst worden gevalideerd door een gezondheidsorganisatie om te voorkomen dat Jantje uit drie havo zijn hele klas twee weken vrijgeeft door voor de lol zichzelf aan te merken als coronapatiënt. Google en Apple willen dat echter niet verplicht maken. Sterker nog: gebruikers moeten zichzelf aanmelden. In eerste instantie moet dat via een app die in een van de downloadwinkels staat, maar op een gegeven moment kan dat zonder app. Dan nog zal niet iedereen meedoen.
Wat nu als het RIVM de tussenkomst van een gezondheidsorganisatie verplicht wil maken? Google en Apple willen niet echt antwoorden op die vraag. Ze werken samen met gezondheidsorganisaties van landen wereldwijd, maar als die tussenkomst wordt geëist, is dus niet duidelijk wat de reactie van Apple en Google zal zijn.
Als het RIVM een app maakt, hoeft die zich niet te beperken tot contactonderzoek via de nieuwe, gesloten api. Het verzamelen van locatiegegevens via andere api's is dan niet per se verboden, zo laten beide bedrijven weten. Dat opent de deur voor apps die meer doen dan alleen dit relatief privacyvriendelijke contactonderzoek. Van de andere kant heeft de Nederlandse privacytoezichthouder zich eerder al uitgesproken tegen het zomaar verzamelen van locatiedata.
Het plan
Apple en Google willen een api voor corona-apps in hun besturingssystemen verwerken
Het plan van Apple en Google bestaat uit twee delen. Het eerste is de ontwikkeling van een api waarvan apps gebruik kunnen maken en die in mei moet uitkomen. Het tweede is het inbakken in de besturingssystemen zelf, waarbij je je kunt aan- en afmelden in de instellingen. Dat tweede deel volgt pas 'in de maanden erna' en er zijn nog weinig details over bekend.
Over dat eerste, de api, wel. Een application programming interface is uiteraard niets meer dan de tussenlaag tussen apps en de data die ze gebruiken. Zoals eerder gezegd gaat het daarbij dus niet om locatiedata, maar om databases met id's van telefoons waarmee een andere telefoon in contact is gekomen. Google en Apple willen een api bouwen waarmee overheden en gezondheidsorganisaties de resultaten van hun apps over verschillende platforms aan elkaar kunnen koppelen. De database met de id's staat in de eerste plaats lokaal op toestellen, maar als een gebruiker positief wordt getest op het coronavirus, kunnen gezondheidsorganisaties na toestemming toegang krijgen tot die lokale database.
In die eerste fase is de back-end nog verschillend in iOS en Android; het lukt niet om voor die tijd een api te bouwen die met dezelfde back-end kan communiceren. Organisaties zullen dus in de eerste fase vermoedelijk met verschillende servers moeten werken. Later hoeft dat niet meer.
Traceersleutels
Een telefoon maakt daarvoor om te beginnen een tracing key aan. Dat is een willekeurige code die gedurende de hele tijd voor het apparaat hetzelfde blijft, maar die altijd op de telefoon blijft staan en dus niet centraal wordt opgeslagen. Vervolgens maakt de api op basis van die tracing key ook een tweede code aan, een daily tracing key, die is afgeleid van de permanente tracing key. Die code verandert elke dag. Dat is de code die de telefoon naar andere telefoons kan sturen die volgens de regels van de gezondheidsorganisatie bij besmetting een risico kunnen opleveren.
Maar de telefoon loopt niet de hele tijd die daily tracing key naar de hele wereld te schreeuwen. Daarvoor is de rolling proximity identifier. Die wisselt elk kwartier en kan door elk bluetoothapparaat worden opgevangen. Het elk kwartier wisselen maakt het volgen van mensen in bijvoorbeeld een stadscentrum met beacons onmogelijk. Apple en Google gebruiken het mac-adres voor bluetooth van het apparaat niet.
(De)centralisatie
Wat er daarna gebeurt, is onbekend. Het zou kunnen dat van elke patiënt wereldwijd de eigen database op een centrale server wordt gezet en dat elke telefoon die downloadt op zoek naar matches. Heel logisch is dat echter niet; het levert veel te veel dataverkeer op. Dat gaat dus in eerste instantie per app, die per land of per regio werkt; dat mogen gezondheidsorganisaties zelf kiezen. Daarbij kan het zijn dat een app elke dag duizenden keys moet binnenhengelen. Dat zal voor veel Nederlanders en Belgen geen enorm probleem zijn, maar er zijn mensen met beperkte toegang tot internet en dan kan dat een probleem vormen. Er is nog niet genoeg bekend over hoeveel dataverkeer het oplevert.
De api gebruikt unieke
De api maakt melding van een diagnosis key; een subset van dagelijkse codes van besmette patiënten. Die wordt doorgegeven aan de software, waarna die op zoek gaat naar matches. Als die niet gevonden zijn, gebeurt er niets. Als dat wel zo is, vraagt de software toestemming om zaken door te sturen over het bluetoothcontact dat een match heeft; hoe vaak de gebruiker daarbij in de buurt is geweest en hoelang.
sleutels om die via
bluetooth uit te zenden
Derde partijen
Google en Apple maken de api beschikbaar voor gebruik met apps van derden. Dat is niet zomaar iedere partij die een contact-tracingapp maakt, want daarvan zijn er inmiddels tientallen in de maak. De bedrijven geven alleen 'goedgekeurde instanties' toegang tot de api. Dat zou in Nederland het RIVM kunnen zijn of de partij die de Nederlandse aanbesteding voor het plan van minister De Jonge wint. Het is nog niet duidelijk welke criteria Google en Apple hanteren om de toegang te bepalen. Beide bedrijven zeggen wel te werken met een whitelist van organisaties die toegang kunnen krijgen.
Die api is pas het eerste deel van het plan. In een later stadium moet de functie worden ingebouwd in Android en iOS. Dan kunnen gebruikers in de instellingen van hun besturingssysteem aangeven dat ze met het onderzoek willen meedoen, waardoor het niet meer nodig is een aparte app te installeren. Dat moet gebeuren op basis van opt-in, schrijven Google en Apple, maar details zijn nog schaars. "Privacy, transparantie en toestemming zijn het belangrijkst hierin, en we kijken ernaar uit om deze functionaliteit te bouwen in overleg met geïnteresseerde partijen", schrijven de bedrijven in de aankondiging van vrijdag. Ze brengen op een later moment 'informatie over dit werk uit voor anderen om te bekijken'.
Waarom dit nodig is
Deze twee gigantische bedrijven kunnen het bereik van contact-tracingapps flink vergroten
Het plan van Google en Apple kwam op een goed moment, want de discussie over deze apps is aan het losbarsten. Daarbij bleek dat een Singaporese app die via bluetooth werkt, TraceTogether, een probleem heeft: het geringe gebruik. Onderzoekers zeggen dat zo'n zestig procent van de burgers een contact-tracingapp moet installeren voordat die effect heeft, maar dat percentage is erg hoog. In Singapore wordt de Trace Together-app ingezet en door veel landen jaloers bekeken, maar ondanks het voorzichtige succes riepen de autoriteiten burgers eerder al op om de app meer te installeren. Slechts zestien procent van de burgers blijkt de app te gebruiken.
Er wordt dus veel nagedacht over hoe een grote groep gebruikers kan worden bereikt. Installatie verplicht stellen heeft waarschijnlijk niet de voorkeur van de Nederlandse overheid, maar minister De Jonge sloot dat tijdens zijn persconferentie ook niet direct uit. Inmiddels zijn er in Nederland verschillende groepen wetenschappers, privacyexperts en burgerrechtenorganisaties die zich hebben uitgesproken tegen verplichte apps, en die bereid zijn dat aan te vechten. Het bereik van Android en iOS kan daarom voor een groot deel helpen dat benodigde bereik te halen.
Technische iOS-beperkingen
Eerdere voorstellen hadden echter nog een ander probleem en dat is meer technisch van aard. Het zit specifiek in iOS en komt zo: zonder de api mag een app niet op de achtergrond bluetooth-id's uitwisselen met onbekende apparaten. Op de achtergrond zoeken naar bekende apparaten kan wel voor de verbinding met bijvoorbeeld slimme sloten. Het gevolg is dat zulke apps standaard op de voorgrond moeten staan met het scherm aan om te werken. Maar zodra een iPhone-gebruiker een berichtje krijgt, zal hij dat vermoedelijk even lezen en dan moet een iPhone-gebruiker de bluetooth-app weer op de voorgrond zetten en het scherm aanlaten; geen goede gebruikservaring dus en bovendien slecht voor de accuduur.
Het voordeel van de api van Google is dat Google de ondersteuning via Play Services op vrijwel alle westerse smartphones kan krijgen. In China ligt dat lastiger, maar de kans is klein dat China deze techniek gaat gebruiken. Daarmee dreigen recente Huawei-smartphones, die geen Google-apps hebben, buiten de boot te vallen. Google maakt wel een framework beschikbaar waarmee Huawei aan de slag kan, maar of Huawei dat gaat doen en hoe lang dat gaat duren, is nog onbekend.
Apple pusht vermoedelijk een kleine update om de api in te bouwen. De fabrikant ondersteunt nu nog iOS 13 en 12, en kan dus voor beide versies een punt-update maken. De ervaring leert dat relatief veel gebruikers die relatief snel installeren, al gaat dat vermoedelijk niet zo snel als de updates via Play Services; die vereisen geen herstart of zelfs maar een click van een gebruiker. Google kan deze api dus vermoedelijk sneller op veel smartphones krijgen dan Apple.
Een voordeel van een implementatie via Google en Apple is dat beide bedrijven de service beschermen die apps met deze api op de achtergrond draaien. Zo zal het besturingssysteem ze niet per ongeluk kunnen killen als er te weinig geheugen is of het systeem vindt dat de app te veel accusap drinkt.
Kritiek
Google en Apple worden met het plan belangrijke partners van de overheid
Als je aan Google denkt, dan is privacy misschien niet het eerste woord dat in je opkomt. Niet iedereen is daarom even blij met de aankondiging, want het gaat hier immers over twee heel grote bedrijven die zich met wel heel gevoelige gezondheidsdata gaan bezighouden, ook al hebben ze daar zelf geen directe toegang toe. Ook los daarvan zijn er nog veel vragen, veelal niet eens technisch van aard. Wat gebeurt er bijvoorbeeld als je van telefoon wisselt? Kunnen restaurants of bioscopen je weigeren als je geen app hebt? Mag je de telefoon van iemand anders meenemen?
De specifieke plannen van Apple en Google leiden bovendien niet alleen tot zorgen over privacy. Ook de macht van de techbedrijven staat ter discussie. Google en Apple presenteren zich hier als de perfecte partners voor overheden: als je een grootschalig, wereldwijd vraagstuk wil oplossen, dan zijn wij daar het geschiktst voor! Nu zetten de bedrijven die macht nog in voor het algemeen belang, voor de volksgezondheid, en dat is uiteraard een nobel doel. Maar je kunt een samenwerking met de twee machtigste mobielebesturingssysteemfabrikanten ook voor andere doelen aangaan. Misschien wel voor misdaadbestrijding bijvoorbeeld. Het zijn vragen die misschien nog lang niet van toepassing en wellicht veel te voorbarig zijn, maar het is wel goed er nu al over na te denken.
Het is dus ook de vraag of partijen als het RIVM wel om deze api van Apple en Google heen kunnen; het lijkt de enige manier om een app te bouwen die genoeg mensen willen gebruiken. Nu is het aan de bedrijven en overheden om mensen ervan te overtuigen dat deze oplossing nuttig en nodig is. In korte tijd een api bouwen is misschien verdraaid moeilijk, maar gebruikers ertoe overhalen om een app te installeren is, gezien het geringe enthousiasme in Singapore, misschien een nog grotere uitdaging.