Chromium 148 y la huella del sistema

Chromium 148 metió un cambio que, a simple vista, parece de esos que solo interesan a quienes leen changelogs por deporte. Pero si trabajas en privacidad, anti-bot o defensa web, te conviene prestarle atención: una diferencia pequeña en la implementación de Math.tanh ahora puede servir para inferir el sistema operativo subyacente del navegador.

No estamos hablando de magia ni de una fuga obvia tipo “te roban el IP y listo”. El punto es más sutil: una función matemática que debería comportarse igual en todos lados termina mostrando variaciones medibles entre plataformas. Esas variaciones, combinadas con otras señales, amplían la superficie de fingerprinting. Y cuando una señal nueva se vuelve estable, los sistemas de rastreo y de detección también aprenden a usarla.

Qué cambió en Chromium 148

El hallazgo que motivó este tema parte de una observación concreta: desde Chromium 148, Math.tanh ya no se comporta de forma suficientemente uniforme como para ignorarlo en un fingerprint. En ciertas condiciones, la salida o el patrón de ejecución permite distinguir el sistema operativo subyacente con más confianza que antes.

La fuente original del análisis, publicada por Scrapfly, muestra que este cambio no es un bug aislado en una API exótica, sino una consecuencia de cómo el motor y el entorno de ejecución terminan exponiendo diferencias de plataforma. Si quieres revisar el enfoque técnico, puedes leer la publicación original en Scrapfly y contrastarla con la documentación de V8 y Chromium sobre el runtime de JavaScript y sus optimizaciones: https://scrapfly.dev/posts/browser-math-os-fingerprint/ y https://v8.dev/docs.

Lo relevante para ti no es memorizar el detalle interno de la implementación, sino entender el efecto práctico. Si una función estándar empieza a producir una señal consistente entre Windows, macOS y Linux, entonces ya no solo sirve para calcular un valor. También puede convertirse en un identificador auxiliar dentro de un perfil de navegador.

Por qué una función matemática termina siendo una señal

En teoría, Math.tanh recibe un número y devuelve otro número. En la práctica, la ejecución pasa por capas: motor JavaScript, optimizaciones, biblioteca matemática, instrucciones de CPU y particularidades del sistema operativo. Si una de esas capas introduce una diferencia medible, un actor con suficiente volumen de muestras puede usarla como pista.

Eso no significa que cualquier sitio vaya a deducir tu sistema operativo con una sola llamada. La idea funciona mejor cuando se combina con otras señales: navigator.platform, userAgent, diferencias de renderizado, timezone, WebGL, audio, fonts y comportamiento del canvas. El valor de Math.tanh es que suma una pieza más al rompecabezas.

Y ahí está el problema. El fingerprinting moderno no depende de una sola señal perfecta. Depende de muchas señales medianas. Si cada una aporta un poco, el conjunto termina siendo bastante preciso.

Qué significa “fingerprintable” en este contexto

Cuando decimos que algo es fingerprintable, no estamos diciendo que identifica por sí solo al usuario de forma única. Estamos diciendo que agrega entropía al perfil. En términos simples: ayuda a separar un grupo de navegadores en subgrupos más pequeños.

Para defensa web y anti-bot, eso puede ser útil. Para privacidad, es otro vector de seguimiento. Y para plataformas que dependen de la consistencia del navegador, como bancos, ecommerce o sistemas con fraude automatizado, también puede generar falsos positivos si el motor detecta una anomalía o si un bot intenta simular un entorno que no coincide del todo.

Cómo se convierte en una huella del sistema

La huella no nace de Math.tanh aislado. Nace del patrón. Un sitio puede ejecutar la función con varios valores, medir los resultados, observar microdiferencias y comparar ese comportamiento con perfiles ya conocidos. Si el resultado se agrupa con suficiente estabilidad por sistema operativo, la señal sirve.

En fingerprinting, la estabilidad importa más que la precisión absoluta. No necesitas que la señal sea perfecta para todos los usuarios. Necesitas que sea suficientemente consistente para separar poblaciones. Si en Windows el resultado tiende a un rango y en Linux a otro, ya tienes una pista operativa.

Además, las diferencias no siempre son visibles en la interfaz. A veces aparecen en el tiempo de ejecución, en el redondeo, en el manejo de casos extremos o en cómo el motor aprovecha instrucciones específicas de CPU. Es decir, no hace falta que el navegador “revele” el sistema operativo de forma explícita; basta con que lo deje filtrar por la implementación.

Señales directas y señales indirectas

Hay dos formas de pensar este problema. La primera es la señal directa: una API o función devuelve algo que varía entre sistemas. La segunda es la señal indirecta: la misma función devuelve un valor nominalmente igual, pero con suficiente ruido temporal o estadístico como para distinguir plataformas.

En la práctica, la segunda suele ser más útil para fingerprinting real. Un actor puede tomar cientos o miles de muestras, calcular medias, varianzas o patrones de respuesta, y usar eso como input de modelos de clasificación. No necesitas un valor único; necesitas un comportamiento reproducible.

Eso es lo que vuelve delicado este tipo de hallazgo. Una corrección pequeña en el runtime o una optimización de bajo nivel pueden cambiar la calidad de la señal sin que el usuario final note nada.

Ejemplo práctico de correlación

Imagina una página que recolecta 10 señales del navegador. Ocho son comunes: user agent, timezone, idioma, tamaño de pantalla, WebGL vendor, canvas hash, fonts y hardware concurrency. Las otras dos vienen de cálculos numéricos como Math.tanh y otras funciones similares.

Si las primeras ocho ya te ubican en un grupo de 2.000 navegadores, las dos últimas pueden reducir ese grupo a 200 o menos. No hace falta que eliminen toda la ambigüedad. Basta con que mejoren la clasificación. Y cuanto más tráfico tenga el sitio, más rentable se vuelve esa correlación.

Riesgos para privacidad, anti-bot y defensa web

El primer impacto es obvio: más capacidad de rastreo. Si una señal nueva ayuda a distinguir tu navegador de otros con la misma configuración aparente, entonces aumenta la persistencia del fingerprint. Eso complica el trabajo de quienes intentan limitar seguimiento entre sesiones o entre dominios.

El segundo impacto es más operativo: los sistemas anti-bot pueden usar esta información para validar si el entorno que ve la web coincide con el sistema esperado. Si un bot corre en Linux pero intenta presentarse como Windows, la discrepancia puede salir a la luz cuando el runtime matemático no encaja con el resto del perfil.

El tercer impacto es para quienes defienden sus propias plataformas. Un equipo de seguridad puede usar señales de este tipo para detectar automatización, abuso de cuentas o scraping agresivo. El mismo mecanismo que ayuda a rastrear también puede ayudar a filtrar tráfico malicioso.

Para privacidad: más persistencia, menos rotación efectiva

Si tú usas técnicas de mitigación como rotación de IP, perfiles de navegador separados o contenedores, una señal de este tipo puede reducir la efectividad de esa rotación. No porque te identifique con nombre y apellido, sino porque hace más difícil parecer un navegador genérico.

Esto afecta especialmente a usuarios y equipos que dependen de entornos aislados: QA, scraping legítimo, investigación de seguridad y automatización empresarial. Si la huella del sistema se filtra por varias capas, el aislamiento tiene que ser más estricto para seguir funcionando.

En LatAm esto importa mucho en contextos de monitoreo de precios, verificación de inventario o pruebas de disponibilidad. Muchas empresas usan automatización desde diferentes países y entornos mixtos. Si una plataforma empieza a correlacionar señales de runtime con comportamiento, el margen de error sube.

Para anti-bot: mejor clasificación, más costo de evasión

Los sistemas anti-bot viven de sumar señales. Si incorporan Math.tanh u otras diferencias numéricas como parte del perfil, el costo de evasión aumenta. Ya no basta con cambiar el user agent o rotar proxies. Tienes que replicar un entorno coherente a nivel de motor, sistema operativo y comportamiento.

Eso sube la barrera para bots baratos, pero también puede afectar a usuarios legítimos con setups poco comunes. Por ejemplo, navegadores embebidos, VMs, dispositivos con hardening agresivo o configuraciones corporativas pueden verse más sospechosas si sus señales no encajan con la población esperada.

En otras palabras: más precisión no siempre significa mejor experiencia. Si el sistema se vuelve demasiado sensible, aparecen bloqueos falsos y fricción para usuarios reales.

Qué puedes hacer si operas una web

Si administras una web con riesgo de abuso, no necesitas entrar en pánico por este cambio. Sí conviene revisar tu estrategia. La primera pregunta es si realmente necesitas usar señales finas del runtime para decisiones de seguridad. Si la respuesta es sí, hazlo con cuidado y con fallback.

La segunda pregunta es si estás acumulando demasiada dependencia de un solo indicador. Un fingerprint robusto no debería vivir o morir por una única función matemática. Si una señal cambia con una versión de Chromium, tu sistema no debería romperse ni castigar masivamente tráfico legítimo.

La tercera pregunta es si estás midiendo el impacto en usuarios reales. Si subes la sensibilidad anti-bot, revisa métricas de falsos positivos por país, navegador y sistema operativo. En mercados como México, Colombia, Perú, Chile y Ecuador, donde hay mezcla de equipos corporativos, móviles y VMs, ese análisis evita dolores de cabeza.

Recomendaciones concretas

1. No uses una sola señal como decisión final. Combina runtime, red, comportamiento y reputación.
2. Registra el sistema operativo detectado con cautela. Úsalo para scoring, no para bloqueo inmediato.
3. Mide falsos positivos por plataforma. Separa Windows, macOS, Linux y Android cuando puedas.
4. Versiona tus reglas anti-bot. Un cambio de Chromium puede alterar el perfil de una parte del tráfico.
5. Revisa la documentación del navegador y del motor. Chromium publica cambios y V8 documenta parte del runtime: https://chromium.googlesource.com/chromium/src/+/main/README.md y https://v8.dev/docs.

Un patrón de scoring más sano

Una forma más estable de trabajar es asignar pesos. Por ejemplo, user agent puede valer poco porque se falsifica fácil; WebGL y canvas pueden valer más; una señal numérica como Math.tanh puede sumar, pero no decidir sola. Así reduces el riesgo de bloquear usuarios legítimos por un cambio menor en el motor.

También conviene guardar contexto temporal. Si una señal cambia justo después de una actualización mayor de Chromium, no asumas fraude de inmediato. Puede ser simplemente una diferencia de implementación. En seguridad web, el contexto de versión importa tanto como la señal.

Qué implica para desarrolladores y equipos de producto

Si trabajas en producto, este tema te recuerda algo incómodo: tu usuario no navega en un “browser genérico”. Navega en una combinación concreta de versión, sistema operativo, hardware y configuración. Cada capa puede dejar rastros.

Eso obliga a pensar mejor en compatibilidad y observabilidad. Si tu app depende de validaciones estrictas, conviene saber si las diferencias entre Chromium 147 y 148 pueden cambiar el comportamiento de tus scripts o de tus herramientas de detección. Un cambio que parece invisible puede alterar métricas de fraude, conversión o acceso.

También hay un ángulo de soporte. Si un usuario reporta que un flujo falla solo en Linux o solo en macOS, no siempre es culpa de tu código. A veces la plataforma o el motor están exponiendo diferencias no obvias. Tener telemetría por sistema operativo y versión de navegador te ayuda a separar bugs de señales de fingerprinting.

Cómo probar sin sobreajustar

Si quieres evaluar el impacto en tu propio stack, haz pruebas controladas. No necesitas un laboratorio enorme para empezar. Sí necesitas consistencia.

1. Ejecuta el mismo script en al menos tres sistemas: Windows, macOS y Linux.
2. Repite la prueba en varias versiones de Chromium.
3. Registra resultados con formato estable, sin mezclar logs de producción.
4. Compara distribuciones, no solo valores aislados.
5. Valida si el cambio afecta detección, bloqueo o compatibilidad.

Si trabajas con automatización, documenta el navegador exacto, la versión del motor y el contenedor o VM donde corre. En muchos casos, el problema no está en la aplicación sino en la huella que el entorno deja ver.

Tabla resumen

Tabla resumen

Qué deberías llevarte de este cambio

La idea principal es simple: una función que parecía neutra puede convertirse en una señal de plataforma. Chromium 148 no inventó el fingerprinting, pero sí añadió una pieza que puede ayudar a inferir el sistema operativo subyacente con más precisión.

Si tú construyes o defiendes una web, no te conviene pensar en el navegador como una caja cerrada. Cada actualización puede mover el comportamiento del runtime y, con ello, cambiar la calidad de las señales que usas para detectar abuso o proteger privacidad. Lo que hoy parece un detalle matemático mañana puede ser parte de un perfil.

Y si tu trabajo depende de automatización, scraping o pruebas en distintos entornos, esta clase de cambio te obliga a ser más disciplinado. Versiona, mide y compara. No des por hecho que dos navegadores “iguales” lo son realmente. En fingerprinting, la diferencia suele estar en los detalles pequeños.