Resumen de la publicación
Esta semana el lado defensor movió fichas estructurales: Chrome empezó a desplegar para todos sus usuarios las Device Bound Session Credentials (credenciales de sesión atadas al hardware que vuelven inútiles las cookies robadas), Google reportó que bloquea 7.000 millones de notificaciones abusivas por día en Android, y ShieldFont propuso envenenar el texto que leen los scrapers de IA sin tocar lo que ve el humano.
Las tres comparten una misma filosofía: la seguridad mejora cuando la defensa se mete en la arquitectura, no cuando le pide al usuario que se cuide más. En este artículo analizo qué tienen en común y qué pueden copiar de ese enfoque los equipos argentinos que desarrollan y operan sistemas.
Si seguís las noticias de seguridad (acá en el MUG venimos cubriendo brechas, ransomware y paquetes troyanizados casi todas las semanas), es fácil quedarse con la sensación de que la defensa siempre corre de atrás.
Pero esta semana me dejó tres señales de lo contrario, y me parece importante frenar y mirarlas juntas. No son parches: son cambios de arquitectura.
El token que no se puede robar
La primera señal es la que más me entusiasma: Chrome empezó a desplegar para todos sus usuarios las Device Bound Session Credentials (DBSC), credenciales de sesión atadas al dispositivo.
Para entender por qué importa hay que entender el problema. Cuando iniciás sesión en un sitio, el navegador guarda una cookie de sesión: un archivito que le dice al servidor «este ya se autenticó, dejalo pasar».
Los infostealers (programas maliciosos que roban información de la máquina infectada) se especializan en copiar esas cookies. Con la cookie en la mano, el atacante entra a tu cuenta desde su propia máquina sin necesitar tu contraseña y sin que el segundo factor de autenticación lo frene, porque para el servidor «ya estás logueado».
Es uno de los vectores más usados hoy para el robo de cuentas, y familias como LummaC2 lo industrializaron.
DBSC ataca el problema de raíz. En vez de una cookie de larga vida que cualquiera puede copiar, la sesión queda atada a un par de claves criptográficas que se generan y se guardan en el hardware del equipo:
- En Windows, la clave privada vive en el TPM (el chip de seguridad de la motherboard) y no se puede exportar.
- En Mac, cumple ese rol el Secure Enclave.
- Las cookies pasan a ser de corta duración, y para renovarlas Chrome tiene que demostrar que sigue teniendo la clave privada, firmando un desafío del servidor.
El resultado es que el atacante puede robar la cookie igual que antes, pero le sirve de poco: expira enseguida y él no puede renovarla, porque la clave nunca salió de tu chip.
Google lo había lanzado en abril para Windows, y esta semana arrancó la expansión al público general (Chrome 147 en Windows y 150 en Mac, de forma gradual). En las cuentas de Workspace ya viene activado por defecto, y los sitios pueden adherir mediante una API abierta que se está estandarizando en el W3C con participación de Microsoft y Okta.
La honestidad del anuncio también me gustó: Google admite que el software solo no puede impedir que un malware con acceso a la máquina lea archivos y memoria. Por eso movieron el secreto a un lugar donde el software no llega.
7.000 millones de molestias menos por día
La segunda señal parece menor pero no lo es. Google reportó que sus sistemas contra el abuso de notificaciones redujeron en más de 7.000 millones por día las notificaciones no deseadas en Chrome para Android durante el primer trimestre de 2026.
Las notificaciones web abusivas son hoy un canal enorme de estafas, phishing y distribución de malware: el sitio te pide permiso una vez y después te bombardea con «tu equipo está infectado» o premios falsos.
Lo interesante es cómo lo atacaron. Google lo describe como un modelo de «queso suizo»: capas superpuestas donde, si el abuso pasa por un agujero de una capa, lo agarra la siguiente.
- Chrome revoca solo los permisos de notificación de sitios que no visitás hace tiempo o que disparan alertas de actividad sospechosa, y te lo muestra en el Safety Hub.
- Analiza el comportamiento coordinado entre redes de sitios relacionados, para revocar permisos de manera proactiva a los grupos que distribuyen contenido malicioso.
- A los sitios clasificados como disruptivos les limita el envío a 1.000 mensajes por minuto, y el excedente recibe un error HTTP 429.
Fijate el patrón: en ningún momento la solución es «educá al usuario para que no acepte notificaciones». La plataforma asume que el permiso mal dado va a existir, y limpia sola.
ShieldFont: envenenar el texto que lee la máquina
La tercera señal viene de un rincón inesperado: la tipografía. ShieldFont es una fuente creada por los diseñadores Isaque Seneda y Gabriel Abrucio, con apoyo de la fundidora tipográfica Playtype, para defenderse de los scrapers de IA (los programas que recorren la web recolectando contenido para entrenar modelos sin permiso del autor).
El truco es elegante. Un paso previo de compilación reemplaza palabras del HTML por señuelos, y la fuente usa las reglas de sustitución de OpenType (las mismas que unen «f» e «i» en una ligadura) para que en pantalla se vea el texto original.
El humano lee lo que el autor escribió. El scraper, que solo levanta los bytes del HTML, se lleva una versión fluida pero incorrecta de la página.
Según el white paper que publicaron a fines de julio, más del 90% de las páginas protegidas terminan descartadas por los filtros automáticos de calidad de los pipelines de entrenamiento. Los propios autores aclaran que no es irrompible: un scraper decidido puede renderizar la página o invertir el mapeo de la fuente.
Y tiene costos reales: los buscadores indexan el señuelo (Googlebot recibe los mismos bytes que el scraper) y los lectores de pantalla sufren. Aun así, la idea me parece valiosa como símbolo: la defensa del contenido metida en el propio formato del contenido, no en un cartelito de «prohibido scrapear» que nadie respeta.
El patrón común: la defensa se mete en la arquitectura
Las tres noticias son distintas en escala y madurez, pero comparten una filosofía que vengo defendiendo hace años: la seguridad que funciona es la que no depende de que el usuario se porte bien.
Durante dos décadas le pedimos a la gente que use contraseñas largas, que no haga clic en links raros, que revise el candadito. El resultado está en cualquier informe de brechas: el eslabón humano sigue fallando, porque pedirle atención infinita a una persona no escala.
El enfoque que sí escala es cambiar la arquitectura para que el ataque deje de tener sentido:
- DBSC no le enseña al usuario a evitar infostealers: hace que la cookie robada no valga nada.
- El sistema de notificaciones no le pide criterio al usuario: revoca y limita solo, por comportamiento observado.
- ShieldFont no le ruega al scraper que respete el robots.txt: hace que lo scrapeado sea basura.
Es la misma lógica que hizo que las passkeys (llaves de acceso que reemplazan a la contraseña con criptografía atada al dispositivo) avancen donde veinte años de campañas de concientización fracasaron. El secreto que no se puede escribir en un phishing no se phishea.
Qué podemos copiar desde Argentina
Nada de esto es exclusivo de Google. La filosofía se puede aplicar en cualquier equipo de acá, con presupuesto normal, en decisiones concretas:
- Si tu aplicación maneja sesiones, acortá la vida de los tokens y empezá a seguir la especificación de DBSC del lado del servidor: la API ya está publicada y tus usuarios de Chrome la van a tener activada.
- Adoptá passkeys o al menos MFA resistente a phishing en todo lo interno, antes que otra campaña de «no hagas clic».
- Donde hoy tenés un procedimiento que depende de que alguien se acuerde de hacer algo (rotar una credencial, revocar un acceso), convertilo en un default automático que se revoca solo.
- Medí la defensa como la mide Google: no por capacitaciones dictadas, sino por ataques que dejaron de ser posibles.
La pregunta que me hago (y te dejo) es simple: de los controles de seguridad que tenés hoy en producción, ¿cuántos dependen de que una persona se comporte bien todos los días, y cuántos seguirían funcionando aunque esa persona tenga su peor día?
Si la respuesta te incomoda, esta semana te regaló tres ideas para empezar a darla vuelta. Te leo en los comentarios.
