Las páginas de prueba de huella muestran muchos datos que los sitios web ya pueden leer. Estas seis comprobaciones ayudan a detectar contradicciones entre navegador, sistema, región, red y renderizado, porque las señales incoherentes suelen destacar más que un valor poco habitual.
Abre cualquier página de prueba de huella del navegador y verás una larga lista de campos: UA, pantalla, zona horaria, fuentes, resultados de renderizado de Canvas y parámetros de hardware. Mucha gente se fija primero en la “unicidad”, pero en realidad es lo menos importante. Lo decisivo es si todos esos datos encajan entre sí.
Qué puede leer un sitio web de todos modos
Una huella no se guarda como una cookie. Las cookies se pueden borrar, bloquear o evitar con el modo privado; la huella procede de la configuración del propio navegador y del dispositivo. El UA incluye el tipo y la versión del navegador, además del sistema operativo y su versión. También aparecen los plugins instalados, la resolución y la profundidad de color de la pantalla, la lista de fuentes, la zona horaria y el idioma preferido, el tipo de CPU, el modelo de GPU y la memoria, la IP, el proveedor y el tipo de conexión, así como los resultados de renderizado de interfaces HTML5 como Canvas y WebGL. La combinación de estos campos forma un identificador que apenas cambia al sustituir la IP, borrar cookies o usar modo privado. Las plataformas aplican el mismo principio para valorar si varias cuentas pueden estar relacionadas.
Primero, contrasta tres elementos con el sistema
El User Agent es el mejor punto de partida porque es la forma en que el navegador se describe a sí mismo. Copia el UA de la página de prueba, comprueba la versión del navegador en sus ajustes y verifica la versión del sistema operativo en la configuración del sistema. Si el sistema o la versión del kernel declarados por el UA no coinciden con la máquina real, o están claramente por detrás de versiones actuales de uso común, es una de las incoherencias más fáciles de detectar.
La zona horaria debe corresponder con la región de salida de la red. Las páginas de prueba suelen mostrarla directamente y un script sencillo para consultar la zona horaria devuelve el mismo valor. Revisa además cualquier página de consulta de IP para ver la ubicación de la salida. Si ambas apuntan a regiones distintas, hay que corregir la discrepancia.
El idioma y la región son señales débiles por separado, pero útiles en conjunto. Revisa lo que devuelven navigator.language y navigator.languages y compáralo con los idiomas habituales de la región de salida. Una zona horaria de Estados Unidos, el idioma configurado en chino y una salida en Europa llaman más la atención juntos que cualquiera de esos datos por separado.
Pantalla, salida de red y características de renderizado
En los parámetros de pantalla y hardware conviene comprobar dos cosas: si los valores son habituales y si encajan con el tipo de dispositivo indicado por el UA. Resolución, relación de píxeles, área disponible, número de núcleos de CPU y memoria pueden evaluarse conjuntamente. Una resolución propia de un móvil combinada con un UA de escritorio es una contradicción típica.
WebRTC debe revisarse por separado porque puede revelar información real de la red. Las páginas de prueba suelen mostrarlo como un apartado independiente. Comprueba si devuelve una dirección local del equipo, por ejemplo una que empiece por 192.168 o 10, o incluso la salida pública real. Si hay un proxy activo pero sigue apareciendo la dirección real, ese tráfico no está pasando por el proxy. Esta comprobación tiene la máxima prioridad.
En Canvas y WebGL hay que observar si los resultados son estables y si coinciden con el modelo de GPU declarado. Hay un detalle importante: si varios entornos abiertos a la vez en la misma máquina devuelven exactamente los mismos valores de renderizado, es más fácil relacionarlos entre sí que cuando los valores presentan cierta variación o ruido.
Las contradicciones destacan más que una apariencia poco realista
Las plataformas no exigen que cada dispositivo sea completamente único. Lo que intentan determinar es si el conjunto de información parece proceder de una máquina normal. Un valor poco “realista”, como una resolución rara, suele ser solo una señal débil. Cuando varios datos se contradicen, la anomalía resulta mucho más fácil de detectar. El UA dice Windows pero la lista de fuentes parece de macOS; la zona horaria está en Estados Unidos, el idioma es chino y la salida está en Europa; la resolución corresponde a un móvil pero el UA indica un navegador de escritorio. Cualquiera de estas combinaciones puede anular muchos ajustes finos hechos en otros parámetros. Por eso, una autoauditoría debe buscar primero contradicciones claras y solo después afinar los detalles.
Si solo quieres cambiar tres cosas
Las filtraciones de WebRTC van primero porque exponen información real de la red. En segundo lugar, la zona horaria y el idioma deben ser coherentes con la región de salida, ya que esta combinación puede acumularse fácilmente hasta formar un perfil anómalo. En tercer lugar está el tratamiento de Canvas y WebGL, para evitar que la misma máquina exponga directamente un valor estable y único.
También hay un límite práctico: desactivar o restringir JavaScript puede bloquear parte de la recopilación, pero reduce claramente la usabilidad de muchos sitios web. Los navegadores orientados a la privacidad incorporan algunas protecciones y suelen bastar para la navegación diaria, pero son menos flexibles si necesitas mantener durante mucho tiempo varias identidades no relacionadas.
Cómo mantener varios entornos
La clave no es generar una huella aleatoria distinta cada vez, sino mantener cada entorno estable por dentro y diferente de los demás. Con PurpleMark puedes crear un entorno de navegador independiente para cada cuenta, tratar por separado parámetros como Canvas y comprobar después la coherencia de cada entorno en una página de prueba. Solo un entorno que supere esta revisión merece mantenerse a largo plazo.
En definitiva, una prueba de huella tiene dos objetivos: ver qué estás exponiendo y confirmar que toda esa información es coherente internamente. La unicidad es lo último por lo que deberías preocuparte.
