Prueba de Huella Digital del Navegador: Analiza Canvas, WebGL y Unicidad

Cambiar únicamente la cabecera User-Agent no protege contra el rastreo, sino que genera notorias "contradicciones entre capas": Primero, discrepancia entre la capa de aplicación y la de transporte: si en Windows se cambia el UA a iPhone Safari, la cabecera HTTP declara Apple, pero el paquete TCP SYN presenta la firma del kernel de Windows (sin opción TS y con orden MSS, NOP, WS, NOP, NOP, SACK_PERM), lo cual contradice la secuencia exclusiva de 8 opciones de Apple. Segundo, invariantes de implementación en HTTP/3 y HTTP/2: los motores Chromium, WebKit y Gecko difieren en aspectos infalsificables, como el mapeo de flujos unidireccionales en HTTP/3 (Chromium: 2:control,10:encoder vs. WebKit: 2:control,6:encoder) y el orden de pseudocabeceras en HTTP/2 (Chromium: m,a,s,p vs. no-Chromium: m,s,a,p). Modificar un encabezado superficial mientras la pila de red transmite otra información delata de inmediato una manipulación deliberada.

💡 Conozca más sobre firmas de transporte en nuestro Análisis de anonimato de proxy.

Los navegadores antidetección modifican Chromium o inyectan scripts de intercepción (hooks) para alterar propiedades de navigator, introducir ruido en imágenes de Canvas/WebGL y simular resoluciones de pantalla o contextos de audio. Sin embargo, los sistemas de seguridad avanzados detectan señales reveladoras: Primero, manipulación de prototipos y funciones nativas: los hooks de JS suelen corromper Function.prototype.toString, los descriptores de propiedades y la cadena de herencia de prototipos. Segundo, invariantes de GPU y sombreadores: aunque el ruido inyectado cambie el hash de la imagen, la precisión matemática de coma flotante y la lógica de rasterización del controlador gráfico físico se mantienen inalterables, creando patrones de ruido artificiales muy reconocibles. Tercero, pilas de red desincronizadas: la mayoría de estos navegadores solo operan a nivel de JavaScript y no simulan el comportamiento TCP/TLS del sistema operativo anfitrión.

No. El modo incógnito está diseñado exclusivamente para evitar "guardar el historial y cookies en su propio dispositivo", no para evitar "la identificación por parte de servidores remotos". Al cerrar la ventana privada se eliminan cookies, almacenamiento local e historial; sin embargo, la huella digital se calcula mediante JavaScript leyendo características físicas del hardware y del entorno (modelo de GPU, rasterización en Canvas, sombreadores WebGL, fuentes instaladas, procesamiento de audio, núcleos de CPU y profundidad de color). Dado que el hardware físico, los controladores y el motor de renderizado no cambian en modo incógnito, los servidores remotos generan exactamente el mismo hash de huella digital que en el modo normal.

No se trata de un falso positivo, sino de la arquitectura técnica obligatoria en la plataforma iOS: Primero, directrices de la App Store de Apple: Apple exige estrictamente que todos los navegadores web en iOS/iPadOS (incluidos Chrome, Edge, Firefox y Opera) utilicen el motor de renderizado WebKit / WKWebView proporcionado por el sistema, prohibiendo la inclusión de motores Chromium Blink o Gecko. Segundo, verificación por protocolo: en iOS, Chrome (CriOS) emite en conexiones HTTP/3 el mapeo de flujos unidireccionales exclusivo de WebKit (2:control,6:encoder), claramente diferenciado de Chromium en escritorio o Android (2:control,10:encoder). Chrome en iOS es, en esencia, un navegador WebKit con la interfaz visual de Google, por lo que identificarlo como WebKit es técnicamente exacto.

Sí, pero bajo condiciones estrictas y límites definidos, y esto no tiene nada que ver con una autenticación de usuario. La recuperación de identidad en este sitio emplea un modelo de ponderación en cuatro capas: 1) Capa de anclaje de hardware (cadena del modelo de GPU, latencia base de audio, recuento de dispositivos multimedia); 2) Capa de alta entropía del sistema (lista de fuentes instaladas, paquetes de síntesis de voz); 3) Capa mutable del navegador (hash de renderizado Canvas, hash de cálculo de AudioContext); 4) Capa del entorno de visualización (resolución de pantalla, zona horaria). Tras agregar las cuatro capas, deben cumplirse simultáneamente dos condiciones para validar una identidad existente: que la puntuación total supere el umbral y que coincida al menos una característica central de alta entropía (fuentes, voces, Canvas o Audio). Esta segunda condición se añadió deliberadamente: los atributos públicos de baja entropía como el modelo de GPU, la zona horaria y la resolución se repiten masivamente en dispositivos del mismo lote y bajo ningún concepto pueden constituir una identidad por sí solos; versiones anteriores sin este filtro podían asociar erróneamente a usuarios desconocidos. Además, la capa de anclaje de hardware aplica un veto estricto: si difieren los núcleos lógicos de la CPU, la memoria varía en más de 4GB, la latencia base de audio discrepa en más de 0.005 segundos o difieren los puntos táctiles máximos, el candidato se cataloga de inmediato como un equipo distinto y queda fuera de la puntuación.

⚠ El propósito de este mecanismo es alinear de forma consistente las observaciones repetidas de un mismo dispositivo, no probar la identidad de una persona: no constituye una autenticación y jamás debe emplearse para tal fin.

Ambas pertenecen a las «características de alta entropía del sistema», no requieren permisos y operan de forma totalmente silenciosa e imperceptible. Huella de AudioContext: en un OfflineAudioContext se conecta un oscilador (Oscillator) a un compresor dinámico (DynamicsCompressor) para renderizar una señal de audio fuera de línea, leyendo los valores de punto flotante para generar un hash. El mismo grafo de audio produce mínimas diferencias en el bit menos significativo entre distintos navegadores, librerías matemáticas y unidades de punto flotante, sin reproducir ningún sonido. Próximo a este parámetro, pero completamente independiente, se encuentra AudioContext.baseLatency: refleja el tamaño del búfer de salida de la tarjeta de sonido condicionado por el hardware y los controladores; lo empleamos como ancla de hardware (una discrepancia mayor a 0.005 segundos descarta la coincidencia) y no como hash de identidad. Huella de enumeración de fuentes: mide una por una las dimensiones del texto renderizado con cada fuente de una lista frente a las fuentes de reserva predeterminadas; cualquier diferencia confirma que la fuente está instalada. El repertorio tipográfico depende del software que haya instalado (suites de Office, Adobe, entornos de desarrollo, teclados virtuales), por lo que la lista de fuentes suele ser el elemento con mayor capacidad de discriminación individual de todo el sistema.

💡 La disparidad en estabilidad radica en el origen del cambio: los hashes de Canvas y Audio varían con cada actualización de versión del navegador (los motores de renderizado y librerías matemáticas evolucionan constantemente), mientras que las fuentes únicamente cambian al instalar o desinstalar programas, razón por la cual reciben el peso más alto.

El MSS (Maximum Segment Size) es la carga útil máxima por segmento TCP anunciada durante el protocolo de enlace. Nuestro servidor la extrae directamente de su paquete SYN sin requerir instalaciones ni configuraciones de software. Al sumar la sobrecarga de las cabeceras IP y TCP se reconstruye el MTU del enlace: sumar 40 bytes en IPv4, sumar 60 bytes en IPv6. Los valores comunes poseen un significado técnico preciso: 1500 corresponde a redes Ethernet estándar o servidores en la nube directos; 1492 identifica conexiones PPPoE (banda ancha doméstica DSL / FTTH), donde los 8 bytes de cabecera PPPoE reducen la carga útil; menor o igual a 1420 revela una encapsulación adicional, propia de túneles VPN como WireGuard / Tailscale o del enrutamiento a través de una CDN.

⚠ El aspecto fundamental es que el MSS describe el enlace de red, no el dispositivo. Únicamente señala la existencia de encapsulación en la ruta y no demuestra por sí solo el uso de un proxy (las conexiones residenciales PPPoE tampoco tienen 1500). El auténtico valor reside en las contradicciones: cuando la ubicación declarada en la capa de aplicación discrepa de forma sostenida con las características de transporte (por ejemplo, declarar una conexión local directa mientras el MSS se sitúa de forma invariable en rangos propios de un túnel). Consulte nuestro Análisis de anonimato de proxy para más detalles.

Es el tipo de error que prevenimos con mayor rigor (fusión errónea) y disponemos de tres líneas de defensa consecutivas; si cualquiera de ellas salta, la unión se rechaza. Primero, aislamiento estricto por compartimentos: los candidatos se clasifican estrictamente por plataforma de sistema operativo y motor de navegador, sin comparaciones entre grupos. Dos motores de navegador distintos en un mismo equipo físico, aun con idéntico hardware, jamás se consolidarán en una misma identidad. Segundo, veto por anclaje de hardware: recuento de núcleos lógicos de la CPU, capacidad de memoria RAM (tolerancia de 4GB), latencia base de audio (tolerancia de 0.005 segundos) y puntos táctiles máximos conllevan la exclusión inmediata antes de calcular la puntuación si se detecta un conflicto que exceda la tolerancia. Tercero, filtro de admisión de características centrales: aun con una puntuación compuesta muy alta, si no coincide ninguna característica central de alta entropía (fuentes, voces, Canvas, Audio), la asociación queda prohibida, evitando que una suma de datos públicos de baja entropía alcance una puntuación indebida.

⚠ Declaración de transparencia: en la actualidad no disponemos de una tasa de fusiones erróneas medida sobre tráfico natural que podamos hacer pública. Este índice exige mediciones prolongadas sobre tráfico real; publicar cualquier cifra antes de disponer de un volumen de muestra representativo carecería de rigor ético y técnico.