TL;DR: browser anti-fraud standards work
- Open, not proprietary: Anti-fraud work does not belong behind a private vendor vault. Fraud fails in public review, which is why cside co-chairs the W3C Anti-Fraud Community Group with Google's Sam Schlesinger instead of shipping fingerprinting behind a login.
- Old signals fail: IP reputation breaks under CGNAT, fingerprints trip consent laws, and CAPTCHAs shift cost to real users. cside brings runtime browser evidence into open proposals like PACT (opened 2 December 2025) and Private State Tokens.
- Your call: If your fraud program still depends on device fingerprints, decide now whether you want to be part of the standards that replace them or a customer of whatever survives.
Short on time? See cside's in-browser Magecart and skimmer blocking. It covers everything below in one deployment.
Fraud increasingly happens inside the browser session. Credential stuffing, account takeover, invalid advertising traffic, bot-driven carding, scraping, fake engagement, and automated abuse all depend on what the web platform lets a client do.
Naming the attacks is the easy part. Stopping them, without turning the browser into a surveillance layer or forcing every legitimate user through repeated CAPTCHA challenges, is what's hard.
AI is changing fraud fast. Attackers can generate convincing account behavior, automate browser flows, coordinate low-and-slow abuse, and adapt faster than static rules. Defenders need browser signals that keep pace without turning every user into a trackable profile.
That is why Simon Wijckmans is now co-chair of the W3C Anti-Fraud Community Group (AFCG), representing cside alongside Sam Schlesinger from Google and the broader community working on this problem in public.
| Abuse pattern | Browser-session dependency | Why server logs miss context |
|---|---|---|
| Credential stuffing | Automated login attempts execute through real browser flows | Server logs see requests, not client behavior |
| Account takeover | Session behavior, scripts, and interaction patterns matter | Backend events miss runtime manipulation |
| Carding | Checkout automation happens inside browser sessions | Payment attempts lack browser-side evidence |
| Scraping | Automated clients mimic normal browsing | IP and request rate alone are weak signals |
| Fake engagement | AI agents generate plausible interaction flows | Engagement events do not prove human intent |
What the W3C Anti-Fraud Community Group does
The AFCG exists to identify gaps in the web platform that enable fraud and unwanted traffic. Its work focuses on browser features and APIs that can address those scenarios while improving user security, privacy, and accessibility.
The group is open. Browser vendors, anti-fraud providers, privacy advocates, web developers, cloud providers, and operators of services that receive unwanted traffic can participate. The technical work happens in public, mainly across the AFCG proposals and use cases repositories.
That public model matters. Anti-fraud work fails when it becomes a private arms race between trackers and attackers. Browser standards need a higher bar: precise capabilities, privacy constraints, accessibility constraints, and review from people who disagree with each other.
Why browser security needs anti-fraud primitives
The AFCG use cases repository lays out the threat surface clearly. It includes account creation fraud, account takeover, credential cracking, credential stuffing, phishing, token theft, invalid traffic in advertising, ecommerce fraud, carding, card cracking, cashing out, promotion abuse, scraping, spam, fake engagement, denial of service, and unauthorized access.
That threat list is browser security.
Most fraud defenses today rely on a mix of brittle signals:
- IP reputation that breaks under proxies, VPNs, and carrier-grade NAT
- Device fingerprints that create tracking and consent problems
- CAPTCHAs that shift cost to real users and accessibility teams
- Server-side rate limits that cannot see what happened in the browser
- Bot challenges that block legitimate automation and assisted browsing
| Current defense | What it helps with | Where it breaks | Better primitive needed |
|---|---|---|---|
| IP reputation | Blocks known bad infrastructure | Fails under proxies, VPNs, and carrier-grade NAT | Narrow browser trust signal |
| Device fingerprinting | Distinguishes repeated clients | Creates tracking and consent problems | Bounded, privacy-preserving proof |
| CAPTCHA | Adds friction to suspicious flows | Burdens legitimate users and accessibility teams | Low-friction abuse control |
| Server-side rate limits | Limits request volume | Cannot see browser runtime behavior | Client-aware rate-limiting primitive |
| Bot challenges | Filters obvious automation | Blocks legitimate automation and assisted browsing | Privacy-preserving automation signal |
The web platform needs better primitives. A good primitive should answer a narrow question without revealing more than necessary. It should help a site defend a sensitive flow without letting that site follow the user around the web.
That balance matters. Anti-fraud signals need to be strong enough to stop abuse, but constrained enough that they do not become new tracking systems. Zero-knowledge proofs and on-device inference make new designs possible: the browser can prove a bounded fact or classify risky behavior locally without exposing raw identifiers, browsing history, or device fingerprints to every site.
| Primitive or control | Privacy risk | Abuse resistance | Standards constraint |
|---|---|---|---|
| Server-side rate limits | Lower | Lower | Useful, but missing browser context |
| CAPTCHA | Low-medium (third-party data collection) | Medium | Must not become the default path for legitimate users |
| Raw device fingerprinting | Higher | High | Creates tracking and consent risk |
| Private State Tokens | Lower | Medium-high | Needs bounded trust signals and no stable cross-site identifier |
| Private Access Control Tokens | Lower | High | Needs privacy-preserving rate limits and access control |
| Device Integrity Attestation | Medium | High | Needs strong constraints to avoid exclusion and tracking |
Active proposals worth watching
Several proposals and discussion threads show where the work is heading.
Private Access Control Tokens
Private Access Control Tokens (PACT) is one of the most important recent work items. The issue was opened on 2025-12-02 as a joint problem statement from Dennis Jackson, Sam Schlesinger, and Eric Trouton.
PACT explores a web mechanism that can reduce CAPTCHA friction while allowing websites to enforce rate limits against high-volume unwanted traffic. The design goal is explicit: preserve privacy, avoid cross-session tracking, and avoid excluding users based on hardware, platform, or user agent.
The proposal also matters for access control. A user may need to prove they hold a valid account in good standing without revealing which resources they are accessing. That becomes more important as local browser AI agents act on behalf of users and trigger automation signals that many sites block today.
Private State Tokens
Private State Tokens grew out of the Trust Token API work. The concept is to let an issuer provide cryptographic tokens to a browser when a user is trusted, then let those tokens be redeemed later in another context without exposing a stable cross-site identifier.
That kind of mechanism is foundational for privacy-preserving trust signals. It does not solve every abuse scenario, but it conveys a bounded signal, keeps raw tokens away from JavaScript, and avoids giving sites a new tracking handle.
Device Integrity Attestation
The Device Integrity Attestation discussion captures use cases and requirements for high-fidelity, low-entropy signals about device integrity. The goal is to help distinguish legitimate environments from emulated, rooted, or spoofed environments used in abuse.
This is sensitive work. Integrity signals can improve defense, but they can also exclude users on older devices, alternative operating systems, or privacy-preserving setups. That is exactly why the work belongs in an open standards forum instead of being treated as a private vendor feature.
Why this matters for cside's work
cside works at the browser layer. We monitor what scripts execute, what they load, how they change, and how browser-side behavior affects security, privacy, fraud, and compliance.
That operational view lines up with the AFCG's mission. Fraud teams need signals accurate enough to act on, while privacy teams need those same signals to avoid becoming new identifiers. Security teams also need browser-level visibility, since server logs miss the code that runs on the user's machine.
Standards work will not replace runtime browser security. It can make the underlying platform safer and give defenders better tools than fingerprinting, tracking, and blunt challenges.
Thank you to Sam Schlesinger and Google
This work depends on people who show up, write proposals, accept review, and keep difficult tradeoffs in view. I want to thank Sam Schlesinger and the team at Google for the opportunity to help lead this work together.
Sam's work on privacy-preserving protocols, PACT, and Private State Tokens has shaped the AFCG's technical direction. That depth matters because anti-fraud standards need to survive both attacker pressure and privacy review.
This role is a natural extension of cside's earlier W3C work. Since joining the W3C Web Application Security Working Group in 2024, we have pushed for a stronger browser security model. The AFCG gives us another place to bring practical runtime evidence into the standards process.
How to get involved
The AFCG is open to participation. If your team works on fraud, browser security, privacy-preserving signals, cloud infrastructure, AI agents, payments, advertising integrity, or abuse prevention, the group needs practitioners who understand the operational reality.
Start with the W3C group page and the public GitHub repositories for use cases and proposals. Read the open issues. Add concrete use cases. Challenge weak assumptions. Bring implementation constraints early.
The browser is evolving quickly. The standards that govern browser security and anti-fraud signals need to keep pace.
As of 2026-05-12, AFCG proposals remain active public discussions. Implementation status, browser support, and standards-track destinations can change.
