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.
| Veld in de upload | Wat het is | Grootte | Bewijs |
|---|---|---|---|
| photoFile | DG2, de pasfoto uit de chip, JPEG2000 | 14.869 byte | vastgesteld, payload |
| dataGroup1 | de volledige ruwe machineleesbare zone (MRZ) | 93 byte | vastgesteld, payload |
| efSodFile | het Document Security Object, de digitale handtekening van het document | 2.664 byte | vastgesteld, payload |
| deviceId, publicKey, appBundleId | device-binding | - | vastgesteld, payload |
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.