cside copreside la seguridad antifraude del navegador en W3C
El fraude ocurre cada vez más dentro de la sesión del navegador. Credential stuffing, account takeover, tráfico publicitario inválido, carding con bots, scraping, engagement falso y abuso automatizado dependen de lo que la plataforma web permite hacer a un cliente.
Lo difícil no es nombrar los ataques. Lo difícil es detenerlos sin convertir el navegador en una capa de vigilancia ni obligar a cada usuario legítimo a pasar por CAPTCHAs repetidos.
La IA está cambiando rápidamente el panorama del fraude. Los atacantes pueden generar comportamiento de cuenta convincente, automatizar flujos del navegador, coordinar abuso lento y distribuido, y adaptarse más rápido que las reglas estáticas. Los defensores necesitan señales del navegador que sigan ese ritmo sin convertir a cada usuario en un perfil rastreable.
Por eso Simon Wijckmans es ahora copresidente del W3C Anti-Fraud Community Group (AFCG), representando a cside junto con Sam Schlesinger de Google y la comunidad más amplia que trabaja en este problema de forma pública.
Qué hace el W3C Anti-Fraud Community Group
El AFCG existe para identificar brechas en la plataforma web que permiten fraude y tráfico no deseado. Su trabajo se centra en funciones y APIs del navegador que puedan abordar esos escenarios mientras mejoran la seguridad, la privacidad y la accesibilidad del usuario.
El grupo es abierto. Pueden participar proveedores de navegadores, proveedores antifraude, defensores de la privacidad, desarrolladores web, proveedores cloud y operadores de servicios que reciben tráfico no deseado. El trabajo técnico ocurre en público, principalmente en los repositorios de propuestas y casos de uso del AFCG.
Ese modelo público importa. El trabajo antifraude falla cuando se convierte en una carrera privada entre rastreadores y atacantes. Los estándares del navegador necesitan un listón más alto: capacidades precisas, límites de privacidad, límites de accesibilidad y revisión de personas que no siempre están de acuerdo.
Por qué la seguridad del navegador necesita primitivas antifraude
El repositorio de casos de uso del AFCG muestra la superficie de amenaza con claridad. Incluye fraude en creación de cuentas, account takeover, credential cracking, credential stuffing, phishing, robo de tokens, tráfico inválido en publicidad, fraude ecommerce, carding, card cracking, cashing out, abuso de promociones, scraping, spam, engagement falso, denegación de servicio y acceso no autorizado.
Esto no está separado de la seguridad del navegador. Es seguridad del navegador.
La mayoría de defensas antifraude actuales dependen de una mezcla de señales frágiles:
- Reputación IP que se rompe con proxies, VPNs y CGNAT
- Fingerprints de dispositivo que crean problemas de rastreo y consentimiento
- CAPTCHAs que trasladan coste a usuarios reales y equipos de accesibilidad
- Límites de tasa del lado del servidor que no ven lo ocurrido en el navegador
- Retos antibot que bloquean automatización legítima y navegación asistida
La plataforma web necesita mejores primitivas. Una buena primitiva debe responder a una pregunta estrecha sin revelar más de lo necesario. Debe ayudar a un sitio a defender un flujo sensible sin permitir que ese sitio siga al usuario por toda la web.
Ese equilibrio importa. Las señales antifraude deben ser lo bastante fuertes para detener el abuso, pero lo bastante limitadas para no convertirse en nuevos sistemas de rastreo. Las pruebas de conocimiento cero y la inferencia en el dispositivo hacen posibles nuevos diseños: el navegador puede demostrar un hecho acotado o clasificar comportamiento de riesgo localmente sin exponer identificadores sin procesar, historial de navegación o fingerprints de dispositivo a cada sitio.
Propuestas activas que merece la pena seguir
Varias propuestas e hilos de discusión muestran hacia dónde avanza el trabajo.
Private Access Control Tokens
Private Access Control Tokens (PACT) es uno de los trabajos recientes más importantes. El issue se abrió el 2025-12-02 como una declaración conjunta del problema de Dennis Jackson, Sam Schlesinger y Eric Trouton.
PACT explora un mecanismo web que pueda reducir la fricción de los CAPTCHAs y permitir que los sitios apliquen límites de tasa contra tráfico no deseado de alto volumen. El objetivo de diseño es explícito: preservar la privacidad, evitar el rastreo entre sesiones y no excluir a usuarios por hardware, plataforma o user agent.
La propuesta también importa para el control de acceso. Un usuario puede necesitar demostrar que tiene una cuenta válida y en buen estado sin revelar a qué recursos está accediendo. Eso se vuelve más importante a medida que agentes locales de IA en el navegador actúan en nombre de usuarios y activan señales de automatización que muchos sitios bloquean hoy.
Private State Tokens
Private State Tokens nació del trabajo de Trust Token API. El concepto permite que un emisor entregue tokens criptográficos al navegador cuando confía en un usuario, y que esos tokens se canjeen más tarde en otro contexto sin exponer un identificador estable entre sitios.
Ese tipo de mecanismo es fundacional para señales de confianza que preservan la privacidad. No resuelve todos los escenarios de abuso, pero apunta en la dirección correcta: transmitir una señal acotada, mantener los tokens sin procesar fuera de JavaScript y evitar dar a los sitios un nuevo identificador de rastreo.
Device Integrity Attestation
La discusión sobre Device Integrity Attestation recoge casos de uso y requisitos para señales de alta fidelidad y baja entropía sobre la integridad del dispositivo. El objetivo es ayudar a distinguir entornos legítimos de entornos emulados, rooteados o falsificados usados en abuso.
Es un trabajo delicado. Las señales de integridad pueden mejorar la defensa, pero también pueden excluir usuarios con dispositivos antiguos, sistemas operativos alternativos o configuraciones que preservan la privacidad. Por eso este trabajo pertenece a un foro abierto de estándares y no debe tratarse como una función privada de proveedor.
Por qué esto importa para el trabajo de cside
cside trabaja en la capa del navegador. Monitorizamos qué scripts se ejecutan, qué cargan, cómo cambian y cómo el comportamiento del lado del navegador afecta a seguridad, privacidad, fraude y cumplimiento.
Esa visión operativa encaja con la misión del AFCG. Los equipos antifraude necesitan señales lo bastante precisas para actuar. Los equipos de privacidad necesitan que esas señales no se conviertan en nuevos identificadores. Los equipos de seguridad necesitan visibilidad a nivel de navegador porque los logs del servidor pierden el código que se ejecuta en la máquina del usuario.
El trabajo de estándares no sustituirá la seguridad del navegador en runtime. Puede hacer que la plataforma subyacente sea más segura y dar a los defensores mejores herramientas que fingerprinting, rastreo y retos bruscos.
Gracias a Sam Schlesinger y Google
Este trabajo depende de personas que se presentan, escriben propuestas, aceptan revisión y mantienen a la vista tradeoffs difíciles. Quiero agradecer a Sam Schlesinger y al equipo de Google la oportunidad de ayudar a liderar este trabajo juntos.
El trabajo de Sam en protocolos que preservan la privacidad, PACT y Private State Tokens ha marcado la dirección técnica del AFCG. Esa profundidad importa porque los estándares antifraude deben resistir tanto la presión de atacantes como la revisión de privacidad.
Este papel es una extensión natural del trabajo previo de cside en el W3C. Desde que nos unimos al W3C Web Application Security Working Group en 2024, hemos impulsado un modelo de seguridad del navegador más fuerte. El AFCG nos da otro lugar para llevar evidencia práctica de runtime al proceso de estándares.
Cómo participar
El AFCG está abierto a la participación. Si tu equipo trabaja en fraude, seguridad del navegador, señales que preservan la privacidad, infraestructura cloud, agentes de IA, pagos, integridad publicitaria o prevención de abuso, el grupo necesita practicantes que entiendan la realidad operativa.
Empieza por la página del grupo W3C y los repositorios públicos de GitHub de casos de uso y propuestas. Lee los issues abiertos. Añade casos de uso concretos. Cuestiona supuestos débiles. Trae pronto las restricciones de implementación.
El navegador evoluciona rápido. Los estándares que gobiernan la seguridad del navegador y las señales antifraude deben mantener el ritmo.
A fecha de 2026-05-12, las propuestas del AFCG siguen siendo discusiones públicas activas. El estado de implementación, el soporte de navegadores y los destinos de estandarización pueden cambiar.
