Je scant je paspoort om naar de wedstrijd te kunnen. Dat is de belofte van Persoonlijke Digitale Toegang. Ik heb de PEC Zwolle App uit elkaar gehaald, het netwerkverkeer afgevangen op een emulator, en de identiteit-flow gemeten op een echt toestel met een echt paspoort. Wat ik vond: de gevoelige kanalen zijn netjes beveiligd, maar de telemetrie naar Google vuurt al voor je iets aanraakt en zonder toestemming, en dezelfde app draait als sjabloon bij meerdere clubs. Je identiteit blijft niet op je toestel.
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.
| Wat er weggaat | Naar wie | Bewijs |
|---|---|---|
| Firebase Installation ID, app-instance-id, model, taal, open_app-event | Google, VS | vastgesteld, veld gelezen |
| Crashlytics device-instance-id, sessie | Google, VS | vastgesteld |
| Foutrapportage | Sentry, VS | vastgesteld, endpoint |
| Identiteit-upload bij registratie | Siip, EU | afgeleid, kanaal gepind |
| Naam, leeftijd, pasfoto, e-mail als profiel | Siip, EU | vastgesteld op scherm |
| Bezoekerskoppeling identiteit aan ticket | Siip naar club | afgeleid, kanaal gepind |
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
- Weiger de notificatietoestemming als je die niet nodig hebt. De tracking staat daar los van, maar het scheelt.
- Reset regelmatig je advertising-ID via de Android-instellingen onder Privacy en advertenties.
- Zet de app-toestemming voor de reclame-ID uit als je die niet gebruikt.
- 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.
- 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/