Bij registratie, nog voordat je een ticket koopt, vertrekken je BSN, je pasfoto uit de chip en de door de staat gezette handtekening van je paspoort in een upload naar de server van Siip op AWS in Ierland. De app toont je dat je vijf velden deelt. De upload bevat er meer.

Bij registratie stuurt de PEC Zwolle-app de ruwe gegevens uit de chip van je paspoort naar onboarding.siip.io, de identiteitsbackend van Siip. In een upload gaan mee:

• je burgerservicenummer, in de volledige machineleesbare zone van je paspoort
• je gezichtsfoto uit de chip (DG2, JPEG2000), scherper dan de foto op de pagina van je paspoort
• de staatshandtekening van je document, het Document Security Object waarmee de echtheid van je paspoort passief te controleren is
• je documentnummer en je nationaliteit

Die server draait op AWS in Ierland. AWS is de clouddienst van Amazon: onboarding.siip.io wijst door naar ingress-siip-…eu-west-1.elb.amazonaws.com, een Amazon-adres in de regio Ierland. Je gegevens staan dus fysiek in Europa. Maar Amazon is een Amerikaans bedrijf, en dat is het punt. De Amerikaanse CLOUD Act is een wet die de Amerikaanse overheid het recht geeft om een Amerikaans bedrijf te dwingen gegevens af te geven, ook als die gegevens op servers in Europa staan. Je paspoortgegevens vallen daarmee binnen bereik van de Amerikaanse autoriteiten, zonder dat een Nederlandse of Europese rechter daar iets over te zeggen heeft.

De app toont je bij registratie dat je vijf dingen deelt: naam, roepnaam, foto, geboortedatum en contactgegevens. De echte upload bevat dat, plus je BSN, je documentnummer, je nationaliteit, de volledige machineleesbare zone en de staatshandtekening. Wat wordt verzonden, is breder dan wat wordt getoond.

Het is gemeten verkeer, vastgelegd op mijn eigen toestel en verzegeld met hashes en tijdstempels. Een hash is een cryptografische vingerafdruk van een bestand, en een tijdstempel legt onafhankelijk vast wanneer dat bestand bestond, zodat het bewijs achteraf niet ongemerkt te wijzigen is. In mijn oorspronkelijke artikel stond deze upload nog als afgeleid, dus indirect vastgesteld. Nu is het vastgesteld op payloadniveau: gelezen aan de daadwerkelijk verzonden inhoud zelf.

Over de overheid op de Amerikaanse cloud maken we ons druk. Tegelijk scan je bij PEC Zwolle je paspoort en staat je BSN, met je pasfoto uit de chip, binnen een minuut op de Amerikaanse cloud van Amazon. Dezelfde app draait bij ADO Den Haag, NAC Breda en FC Eindhoven, en als het aan de KNVB ligt wordt dit vanaf seizoen 2027/28 de norm bij alle Nederlandse clubs.

Dit stuk hoort bij de oorspronkelijke meting van 1 juli, waarin ik de PEC Zwolle-app uit elkaar haalde en de identiteit-flow op een echt toestel mat. Daar liet ik een vraag expliciet open: welke velden mijn toestel precies verlaten. Op het scherm kon ik toen alleen vaststellen dat er een profiel ontstond. Siips CEO ontkent de hoofdconclusie, en dat gaf mij een concrete reden om die vraag alsnog te beantwoorden.

De reactie van Siip

Bij dit onderzoek heb ik Siip wederhoor geboden. Na een telefoongesprek met oprichter en CEO Remco Voorhorst stuurde ik hem een schriftelijke samenvatting van wat ik uit dat gesprek had begrepen, met mijn technische bevindingen, en vroeg ik om bevestiging of correctie. Zoals beloofd geef ik zijn reactie hieronder woordelijk weer. De volledige e-mailwisseling is gedocumenteerd en ligt vast.

De kern van zijn reactie, letterlijk uit zijn e-mail:

In je artikel trek je de conclusie ‘Je identiteit verlaat het toestel en wordt een server-side profiel’. Dat is niet geval. Dit lichten we dinsdag toe.

Over het commerciele citaat van Siips eigen site schreef hij:

Dit uitgelichte citaat van onze site klopt en is van ons, maar mist de volledige context. Er zijn commerciele voordelen voor onze klanten wanneer bekend is wie een evenement of stadion bezoekt. (…) Daarbij is de privacy van de gebruiker randvoorwaardelijk. Waarde voor de organisator, voor de bezoeker en zorgvuldige verwerking van persoonsgegevens gaan bij ons samen.

Over de DPIA, de verplichte toets die vooraf de privacyrisico’s van een gegevensverwerking in kaart brengt en afweegt:

Siip stelt een DPIA op die de dienstverlening van Siip dekt. Er worden onafhankelijke audits gedaan op de toegepaste techniek, o.a. door Pels Rijcken. (…) Siip gaat niet over de DPIA’s van clubs.

Een tweede punt uit mijn samenvatting, over meldingen zonder aparte opt-out, herkende hij niet: “Dit punt herken ik niet uit ons gesprek. Het is in deze vorm niet aan de orde geweest, en ik kan het niet bevestigen.” Dat schrijf ik daarom niet aan hem toe. Op mijn vraag naar de herkomst van mijn telefoonnummer: “Ik heb je nummer al langer. De precieze herkomst kan ik daardoor niet reconstrueren.” Tot slot wees hij op het meldpunt privacy@siip.group van Siips Functionaris Gegevensbescherming.

Een kanttekening bij dat laatste. Zo’n meldpunt is bedoeld voor kwetsbaarheden, en dit is er geen. Ik ben geen systeem van Siip binnengedrongen en heb geen zwakke plek misbruikt. Ik heb op mijn eigen toestel, met mijn eigen paspoort, het verkeer van mijn eigen telefoon geanalyseerd, en gekeken wat de app en de website met mijn gegevens doen. Dat is geen beveiligingslek dat eerst via een besloten kanaal gemeld moet worden voordat erover geschreven mag worden. Het is een meting van wat er met jouw data gebeurt, en die hoort gewoon openbaar te kunnen.

Ik neem het weerwoord serieus. Hieronder zet ik de beweringen van Siip naast wat de meting laat zien.

Elke bewering van Siip, naast de meting

Siip zegt: je identiteit verlaat je toestel niet. Voorhorst schrijft over mijn conclusie dat je identiteit het toestel verlaat: “Dat is niet geval.” Siips algemene voorwaarden formuleren het zo: je persoonlijke gegevens staan uitsluitend op jouw smartphone.

De meting laat het tegendeel zien. Bij registratie gaan je BSN (in de machineleesbare zone), je gezichtsfoto uit de chip en de staatshandtekening van je paspoort in een upload naar onboarding.siip.io, de server van Siip op AWS in Ierland. Gemeten, en verzegeld met hashes en tijdstempels.

Siip zegt: er zijn commerciele kansen in weten wie je stadion bezoekt, en de privacy is “randvoorwaardelijk”. Dat bevestigt Voorhorst op schrift.

Dat mag niet zomaar. Toegang verlenen is een doel. Die geidentificeerde bezoeker commercieel gebruiken is een ander doel. Onder de AVG (doelbinding) mag dat niet zonder een eigen wettelijke basis en zonder aparte, niet in de algemene voorwaarden verstopte toestemming. “Randvoorwaardelijk” is geen grondslag.

Siip zegt: de gegevens staan veilig op je eigen telefoon.

Maar de kopie staat bij Amazon. De ruwe upload verlaat je toestel en komt binnen bij Siip op AWS in Ierland. AWS is een Amerikaanse aanbieder, dus je paspoortgegevens vallen onder de Amerikaanse CLOUD Act. Wat er op je telefoon staat, verandert niets aan wat er met die geuploade kopie op de server kan gebeuren.

Siip zegt: we hebben een DPIA.

Het aangedragen bewijs is geen DPIA. Als voorbeeld van “onafhankelijke audits” noemt Voorhorst het Pels Rijcken-rapport. Dat is een juridisch adviesrapport in opdracht van Sportinnovator en de KNVB, dat zelf een aparte technische audit aanbeveelt. De DPIA voor de PEC-implementatie kreeg ik niet, daarvoor werd ik doorverwezen. Een adviesrapport en een e-mail zijn geen DPIA.

De meting

De metingen zijn verricht op mijn eigen toestel, met mijn eigen account en mijn eigen paspoort, op mijn eigen netwerkverkeer. Geen gegevens van derden, geen toegang tot de systemen van Siip.

Ik heb op mijn eigen toestel vastgelegd welke gegevens de app bij registratie verstuurt. Wat mijn eigen toestel met mijn eigen document verstuurt, mag ik meten en vastleggen.

Wat mijn toestel verstuurt

Bij registratie stuurt de app de ruwe gegevens uit de chip van je paspoort naar onboarding.siip.io, de identiteitsbackend van Siip op AWS in Ierland. Ze gaan als losse, benoemde bestanden mee in een upload.

In het oorspronkelijke artikel stond de regel “identiteit-upload bij registratie” als afgeleid. Die regel is nu vastgesteld op payloadniveau.

Twee dingen springen eruit. De foto is JPEG2000, en dat is de foto uit de chip zelf, scherper dan de foto op de pagina van je paspoort. En het Document Security Object reist mee. Dat is het object waarmee de echtheid van het document passief te controleren is. Er gaat dus een door de staat ondertekend, verifieerbaar identiteitsobject naar de server van Siip. Dat is meer dan een naam en een foto.

Twee preciseringen, zodat het klopt. Deze upload bevatte de machineleesbare zone (DG1), de foto (DG2) en het beveiligingsobject (SOD). Uit de programmacode van de app blijkt dat die nog meer chip-onderdelen kan versturen (de datagroepen DG5, DG7 en DG11 tot 15), maar die zaten niet in deze meting. Ik claim dus alleen wat ik daadwerkelijk heb zien vertrekken.

De upload viel bij registratie, voor enige ticketstap. De onboarding-calls stonden op 10:10:20Z en 10:16:43Z, de e-mailverificatie op 10:19:04Z, en de eerste ticketing-call pas op 10:20:15Z. Die laatste was de app die na registratie de ticketweergave ophaalde, geen aankoop. Er is nooit een ticket gekocht of geaccepteerd. Op het moment dat mijn identiteit werd geupload, bestond er dus geen overeenkomst tot toegang die uitgevoerd moest worden. De calltiming komt uit de eerste registratiemeting op het toestel en de veldinhoud van de upload uit de tweede. Het zijn twee metingen op mijn eigen toestel die elkaar bevestigen, niet een meting die door elkaar loopt.

De ontkenning, ontleed

De zin die Voorhorst ontkent, heeft twee helften. Ik houd ze uit elkaar, want het bewijs verschilt per helft.

De eerste helft is dat de identiteit het toestel verlaat. Die helft is nu vastgesteld op payloadniveau. De ruwe MRZ, de chipfoto en het beveiligingsobject worden verstuurd naar onboarding.siip.io. Er is geen lezing waarin “de identiteit verlaat het toestel niet” waar is. Dit is gemeten verkeer.

Dit raakt niet alleen de e-mail van Voorhorst. Siips eigen privacyverklaring stelt dat Siip een digitale kluis op je smartphone gebruikt en dat de persoonsgegevens veilig versleuteld op je toestel worden opgeslagen. De algemene voorwaarden formuleren het strakker: je persoonlijke gegevens staan uitsluitend op jouw smartphone. Ook de app-store-tekst zegt dat Siip je gegevens op je eigen telefoon bewaart. De meting laat zien dat de ruwe gegevens uit de chip van je paspoort bij registratie naar de server van Siip gaan. De belofte dat de gegevens het toestel niet verlaten, houdt op payloadniveau geen stand.

De tweede helft is dat er een server-side profiel ontstaat. Dat is nu ook op payloadniveau vastgesteld, niet langer afgeleid. De response van onboarding.siip.io is een compleet profielobject dat de server terugstuurt naar mijn telefoon: mijn achternaam, voornamen, geboortedatum, documenttype en vervaldatum, een door de server toegekend gebruikers-ID (organizationUserId), en mijn gezichtsfoto als veld photoJpeg, een base64-JPEG van circa twintig kilobyte, gelabeld photoType: jpeg2000. De foto die je op je profiel ziet komt dus niet uit je lokale scan, maar wordt door de server samengesteld en teruggestuurd. Dat de server je identiteit opslaat en als profiel terugserveert, is daarmee gemeten in beide richtingen. Wat strikt genomen nog open is, is wat de server daarna met de bestanden doet: hoelang ze bewaard blijven en of Siip ze kan inzien. Dat is te sluiten met een controle op een schone herinstallatie, en dat draaiboek ligt klaar.

Kort gezegd: dat de data het toestel verlaat en bij de server van Siip aankomt, is gemeten. Wat er in ruste mee gebeurt, is de vraag die Siip zou moeten beantwoorden. Een ontkenning in een regel per e-mail beantwoordt die vraag niet. De DPIA die Voorhorst zegt te hebben, wel.

Het burgerservicenummer wordt verzonden

Dit is de zwaarste toevoeging ten opzichte van het artikel. In de machineleesbare zone van een Nederlands paspoort dat is uitgegeven voor 30 augustus 2021 staat het burgerservicenummer in het personal-number-veld. Mijn document is zo’n document. In de gemeten upload is dat veld gevuld met een negencijferig nummer, en dat is het BSN. Het gemeten nummer is mijn eigen burgerservicenummer en het doorstaat de elfproef, de rekenkundige controle waarmee een geldig BSN te herkennen is. Het is dus geen willekeurig veld dat toevallig uit negen cijfers bestaat, maar aantoonbaar het BSN. Het BSN is verzonden naar onboarding.siip.io.

Dit is niet mijn norm, het is die van het rapport waar Siip zelf naar verwijst. De Landsadvocaat, de vaste advocaat van de Rijksoverheid, schrijft dat betaald voetbalorganisaties het BSN niet mogen verwerken zonder een specifieke wettelijke basis (artikel 87 van de AVG, de Europese privacywet, in combinatie met artikel 46 van de Nederlandse Uitvoeringswet AVG), en dat zij maatregelen moeten treffen die voorkomen dat het BSN wordt uitgelezen. Voor documenten van voor 30 augustus 2021 leidt het uitlezen van de chip zonder zulke maatregelen automatisch tot verwerking van het BSN. De maatregel die het rapport aanraadt, is het informatieveld met het BSN technisch niet uitlezen. Deze app leest en verstuurt de volledige ruwe MRZ, inclusief dat veld.

De consenttekst dekt de lading niet

De app toont bij het toewijzen van de kaart letterlijk welke gegevens worden gedeeld. In de tekst staan vijf dingen: voor- en achternaam, roepnaam, foto, geboortedatum en contactgegevens.

De feitelijk verzonden set is breder. Daar zitten ook het documentnummer, het BSN, de nationaliteit, de volledige machineleesbare zone en het beveiligingsobject bij. Je wordt dus geinformeerd over minder dan wat er werkelijk wordt verwerkt en verzonden. Dat raakt de transparantieplicht van de AVG, de plicht om je eerlijk en volledig te vertellen wat er met je gegevens gebeurt (artikelen 13 en 14). En het meesturen van je volledige machineleesbare zone en het beveiligingsobject raakt het beginsel van dataminimalisatie, dat voorschrijft niet meer gegevens te verzamelen dan strikt nodig is (artikel 5).

Naast de identiteit: drie datastromen die hier los van staan

De identiteits-upload is de kern. Maar de meting bracht drie stromen in beeld die daar los van staan, en die elk op zichzelf een AVG- of Telecomwet-vraag oproepen. Ze zijn met een gewone scan reproduceerbaar en staan los van de app en de chip.

De telemetrie vertrekt naar de Verenigde Staten, voor toestemming

Zodra je de app voor het eerst opent, nog voordat je iets hebt aangeraakt of ergens toestemming voor hebt gegeven, vertrekt er al gebruiks- en foutinformatie naar Google. Vier meetdiensten van Google, Firebase Installations, Google Analytics 4, Crashlytics en Firebase Performance, starten automatisch mee op het moment dat de app opstart, voordat er een scherm is getekend. Meegestuurd worden onder meer een vast nummer dat je installatie herkenbaar maakt, het model van je telefoon, het besturingssysteem en de gebeurtenis dat de app is geopend. Consent Mode v2, de standaard van Google om toestemming door te geven, is niet ingebouwd: de toestemmingssignalen die Google verwacht ontbreken. Op het toestel gaat daarnaast foutrapportage naar Sentry, een Amerikaanse dienst die crashmeldingen verzamelt, in twee projecten, ook al voor toestemming.

Google en Sentry zijn Amerikaanse bedrijven. Er vertrekt dus data naar de Verenigde Staten voordat je ook maar iets hebt aangeklikt. De enige toestemmingsstap in de app is een akkoord op de voorwaarden bij registratie, in een blok, zonder aparte keuze per doel, en die stap valt ruim na deze gegevensstroom. De inhoud van deze berichten heb ik leesbaar gemaakt op een nagebootste telefoon waarop ik het verkeer kon meelezen; op mijn echte toestel is dezelfde gegevensstroom op verbindingsniveau bevestigd.

De webshops volgen je zonder cookiebanner

Los van de app laden de websites waar je kaarten koopt al volgtechnologie voordat er toestemming is. Volgtechnologie, ook wel trackers, zijn stukjes code van advertentie- en analysebedrijven die je gedrag op de site registreren en doorgeven. Op seizoenkaart.peczwolle.nl en wachtlijst.peczwolle.nl verschijnt geen cookiebanner, en toch worden er al acht volg-cookies geplaatst voordat je iets kiest, met daarbij meetcode van Meta (Facebook), LinkedIn, Google Analytics en Google Ads (DoubleClick). Ook een Facebook-pixel die je paginabezoek meteen doorgeeft. Een privacyverklaring ontbreekt op die pagina’s. De hoofdsite peczwolle.nl heeft wel een toestemmingsbanner (Cookiebot), maar laadt daar overheen alsnog volgtechnologie van Google voordat je toestemming geeft.

De scan las het letterlijk uit: acht volg-cookies voordat je iets kiest, meetcode van Google Analytics (property G-WYHE7T46YP), een oude Universal Analytics-property (UA-43609346-1) en een Meta-pixel, en vijf verzoeken die actief gegevens naar Google, Meta en LinkedIn wegsturen.

Dit is een zelfstandige overtreding van de cookiewet (artikel 11.7a van de Telecommunicatiewet, dat voorschrijft dat volgtechnologie pas na jouw toestemming mag laden) en van de toestemmingseis van de AVG, en ze is met een gewone scan te reproduceren.

Het is niet een club, het is een vloot met een gedeeld foutkanaal

Wat ik bij PEC Zwolle mat, is geen toeval dat alleen deze club treft. De app van FC Eindhoven en die van PEC Zwolle zijn twee versies van hetzelfde kant-en-klare sjabloon dat Siip per club uitrolt: een white-label app, dezelfde software met een ander clublogo. De programmacode die je paspoort uitleest en verstuurt is regel voor regel identiek, en beide apps praten met dezelfde Siip-servers. Ze delen zelfs hetzelfde foutrapportage-account bij Sentry, wat betekent dat de crashmeldingen van meerdere clubs door een gemeenschappelijk account lopen. Alleen de meetomgeving bij Google verschilt per club.

De onboarding-architectuur die ik bij PEC heb gemeten, is dus het template dat de vloot draait, en Siips gestelde doel is deze toegang standaard te maken bij Nederlandse clubs.

Het verweerdocument beschermt Siip niet

Voorhorst noemt het Pels Rijcken-rapport als voorbeeld van “onafhankelijke audits op de toegepaste techniek”. Dat rapport is een juridische verkenning in opdracht van Sportinnovator en de KNVB. Het is gebaseerd op interviews met twee BVO’s, waarbij ook de app-ontwikkelaars aanwezig waren, en het beveelt zelf een aparte technische audit aan om vast te stellen of gegevens daadwerkelijk niet meer herleidbaar zijn. Het is een juridische toets van de techniek in het algemeen. Het is geen audit van de Siip-app.

Belangrijker is dat het rapport op de inhoud tegen deze implementatie in werkt. De variant die het rapport goedkeurt, Casus 1 (IBA), beschrijft een app die uit het document enkel naam, geboortedatum en pasfoto haalt, die data in een kluis op de telefoon houdt, waarbij “de beheerder van de app dus niet bij deze gegevens” kan, en die de gegevens pas bij ticketacceptatie overdraagt aan de club.

Mijn meting wijkt op elk van die punten af. De app verstuurt de ruwe gegevens uit de chip van je paspoort naar de server van Siip, al bij registratie, voor en zonder ticket. Ik heb nooit een ticket gekocht of geaccepteerd. En de verzonden set is veel breder dan naam, geboortedatum en pasfoto. De goedkeuring van IBA in dat rapport rust dus op een architectuur die deze app op de kernpunten niet volgt.

Datzelfde geldt voor de beveiligingsparagraaf. Het rapport merkt op dat er op dat moment “enkel sprake is van decentrale en encrypted data”, en dat dit al voor een hoger beveiligingsniveau zorgt. Die aanname klopt niet voor deze implementatie. De ruwe gegevens uit de chip van je paspoort gaan naar een centrale server. Het rapport is daarmee geen schild. Het is een checklist die deze app niet haalt.

De commerciele waarde, nu op de eigen band bevestigd

In het artikel citeerde ik Siips eigen site over de geidentificeerde bezoeker als commerciele kans. Voorhorst bevestigt nu op schrift dat dat citaat van Siip is en klopt, en dat er commerciele voordelen zijn wanneer bekend is wie een evenement of stadion bezoekt. Hij noemt de privacy “randvoorwaardelijk”.

Dat is precies het punt van de doelbinding, het beginsel dat gegevens die je voor het ene doel geeft niet zomaar voor een ander doel gebruikt mogen worden. Toegang verlenen is een doel. Commercieel gebruik en communicatie op maat zijn een ander doel. Dat andere doel valt niet onder de overeenkomst om je toegang te geven, en vereist een eigen wettelijke basis. Het rapport waar Siip naar verwijst, stelt bovendien dat toestemming niet verstopt mag zijn in de algemene voorwaarden.

In mijn samenvatting noteerde ik dat meldingen zonder aparte opt-out worden verstuurd en dat de aankoop van een toegangsbewijs als opt-in geldt. Voorhorst herkent die formulering niet uit ons gesprek en bevestigt haar niet. Ik laat daarom rusten wie wat in dat gesprek heeft gezegd. De meting staat daar los van. De enige toestemmingsstap in de app is een blanket-akkoord bij registratie, zonder granulaire keuze per doel. Of dat volstaat als toestemming voor marketing en meldingen, is een juridische vraag.

De DPIA die Siip zegt te hebben

Ik vroeg concreet om de DPIA voor de implementatie bij PEC Zwolle. Het antwoord was tweeledig. Siip stelt naar eigen zeggen een DPIA op die de dienstverlening van Siip dekt, en Siip gaat niet over de DPIA’s van clubs. In mijn samenvatting van het gesprek had ik begrepen dat Siip voor iedere afnemer een DPIA opstelt en de publicatie aan de afnemer overlaat. De schriftelijke reactie legt het accent nu op een DPIA voor de dienstverlening van Siip.

Hoe dan ook wordt mijn verzoek niet ingewilligd, en word ik voor de PEC-implementatie doorverwezen. Dat maakt de vraag scherper. Stel de Siip-DPIA beschikbaar die de dienstverlening dekt, en benoem wie de DPIA voor de PEC-implementatie houdt. Want de upload die ik heb gemeten, van de ruwe gegevens uit de chip van je paspoort naar de server van Siip, valt onder de dienstverlening van Siip.

Daar zit ook de rolvraag. Siip merkt zichzelf in de eigen privacyverklaring aan als verwerkingsverantwoordelijke voor de gegevens in de app, de partij die juridisch verantwoordelijk is voor wat er met je gegevens gebeurt. En de upload gaat naar de server van Siip. Wie is dan voor welke verwerking verantwoordelijk, en welke DPIA dekt de upload die ik heb gemeten? Een ontkenning in een e-mail is geen DPIA.

De poort: geautomatiseerde toegang

Toegang aan de poort verloopt geautomatiseerd. De app bouwt zelf een machine-leesbare toegangscode op, dat blijkt uit de app-code (_buildAccessCode, plus de QR- en streepjescode-generatoren). Je biedt die code aan een scanner aan, en die verleent of weigert automatisch toegang. Dat is geautomatiseerde verwerking van een aan je geverifieerde identiteit gekoppeld token. Siip bevestigt op de eigen site dat er aan de deur wordt geverifieerd en dat de app dat versnelt.

Wat er daarna aan de poort precies gebeurt, valt buiten de app en heb ik niet gemeten.

Wat nog open staat

Ik houd de grenzen van het bewijs scherp, ook nu. Deze punten zijn gemeten noch weerlegd:

• De persistentie van het profiel bij Siip. De upload is gemeten. De bewaartermijn en de vraag of Siip de bestanden kan inzien of dat ze versleuteld liggen met een sleutel die uitsluitend de gebruiker heeft, vergen de controle op een schone herinstallatie.
• De advertentie-ID van je telefoon, het reclamenummer waarmee adverteerders je herkennen. De app heeft de toestemming en de techniek ervoor aan boord. Of die waarde ook echt verzonden wordt, heb ik nog niet gemeten.
• De beslissing aan de poort en eventuele profilering daar. Die gebeurt op de servers of in de scanapparatuur bij de ingang, buiten de app, en is in de app zelf niet aan te tonen en niet te weerleggen.

Slot

Vanaf seizoen 2027/28 wil Siip dit de norm maken. Dan geldt: geen scan, geen wedstrijd. En wie scant, geeft in een upload zijn burgerservicenummer, zijn gezichtsfoto uit de chip, zijn volledige machineleesbare zone en de handtekening van de staat op zijn paspoort af aan een server van Siip bij Amazon. Een Amerikaans bedrijf, dus binnen bereik van de Amerikaanse overheid via de CLOUD Act.

Het gaat niet om een handjevol mensen. De Eredivisie alleen trok vorig seizoen ruim 4,7 miljoen stadionbezoeken, en met de andere profcompetities erbij zijn het er miljoenen meer. Wordt PDT de norm, dan registreert vrijwel elke supporter in Nederland eenmalig zijn identiteitsdocument, met alles wat daarop en in de chip staat.

Voor een avondje voetbal lever je de kern van je identiteit in. Een bank mag je BSN verwerken omdat de wet dat verplicht. Een voetbalclub heeft die grond niet, en hoort het BSN juist onleesbaar te houden. Je gezichtsfoto uit de chip gaat mee naar hun server en wordt daar onderdeel van een identiteitsprofiel. En toestemming die je alleen kunt weigeren door thuis te blijven, is geen vrije toestemming, terwijl de wet dat wel eist. Zo is de app gebouwd.

De upload staat niet ter discussie. Die is gemeten en verzegeld, klaar ter verificatie. Dinsdag spreek ik Siip, en hun volledige weerwoord staat hierboven.

De e-mailwisseling met Siip

Hieronder de volledige wederhoor, waaruit de citaten hierboven woordelijk zijn overgenomen. Eerst mijn samenvatting van het telefoongesprek, met een verzoek om bevestiging of correctie, daarna de schriftelijke reactie van CEO Remco Voorhorst. De EXIF-metadata van de afbeeldingen is verwijderd.

Bronnen

Eigen meting en bewijsmateriaal, beschikbaar ter verificatie: het forensisch rapport PEC Zwolle / Siip van 2 juli 2026, het payload-rapport met wat per veld naar wie gaat, en de verzegelde onboarding-capture, met SHA-256 en een OpenTimestamps-tijdstempel dat in de Bitcoin-blockchain is verankerd. De capture bevat de ongemaskeerde persoonsgegevens en is in de rapporten en in dit stuk gemaskeerd. Daarnaast de web-scans van seizoenkaart.peczwolle.nl, wachtlijst.peczwolle.nl en peczwolle.nl, en de app-binaries van de PEC Zwolle-app 2.1.1.

Publieke bronnen: Siips uitspraak over “customized communication” en “exciting commercial opportunities” op siip.group; de Siip privacyverklaring en algemene voorwaarden met de belofte van opslag uitsluitend op de smartphone; het Pels Rijcken-rapport “De inzet van (digitale) preregistratie en biometrische toegangspoortje door betaald voetbalorganisaties” van 19 februari 2024; en de PEC Zwolle-app in Google Play; en de KNVB over de ambitie dat PDT “vanaf het seizoen 2027/2028 de standaard wordt bij alle Nederlandse clubs” (Voetbalprimeur, 21 april 2026). Toeschouwerscijfers Eredivisie 2025/26 via Transfermarkt; seizoenkaart-aantallen via de KNVB-supporterskaart.

Correspondentie: e-mailwisseling met Remco Voorhorst, oprichter en CEO van Siip Group, 1 juli 2026, gedocumenteerd en als onderdeel van deze wederhoor volledig opgenomen.

Het volledige, ongemaskeerde BSN en de paspoortvelden staan uitsluitend in de verzegelde capture en zijn in dit stuk gemaskeerd.

Op 25 juni 2026 beantwoordde staatssecretaris Eerenberg van Financiën de Kamervragen over de Adobe-tracker in de betaalomgeving van de Belastingdienst. De kern van dat antwoord staat er zonder omhaal:

Het gebruik van Adobe Analytics was niet in lijn met de geldende ePrivacy-regels en de Algemene verordening gegevensbescherming.

Daarmee is de cirkel rond. Op 2 juni publiceerde ik wat er feitelijk over de lijn ging toen ik, ingelogd met mijn eigen DigiD, een aanslag wilde betalen: een handeling-voor-handeling verslag naar Adobe in de Verenigde Staten, met een herkenningsnummer van twee jaar eraan vast. Vier weken later is de tracker uit, is het datalek door de dienst zelf bij de Autoriteit Persoonsgegevens gemeld, is de schending door het kabinet erkend, en ben ik als melder bedankt en beloond.

Dit dossier eindigt zoals een dossier hoort te eindigen: gemeten, gemeld, gestopt en erkend.

De tijdlijn: van meting tot erkenning in vier weken

Die twaalf Kamervragen verdienen een eigen alinea, want ze zijn het resultaat van een directe samenwerking met JA21-Kamerlid Daniël van den Berg. Ik leverde de meting en de technische onderbouwing, hij vertaalde die naar precieze, goed getimede vragen en tilde het debat daarmee een niveau hoger in de Kamer. Vraag voor vraag zat er techniek onder: van de ECID-cookie en de verhulde DNS-omleiding tot de rolverdeling tussen verwerkingsverantwoordelijke en verwerker. Die combinatie van meetwerk en politiek vakmanschap is de reden dat dit dossier in vier weken van bevinding naar erkenning ging.

Wat de staatssecretaris erkent

De antwoorden op de Kamervragen bevestigen de bevinding op alle hoofdpunten, en voegen er een paar dingen aan toe die ik zelf niet kon vaststellen.

Ten eerste de rechtmatigheid. Het kabinet erkent dat de tracking in strijd was met de ePrivacy-regels en de AVG, en dat vooraf niet is beoordeeld of het verwerken van persoonsgegevens noodzakelijk was. Er lag geen afgeronde beoordeling onder een systeem dat meekeek met burgers in de meest verplichte omgeving die de overheid kent.

Ten tweede de reikwijdte. Vast staat dat in elk geval IP-adressen naar Adobe zijn verstuurd, naast de gedragsgegevens die ik documenteerde: de specifieke vordering, de geopende aanslag, de stap in de betaalfunnel. En er blijft een onbekende rest: wat gebruikers hebben ingetypt in vrije tekstvelden en zoekfuncties is achteraf niet meer volledig te reconstrueren. Die onzekerheid is precies waarom dit als datalek is gemeld.

Ten derde de voorwaarden voor de toekomst. De verwerking is gestopt en wordt pas hervat als de rechtmatigheid en proportionaliteit zijn beoordeeld en geborgd, met eerst een DPIA en sluitende verwerkersafspraken.

Mijn eigen meetnuance blijft daarbij overeind staan, want daar hecht ik aan: het bedrag, het BSN, het IBAN en het betalingskenmerk gingen aantoonbaar niet mee. Wat wegvloeide was je gedrag eromheen, gekoppeld aan een nummer dat twee jaar blijft staan. De erkenning gaat over precies dat.

De dienst meldde zichzelf

Het opvallendste aan deze afloop is de volgorde. De Autoriteit Persoonsgegevens hoefde er niet aan te pas te komen om dit boven water te krijgen: de Belastingdienst deed uit eigen beweging een datalekmelding bij de toezichthouder, en de staatssecretaris informeerde de Kamer daar zelf over.

In diezelfde Kamerbrief richt de staatssecretaris zich rechtstreeks tot de melder:

Ik ben dankbaar dat deze ethisch hacker de Belastingdienst hierop heeft gewezen.

En het bleef niet bij woorden: voor de melding kreeg ik van de Belastingdienst een beker. Een echte, met het logo van de dienst in de lauwerkrans, een handdruk op de voorkant, en op het voetstuk een opschrift met gevoel voor humor: “I hacked the Dutch Tax Office and never got a refund”. Dat vermeld ik hier met plezier, omdat het laat zien hoe een overheidsdienst met een melder om kan gaan: serieus nemen, rechtzetten, en de boodschapper bedanken in plaats van hem als tegenstander te behandelen.

Wat de pers ervan maakte

De antwoorden van 25 juni leverden een tweede golf berichtgeving op, na de eerste golf rond de uitschakeling:

• Security.NL en PrivacyNieuws: “Belastingdienst schond privacywetgeving”
• iBestuur en Binnenlands Bestuur: “Belastingdienst schond AVG met gebruik van Adobe Analytics”
• NieuwRechts: “Persoonsgegevens belastingbetalers doorgestuurd naar Amerikaans bedrijf”
• De fiscale vakpers (Taxence, TaxLive): het gebruik is gestopt en het datalek gemeld

Alle vermeldingen staan gebundeld op de pers-pagina, met de links naar de originele publicaties en de Kamerstukken.

Waarom dit een succesverhaal is

Elk onderdeel van het stelsel deed waarvoor het bestaat. De meting bracht een verborgen datastroom aan het licht. De Kamer stelde er binnen een dag vragen over. De dienst zette de tracker binnen een week uit, controleerde niet alleen de betaalomgeving maar inventariseert soortgelijke tooling breder, en meldde zichzelf bij de toezichthouder. Het kabinet erkende de schending zwart op wit. En de melder werd bedankt.

Het verwijt over de oorspronkelijke situatie blijft staan: jarenlang kreeg een Amerikaans reclamebedrijf een klik-voor-klik verslag mee van burgers die hun belasting betaalden, zonder grondslag en zonder dat iemand dat vooraf had getoetst. Dat is en blijft de bevinding, en die staat volledig gedocumenteerd met de echte waarden uit mijn sessie.

Wat openstaat, benoem ik ook. De uitschakeling is formeel voorlopig: hervatting kan na een DPIA en verwerkersafspraken, en dat moment verdient een nieuwe meting. En de vraag wat er in de vrije tekstvelden richting Adobe is gegaan, blijft per definitie onbeantwoord. Zodra de betaalomgeving opnieuw gaat meten, meet ik mee.

Aan iedere onderzoeker die iets ziet: meld het

Dit is waar dit artikel eigenlijk om draait. Zit je als onderzoeker op een bevinding, bij de overheid of daarbuiten, en twijfel je of melden zin heeft: dit dossier is het antwoord. De Belastingdienst ging er van begin tot eind goed mee om. De melding werd serieus genomen, de tracker ging binnen dagen uit, de dienst meldde zichzelf bij de toezichthouder, de staatssecretaris bedankte de melder in een brief aan de Kamer, en er stond een prijs tegenover.

Zo bouw je vertrouwen tussen onderzoekers en overheid: de melder wordt behandeld als bondgenoot, en de volgende bevinding komt daardoor wéér binnen via de voordeur. Melden loont, voor jou, voor de dienst en voor iedereen wiens gegevens het betreft.

Dus doe die melding. Dit is hoe het hoort te gaan, van begin tot eind. Eind goed, al goed.

En de leverancier, Siip, ziet die geidentificeerde bezoeker als commerciele waarde, in zijn eigen woorden. Het document dat de risico’s zou moeten afwegen, de DPIA, is niet openbaar, en de privacyverklaring zwijgt over precies deze punten. Zonder deze meting zou niemand weten wat er met je paspoortdata gebeurt.

Waarom dit alle clubs raakt

Siip levert een white-label sjabloon en rolt dat per club uit. Bevestigd op Google Play: PEC Zwolle, FC Eindhoven, ADO Den Haag en NAC Breda draaien hetzelfde sjabloon (io.siip.saas.*), dus vermoedelijk met hetzelfde gedrag. Dat laatste is afgeleid: alleen de PEC-app is dynamisch gemeten, en de FC Eindhoven-app is er statisch naast gelegd (identieke SDK-set en permissies, met een eigen Firebase-project per club). Ze delen infrastructuur op AWS in Ierland. Een ontwerpfout in het sjabloon werkt daardoor vermoedelijk platform-breed door. De publieke ambitie is dat PDT vanaf seizoen 2027/28 de standaard wordt bij alle Nederlandse clubs.

Lees dit eerst

Dit is deels statische analyse van de code en deels echte netwerkmeting. Ik maak dat onderscheid steeds expliciet met een bewijsniveau. Vastgesteld betekent dat ik het veld in de gedecodeerde data of op het scherm heb gezien. Afgeleid betekent dat gedrag of architectuur het impliceert, zonder dat ik de payload zag. Open betekent dat het achter certificate pinning zit en niet passief te lezen was.

Alle metingen zijn op eigen toestel, eigen account en eigen paspoort gedaan, met eigen verkeer. Geen data van andere supporters, geen schrijfacties op de backend. De ruwe meetbestanden en hun hashes zijn bewaard.

Wat het is

Sinds april 2025 heet Identity Based Access officieel Persoonlijke Digitale Toegang, PDT. Het koppelt je identiteit aan je toegangsticket. Leverancier is Siip, een softwarebedrijf uit Zwolle. De app is de PEC Zwolle App, pakketnaam io.siip.saas.pec, versie 2.1.1, gebouwd met Flutter.

Er zijn twee identificatiemomenten. Bij de onboarding, eenmalig en thuis, leest de app de NFC-chip van je paspoort, ID-kaart of rijbewijs. Aan de poort, per wedstrijd, wordt alleen een barcode of token gescand. Dat verschil bepaalt waar je gegevens heen gaan.

Waarom dit anders is

Een toegangsticket koop je, een identiteit maak je aan. Je paspoort is de sterkste identiteit die je hebt, uitgegeven door de staat, met je pasfoto als biometrisch gegeven. Zodra die identiteit een account wordt op een server, verandert een kaartje dat je scant in een dossier dat aan jouw naam hangt. De vraag is of de belofte klopt dat het op je toestel blijft.

Het goede nieuws eerst: differentiële certificate pinning

Dit is de technische hoofdvondst, en het pleit voor Siip. Ik heb de app op een echt, niet-geroot toestel gepatcht zodat de Flutter-certificaatcontrole uitstond, en het verkeer door een eigen tunnel geleid. Alleen het publieke contentkanaal werd toen leesbaar. Elk gevoelig kanaal brak af met een certificaatfout. Dat is het patroon van certificate pinning: de app vertrouwt alleen het echte servercertificaat en weigert elke tussenpartij, ook een onderzoeker.

Vastgesteld: scl.siip.io, het contentkanaal met fixtures, nieuws en afbeeldingen, is niet gepind en werd ontsleuteld. onboarding.siip.io voor de identiteit, iam.siip.io en user.siip.io voor auth en profiel, en ticketing.siip.io voor de tickets zijn wel gepind. Alles wat gevoelig is, is dus extra beveiligd. Dat is een bewuste, sterke keuze.

Wat er weggaat, en wat het zegt

De trackingstack is volledig Google en Firebase, aangevuld met Sentry voor foutrapportage. Geen advertentie- of databroker-SDK van een derde partij. Op de emulator heb ik de Firebase-payloads op veldniveau gelezen.

De advertising-ID is een apart punt. De app vraagt de permissies AD_ID en ACCESS_ADSERVICES aan en heeft de bijbehorende Firebase-plumbing, maar de exacte reclame-identifier was op de emulator niet te meten omdat die geen Play-advertising-ID heeft. Dat blijft open.

De kaart

Petrol is functioneel en blijft in Europa. De terracotta bogen zijn telemetrie richting de Verenigde Staten. Er is hier geen Rusland-laag, in tegenstelling tot sommige andere apps.

De timing is het probleem

De telemetrie vuurt bij de allereerste start, nog voor je iets aanraakt. De enige onboarding is een carrousel van drie slides zonder keuze. Er verschijnt nergens een toestemmingspoort voor de tracking. De eerste keer dat je iets moet accepteren zijn de algemene voorwaarden bij de registratie, en dat is een blanket-akkoord, geen granulaire opt-in voor analytics. Op dat moment draait de telemetrie al minuten.

Verlaat je identiteit het toestel

De kernvraag, en het antwoord is ja. Vastgesteld: de chip wordt lokaal gelezen via NFC, de datagroepen DG1 met de machineleesbare zone en DG2 met de pasfoto. Maar na de scan meldt de app letterlijk dat een gepersonaliseerd profiel is aangemaakt op basis van jouw identiteit. Het profielscherm toont je pasfoto, je volledige naam, je e-mailadres en je leeftijd, geleverd door de gepinde identiteitsbackend. Een lokale cache is niet aannemelijk, want het profiel zat niet in het enige leesbare kanaal. Je identiteit staat dus server-side bij Siip.

Wat open blijft: welke ruwe velden precies worden bewaard. De volledige machineleesbare zone en het documentnummer, of alleen de afgeleide naam, pasfoto en leeftijd. Die payload zit achter de pinning en is passief niet te lezen. Dat vergt een geroot toestel met een gerichte hook, wat buiten deze meting viel. De belofte dat de identiteit op je toestel blijft, klopt in elk geval niet volledig: er ontstaat een server-side profiel.

Hoe kon dit ontstaan

De oorzaak ligt in een default. Firebase initialiseert zichzelf standaard bij het opstarten. Configureer je Consent Mode v2 niet, en zet je die default in een sjabloon dat je per club uitrolt, dan krijg je pre-consent telemetrie bij elke club tegelijk. Eén standaardinstelling die niemand aanzette, plant zich voort over de hele vloot.

Jurisdictie: locatie in Ierland helpt niet

De Siip-backend staat fysiek in de EU, op AWS in Ierland. Dat is groen. Maar Amazon, Google en Sentry zijn Amerikaanse bedrijven, en de Amerikaanse CLOUD Act en FISA 702 volgen de nationaliteit van het bedrijf, niet de locatie van de server. Het EU-US Data Privacy Framework dekt de doorgifte, maar neemt het restrisico van Amerikaanse overheidstoegang niet weg. De backend in Ierland zetten helpt daar juridisch niet tegen.

Wie is waarvoor verantwoordelijk

De club, in dit geval PEC Zwolle, is verwerkingsverantwoordelijke. Siip Custodian B.V. uit Zwolle, KVK 81544995, is verwerker en bouwt de app. Voor de gegevens in de app merkt Siip zichzelf in de eigen privacyverklaring overigens aan als verwerkingsverantwoordelijke, dus in de praktijk is er sprake van gedeelde verantwoordelijkheid. Daaronder hangen subverwerkers: Google Firebase en Sentry, beide in de Verenigde Staten, en AWS Ierland voor de hosting. De verantwoordelijkheid voor de grondslag en de toestemming ligt daarmee bij Siip en de club, niet bij Google. Het geheel staat niet los van de KNVB, die met het programma Ons Voetbal is van Iedereen en de norm voor Persoonlijke Digitale Toegang de richting bepaalt.

In Siips eigen woorden: de bezoeker als commerciele waarde

Technisch zit er geen advertentie-SDK in de app, dus je wordt niet aan een advertentienetwerk doorverkocht. De commerciele waarde zit ergens anders, en Siip benoemt die zelf. Op de eigen site legt oprichter en CEO Remco Voorhorst uit wat een geidentificeerde bezoeker oplevert.

Zijn woorden, over de eventsbranche: het is nuttig om te weten wie er komt, je kunt controleren dat bezoekers de juiste leeftijd hebben, je kunt customized communication bieden, en het opent exciting commercial opportunities. Op diezelfde pagina vat hij het samen: elke bezoeker kan als VIP worden behandeld zodra de organisator weet dat hij of zij komt. Voorhorst zegt er expliciet bij dat dit ook voor de events- en festivalbranche geldt, niet alleen voor voetbal. De geidentificeerde bezoeker is zo zelf het product: bekend, leeftijd-geverifieerd en benaderbaar met communicatie op maat.

Let op de precieze woorden. Siip zegt commercial opportunities en customized communication, en nergens advertenties. Het punt is dus niet dat je banners krijgt, maar dat je identiteit, gekoppeld aan je paspoort, wordt gepresenteerd als commerciele en marketingwaarde.

Op dezelfde site staat een claim die botst met de meting. Over dezelfde technologie schrijft Siip: Only the user has the key to all data, naast Fully GDPR compliant, privacy by design en privacy by default.

Die belofte, dat alleen de gebruiker de sleutel tot alle data heeft, staat op gespannen voet met wat ik mat. Na de scan bestaat er een server-side profiel met je naam, je pasfoto en je leeftijd, geserveerd vanaf de identiteitsbackend van Siip. Als dat profiel ook bij Siip staat, klopt het niet dat alleen de gebruiker de sleutel heeft.

Welke rechten dit raakt

De pre-consent telemetrie en de advertising-ID raken artikel 11.7a van de Telecommunicatiewet en, zonder geldige toestemming, de grondslag onder artikel 6 AVG. Het server-side identiteitsprofiel met pasfoto raakt artikel 9 AVG over bijzondere persoonsgegevens. Niet-gedeclareerde subverwerkers raken de transparantieplicht van de artikelen 12 tot en met 14. Telemetrie binnen Amerikaans bereik raakt de doorgifteregels van de artikelen 44 tot en met 49.

Twee punten reiken verder dan de app zelf. Zodra de identiteit gekoppeld wordt aan een stadionverbod komt artikel 10 AVG over strafrechtelijke gegevens in beeld, samen met artikel 33 van de Uitvoeringswet AVG. En waar identificatie bij uitwedstrijden verplicht wordt gesteld, botst dat met de eis dat toestemming vrij moet zijn en met het proportionaliteitsbeginsel: comfort voor de een is dwang voor de ander.

Is er een DPIA, en klopt de uitleg

Voor een systeem dat je paspoort inleest verwacht je een openbare gegevensbeschermingseffectbeoordeling, een DPIA. In de publieke toelichting bij PDT staat dat de club en Siip er een hebben uitgevoerd. Het document zelf is nergens openbaar te vinden: niet op de site van Siip, niet op de clubpagina’s, en er wordt ook niet naar gelinkt. Je moet dus op de mededeling vertrouwen dat de risico’s zijn afgewogen, zonder de afweging te kunnen inzien.

De privacyverklaring van Siip die er wel is, is summier. Er staat dat je gegevens versleuteld op je eigen toestel worden opgeslagen, en dat alleen je 06-nummer of e-mailadres worden bewaard zolang je de app gebruikt. Wat er niet in staat is veelzeggend: geen woord over de verwerking van de pasfoto of de chipdata, geen subverwerkers zoals Google, Sentry of AWS, geen internationale doorgifte, en geen verwijzing naar de DPIA. Dat zijn precies de punten die deze meting blootlegt. De telemetrie naar Google en Sentry in de Verenigde Staten komt er niet in voor, en het server-side profiel dat na de scan ontstaat staat op gespannen voet met de belofte dat alles op je toestel blijft.

Nog iets, PDT is niet overal hetzelfde. Excelsior Rotterdam regelt de toegang via een andere leverancier, TicketTrigger, met een eigen verklaring waarin staat dat het identiteitsbewijs niet door de club wordt bewaard. De naam Persoonlijke Digitale Toegang dekt dus meerdere systemen van meerdere bouwers, elk met een eigen privacyregime. Wie het over PDT heeft, heeft het niet automatisch over dezelfde datastromen.

Hier komt het op neer. Het document dat de risico’s zou moeten afwegen is geheim. De verklaring die er wel is, zwijgt over de pasfoto, over de Amerikaanse verwerkers Google en Sentry, en over de doorgifte. Voor de supporter die zijn paspoort op tafel legt, betekent dat je niet kunt controleren wat er met je identiteit gebeurt. Het enige zicht dat er is, is er omdat iemand het van buitenaf heeft gemeten. Een systeem dat je staatsidentiteit inleest, hoort transparanter te zijn dan dit.

Dit bevestigt wat supporters al vreesden

De weerstand tegen Persoonlijke Digitale Toegang bestond al voor deze meting, en ging precies over dit punt. In mei 2026 kwam het supportersprotest tegen het KNVB-ticketsysteem breed in het nieuws. Frank Kriellaars, voorzitter van Supporterscollectief Nederland, waarschuwde dat het systeem de drempel voor een stadionbezoek verhoogt en spontaan gaan onmogelijk maakt. Carli Klijn van FSV De Feijenoorder zei over de privacy dat daar nog weinig over bekend was, en dat supporters niet bij de ontwikkeling zijn betrokken. Susanne Wichhart van de Vitesse-supportersvereniging wees op de Ajax-hack als bewijs dat zulke systemen kwetsbaar zijn, en vroeg zich af waarom het voetbal strengere maatregelen krijgt dan festivals of het uitgaansleven.

Die zorg, dat er weinig bekend is over wat er met je identiteit gebeurt, is precies het gat dat deze meting vult. Nu is het gemeten. Je identiteit verlaat het toestel en wordt een server-side profiel. De telemetrie vertrekt naar Google in de Verenigde Staten voordat je toestemming geeft. En omdat het om een gedeeld sjabloon gaat, geldt dat voor de hele vloot tegelijk. De abstracte angst is daarmee concreet geworden. Het punt van Wichhart over de Ajax-hack krijgt er een randje bij: de gevoelige kanalen zijn weliswaar netjes gepind, maar het profiel staat wel degelijk server-side, dus een datalek raakt precies die identiteitsgegevens.

Wat je zelf kunt doen

1. Weiger de notificatietoestemming als je die niet nodig hebt. De tracking staat daar los van, maar het scheelt.
2. Reset regelmatig je advertising-ID via de Android-instellingen onder Privacy en advertenties.
3. Zet de app-toestemming voor de reclame-ID uit als je die niet gebruikt.
4. Vraag bij de club om inzage in je profiel op grond van artikel 15 AVG, en om verwijdering op grond van artikel 17 als je stopt.
5. Weet dat het alternatief vaak een fysiek ticket aan de kassa is. Persoonlijke Digitale Toegang is comfort, geen verplichting bij elke club.

Wat eerlijk is om erbij te zeggen

Verschillende dingen pleiten voor Siip en de clubs. De gevoelige kanalen zijn gepind. De beeldverwerking van de app, ML Kit, draait on-device, vermoedelijk enkel voor de barcodescan. Er zit geen advertentie- of databroker-SDK van een derde partij in. De functionele backend staat in de EU. En de identiteitsdata is niet uitgesmeerd over tien trackers.

Het probleem zit in de timing en de defaults van de telemetrie, in de Amerikaanse subverwerkers, en in de afstand tussen de kluis-belofte en het server-side profiel. Dat is te repareren zonder de functionaliteit aan te tasten: Consent Mode v2 configureren, een echte toestemmingspoort voor de start, en transparantie over Google, Sentry en waar de data staat.

Methode en reproductie

Statische analyse met apktool, jadx en strings op de APK, io.siip.saas.pec versie 2.1.1, sha256 bewaard. De pre-consent telemetrie is op veldniveau gemeten op een Android-14 emulator, waarbij het Firebase-verkeer via de systeem-certificaatstore werd ontsleuteld. De identiteit-flow is gemeten op een echt Android-toestel met een echt paspoort, met de Flutter-certificaatcontrole uitgeschakeld en het verkeer door een eigen tunnel geleid. Certificate pinning op de identiteits-, auth- en ticketkanalen blokkeerde het lezen van die payloads, wat als bevinding is genoteerd.

Alleen eigen toestel, eigen account, eigen document en eigen verkeer. Geen data van derden, geen schrijfacties op de backend, geen exploit. Bevindingen reproduceerbaar, serverlocaties geverifieerd op het moment van schrijven. Onderzoek via mickbeer.com.

Bronnen

Eigen meting (statisch, emulator en echt toestel): - App: PEC Zwolle App, io.siip.saas.pec versie 2.1.1. Ruwe meetbestanden en hashes bewaard. - Fleet-bevestiging via Google Play: io.siip.saas.pec, io.siip.saas.fceindhoven, io.siip.saas.adodenhaag, io.siip.saas.nac.

Siip, eigen publicaties: - Commerciele kansen, CEO Remco Voorhorst: siip.group/en/author/siip/ - “Only the user has the key to all data” en “Fully GDPR compliant”: siip.group/en/use-cases/identity-based-access/ - Siip voor stadions: siip.group/en/use-cases/siip-for-stadiums/ - Privacyverklaring Siip: siip.group/privacyverklaring/

Persoonlijke Digitale Toegang, publiek: - KNVB over Identity Based Access met Siip: knvb.nl/11/innovatiefestival/siip - Procesmeting PDT, DSP-groep, juli 2025: dsp-groep.nl - Supportersprotest tegen het ticketsysteem, 19 mei 2026: fcupdate.nl - Excelsior Rotterdam PDT via TicketTrigger: excelsiorrotterdam.nl/persoonlijke-digitale-toegang/

Er is een hele bedrijfstak die voor de kost beoordeelt of anderen zich aan de privacyregels houden. Certificeerders geven keurmerken uit, juridische adviseurs schrijven de compliance-rapporten, en privacy-organisaties houden de rest een spiegel voor. In de Nationale Privacy Index van juni 2026 richtte ik die spiegel een keer op henzelf. Ik legde negen van die websites langs precies dezelfde meetlat als alle andere, en het beeld is ongemakkelijk: uitgerekend de twee grootste certificeerders lekken het hardst.

De gedachte is simpel. Als er één sector zou moeten kloppen op het gebied van privacy, dan is het de sector die privacy verkoopt. Een bedrijf dat jou een keurmerk verstrekt omdat jouw site netjes met bezoekersgegevens omgaat, mag op zijn eigen site geen trackers laten afgaan voordat je toestemming hebt gegeven. Een adviseur die anderen factureert voor AVG-naleving, hoort de weigerknop op zijn eigen cookiebanner te laten werken. Dat is geen hoge lat. Dat is de lat die ze zelf aanleggen.

“Ze preken water en drinken zelf wijn.” Het gezegde dat deze meting helaas bevestigt.

De korte versie

• Van de negen gemeten organisaties in de sector keurmerken en juridisch advies staan er drie op Privacy Lek: Kiwa, DNV en ICTRecht.
• De twee grootste, internationaal opererende certificeerders, Kiwa en DNV, scoren allebei het laagste dat kan: 1 ster. Bij beide werkt de weigerknop niet: na “weigeren” blijven trackers gewoon doorlopen.
• Kiwa laadt vier tracking-cookies voordat er een banner is, met onder andere een Facebook/Meta Pixel en Google AdSense erbij.
• DNV zet zelfs een nieuwe trackingcookie nadat je op weigeren hebt geklikt, en verbergt een tracker achter zijn eigen domein (CNAME-cloaking).
• Eén partij doet het vlekkeloos: Privacy First (5 sterren, Beste Keuze). Geen tracking, niets te weigeren. Practice what you preach.
• Wat dit betekent: een keurmerk of een adviesfactuur zegt niets over hoe de uitgever zelf met jouw bezoek omgaat. Je kunt het, zoals ik hieronder laat zien, gewoon zelf nameten.

De ranglijst

De Nationale Privacy Index drukt elke site uit in zes dimensies (zie verderop wat ze betekenen) en vat die samen in een eindscore van 1 tot 5 sterren plus een keurmerk-label. Voor de sector keurmerken en juridisch advies ziet de juni-meting er zo uit.

De lekken

Kiwa · de certificeerder die zelf geen banner heeft

Kiwa geeft wereldwijd keurmerken en certificaten uit. Op de eigen homepage scoorde Kiwa het slechtste resultaat van de hele sector: 1 ster, Privacy Lek, met de meeste bevindingen van alle negen.

Het begint al voordat je iets kunt kiezen. Ik trof in de “niets doen”-stand vier tracking-cookies aan die gezet worden zonder dat er een cookiebanner verschijnt, plus vier bekende externe trackers die meteen bij het laden afgaan: Google Tag Manager, een Facebook/Meta Pixel, Google AdSense en een Facebook-tracking-pixel in de HTML. Dat is precies het patroon dat een keurmerk-audit bij een klant zou afkeuren.

En weigeren helpt niet. Nadat ik op de weiger-optie klikte, bleven drie tracking-cookies staan en dertien bekende trackers gewoon actief, waaronder Facebook, Cookiebot, Google Tag Manager en Microsoft Azure-monitoring. In de gesimuleerde gebruikerssessie zette YouTube er nog zes third-party cookies bovenop.

DNV · een nieuwe cookie nadat je nee zegt

DNV is de andere grote internationale certificeerder in de lijst, en eindigt op dezelfde plek: 1 ster, Privacy Lek. De ernstigste bevinding is hier juridisch het scherpst. Ik zag dat DNV een nieuwe trackingcookie zet nadat er op weigeren is geklikt. Dat is geen grijs gebied: een nieuwe trackingcookie plaatsen na een uitdrukkelijke weigering is een verwerking zonder grondslag.

Daarbovenop verbergt DNV een tracker achter het eigen domein. Ik detecteerde CNAME-cloaking: sgtm.dnv.com ziet eruit als eigen infrastructuur, maar is een server-side Google Tag Manager. Die constructie omzeilt browser-bescherming en adblockers, juist omdat hij op de domeinnaam van het bedrijf zelf staat. Na weigeren bleven nog zes bekende trackers actief (OneTrust, Google Tag Manager, Azure-monitoring, Brightcove), en in de bestanden vond ik fingerprinting en een geobfusceerd script.

ICTRecht · het juridisch advies dat zelf zestien trackers laat staan

ICTRecht verkoopt juridisch privacy-advies. De homepage staat op 2 sterren, Privacy Lek. Ik trof acht bekende trackers aan voordat er toestemming was: Google Tag Manager, de hele HubSpot-suite en Google AdSense, plus een eigen-gehoste Google Analytics 4 op sst.ictrecht.nl. Na weigeren bleven er zestien trackers actief, het hoogste aantal van de sector. In de gebruikerssessie kwamen daar twaalf third-party cookies bij.

De middenmode

Vier organisaties zitten in het midden, met 2 of 3 sterren. Het patroon is hier milder maar consistent: een analyse-tracker die afgaat voordat je toestemming hebt gegeven.

• Considerati (3 sterren) laadt Matomo en Google Tag Manager voor consent, en in de bestanden zaten fingerprinting en obfuscatie.
• Bits of Freedom (3 sterren) is een bijzonder geval. De enige bevinding is formeel kritiek (een eigen-gehoste Piwik op stats.bitsoffreedom.nl die voor consent afgaat), maar het gaat om privacyvriendelijke, zelf-gehoste statistiek zonder externe partijen. Verder is de site schoon. De dimensies laten dat zien: alleen toestemming en transparantie drukken de score, de rest staat hoog.
• Privacy Company (2 sterren, Risico) laadt Matomo Cloud voordat je kiest. Hierover hoort een eerlijke kanttekening (zie hieronder), want juist deze meting legde een fout in mijn eigen meetmethode bloot.
• Privacy Verified (2 sterren, Risico) laadt Piwik PRO voor consent, en ik kon op de site geen weigerknop vinden.

De goede voorbeelden

Het kan dus wel, en twee partijen laten zien hoe.

Privacy First scoort als enige in de sector 5 sterren, Beste Keuze, met een vlekkeloze rij dimensies (A tot en met E op het maximum). Ik vond geen tracking en geen externe partijen die voor consent afgaan. De enige twee kanttekeningen zijn mild: een Referrer-Policy-instelling en één timezone-detectie in Simple Analytics, een privacyvriendelijke analyse-dienst. Bij Privacy First is weigeren niet eens nodig, want er valt niets te weigeren.

TÜV Nederland komt op 4 sterren, Acceptabel. De enige bevinding is een ontbrekende beveiligingsheader (HSTS), verder is de site schoon. Dat is het bewijs dat een certificeerder wel degelijk een nette eigen site kan hebben.

Hoe de Nationale Privacy Index dit meet

De score is geen mening. Elke site wordt langs zes dimensies gelegd, elk van 0 (slecht) tot 5 (goed), met een eigen weging.

Hoe hard is elke laag?

Wat dit voor jou betekent

• Een keurmerk op een site van een derde zegt niets over hoe de uitgever van dat keurmerk zelf met jouw bezoek omgaat. Dat zijn twee losse dingen.
• Je kunt het zelf controleren. Open de site, weiger de cookies, en kijk in de ontwikkelaarsconsole van je browser (tabblad Netwerk) of er daarna nog verzoeken naar Google, Facebook of analytics-domeinen vertrekken. Als dat zo is, werkt de weigerknop niet.
• Voor de organisaties zelf is de fix bekend en goedkoop: laad niets voordat er toestemming is, en zorg dat weigeren ook echt alles stopt. Privacy First en TÜV Nederland laten zien dat het kan.

Methode

De meting komt uit de Nationale Privacy Index van 1 juni 2026, methodiek-versie 2026-06.2. Ik laad elke site in een schone browsersessie (geen cache, geen cookies, geen opslag) in drie standen: niets doen, alles weigeren, alles accepteren. Per stand leg ik cookies, netwerkverzoeken, opslag en HTML vast. Daarna volgt een gesimuleerde gebruikerssessie (banner accepteren, scrollen) waarvan ik de volledige netwerk-trace bewaar, en haal ik de geladen tracker-bestanden op om ze te ontleden op tracker-ID’s, fingerprinting-API’s en obfuscatie. CNAME-cloaking stel ik vast via DNS-resolves tegen 1.1.1.1. De zes dimensies en de eindscore volgen uit die meetwaarden, niet uit een handmatig oordeel. De bevindingen zijn patroonherkenning en een startpunt voor handmatig onderzoek, geen juridisch eindoordeel.

Wat nog open staat

• De klantsites van de certificeerders. De NPI meet de eigen homepage van Kiwa en DNV, niet de sites die zij certificeren. Of hun keurmerk-klanten het beter of slechter doen, is een aparte meting.
• Een herhaalmeting. Dit is één momentopname uit juni. Een tweede meting laat zien of de gevonden lekken structureel zijn of dat er sinds de publicatie iets is gerepareerd.

Bronnen en verantwoording

• De meting. Nationale Privacy Index, sector “Privacy keurmerken en juridisch advies”, 1 juni 2026, methodiek-versie 2026-06.2. Negen organisaties met een vastgestelde eindscore. De ruwe meetdata, scoredimensies en bevindingen zijn gehasht bewaard en reproduceerbaar.
• De meetcorrectie. De audit van 17 juni 2026 op de “vendor niet benoemd”-bevinding (aanleiding: tegenspraak van Privacy Company) is gedocumenteerd en op de bestaande scan-data herberekend, zonder nieuwe scan.
• Standaarden. De bevindingen verwijzen naar de Telecommunicatiewet (artikel 11.7a, toestemming voor cookies en trackers) en de AVG (onder meer artikel 6 grondslag, artikel 7(3) intrekken van toestemming, artikel 28 verwerker en artikel 13 informatieplicht).

De technische bevindingen zijn eigen metingen uit juni 2026. Een score is een momentopname van de gemeten homepage en geen volledig oordeel over de organisatie.

Ik legde een doodgewone sessie op www.anwb.nl vast, twee keer: een keer met cookies geweigerd en een keer met alles geaccepteerd, allebei tot en met een iDEAL-betaling. Twee dingen springen eruit. De iDEAL-betaalpagina vuurt 353 verzoeken naar poorten op je eigen computer, en dat gebeurt ongeacht je cookiekeuze. En ANWB stuurt al gedrag naar Google voordat je iets hebt aangeklikt. De zware advertentiepixels respecteren je weigering wel. Hieronder wat er vertrekt, waarheen, en wat hard gemeten is en wat niet.

Je verlengt je lidmaatschap, je regelt een verzekering, je rekent af. Een vertrouwde Nederlandse club, een vertrouwd betaalmerk. Niets aan de hand, zou je denken. Maar onder de motorkap gebeuren in diezelfde seconden dingen die niemand je heeft uitgelegd, en eentje daarvan raakt niet ANWB maar het hart van het Nederlandse betaalverkeer.

Ik heb het netwerkverkeer van een ingelogde sessie vastgelegd in vijf HAR-bestanden, samen ongeveer 83 megabyte, en daar regel voor regel doorheen gewerkt. Geen aannames vooraf: gewoon kijken wat het toestel verstuurt, naar wie, en op welk moment.

“Laat Mick maar praten, het is gewoon een betaalpagina.” Tot je ziet wat die pagina naar je eigen computer stuurt.

De korte versie

• De iDEAL-betaalpagina (pay.ideal.nl, gebouwd door Payconiq voor Currence) stuurt tijdens het betalen 353 verzoeken naar poorten op je eigen computer. Dat is gemeten, en het staat zwart op wit in de beveiligingsregels van die pagina dat het mag.
• Die scan negeert je cookiekeuze volledig: 177 keer toen ik weigerde, 176 keer toen ik accepteerde. Het is geen marketing, het is vrijwel zeker fraudedetectie. Maar je weet er niets van.
• ANWB stuurt gedrag naar Google voordat je toestemming geeft. Met cookies geweigerd vertrokken er tóch analytics-gebeurtenissen, waaronder een login-event, via een eigen ANWB-subdomein dat trackerblokkers omzeilt.
• De advertentiepixels respecteren je weigering wel. Meta, Microsoft, DoubleClick, remarketing, het klantprofiel met je IP-adres en de sessie-opname kwamen pas ná “alles accepteren”. Dat hoort zo, en dat zeg ik er eerlijk bij.
• Wat je kunt doen: weiger cookies (het scheelt aantoonbaar veel), en weet dat de iDEAL-scan losstaat van die keuze. Verderop staat meer.

Wat ik onderzocht, en hoe

Ik heb met de browser het volledige netwerkverkeer opgenomen van een ingelogde sessie op www.anwb.nl, doorlopend tot een echte iDEAL-betaling. Dat levert een HAR-bestand op: een letterlijk logboek van elk verzoek dat de browser doet, met adressen, kopteksten en, waar de browser ze bewaart, de inhoud.

Het belangrijkste in de opzet: ik heb het twee keer gedaan. Eén keer met de cookiebanner op weigeren, en één keer met alles accepteren. Zo kun je precies zien wat er afhangt van je toestemming en wat niet. Dat de twee echt verschillen, is geen interpretatie: ANWB’s eigen toestemmingscookie legt het vast.

Deel 1 · Je betaalpagina scant je eigen computer

Dit is de vondst die er het meest uitspringt, en die niet over ANWB gaat maar over iDEAL zelf.

Op het moment dat de iDEAL-betaalpagina laadt, begint je browser verbindingen op te zetten naar je eigen computer. Niet naar internet: naar 127.0.0.1, het adres dat altijd “deze machine hier” betekent. In totaal 353 keer, verdeeld over zeven vaste poorten, telkens met het pad /initiate.

De poorten zijn 666, 6039, 7070, 9527, 9528, 37014 en 37114. Poort 666 wordt het vaakst geprobeerd (88 keer), de rest elk een stuk of vijftien keer. De verzoeken zijn van het type no-cors, wat een belangrijk detail is: de pagina mag het antwoord niet lezen, maar kan wel detecteren of er iets antwoordt. Dat is precies de techniek waarmee je van buitenaf kunt vaststellen of er op je computer een bepaald programma draait, zonder dat je het kunt zien.

Waarom doet iDEAL dit? Het eerlijke antwoord: het meest waarschijnlijke doel is het opsporen van software waarmee iemand je computer op afstand overneemt of meekijkt. Dat is een bekende anti-fraudetechniek tegen oplichting waarbij een crimineel je tijdens een betaling aan de lijn houdt en het scherm overneemt. De zeven poorten passen bij dat soort programma’s. Maar let op het bewijsniveau: de scan zelf heb ik gemeten, het doel is een gefundeerde gevolgtrekking. De code die de exacte poort-naar-programma-vertaling maakt, zit in een bestand van 1,64 megabyte dat de browser bij het opslaan op precies 1,0 megabyte heeft afgekapt. Ik kan die code dus niet letterlijk citeren, alleen het gedrag dat eruit voortkomt. (Inmiddels achterhaald, zie de update direct hieronder.)

Dezelfde module doet trouwens meer dan poorten scannen: ze leest ook het betaalbedrag en de begunstigde uit de pagina (data-testid=payment-amount-euros en …-creditor) en let op of de pagina onderweg gewijzigd wordt. Het resultaat gaat eerste-partij terug naar iDEAL (PUT pay.ideal.nl/api/v1/transactions/initiate). Wie de module precies levert, is uit de sterk versluierde code niet hard vast te stellen; dat houd ik bij de feiten weg.

En het venijn: deze scan trekt zich niets aan van je cookiekeuze. In de geweigerde run gebeurde het 177 keer, in de geaccepteerde run 176 keer. Logisch, want het is geen marketing. Maar het betekent ook dat je er op geen enkele knop “nee” tegen kunt zeggen.

Deel 2 · Wat vuurt er vóór je iets aanklikt

Nu naar ANWB zelf. De grote vraag bij elke website: wat gebeurt er als je de cookies weigert? Het korte antwoord hier: minder dan met accepteren, maar niet niets.

ANWB gebruikt server-side tagging. Op een eigen subdomein, sst.anwb.nl, draait een kopie van Google Tag Manager. Je gegevens gaan eerst naar dat ANWB-adres, en van daaruit server-naar-server door naar Google. Het effect: voor je browser en voor trackerblokkers ziet het eruit als “gewoon ANWB”, terwijl het in werkelijkheid het doorgeefluik naar Google is. Dat heet first-party cloaking, en het is precies waarom dit soort verkeer zo lastig te zien is.

Met cookies geweigerd (gemeten) vertrok er tóch:

• Analytics naar Google via sst.anwb.nl (18 keer): gebeurtenissen page_view, login, scroll, user_interaction, user_engagement en view_experiment. Dus ook dát je inlogt werd geregistreerd, terwijl analytics geweigerd was.
• Directe advertentiepings naar Google (pagead2.googlesyndication.com, 9 keer).
• Sentry (27 keer, foutopname inclusief de sessie-opname-module, daarover verderop).

En wat respecteerde de weigering wel? Een hoop, en dat hoort gezegd te worden. In de geweigerde run zag ik geen Meta, geen Microsoft Bing, geen DoubleClick, geen remarketing, geen BlueConic-klantprofiel en geen Contentsquare. Die kwamen allemaal pas ná “alles accepteren”. Op dat punt doet ANWB het dus zoals het hoort.

Deel 3 · Waar je gegevens heen gaan

Als je wél accepteert, ontvouwt zich het complete beeld. Het mooie nieuws eerst: ik heb gecontroleerd of je identiteit (e-mailadres, account-id, IP-adres, betaaltoken) ergens naar een derde partij vertrekt, en dat heb ik in deze opnames niet gevonden. Je persoonsgegevens blijven binnen de ANWB-subdomeinen. Het gaat dus niet om een directe verkoop van je naam aan adverteerders, maar om gedrag, een IP-adres, en de timing rond je toestemming.

De opvallendste verwerker is BlueConic, een klantdataplatform, verstopt op het ANWB-subdomein t066.anwb.nl. Dat platform kreeg je echte IP-adres te zien (het kaatste het netjes terug in zijn antwoord) en draagt een rijke lijst gedragslabels: of je op het punt staat weg te klikken, of je inactief bent, of je een route plant, en, veelzeggend, Lidnummer bekend, plus verzekeringstrechters met namen als Woonverzekering vragenlijst. Dit is profilering, gekoppeld aan je lidmaatschap. Belangrijk en eerlijk: dit vuurde alleen ná toestemming. Weiger je, dan blijft BlueConic stil.

Deel 4 · Sentry en sessie-opname

Op de site zit Sentry, een dienst voor foutmeldingen. Twee aparte Sentry-projecten, en ze vuren ook al voordat je toestemming geeft. Goed nieuws voor de datasoevereiniteit: deze Sentry draait op de Europese omgeving (Frankfurt), niet in de VS.

Wat ik wel kan vaststellen: de ANWB-code laadt naast foutopname ook de sessie-opname-module van Sentry (de zogeheten Replay, die letterlijk je schermgedrag kan terugspelen). Wat ik niet kan vaststellen uit deze opnames: hoe vaak die opname aanstaat en of er gevoelige gegevens in worden vastgelegd. De inhoud van die Sentry-verzoeken heeft de browser namelijk niet bewaard, de verzoeken zijn leeg in mijn log. Ik laat dat hier nadrukkelijk open: de mogelijkheid zit aantoonbaar in de code, het bewijs van wat er wordt opgenomen ontbreekt. Daarnaast staan er nog Contentsquare (sessie-opname, pas ná toestemming) en LivePerson (chat, met de mogelijkheid tot meekijken) op de site.

Wat hard is, en wat niet

Dit hoort er bij elk eerlijk onderzoek bij. Tijdens het graven ben ik ook een paar dingen tegengekomen die er op het eerste gezicht erger uitzagen dan ze zijn. Die corrigeer ik liever zelf dan dat ik ze laat staan.

• De localhost-scan komt van iDEAL, niet van ANWB. ANWB’s eigen code noemt 127.0.0.1 ook, maar alleen om te herkennen of de site in een testomgeving draait. Dat is geen scan.
• Het is geen “Google Tag Manager die je poorten scant”. De poortnummers kwamen toevallig ook voor in een groot Google-bestand, maar zonder de bijbehorende scan-code. De scan zit echt op de betaalpagina.
• Ik heb geen IP-lek naar derden gevonden. Een paar getallen die op IP-adressen leken, bleken bij nader inzien coördinaten uit een tekening (een SVG-pictogram) te zijn. Die heb ik niet meegeteld.
• Ik beweer niet dat de sessie-opname jouw gevoelige gegevens vastlegt. De module is aanwezig, de inhoud is onbewezen.

Eén kanttekening over hygiëne aan ANWB’s kant: in de publieke Google-configuratie van de site staat een intern e-mailadres van een ANWB-medewerker hardcoded. Dat is niet jouw data, maar het hoort niet in code die aan iedereen wordt uitgeleverd.

Wat je kunt doen

• Weiger de cookies. Het scheelt aantoonbaar veel: de remarketing, het klantprofiel met je IP-adres, Meta, Microsoft en de sessie-opname blijven dan uit. Dat het analytics-restje en de iDEAL-scan blijven, is vervelend, maar je vermindert het meeste.
• Weet dat de iDEAL-scan losstaat van je keuze. Je kunt hem niet uitzetten via een cookiebanner. Wil je hem helemaal kwijt, dan kom je uit bij browser-extensies die 127.0.0.1-verzoeken blokkeren, met het risico dat een legitieme fraudecheck dan ook sneuvelt.
• Vraag het na. Je hebt recht op inzage (AVG, artikel 15). Vraag ANWB welke gedragsgegevens ze vóór je toestemming naar Google sturen, en vraag Currence waarom de betaalpagina je localhost scant en hoe lang ze de uitkomst bewaren. Dat zijn precies de vragen waar dit dossier de feiten voor levert.

Een doodgewone Nederlander opent ‘s ochtends de weer-app, plant ‘s middags een reis, scrolt ‘s avonds over Marktplaats. Bij elk van die handelingen vertrekt er, voordat je de advertentie ziet, een berichtje naar een advertentieveiling. Daarin staat je advertentie-ID, je locatie, je telefoonnetwerk en je taal. Honderden partijen bieden mee en zien dat profiel. Dit is wat ik bij drie Nederlandse apps zelf heb vastgelegd, en wat ik niet kon vastleggen, eerlijk uit elkaar gehouden.

Het werkt zo onzichtbaar dat niemand het merkt. Je vraagt of het gaat regenen, en in diezelfde seconde wordt je toestelprofiel een veiling in geschoten waar advertentiebedrijven op bieden. Niet de weersinformatie is het product. Jij bent het. En het kost je, gemeten, je databundel en je accu, terwijl je dacht dat je gewoon het weer checkte.

Ik heb het verkeer van drie alledaagse Nederlandse apps onderschept en ontcijferd, het toestel uitgelezen tot op de simkaart, en de app-code uit elkaar getrokken. Hieronder staat per app de keten: wat vertrekt, waarheen, en wat het voor jou betekent.

“Laat Mick maar praten, het zijn maar advertenties…” De reactie die ik het vaakst krijg.

De korte versie

• Bij het laden van een advertentie stuurt je toestel een bid-request met je advertentie-ID, locatie en netwerkgegevens naar een advertentieveiling. Ik ving en ontcijferde die bid bij Buienalarm en Marktplaats.
• De app stuurt het volledige toestelprofiel ongefilterd door. Geen anonimisering, geen afweging per veld of een waarde mee mag.
• De gegevens belanden aantoonbaar bij databrokers: 9292, Marktplaats en VI staan in de gelekte Gravy-lijst van een databroker die uit de bidstream oogst.
• Het kost je data en accu. Bij een advertentiezware app als Marktplaats ging in mijn meting ongeveer 85% van het dataverbruik tijdens gebruik naar de advertentie- en trackinglaag. Bij een schone utility als 9292 was dat ongeveer 1%.
• Wat je kunt doen: reset je advertentie-ID, schakel advertentiepersonalisatie uit, en weiger toestemming waar dat kan. Het verlaagt de waarde van wat er wordt doorgestuurd.

Keten 1 · Buienalarm: het weer als lokaas

Je opent de app om te zien of je droog thuiskomt. Buienalarm (van Infoplaza) toont je de regengrafiek, en laadt daarbij een advertentie. Op dat moment bouwt het toestel een OpenRTB-bid en stuurt die naar PubMatic OpenWrap (ow.pubmatic.com). Ik heb die bid onderschept en ontcijferd.

In de bid zit de advertentie-ID (device.ifa), plus land, netwerkcode (mccmnc), carrier, taal en locatie, samen met de IAB-toestemmingsstring en de package-naam van de app. Het volledige profiel dat je toestel aanlevert, ongefilterd de veiling in.

De last is ook in volume zichtbaar. In een gebruikssessie ging 87% van alle netwerkverzoeken en 54% van alle bytes naar de advertentie- en trackingketen, tegenover ongeveer 0,2 MB echt weerverkeer. Je betaalt databundel om advertenties op te halen, niet om het weer te zien.

Waar het heen gaat (gemeten)

De bid gaat naar PubMatic (OpenWrap), een advertentie-exchange. Vanaf daar wordt jouw plek doorgeveild aan de meebiedende partijen, die elk het profiel zien. Buienalarm staat daarnaast in de gelekte Gravy-lijst: een databroker die uit de bidstream oogst, doorgaans zonder dat de uitgever het weet.

Keten 2 · Marktplaats: scrollen kost je de helft van je bundel

’s Avonds op de bank, even over Marktplaats scrollen naar een tweedehands fiets. Bij elke listing en in de feed laadt de app advertenties, en stuurt het toestel bid-requests naar PubMatic OpenWrap, met een Prebid Server ernaast. Ook deze bid heb ik gevangen en ontcijferd: dezelfde structuur, advertentie-ID plus het volledige device-profiel.

Maar bij Marktplaats is de kosten-kant het scherpst. Ik mat het dataverbruik twee keer onder identieke omstandigheden: een keer met de advertentiedomeinen toegestaan, een keer geblokkeerd. Het verschil is de pure advertentie-overhead.

Wat het je bundel kost (gemeten)

Tien minuten scrollen kostte met advertenties ongeveer 15 MB, zonder de advertentiedomeinen ongeveer 2 MB. Het overgrote deel van wat de app je bundel kost tijdens gebruik, ongeveer 85%, is de advertentie- en trackinglaag. De listings die je zoekt zijn een kleine fractie. Een deel van die 85% is de zichtbare advertentie zelf (het gratis-app-model), een deel is onzichtbare bied- en trackingoverhead die jou niets oplevert. De harde ondergrens van pure tracking-calls was ongeveer 5%.

Keten 3 · 9292: de schone app die toch in de broker-lijst staat

’s Middags je trein plannen met 9292, de OV-reisplanner van Infoplaza. En hier wordt het verhaal genuanceerder, want 9292 is juist schoon in verbruik: in mijn meting was maar ongeveer 1% van het dataverkeer klassieke advertentie-/trackingdata. Een OV-utility eet je bundel niet op zoals een feed-app dat doet. Dat is het eerlijke contrast: niet elke app is een bundelvreter.

En tóch staat 9292 in de gelekte Gravy-lijst van de databroker. Dat is de kern van keten 3: een app kan relatief licht zijn in verbruik en tegelijk je gegevens bij een broker laten belanden. 9292 is bovendien het anker dat de broker-lijst verbindt met de Infoplaza-familie, dezelfde uitgever als Buienalarm.

Het mechanisme-onderscheid (streng)

Er zijn twee manieren waarop je gegevens bij een broker komen, en die horen niet op een hoop. De ene is bidstream-oogst: een broker als Gravy verzamelt uit de advertentieveiling, doorgaans zonder dat de uitgever het weet. De andere is een ingebouwde SDK: bij sommige apps (zoals de jRustonApps-weerserie) zit een locatie-SDK uit de X-Mode/Sense360-familie die de uitgever zelf heeft ingebouwd. Het eerste overkomt de uitgever, het tweede is een keuze van de uitgever.

De status van 9292 blijft eerlijk: het staat in de Gravy-lijst en het ad-verkeer is waargenomen, maar de eigen bid met de 9292-package heb ik niet gevangen. Daarvoor zou ik een geroot toestel nodig hebben. Dus 9292 staat op lijst-vermelding plus waargenomen verkeer, niet op een eigen ontcijferde bid.

Keten 4 · Buienradar: dezelfde markt, andere route

’s Ochtends even Buienradar (van RTL Nederland, sinds de overname onder DPG Media) openen om te zien of je droog wegkomt. Ook hier laadt de app een advertentie. Maar als je nu naar het netwerkverkeer kijkt, mist er iets: er vertrekt geen zichtbare bid-request uit je toestel. Geen PubMatic, geen veiling-in-je-telefoon. Het toestel praat voor advertenties alleen met Google.

Dat lijkt schoner, en op één punt is het dat ook. Maar het is vooral een andere route. De advertentieveiling draait niet in je toestel maar server-side bij Google (Ad Manager, Open Bidding); jij ziet alleen de winnaar. Je profiel wordt niet zichtbaar de ether in geschoten, het wordt bij Google verhandeld, daar waar je het niet kunt onderscheppen.

En “schoner” betekent hier niet “zonder identifier”. De app leest gewoon je advertentie-ID, vraagt achtergrondlocatie (met geofencing, waarschijnlijk voor regen-alarm, maar het blijft een brede toestemming) en omarmt Google’s nieuwe advertentie-API’s (Topics, Attribution). De advertentiebeelden komen via LemonPI, een Nederlands platform voor dynamische advertenties uit Eindhoven.

Wat erbij komt: een eigen meetlaag (uit de APK)

Buienradar draagt boven op Google nog een laag die de andere apps niet zo hebben: een eigen, door DPG en RTL gehoste meetpijplijn (Snowplow) die je schermgedrag, je scrollen en je locatie-context vastlegt, plus Kantar NMO, het Nationaal Media Onderzoek, dat een gebruikers-ID naar Kantar stuurt voor de kijkcijfers. Toestemming loopt via OneTrust, met de IAB-toestemmingsstring plus Google’s eigen partnerlijst, achter de bekende betalen-of-toestemmen-muur.

Nog één: VI

VI (Voetbal International) doet iets dat de andere niet zo openlijk doen: het stuurt je advertentie-ID rechtstreeks naar een databedrijf. In mijn capture ging je advertentie-ID naar Lotame (crwdcntrl.net), een Data Management Platform dat profielen over apps en sites heen bouwt, georkestreerd via het Nederlandse advertentienetwerk Next Day Media. Daarnaast meet VI je mee met comScore, serveert advertenties via Google Ad Manager, en draait de eigenlijke veiling via een Prebid Server bij Magnite. VI staat ook in de Gravy-lijst. Wat ik hier zag is dus niet alleen een veiling, maar een rechtstreekse levering van je identifier aan een profielenbouwer.

Waarom je dit niet op je eigen toestel kunt zien

Er zit een ongemakkelijke kant aan dit onderzoek: je kunt zelf bijna niet controleren wat je apps versturen, en dat is zo ontworpen.

Sinds Android 7 (2016) vertrouwen apps voor hun beveiligde verbindingen standaard alleen de certificaten van het systeem, niet die jij als gebruiker zelf installeert. Wie het bid-verkeer wil meelezen wordt genegeerd, tenzij je je toestel “root”, en dat verzwakt de beveiliging van je telefoon juist. Dat geldt voor het bid-verkeer van Buienalarm, Marktplaats en VI; VI zet er bovendien code-pinning overheen. De keten die je gegevens doorverkoopt is daarmee precies de keten die je niet mag inzien.

Daarom legde ik het gedrag vast op een emulator en mat ik de Nederlandse identiteit los op een echt Odido-toestel. De plek waar dit zichtbaar wordt is een ingerichte testopstelling, niet je eigen telefoon, en dat is precies het punt.

Wat je kunt doen · Trek de stekker uit het profiel, niet uit de app

• Reset je advertentie-ID en schakel advertentiepersonalisatie uit in de Android-instellingen. Het breekt de koppeling tussen je gedrag en een vast nummer.
• Weiger toestemming waar dat kan. Herken een betalen-of-toestemmen-muur als een keuze die je mag afslaan.
• Dien een inzageverzoek (AVG artikel 15) in bij de exchange en de brokers, om te zien welke gegevens zij aan je advertentie-ID koppelen.
• Weet welke apps je bundel opeten. De feed- en content-apps doen dat onevenredig; de utilities zijn vaak licht. Je hoeft ze niet weg te gooien, wel bewust te gebruiken.

Hoe hard is elke laag?

Methode (voor wie het zelf wil nalopen)

Het toestelprofiel (Bewijs A) is read-only van een fysiek toestel gelezen met getprop: model SM-A528B, simkaart-netwerkcode 20416 (Odido), taal nl-NL, geen enkele hook. Het gedrag (Bewijs B) is op een Android-emulator vastgelegd met mitmproxy als onderschepper, met een veld-voor-veld-analyse op de ontcijferde OpenRTB-bid; elke bid is gecontroleerd tegen de package die hem hoort te versturen. De grens is bepaald met statische analyse van de network_security_config van elke app. Een onafhankelijke verificatielaag herscoorde alle captures met een strengere tool en zette overclaims terug; geen enkele bevinding is als gebonden bewijs op een echt toestel geclaimd. De overhead is gemeten met een twee-runs-vergelijking (met en zonder advertentiedomeinen) onder identieke omstandigheden.

Wat nog open staat (onderzoeksagenda)

Een eerlijk onderzoek laat zien waar het ophoudt. Dit zijn de open einden, en wat elk ervan vergt om te sluiten.

• Het overhead-percentage van Buienradar en VI. De architectuur is bekend (Buienradar veilt server-side bij Google, VI levert je advertentie-ID aan Lotame), maar een schoon “zoveel procent van je bundel”-getal heb ik er niet voor. Mijn twee testruns waren niet gelijk van lengte, en een deel van het advertentieverkeer liep over een protocol (QUIC) dat mijn meetpunt passeert. Dat sluiten vergt een meting over wifi met de radio actief, twee gelijke runs.
• De eigen bid van 9292 op package-niveau. 9292 contacteert wel PubMatic en Google, en staat in de Gravy-lijst, maar een eigen ontcijferde bid met de 9292-package heb ik niet. Daarvoor is een geroot toestel nodig.
• De koppeling op een echt toestel (de NL-identiteit in de bid). Dat een precieze locatie en je advertentie-ID de veiling in gaan, is aangetoond. Dat op jouw eigen toestel jouw unieke advertentie-ID met de Nederlandse netwerkwaarden in één bid samenkomt, vergt root, en dat heb ik bewust niet op mijn dagelijkse toestel gedaan.
• De andere kant van de keten (inzageverzoeken). De brug tussen “ik zag het de veiling in gaan” en “een broker bevestigt dat hij het heeft” loopt via een AVG artikel 15-verzoek met de advertentie-ID van een echt toestel. De brieven liggen klaar (PubMatic, Lotame, Eskimi, Datasys, Infoplaza); versturen kan alleen met een echte identiteit.
• De accu- en maandkosten. De data-overhead is hard gemeten; de vertaling naar accuslijtage en een maandtotaal is een doorrekening, geen meting. De energiemeting zelf was ruis omdat de testopstelling de radio idle hield.

Bronnen en verantwoording

• Databroker-lijst (Gravy). Geëxtraheerd en gepubliceerd door 404 Media uit de Gravy Analytics-hack (januari 2025), 12.372 apps, door mij gefilterd op Nederlandse packages en uitgevers (19 NL-treffers, waaronder 9292, Marktplaats en VI). Een vermelding betekent dat de app-data in de Gravy-dataset opdook via de advertentieketen, niet per se een directe relatie tussen de app-maker en Gravy.
• X-Mode / Outlogic-lijst. Uit het Xoth-onderzoek van ExpressVPN, bron voor het SDK-mechanisme bij de jRustonApps-serie.
• Systeem-CA sinds Android 7. Android Developers, network security configuration (developer.android.com/privacy-and-security/security-config) en de Android Developers Blog, juli 2016.
• Context. De Databroker Files (netzpolitik.org en BR) en de FTC-orders tegen Mobilewalla en Gravy Analytics, december 2024.
• Standaarden. OpenRTB 2.5 (IAB Tech Lab) voor de bid-structuur, IAB TCF voor de toestemmingsstring.
• Genoemde partijen. Lotame is een Data Management Platform (crwdcntrl.net); Next Day Media een Nederlands advertentienetwerk; LemonPI een Nederlands platform voor dynamische advertenties uit Eindhoven. Rollen geverifieerd via openbare bedrijfsbronnen.

De technische bevindingen (de gedecrypteerde bids, het toestelprofiel, de overhead-metingen) zijn eigen metingen uit juni 2026, gehasht bewaard en reproduceerbaar. De databroker-vermeldingen komen uit de bovengenoemde openbare bronnen.

Een cyclus-app weet wanneer je ongesteld bent, wanneer je vruchtbaar bent, of je probeert zwanger te worden, en vaak ook wanneer je seks hebt gehad. Dat is precies het soort gegeven waarvan je wilt weten waar het terechtkomt. Ik heb de Android-versie van drie populaire apps ontleed en in één onderzoek naast elkaar gelegd.

Het gaat niet om je grootste nieuws, maar om je gewoonste

Het beeld bij gezondheidsapps is vaak: straks weten ze dat je zwanger bent. Maar de echte reikwijdte is breder, en ongemakkelijker. Wie een kinderwens heeft, of gewoon haar cyclus volgt, houdt veel meer bij dan een paar data. Deze apps vragen, dag na dag, hoe zwaar je menstruatie is, of je seks had en of het beschermd was, of er een orgasme was, hoe je libido is, je stemming, je krampen, je cervixslijm, je temperatuur.

En die gegevens blijven niet liggen waar je ze invoert. In de advertentie- en databroker-economie ben je geen persoon, maar een doelgroep. Zo zou je eruit kunnen zien:

Ter illustratie. Geen echte export uit Clue, Flo of Clover, maar de logica van de doelgroep-handel die hun trackers met data voeden.

Het schrijnende zit niet in één dramatisch moment. Het zit in het gewone, verhandelbaar gemaakt. Niet "ze weten mijn grootste nieuws", maar "ik sta te koop als vrouw die gisteren seks had". Dat is wat niemand op straat wil hebben liggen. En toch schrijft Flo "seksuele activiteit" via Health Connect weg, zwart op wit in de rechten die de app vraagt.

Wat er weggaat, en wat het over je zegt

De volledige lijst, vertaald van techniek naar betekenis. Links wat er vertrekt, rechts wat iemand daaruit kan aflezen over jou en je leven.

Op zichzelf zegt "late menstruatie" of "stemming somber" weinig. De waarde, en het risico, zit in de optelsom: een getimed, intiem beeld van je lichaam en je relatie, gekoppeld aan een naam en een toestel.

Niet alleen privacy. Autonomie.

Een vrouw vertrouwt een cyclus-app iets toe wat ze misschien niet eens met haar werkgever, haar ouders, de overheid, haar verzekeraar of haar partner zou delen. En die app kan dat behandelen als handelswaar. Daar zit een dubbele schending.

Eerst wordt iets extreem intiems verzameld: wanneer je menstrueert, wanneer je vruchtbaar bent, of je seks hebt, of je zwanger probeert te worden, of je het bent geweest, je klachten, je pijn, je stemmingen, je anticonceptie, misschien een miskraam of een abortus. Daarna kan diezelfde informatie uit de context worden getrokken. Jij voert het in als zelfzorg. Buiten je zicht kan het een profiel worden dat commercieel, politiek, medisch, juridisch of zelfs geopolitiek bruikbaar is.

De wrangheid: wat bedoeld is om een vrouw meer regie over haar lichaam te geven, kan juist het instrument worden waarmee anderen iets over haar lichaam te weten komen. In jouw telefoon betekent een late menstruatie stress, of een kinderwens, of angst. In een datasysteem wordt het een signaal dat een vreemde mag duiden. En in situaties waar zwangerschap, abortus of seksualiteit politiek, religieus of juridisch beladen zijn, is zulke data niet neutraal. Dan wordt informatie over je lichaam macht over jou.

Drie apps, en toch dezelfde advertentie-ID

De drie apps verschillen sterk, maar twee dingen hebben ze gemeen. Geen van de drie vraagt een locatiepermissie, dat is netjes. En alle drie vragen wel de advertentie-identifier (AD_ID) en de attributie-rechten van Androids Privacy Sandbox. Ook Clue, de app met de beste privacyreputatie, doet dat in de actuele versie, terwijl een oudere versie die ik ernaast legde dat recht nog niet vroeg. De advertentie-ID is het unieke nummer waarmee je toestel herkenbaar is voor advertentiedoeleinden. Dat een cyclus-app dat nummer opvraagt, is geen kleinigheid.

Het echte verschil zit in hoeveel derde partijen er meeluisteren. Ik heb per app geteld hoeveel externe diensten gegevens kunnen ontvangen, op basis van de ingebouwde bibliotheken. Het verschil is groot.

En er is iets wat in geen van de drie zit: een herkenbaar toestemmingsframework. Ik vond in geen enkele app een Consent Management Platform of de IAB-standaard voor transparantie en toestemming (geen Didomi, OneTrust, Usercentrics, Sourcepoint of Google UMP). Dat betekent dat de toestemmingsvraag, voor zover die er is, in de app zelf wordt afgehandeld en niet als gestandaardiseerd signaal naar de advertentiepartners wordt doorgegeven. Voor een categorie zo gevoelig als deze is dat een opvallende leegte.

Het meeste gaat naar de VS, bij Clover ook naar Rusland

Alle drie apps sturen tracking en telemetrie naar verwerkers onder Amerikaans recht: Google en Firebase bij alle drie, en afhankelijk van de app ook Meta, TikTok, AppsFlyer, Braze, Datadog, Sentry, Auth0 en Amplitude. Clue houdt zijn functionele inhoud daarbij in de EU. Clover voegt er een hele laag aan toe die in Rusland eindigt.

Endpoints van Google worden via anycast vaak op een Europese rand-server geraakt, dus fysiek reist je data soms niet de oceaan over. Maar de partij die de gegevens ontvangt en verwerkt is het buitenlandse moederbedrijf, en dat valt onder buitenlands recht. Voor de vraag wie er bij je data kan, telt de verwerker, niet alleen de plek van de kabel.

Clue maakt zijn reputatie grotendeels waar. De inhoud, je cyclus en symptomen, gaat naar een eigen API (api.helloclue.com) die op Amazon-infrastructuur in Europa draait, en die verbinding is extra beveiligd: de app pint het certificaat met vijf vingerafdrukken, zodat onderschepping veel moeilijker wordt. Artikelen komen via een contentdienst binnen. Er zit geen advertentienetwerk in, en geen Meta-SDK.

Toch is sober niet hetzelfde als leeg. Clue draagt een marketing- en meetlaag mee die naar Amerikaanse bedrijven wijst: Braze voor klantbenadering, op een datacenter aan de Amerikaanse oostkust, Datadog voor monitoring, en de Firebase- en Google Analytics-bouwstenen. Attributie loopt via Adjust, dat zijn servers in Duitsland heeft. De app vraagt sinds kort ook de advertentie-ID en leest een beperkte set biometrie via Health Connect (hartslagvariabiliteit, rusthartslag, huidtemperatuur, slaap, gewicht), maar uitsluitend lezen, en niet de menstruatie- of seksuele-activiteit-categorieën. Het beeld: de privacyvriendelijkste van de drie, maar ook hier deelt de app gedrag en engagement met Amerikaanse verwerkers.

Flo is het interessantste geval, want het trekt twee kanten op tegelijk. Na een schikking met de Amerikaanse toezichthouder FTC in 2021, over het delen van gezondheidsdata met onder andere Facebook en Google, investeerde Flo zichtbaar in privacy. De app heeft een Anonymous Mode die telemetrie via een speciale gateway stuurt, een techniek waarbij Flo de gegevens niet aan een IP-adres of identiteit kan koppelen. Die gateway is er echt en antwoordt live.

Tegelijk draagt diezelfde app in 2026 nog steeds de SDK's van Meta, TikTok, AppsFlyer en Google mee, plus Sentry voor crashes en Auth0 voor inloggen. En Flo vraagt de breedste, gevoeligste set rechten van de drie. Via Health Connect leest het negentien categorieën, waaronder menstruatie, tussentijdse bloedingen, cervixslijm, ovulatietesten en seksuele activiteit, en het schrijft er zes terug, waaronder opnieuw seksuele activiteit, cervixslijm en ovulatietesten. De spanning is dus reëel: de verzendinfrastructuur naar advertentie- en analytics-partijen zit ingebouwd, en de privacy-laag bepaalt hoeveel daarvan herleidbaar blijft. Welke van de twee wint bij een concrete handeling, is precies wat een statische analyse niet kan beslissen.

Clover is een gratis app die op advertenties draait, en dat is in de code goed te zien. Er zitten vier advertentienetwerken in: Google AdMob, met aanvulling via AppLovin, ironSource en Fyber. Daarnaast Adjust voor attributie, Amplitude en Firebase voor analytics, en de Meta-SDK. Voor een gevoelige gezondheidsapp is dat al een volle commerciële stapel.

Daarbovenop staat iets wat ik bij de andere twee niet zag: een uitgebreide Russische laag. De app bevat Yandex AppMetrica voor analytics, VK voor sociale login, en de volledige account- en betaal-SDK's van YooMoney en SberPay. De bijbehorende adressen draaien op typisch Russische webservers, wat de operators bevestigt. De app staat bovendien onversleuteld verkeer toe naar een YooMoney-domein, een uitzondering op het verder versleutelde geheel. En er zit een ingebouwde, merk-gesponsorde vragenlijst in: een complete Kotex-flow die naar je cyclus vraagt. Of de Russische componenten bij een Nederlandse gebruiker actief worden, hangt af van regio en server-instellingen, maar de code wordt onverkort meegeleverd. Het is de breedste jurisdictie-spreiding van de drie, in de meest gevoelige datacategorie.

De vergelijking

Wat je kunt doen zonder je app op te geven

1. Kies bewust. Wil je het soberst, dan is Clue van de drie de minst vergaande: geen advertentienetwerk, geen Meta-SDK, en je inhoud blijft in Europa.
2. Reset je advertentie-ID. Alle drie apps vragen die identifier. In de Android-instellingen onder Privacy kun je hem wissen, en je kunt gepersonaliseerde advertenties helemaal uitzetten.
3. Wees zuinig met Health Connect. Vooral bij Flo bepaalt Health Connect hoeveel intieme categorieën de app mag lezen en schrijven. Geef alleen toegang tot wat je echt nodig hebt, en trek het later weer in als je twijfelt.
4. Gebruik de privacymodus als die er is. Flo's Anonymous Mode bestaat echt en helpt. Zet hem aan als je Flo gebruikt.
5. Denk na over de gevoeligste invoer. Een app die niet weet of je zwanger probeert te worden, kan dat ook niet doorgeven. Niet alles hoeft erin.

Conclusie

Drie apps voor dezelfde, uiterst gevoelige taak, en drie heel verschillende antwoorden op de vraag waar je data heen gaat. Clue houdt het Europees en sober, al vraagt ook deze app inmiddels de advertentie-ID. Flo bouwt een echte privacy-laag, maar bovenop een infrastructuur die nog vol zit met de SDK's van advertentie- en socialmediabedrijven, en het vraagt de meest intieme gezondheidsrechten. Clover spreidt analytics, login en betalingen uit over drie jurisdicties, tot in Rusland, en draagt vier advertentienetwerken mee.

Geen van deze keuzes is een ongeluk, het is hoe de apps zijn gebouwd. En het is precies het soort keuze dat iemand die elke dag haar cyclus invoert zou moeten kunnen wegen. Dit dossier legt die keuzes naast elkaar op tafel.

Bestaat er dan wél een veilige? Ja: drip.

Het verschil met Clue, Flo en Clover zit in één detail dat alles bepaalt: drip vraagt niet eens toestemming om het internet te gebruiken. Een Android-app die dat recht niet heeft, kan geen enkele verbinding naar buiten openen. Geen advertentienetwerk, geen analytics, geen server in de VS of Rusland, want er is simpelweg geen weg naar buiten. Op de testtelefoon verstuurde de app dan ook nul bytes, terwijl dat toestel verder gewoon online was.

Alles wat je invoert, van menstruatie tot temperatuur, seks en stemming, blijft in een database op je eigen telefoon. Geen account, geen advertentie-ID, geen cloud, en geen enkele meet- of reclamebibliotheek in de app. Je kunt drip op slot zetten met een pincode en je gegevens laten versleutelen. En omdat de broncode openbaar is, kan iedereen dit zelf nakijken in plaats van een privacybelofte te moeten geloven.

Een Growatt- of Solis-omvormer met wifi-monitoring stuurt elke vijf minuten een gedetailleerd beeld van je huishouden naar de cloud, en die verbinding gaat twee kanten op. Dit stuk laat zien wat er vertrekt, waar het heen gaat, en welke risico's daaruit volgen: van aflezen wanneer je thuis bent tot op afstand aan je omvormer draaien. En wat je eraan kunt doen zonder je panelen kwijt te raken.

De korte versie

• Je omvormer stuurt elke vijf minuten een gedetailleerd beeld van je opwek, batterij en verbruik naar de cloud. Daaruit is af te leiden wanneer je thuis bent en wanneer niet.
• De app koppelt dat profiel aan jou persoonlijk: je e-mail, telefoonnummer en het adres van je installatie.
• Bij Growatt reist de meetdata zonder echte versleuteling, alleen een omkeerbare versluiering met een openbaar bekend sleutelwoord. Geen echt slot.
• De verbinding gaat twee kanten op: de cloud kan ook instellingen en firmware naar je omvormer terugsturen, dus op afstand het vermogen terugregelen of het apparaat uitschakelen.
• Het goede nieuws: trek je de wifi-stick eruit, dan blijven je panelen gewoon stroom leveren. Je verliest alleen de app, niet de opwek.

De kernrisico's

Er is niet één risico, maar een handvol, en ze versterken elkaar. Het meest tastbare eerst, daarna de minder zichtbare maar minstens zo belangrijke.

1 · Wanneer ben je thuis

De gevoeligste informatie is niet je energierekening, maar een aanwezigheidskalender van je huis, en die rolt er bijna vanzelf uit. Een omvormer met batterij rapporteert niet alleen hoeveel zon er was. Hij rapporteert elke vijf minuten je verbruik: hoeveel het huis op dit moment gebruikt, en of de batterij oplaadt of leeggetrokken wordt. En verbruik volgt menselijke activiteit bijna een-op-een.

Een gewone dag tekent zich daardoor scherp af. 's Nachts een vlakke bodem (alleen de koelkast en sluipverbruik), 's ochtends een piek (je staat op, doucht, ontbijt), een terugval als iedereen de deur uit is, overdag stilte, 's avonds weer een piek (koken, wasmachine, laptops), en dan terug naar de bodem. Die curve is een vrijwel perfect aanwezigheidslogboek, met 288 meetpunten per dag.

Het verraderlijkst is dat laatste. Ga je weg, dan zakt het verbruik terug naar kaal sluipverbruik en blijft daar dagenlang. Die platte, lage lijn over meerdere dagen is het luidst denkbare signaal "hier is niemand, en voorlopig ook niet". Andersom verraadt een laadpiek in de avond dat je auto, en waarschijnlijk jij, thuis is.

Wie heeft daar wat aan?

• Inbraak. Een betrouwbare kalender van wanneer jouw huis, op jouw adres, leeg is, plus een helder vakantiesignaal. Dat is precies de informatie waar inbrekers naar gissen.
• Profilering. Je dagritme, gezinsgrootte en gewoonten zijn bruikbaar voor verzekeraars, kredietverstrekkers of adverteerders die op gedrag prijzen.
• Datahandel. Eenmaal in de cloud is het profiel te aggregeren en door te verkopen.
• Op buurtschaal. Draaien veel huizen in een straat op hetzelfde platform, dan ontstaat een kaart van wanneer een hele wijk uitvliegt: werkdagen, schoolvakanties, feestdagen.

2 · Iemand kan op afstand aan je omvormer draaien

Dit is een ander soort risico dan privacy, en wordt vaak gemist. De verbinding gaat twee kanten op. De cloud stuurt niet alleen metingen op, maar kan ook instellingen en firmware terugsturen naar je omvormer. In het Growatt-protocol zitten aparte berichten om instellingen weg te schrijven, en bij Solis bestaat een vaste procedure voor firmware-updates op afstand. Dat is bedoeld voor onderhoud, maar het betekent dat een partij op afstand kan bepalen hoe jouw installatie zich gedraagt: het vermogen terugregelen, grenzen aanpassen, of in het uiterste geval uitschakelen.

Wie de cloud of je account in handen krijgt, krijgt die knop erbij, of dat nu de fabrikant is, een inbreker op je account, of wie het platform compromitteert. En omdat één fabrikant duizenden installaties tegelijk beheert, is die gebundelde controle over zonne-omvormers een netwerk- en leveringszekerheidskwestie waar overheden inmiddels publiek voor waarschuwen.

3 · En het blijft niet bij meekijken

• Het is niet anoniem, het is jij. Via de app hangt het hele profiel aan je naam, e-mail en adres. Zie de sectie hieronder.
• Bij Growatt kan iedereen op het pad meelezen. De meetdata reist zonder echt slot, dus niet alleen de fabrikant maar ook een gast op je wifi of je provider kan het lezen.
• Buitenlandse toegang. Data en besturing liggen bij bedrijven onder Chinees recht, ook als de opslag toevallig in de EU staat.

Dit alles gaat om data en bediening die je meekrijgt zonder het te weten, zonder dat je er bij de installatie een echte keuze in kreeg.

Wat er precies weggaat, en wat het over je zegt

De volledige lijst, vertaald van techniek naar betekenis. Links wat er vertrekt, rechts wat iemand eruit kan aflezen over jou en je huishouden.

Op zichzelf lijkt elke regel onschuldig. De waarde, en het risico, zit in de optelsom: een getimed gedragsbeeld, gekoppeld aan een naam en een adres.

Wat de app over jou weet

Op zichzelf is dat energieprofiel nog pseudoniem: het hangt aan een serienummer, niet aan een naam. De app legt juist die laatste schakel. Bij het aanmaken van een account geef je je naam, e-mailadres en telefoonnummer, en bij het registreren van je installatie het adres of de locatie ervan, voor de kaart en het weerbericht. Daarmee wordt het anonieme energiebeeld een dataset met naam en huisnummer.

Dat is de eigenlijke sleutel. Het aanwezigheidsprofiel is pas bruikbaar als je weet wiens huis het is en waar het staat, en precies die koppeling maakt de app. Daar komen de telefoon-permissies nog bij: beide apps vragen locatie en camera, SolisCloud ook de microfoon. De locatie-SDK (AMap) bepaalt actief waar je toestel is. Het resultaat is geen geanonimiseerde energiestatistiek, maar een genaamd, geadresseerd, getimed gedragslogboek van je huishouden.

Wat kun je eraan doen

1. Haal de stick van wifi af. 5 minuten
   Koppel de wifi-dongle los of verwijder hem uit je netwerk. De omvormer blijft zonnestroom omzetten en je panelen leveren door. Je raakt alleen de app-grafieken kwijt, niets aan je opbrengst. Dit sluit in één klap alle risico's: geen data meer naar buiten, en ook geen bediening van buitenaf meer.
2. Houd de monitoring lokaal (Growatt). knutselen
   Laat de dongle praten met een eigen mini-server op je thuisnetwerk in plaats van met de fabrikant-cloud. Het open project "grott" doet precies dit: je houdt je grafieken, de data blijft thuis. Vergt een Raspberry Pi of vergelijkbaar en wat instelwerk.
3. Vervang de firmware van de wifi-stick (Solis). gevorderd
   Voor de Solis-stick bestaat open firmware (ESPHome) die de gegevens rechtstreeks in je eigen Home Assistant zet, zonder enige cloud.
4. Of accepteer de cloud bewust. keuze
   Wil je het gemak van de app houden, dan is dat een legitieme keuze, mits je weet welke afweging je maakt. Zet de stick dan op een apart gastnetwerk, los van je telefoons en computers.

Twijfel je bij de aanschaf van een nieuwe omvormer? Vraag de installateur naar lokale monitoring of een open protocol (Modbus), zodat je niet vastzit aan de cloud van de fabrikant.

Vanaf hier: de onderbouwing per merk

De rest van dit stuk laat per merk zien hoe dit is vastgesteld, voor wie het wil controleren of navertellen. Eerst het totaalplaatje, dan Growatt en Solis apart.

Een Growatt-omvormer is binnenin eigenlijk twee computers. Een besturingsbord (een ARM-chip uit de bekende STM32-familie) regelt het scherm, de knoppen en de logica, en een aparte vermogens-DSP (een Texas Instruments C2000) stuurt de eigenlijke omzetting van zonnestroom. Van beide is de firmware publiek te vinden, en, belangrijk, niet versleuteld, dus volledig te bestuderen. In geen van beide staat een internetadres.

Alle connectiviteit zit namelijk in de losse wifi-dongle, de ShineWiFi-X, die via een kabeltje aan de omvormer hangt. Dat is precies waarom je hem eruit kunt trekken zonder je opwek te raken: de dongle is een aanhangsel, geen onderdeel van de stroomopwekking.

Wat er precies verstuurd wordt technisch

Omdat zowel de firmware als het netwerkverkeer leesbaar zijn, kon ik het Growatt-protocol volledig ontcijferen. Eén bericht bevat 50 meetwaarden, byte-exact gevalideerd tegen de firmware. Dit is de data die elke vijf minuten je huis verlaat. Niet-technische lezers mogen de tabel overslaan; de kern staat hierboven.

Waar het heen gaat

De verbinding is een open boek

De dongle opent een vaste verbinding naar server.growatt.com op TCP 5279 en stuurt elke vijf minuten een datapakket, met elke drie minuten een levensteken. Een paar dingen vielen daarbij op:

• De pakketten zijn niet echt versleuteld. Vanaf de negende byte worden ze ge-XOR'd met de vaste tekst Growatt. XOR is een omkeerbare versluiering, geen slot; wie het sleutelwoord kent leest alles, en dat woord staat in elk hobby-project online.
• Daardoor kan iedereen op het netwerkpad meelezen, niet alleen de fabrikant: een gast op je wifi, je provider, of wie het verkeer onderweg aftapt.
• De dongle pint de hostnaam server.growatt.com. Dat is lastig voor de fabrikant om te omzeilen, maar juist handig voor jou: met een simpele naam-omleiding vang je het verkeer lokaal op, zonder cloud-account. Zo werkt ook optie 2 hierboven (grott).

De jurisdictie

De maker, Shenzhen Growatt, is een Chinees bedrijf en valt onder Chinees recht. De servers staan op Alibaba Cloud, verspreid over een internationale regio (met een Duitse tag), de VS en China. In de privacyverklaring staat bovendien expliciet dat je data verwerkt en benaderd mag worden vanuit andere regio's. Anders dan Solis maakt Growatt geen specifieke EU-opslagbelofte.

De app: ShinePhone

ShinePhone is een klassieke Android-app van Shenzhen Growatt met 40 permissions, waaronder locatie, camera en telefoonstatus. In de app staan tientallen vaste Growatt-adressen hardgecodeerd (energy, server, server-cn, oss, cdn, evcharge en meer, allemaal op growatt.com), naast een rij externe SDK's. Het punt is niet hun herkomst, maar dat ze meekijken zonder dat je het merkt of er gericht toestemming voor gaf.

Bij Solis zit de internetverbinding in de S3 wifi-stick, een apart kastje dat je in de omvormer prikt. Ook hier geldt: de stick is een aanhangsel, de omvormer werkt zonder. Maar het kastje is technisch een volwaardige computer. In het hart zit een MXCHIP EMW3080-chip (een variant van de Realtek RTL8710) met 8 megabyte geheugen, die het Chinese besturingssysteem AliOS draait, dezelfde familie die Alibaba voor zijn slimme apparaten gebruikt.

Anders dan bij Growatt is er geen publieke firmware van die stick. Deze analyse komt daarom uit twee bronnen: het reverse-engineering-werk van de hobbyscene aan de AliOS-firmware, en de configuratiepagina die de stick zelf serveert en die ik wel kon uitlezen. Dat verklaart waarom dit hoofdstuk de bedrading anders aanvliegt dan dat van Growatt: bij Growatt kon ik de leiding zelf openleggen, bij Solis lees ik mee langs de randen.

Wat de stick meet technisch

De stick leest de omvormer uit over een industriestandaard (Modbus) en stuurt dat door. De reverse-engineering heeft die registerkaart gedocumenteerd, dus we weten welke waarden beschikbaar zijn, ook al is de verzending versleuteld. Het is dezelfde soort data als bij Growatt, inclusief de velden die je aanwezigheid verraden: huishoudelijk verbruik, batterijvermogen en laadtoestand.

Waar het heen gaat

De stick stuurt zijn metingen via MQTT over TLS naar Alibaba's IoT-platform. In tegenstelling tot Growatt is dit verkeer wel versleuteld onderweg, wat een echt pluspunt is. Maar de stick zoekt servernamen op via een vast ingebouwde Chinese DNS (public1/2.alidns.com), en de geanalyseerde firmware koos een dataserver in Shanghai. De opslag staat in Frankfurt, het verkeer en de naamopzoeking lopen via China.

De stick zelf is een open kastje

De wifi-stick draait een kleine webserver voor de installatie, bereikbaar op een vast adres (10.10.100.254). Daar vielen een paar dingen op die de moeite waard zijn:

• Een vast standaardwachtwoord (123456789) staat letterlijk in de pagina, voor iedereen die fysiek of via wifi bij het kastje kan.
• Een instelling om de meetdata naar een zelfgekozen extra server door te sturen. Handig voor wie het naar zichzelf wil sturen, maar ook een doorgeefluik dat standaard naar de fabrikant wijst.
• Een aparte Nederland-specifieke installatiestap in de paginastructuur, wat laat zien dat de NL-markt expliciet wordt bediend.

De jurisdictie-spanning

Solis stelt dat klantdata in een ISO 27001-datacenter in Frankfurt staat, conform de AVG, en Alibaba Frankfurt is inderdaad aantoonbaar in gebruik. Tegelijk loopt de naam-opzoeking via Alibaba China en koos de geanalyseerde firmware een broker in Shanghai. De data in rust kan dus in de EU staan terwijl de besturings- en naamopzoeklaag China raakt. Bovendien valt de exploitant, Ginlong, onder Chinees recht. Of dat voor jou een probleem is, mag je zelf wegen; het punt is dat die keuze nu impliciet voor je gemaakt wordt.

De app: SolisCloud

SolisCloud is geen gewone app maar een hybride schil gebouwd op het mobiele platform van Ant (Alipay), het betaalconcern van Alibaba. Dat het op Ant draait is geen vermoeden: in de app zit een configuratiebestand met een Alipay-app-identificatie (ALIPUBBE6BD07051653). De app vraagt 34 permissions, waaronder locatie, camera en de microfoon, en draagt AI-modellen aan boord voor beeld- en spraakherkenning. Dat is veel toegang voor een app die alleen je zonnepanelen hoort te tonen. In de app staan bovendien vaste server-adressen hardgecodeerd, waaronder een in Shanghai (47.102.211.126).

Growatt of Solis: wat is beter?

Kort gezegd: geen van beide is veilig uit zichzelf, en ze schuiven de afweging op verschillende plekken weg. Solis versleutelt het verkeer onderweg, een echt pluspunt, maar is geslotener en de app graait meer. Growatt is transparanter en volledig te controleren, maar verstuurt onversleuteld en doet geen EU-belofte. Voor jou maakt het verschil minder uit dan je zou denken: de oplossing is voor beide hetzelfde, namelijk de stick eruit of lokaal monitoren.

De Nederlandse context

Tot zover de techniek. Maar hoe groot is dit eigenlijk in Nederland, en doet er iemand iets aan? Dit deel zet de bevindingen in de bredere context, met een eerlijke scheiding tussen wat hard is en wat schatting blijft.

Hoe groot is dit hier?

De installatiebasis is enorm. De officiele cijfers van CBS en Netbeheer Nederland:

Growatt en Solis zijn geen niche-merken. In de onafhankelijke mondiale ranglijst over 2024 (Wood Mackenzie) staat Solis op plek 3 en Growatt op plek 4; negen van de tien grootste omvormerleveranciers ter wereld zijn Chinees, en de particuliere markt is hun kernsegment, precies het segment dat in Nederland zo groot is.

Toch is het eerlijke antwoord op "hoeveel staan er in Nederland": niemand weet het precies, ook de overheid niet. Er bestaat geen register dat omvormers naar merk telt. Marktmodellen schatten het gezamenlijke aandeel van Growatt, GoodWe en Solis op 20 tot 25 procent, maar dat zijn gemodelleerde cijfers, geen tellingen. Een ruwe ordegrootte-reconstructie uit installatiebasis maal geschat marktaandeel komt uit op enkele honderdduizenden tot ruim een half miljoen Growatt- en Solis-omvormers bij huishoudens. Behandel dat als bandbreedte, niet als meting.

De overheid noemt dit een nationaal-veiligheidsdossier

Het Nederlandse overheidsoptreden rond Chinese omvormers loopt al sinds 2022, en het bevestigt precies de risico's uit dit stuk, vooral het risico dat iemand op afstand kan ingrijpen.

De RDI-uitkomst is veelzeggend: van de negen geteste omvormers voldeed geen enkele aan de norm, en ze waren op afstand uit te schakelen of in te zetten voor aanvallen. Een Nederlandse ethische hacker toonde aan miljoenen systemen te kunnen overnemen. En op de directe vraag hoeveel Chinese omvormers er in Nederland staan, antwoordt het kabinet dat dat niet kan worden vastgesteld. Litouwen heeft inmiddels het gebruik boven een bepaalde capaciteit verboden.

Wat de nieuwe regels gaan eisen

Er komt regelgeving aan die precies dit adresseert:

• RED 3.3 (Radio Equipment Directive) stelt cybersecurity als markttoegangseis voor draadloos verbonden apparaten; omvormers vallen hieronder.
• Cyber Resilience Act stelt eisen aan de omvormer en de app en de clouddienst. De gegevensverwerking op afstand moet beschreven staan, en de toezichthouder kan toegang tot het cloudplatform vorderen.
• NIS2 geeft meer energiebedrijven meld- en zorgplichten, inclusief toeleveranciersrisico.

Precies het type bevinding uit dit onderzoek (onversleutelde verzending bij Growatt, cloud op Alibaba, DNS en broker die China raken) kan onder die regels straks markttoegang blokkeren. De ongemakkelijke kanttekening: het bestaande geinstalleerde bestand valt er grotendeels buiten. Die omvormers staan al op het dak, en blijven daar.

Hoe hard is elke laag? verantwoording