cside is medevoorzitter van W3C-werk aan antifraude en browsersecurity

Fraude gebeurt steeds vaker in de browsersessie. Credential stuffing, account takeover, invalid advertising traffic, botgedreven carding, scraping, fake engagement en geautomatiseerd misbruik hangen allemaal af van wat het webplatform een client laat doen.

De moeilijke vraag is niet hoe we de aanvallen noemen. De moeilijke vraag is hoe we ze stoppen zonder de browser in een surveillancelaag te veranderen of elke legitieme gebruiker door herhaalde CAPTCHA's te sturen.

AI verandert het fraudelandschap snel. Aanvallers kunnen geloofwaardig accountgedrag genereren, browserflows automatiseren, langzaam en verspreid misbruik coördineren, en sneller aanpassen dan statische regels. Verdedigers hebben browsersignalen nodig die dat tempo volgen zonder elke gebruiker in een traceerbaar profiel te veranderen.

Daarom is Simon Wijckmans nu medevoorzitter van de W3C Anti-Fraud Community Group (AFCG), waar hij cside vertegenwoordigt naast Sam Schlesinger van Google en de bredere community die publiek aan dit probleem werkt.

Wat de W3C Anti-Fraud Community Group doet

De AFCG bestaat om gaten in het webplatform te identificeren die fraude en ongewenst verkeer mogelijk maken. Het werk draait om browserfuncties en APIs die die scenario's aanpakken en tegelijk security, privacy en toegankelijkheid voor gebruikers verbeteren.

De groep is open. Browserleveranciers, antifraudeproviders, privacyvoorstanders, webontwikkelaars, cloudproviders en operators van diensten die ongewenst verkeer ontvangen kunnen deelnemen. Het technische werk gebeurt publiek, vooral in de AFCG-repositories voor voorstellen en use cases.

Dat publieke model is belangrijk. Antifraudewerk faalt wanneer het een private wapenwedloop tussen trackers en aanvallers wordt. Browserstandaarden hebben een hogere lat nodig: precieze capabilities, privacygrenzen, toegankelijkheidsgrenzen en review door mensen die het niet altijd met elkaar eens zijn.

Waarom browsersecurity antifraude-primitieven nodig heeft

De use cases-repository van de AFCG beschrijft het dreigingsoppervlak duidelijk. Het omvat account creation fraud, account takeover, credential cracking, credential stuffing, phishing, tokendiefstal, invalid traffic in advertenties, ecommercefraude, carding, card cracking, cashing out, promotie-misbruik, scraping, spam, fake engagement, denial of service en ongeautoriseerde toegang.

Dit staat niet los van browsersecurity. Dit is browsersecurity.

De meeste antifraudeverdediging van vandaag steunt op een mix van kwetsbare signalen:

• IP-reputatie die breekt bij proxies, VPNs en carrier-grade NAT
• Device fingerprints die tracking- en toestemmingsproblemen maken
• CAPTCHA's die kosten verschuiven naar echte gebruikers en toegankelijkheidsteams
• Server-side rate limits die niet zien wat in de browser gebeurde
• Botuitdagingen die legitieme automatisering en begeleid browsen blokkeren

Het webplatform heeft betere primitieven nodig. Een goede primitieve beantwoordt een smalle vraag zonder meer te onthullen dan nodig is. Ze helpt een site een gevoelige flow te verdedigen zonder die site de gebruiker over het web te laten volgen.

Die balans is belangrijk. Antifraudesignalen moeten sterk genoeg zijn om misbruik te stoppen, maar begrensd genoeg om geen nieuwe trackingsystemen te worden. Zero-knowledge proofs en on-device inference maken nieuwe ontwerpen mogelijk: de browser kan een begrensd feit bewijzen of risicovol gedrag lokaal classificeren zonder ruwe identifiers, browsegeschiedenis of device fingerprints aan elke site bloot te stellen.

Actieve voorstellen om te volgen

Verschillende voorstellen en discussies laten zien waar het werk naartoe gaat.

Private Access Control Tokens

Private Access Control Tokens (PACT) is een van de belangrijkste recente werkitems. De issue werd geopend op 2025-12-02 als gezamenlijke probleemstelling van Dennis Jackson, Sam Schlesinger en Eric Trouton.

PACT onderzoekt een webmechanisme dat CAPTCHA-frictie kan verminderen en websites rate limits kan laten afdwingen tegen grootschalig ongewenst verkeer. Het ontwerpdoel is expliciet: privacy bewaren, tracking tussen sessies vermijden en gebruikers niet uitsluiten op basis van hardware, platform of user agent.

Het voorstel is ook belangrijk voor access control. Een gebruiker moet soms bewijzen dat hij een geldig account met goede status heeft, zonder te onthullen welke resources hij opent. Dat wordt belangrijker nu lokale browser-AI-agenten namens gebruikers handelen en automatiseringssignalen veroorzaken die veel sites vandaag blokkeren.

Private State Tokens

Private State Tokens komt voort uit het Trust Token API-werk. Het concept laat een issuer cryptografische tokens aan een browser geven wanneer een gebruiker vertrouwd wordt, en laat die tokens later in een andere context inwisselen zonder een stabiele cross-site identifier bloot te leggen.

Zo'n mechanisme is fundamenteel voor privacyvriendelijke vertrouwenssignalen. Het lost niet elk misbruikscenario op, maar wijst in de juiste richting: geef een begrensd signaal door, houd ruwe tokens weg uit JavaScript en geef sites geen nieuw trackinghandvat.

Device Integrity Attestation

De discussie rond Device Integrity Attestation verzamelt use cases en requirements voor high-fidelity, low-entropy signalen over device-integriteit. Het doel is om legitieme omgevingen te onderscheiden van geëmuleerde, rooted of vervalste omgevingen die bij misbruik worden gebruikt.

Dit is gevoelig werk. Integriteitssignalen kunnen verdediging verbeteren, maar ze kunnen ook gebruikers uitsluiten op oudere devices, alternatieve besturingssystemen of privacyvriendelijke setups. Juist daarom hoort dit werk in een open standaardenforum, niet als private vendorfeature.

Waarom dit belangrijk is voor cside

cside werkt op de browserlaag. We monitoren welke scripts draaien, wat ze laden, hoe ze veranderen en hoe browsergedrag security, privacy, fraude en compliance beïnvloedt.

Die operationele blik past bij de missie van de AFCG. Fraudeteams hebben signalen nodig die precies genoeg zijn om op te handelen. Privacyteams hebben nodig dat die signalen geen nieuwe identifiers worden. Securityteams hebben zichtbaarheid op browserniveau nodig, omdat serverlogs de code missen die op de machine van de gebruiker draait.

Standaardenwerk vervangt runtime browsersecurity niet. Het kan het onderliggende platform veiliger maken en verdedigers betere tools geven dan fingerprinting, tracking en grove uitdagingen.

Dank aan Sam Schlesinger en Google

Dit werk hangt af van mensen die komen opdagen, voorstellen schrijven, review accepteren en moeilijke tradeoffs zichtbaar houden. Ik wil Sam Schlesinger en het team van Google bedanken voor de kans om dit werk samen te helpen leiden.

Sams werk aan privacyvriendelijke protocollen, PACT en Private State Tokens heeft de technische richting van de AFCG gevormd. Die diepgang is belangrijk, want antifraudestandaarden moeten bestand zijn tegen zowel aanvallersdruk als privacyreview.

Deze rol is een natuurlijke uitbreiding van csides eerdere W3C-werk. Sinds onze toetreding tot de W3C Web Application Security Working Group in 2024 hebben we gepleit voor een sterker browsersecuritymodel. De AFCG geeft ons een extra plek om praktische runtime-evidence in het standaardenproces te brengen.

Hoe je kunt deelnemen

De AFCG staat open voor deelname. Als je team werkt aan fraude, browsersecurity, privacyvriendelijke signalen, cloudinfrastructuur, AI-agenten, betalingen, advertentie-integriteit of abusepreventie, heeft de groep mensen nodig die de operationele realiteit begrijpen.

Begin bij de W3C-groepspagina en de publieke GitHub-repositories voor use cases en voorstellen. Lees de open issues. Voeg concrete use cases toe. Daag zwakke aannames uit. Breng implementatiebeperkingen vroeg in.

De browser evolueert snel. De standaarden die browsersecurity en antifraudesignalen sturen moeten dat tempo volgen.

Per 2026-05-12 blijven AFCG-voorstellen actieve publieke discussies. Implementatiestatus, browserondersteuning en standaardenroutes kunnen veranderen.