cside Co-Chairs W3C Anti-Fraud Browser Security
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.
The hard part is not naming the attacks. The hard part is stopping them without turning the browser into a surveillance layer or forcing every legitimate user through repeated CAPTCHA challenges.
AI is rapidly changing the fraud landscape. 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.
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.
These are not separate from browser security. They are 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
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.
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 points in the right direction: convey a bounded signal, keep raw tokens away from JavaScript, and avoid 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 that are accurate enough to act on. Privacy teams need those signals to avoid becoming new identifiers. Security teams need browser-level visibility because 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.
