dvertentie-infrastructuur in een zorgjas is een bouwkeuze
Laadt een app die zich als zorg of welzijn presenteert al bij het opstarten advertentie- en analytics-netwerken, dan is dat geen ongelukje in de code. Het is een keuze in het ontwerp, gemaakt door wie de app liet bouwen. De jas is zorg, de motor is marketing.
De jas is zorg, de motor is marketing¶
Er zijn apps en sites die zich presenteren als zorg of welzijn. Een hulplijn, een gezondheidsplatform, een welzijnsdienst. Wanneer zo'n app al bij het opstarten advertentie- en analytics-netwerken laadt, is dat een ontwerpkeuze. Iemand heeft besloten dat die netwerken erin komen, en iemand heeft de app zo laten opleveren dat ze bij de start meteen vuren. De buitenkant belooft hulp. De infrastructuur eronder komt uit de reclamehandel.
Dat klinkt hard, en het is een bewering die ik wil onderbouwen voordat ik hem uitspreek. Het bewijsniveau is hier belangrijk. Dat de netwerken laden kan ik meten: het staat in het netwerkverkeer bij de eerste seconden van de app. Dat het een keuze in het ontwerp was, is een afgeleide conclusie uit hoe software wordt gebouwd. Advertentie- en analytics-netwerken komen niet vanzelf in een app terecht. Ze zitten er pas nadat iemand ze heeft toegevoegd.
Een bouwkeuze die stap voor stap wordt gemaakt¶
Zulke netwerken komen mee via een reeks bewuste handelingen. Iemand heeft een SDK aan het project toegevoegd. Iemand heeft een tag geplaatst in een tagmanager. Iemand heeft een verwerker gekozen en een sleutel of container-id in de configuratie gezet. Elk van die stappen staat in de broncode, in de build-configuratie of in het beheerpaneel van de tagmanager. Het zijn regels die iemand heeft geschreven of aangevinkt.
In een mobiele app is dat zichtbaar te maken. Een SDK die bij het opstarten vuurt, verstuurt in de eerste seconden een initialisatieverzoek. Dat verzoek is te vangen. Een ruwe procedure om te zien wat er meteen na de start naar buiten gaat:
# volg het uitgaande verkeer van de app en zeef de eerste bestemmingen
adb logcat | grep -iE 'analytics|adjust|appsflyer|firebase|facebook' &
# of onderschep het verkeer via een proxy en exporteer een HAR,
# daarna de unieke hosts in de eerste vensters eruit halen
jq -r '.log.entries[] | .request.url' capture.har | awk -F/ '{print $3}' | sort | uniq -c | sort -rnWat bovenaan die lijst staat, is wat de app als eerste opzoekt. Bij een zorgapp verwacht je daar de eigen backend en verder weinig. Staan er advertentie- en attributienetwerken tussen, dan is dat gemeten feit. Ik noteer per netwerk de host, het moment van vuren en de aard van de payload, zodat de vaststelling navolgbaar blijft en niet op een indruk berust. Dat de app het netwerk laadt, staat dan los van de vraag wat de bouwer bedoelde, en die twee houd ik streng gescheiden in mijn oordeel. Zie Niet alles vuurt bij opstart, sommige trackers wachten op jou voor waarom het moment van vuren telt, en Netwerkverkeer lezen via HAR-files voor de meetmethode.
Waarom de context het zwaarder maakt¶
Dat dit bij een hulpplatform gebeurt, maakt het niet minder bewust. Het maakt het wel pijnlijker. De bezoekers van een zorgdienst zijn per definitie kwetsbaar, en de gegevens die ze achterlaten zijn gevoelig. Iemand die een hulplijn opent, een symptoom opzoekt of een welzijnstest doet, laat gegevens over gezondheid achter.
De AVG behandelt gezondheidsgegevens als een bijzondere categorie onder artikel 9. Voor die categorie geldt een verbod op verwerking, met beperkte uitzonderingen. Zelfs het gegeven dat iemand een bepaalde zorgdienst gebruikt kan al gevoelig zijn, want het onthult iets over de gezondheidssituatie van die persoon. Een advertentie- of analytics-netwerk dat bij zo'n dienst gedrag verzamelt, raakt daarmee de zwaarst beschermde gegevens die de AVG kent. De drempel voor rechtmatige verwerking ligt hier hoger dan bij een gewone webshop.
Bij het opstarten telt het moment¶
Dat de netwerken al bij het opstarten vuren, is niet toevallig van belang. Het moment waarop een verzoek uitgaat, bepaalt of er een toestemming aan vooraf kon gaan. Vuurt een advertentie- of analytics-SDK meteen bij de start, dan is er nog geen scherm geweest waarop de bezoeker iets kon kiezen. Voor het lezen en schrijven van gegevens op een apparaat vraagt artikel 11.7a van de Telecommunicatiewet toestemming, en die toestemming kan er op het opstartmoment nog niet zijn.
Dat maakt het opstartgedrag tot een harde toets. Het is gemeten wanneer een verzoek uitgaat, en daaruit volgt of het vóór of na een keuze gebeurde. Zie Niet alles vuurt bij opstart, sommige trackers wachten op jou voor de nuance dat niet elke tracker meteen vuurt, en dat je dus zowel de eerste seconden als het latere gebruik moet meten. Bij een zorgdienst weegt een verzoek in de eerste seconden extra zwaar, want de bezoeker heeft dan nog niets kunnen weigeren en de gegevens zijn per definitie gevoelig.
Verantwoordelijk is wie het liet bouwen¶
De aansprakelijkheid ligt bij de organisatie die de app bestelde en oplevert, niet bij de losse SDK. Een SDK is een gereedschap. De keuze om dat gereedschap in een zorgdienst te zetten, is van de opdrachtgever. In de taal van de AVG is die organisatie de verwerkingsverantwoordelijke onder artikel 4. Zij bepaalt doel en middelen van de verwerking. De leverancier van de SDK is hooguit verwerker onder artikel 28, en dan nog alleen binnen de opdracht die de verantwoordelijke geeft.
Wie een zorgjas over een advertentiemotor hangt, kan zich daarom niet verschuilen achter de leverancier. Het papier van de dienst belooft zorg. De code voert marketinginfrastructuur uit. De verantwoordelijkheid voor dat verschil ligt bij degene die de opdracht gaf en de oplevering accepteerde. Dat is een juridische gevolgtrekking uit de rolverdeling in de AVG, en die staat los van de vraag of iemand het bewust of onnadenkend deed.
Wat ik hiervan meet en wat ik laat staan¶
Ik meet de bestemmingen bij het opstarten en ik benoem welke daarvan tot de reclame- en analytics-handel horen. Dat is de harde, controleerbare laag. Ik meet niet de bedoeling van de bouwer, en die claim ik dus niet. Wat ik vaststel is dat de infrastructuur er is, dat ze bij de start vuurt, en dat de context er een van gevoelige gegevens is.
De rest is weging. Een advertentiemotor onder een zorgjas is een bouwkeuze, gemaakt door wie de app liet maken en accepteerde. Ik trek die weging pas als de meting staat. Eerst de bestemmingen en het moment van vuren, hard en controleerbaar, en pas daarna het oordeel over verantwoordelijkheid. Die volgorde houdt mijn bevindingen bruikbaar voor iemand die er iets mee moet, want ze rusten op wat aantoonbaar is en niet op wat ik vermoed. Of dat met opzet of uit gemakzucht gebeurde, kan ik niet meten, en daarom laat ik dat oordeel open. Wat vaststaat is de verantwoordelijkheid, want die volgt uit de rol, niet uit de intentie. Zie De maker en de aandeelhouder willen niet hetzelfde voor waarom de keuze bij de bouwers en beslissers ligt.
Zie ook De bouwers en de beslissers weten vaak niet van elkaar, Niet alles vuurt bij opstart, sommige trackers wachten op jou en De maker en de aandeelhouder willen niet hetzelfde.
- AVG, artikel 9 lid 1gezondheidsgegevens mogen in beginsel niet worden verwerkt
- AVG, artikel 25gegevensbescherming door ontwerp: de keuze voor de infrastructuur is de keuze