Un estudio presentado en IMC 2024 convirtió la detección en un experimento en línea reproducible: en vez de confiar en lo que el navegador dice ser, contó propiedades de objetos internos y las comparó con la versión declarada. El método resulta más valioso que la conclusión.
Hay muchas afirmaciones sobre si las huellas de navegador pueden detectarse, y la mayoría se quedan en la conclusión. En lugar de discutir quién gana o pierde, es más útil ver cómo los investigadores convirtieron la cuestión en un experimento reproducible y qué métricas utilizaron para decidir.
Un estudio publicado en la ACM Internet Measurement Conference (IMC) 2024, titulado Browser Polygraph, fue realizado por investigadores de Arizona State University, Boston University y Amazon; su DOI es 10.1145/3646547.3688455. En vez de ejecutar datos simulados en un laboratorio, el sistema se desplegó durante 4,5 meses en el entorno real de producción de una gran empresa financiera y cubrió 205.000 sesiones de usuarios reales. Se evaluaron diez soluciones habituales de enmascaramiento de entorno y se utilizó como control el tráfico normal de usuarios.
Cómo se montó el experimento
Tres decisiones de diseño permitieron desplegar la detección sobre todo el tráfico sin afectar al negocio.
Las características debían ser baratas de obtener. La detección solo lee un conjunto fijo de propiedades, con un coste por ejecución del orden de milisegundos y KB. Por eso puede aplicarse a todo el tráfico sin muestreo y sin que el usuario note el proceso.
Las características debían ser estables. No se eligieron parámetros que el usuario pueda modificar, sino estructuras internas fijadas por el propio navegador. Cada versión incorpora un motor JavaScript distinto, y entre versiones existen pequeñas diferencias en el número de APIs disponibles y en cuántas propiedades cuelgan de cada objeto. El estudio usó como referencia el intervalo entre Chrome 110 y Chrome 114: el sistema contó las propiedades de 28 objetos clave y comparó el resultado con la versión que el navegador afirmaba usar. Si no coincide, la declaración y el comportamiento real no proceden de la misma base.
Las etiquetas debían ser fiables. Cada entorno evaluado se conectó al mismo tráfico de producción y se juzgó con las mismas reglas, mientras que el grupo de control estaba formado por el comportamiento normal de usuarios reales. Por tanto, el resultado no indica subjetivamente si algo “parece real”, sino si ese tráfico puede distinguirse con las mismas reglas.
Métricas para juzgar si la simulación es real
Las medidas utilizadas en el estudio pueden agruparse en cuatro categorías.
- Consistencia: si la versión declarada por el navegador coincide con la estructura de sus objetos internos. Es la métrica central y también la más difícil de falsificar, porque cambiar una cadena de texto no modifica a la vez el número de objetos y propiedades del motor.
- Tasa de detección: el estudio realizó pruebas detalladas con cuatro de las soluciones, con tasas de detección de entre el 67 % y el 84 %.
- Desviación respecto a dispositivos reales: con las mismas reglas, los navegadores normales obtuvieron una puntuación de riesgo de 0, mientras que las soluciones evaluadas promediaron entre 8,85 y 11,66. La puntuación expresa la distancia respecto a la distribución real, no una impresión subjetiva de parecido.
- Distinguibilidad: si el tráfico evaluado puede separarse del tráfico normal. Una categoría que no puede separarse indica que, con este método, no hay una brecha de comportamiento respecto a navegadores reales.
De las cuatro métricas, la primera es la causa; las otras tres son consecuencias.
Dónde falla cada una de las cuatro categorías
El estudio dividió las soluciones evaluadas en cuatro categorías según su implementación interna.
En la primera, las características de bajo nivel no coinciden con ninguna versión conocida de un navegador real, por lo que no existe un motor correspondiente. Una simple revisión deja al descubierto la discrepancia.
En la segunda, el entorno incluye características de huella reales, pero al cambiar de identidad solo se modifica la declaración superficial y el motor interno permanece igual. Fue el patrón más común del estudio. Como analogía, la tarjeta de visita muestra una versión nueva, pero el acento sigue siendo antiguo. El problema no es si cada parámetro está bien ajustado, sino la brecha entre declaración y comportamiento; de ahí procede gran parte de la detección.
En la tercera, el motor interno cambia junto con la identidad. Si el entorno afirma ser una versión concreta, ejecuta el motor correspondiente a esa versión, por lo que la consistencia se mantiene y este detector no pudo distinguir el tráfico. El artículo también señala que identificar esta categoría requiere métodos de detección más complejos.
La cuarta categoría no modifica el navegador. Ejecuta un navegador real dentro de una máquina virtual y después carga la configuración objetivo. Como el navegador es realmente auténtico, el detector no puede diferenciarlo, aunque el coste operativo es alto y resulta difícil escalarlo.
La diferencia entre las cuatro categorías no está en la cantidad de parámetros, sino en si la declaración y el comportamiento proceden de la misma base.
Consejos prácticos para elegir una solución de entorno
El foco de la detección ha pasado de leer declaraciones a validar el comportamiento, por lo que los parámetros superficiales editables ofrecen cada vez menos ventaja. Para una evaluación concreta:
- Pregunte por la capa interna, no por la lista de parámetros. Cuando cambia la versión declarada, ¿cambia también la capa subyacente? ¿Las huellas se generan automáticamente como combinaciones reales o se montan manualmente como un conjunto de valores?
- Compare los entornos entre sí. Si varios devuelven características internas muy parecidas, el aislamiento no es completo.
- Primero consistencia, después diferenciación. Cuantos más rasgos internamente contradictorios se ajusten, mayor será la superficie de exposición.
- Superar una página genérica de detección no significa que una plataforma acepte el entorno. La validación final debe hacerse con una pequeña cantidad de tráfico real propio.
El problema central del aislamiento de entornos es conseguir que cada entorno sea independiente y coherente consigo mismo. Eso es lo que PurpleMark busca resolver. Tanto la detección como la antedetección deben utilizarse dentro de los límites de cumplimiento aplicables; el valor real del estudio es aportar una base verificable para evaluar, no una clasificación de qué producto es bueno o malo.
