¿Conviene aleatorizar los parámetros del navegador? Por qué «más aleatorio» falla antes

«Puse los parámetros de cada entorno en aleatorio, pensando que así estaría más protegido, y la cuenta no aguantó ni unos días.» Quien gestiona varias cuentas ha oído esta historia más de una vez. La intuición dice que, si los parámetros cambian cada vez, la plataforma no debería reconocerlos. En la práctica suele pasar lo contrario: cuanto más aleatorio, antes falla la cuenta.

El punto de partida está invertido. A la plataforma no le interesa si cambias. Lo que mira es si pareces un equipo real. Y el rasgo que más define a un equipo real es, precisamente, la estabilidad.

La conclusión va primero: los parámetros no necesitan ser aleatorios a propósito. Que un entorno sea sólido depende de tres cosas: que cada parámetro sea real, que las decenas de parámetros se expliquen entre sí y que los parámetros de una misma cuenta resistan la comparación a lo largo del tiempo. La aleatorización toca la primera y estropea las dos últimas. Abajo se aclara primero qué cubre lo «independiente» y qué cubre lo «aleatorio», después se repasan los parámetros de huella y al final se ve dónde falla la aleatorización.

¿Un entorno independiente y unos parámetros aleatorios son lo mismo?

Aclaremos primero el malentendido más común: mucha gente, al empezar, piensa que si cada entorno es independiente, los parámetros tendrán que ser aleatorios, porque si no, los entornos serían todos iguales.

La independencia del entorno gestiona el límite. Dos entornos no comparten sesión ni datos web, y lo que haces en el entorno A no se le atribuye a B; de eso se encarga la tecnología de aislamiento. No tiene nada que ver con el valor de los parámetros. Lo aleatorio gestiona el valor y decide cómo se lee cada entorno.

Entre cuentas distintas debe haber un límite; dentro de una misma cuenta debe haber continuidad. El límite lo da el aislamiento y la continuidad la da la estabilidad. La aleatorización aplica la necesidad del límite a la continuidad y derriba cada vez lo que dentro de la cuenta debería mantenerse estable.

¿Qué parámetros de huella existen y cómo los lee un sitio?

El navegador expone más de veinte parámetros de huella que se citan a menudo. No hace falta memorizarlos: basta con separarlos en dos grupos según cómo los obtiene el sitio. El primero lo reporta el propio navegador y el sitio lo lee con solo enviar una petición:

La segunda clase no se pregunta: el sitio la mide en el momento. Canvas y WebGL son el caso más claro. Se pide al navegador dibujar una imagen y renderizar una escena en tres dimensiones, y las tarjetas gráficas y los controladores dan resultados con diferencias mínimas. Con ese resultado, el sitio contrasta la identidad que el navegador declara.

Los parámetros que el navegador declara se aceptan tal cual; el resultado medido se produce en el momento, no se puede corregir y solo se puede falsificar. Ahí está la raíz del problema de la aleatorización.

¿Por qué fallan tan fácil los parámetros aleatorios?

Las extensiones de aleatorización tocan justo esas dos clases, y cada una tiene su propia forma de arruinarlo.

Empecemos por los declarados. Si se sortean por separado el User-Agent, la resolución y las fuentes, lo más probable es que el resultado no arme una máquina que exista: una lista de fuentes de Windows junto a una presentación de macOS, o una resolución de móvil con una identidad que sigue siendo de sobremesa. El modelo de riesgo de la plataforma ha visto millones de dispositivos reales y detecta estas combinaciones imposibles a simple vista.

Hay una variante más discreta: para ahorrarse trabajo, la extensión pone el mismo valor popular en un parámetro para todos sus usuarios. Cuando la usan muchos, un lote de cuentas sin relación recorre la red con el mismo valor. La plataforma no necesita identificarlas una a una: le basta con reconocer ese valor.

Ahora los medidos. Las extensiones que añaden ruido devuelven resultados algo distintos en cada lectura de Canvas: la misma imagen da hoy un valor y mañana otro. Un equipo real no hace eso: en un ordenador normal la lectura no se mueve con el uso diario, y dos lecturas que no cuadran ya son una marca anómala.

La plataforma también conoce el ritmo de cambio de los equipos reales: una versión mayor del navegador o una instalación limpia del sistema ocurren unas pocas veces al año, y en toda la red a la vez. Un cambio aleatorio no tiene ese ritmo y puede darse en cada visita. Solo cambias tú.

La aleatorización cambia el valor de los parámetros, no el juicio sobre si pareces un equipo real.

¿Por qué no basta con mirar la puntuación?

Mucha gente confía en la aleatorización por la herramienta de puntuación: cambia los parámetros, mide, saca 90 o 100 y sale a operar tranquila. Aquí hay un hueco fácil de pisar: la herramienta mide apartados sueltos y la plataforma mira relaciones.

Una nota alta solo dice que ese apartado está bien: IP limpia, parámetro no muy raro, sin filtraciones evidentes. Pero al juzgar vínculos, la plataforma mira si las decenas de apartados se explican entre sí: si el sistema operativo no cuadra con la tarjeta gráfica, si el idioma no cuadra con la IP, cualquier desajuste basta para una segunda mirada.

Esa prueba cruzada entre parámetros es un juicio relacional y la herramienta no lo mide. El peligro de un entorno perfecto está justo ahí: cada apartado brilla por separado y el conjunto puede dibujar un dispositivo que no existe.

La nota no prueba esa coherencia; solo da una calma falsa.

Al revisar un entorno, el orden pesa más que la nota. Son tres capas: primero, si las decenas de parámetros se explican entre sí; después, si el valor leído coincide con el definido en cada apartado; y por último, una nueva medición pasados unos días para ver si las dos lecturas coinciden. En herramientas, bastan tres pasos:

1. Empieza por el test de coherencia. Herramientas como CreepJS buscan parámetros que se pelean: lo que dice la UA, lo que dice la tarjeta gráfica y lo que dicen las fuentes, todo puesto en común.
2. Sigue con las filtraciones por apartado. BrowserLeaks lista el valor reportado de cada apartado por categoría y permite confirmar uno a uno que coincide con el dispositivo definido.
3. Termina con la estabilidad histórica. Repite la medición del mismo entorno pasados unos días: las dos lecturas deben coincidir; si no cuadran, hay ruido siendo leído.

¿Cómo resuelve MostMate la elección entre «real» y «aleatorio»?

**MostMate es un navegador antidetección que lleva lo real, lo consistente y lo estable a los valores por defecto.** El modo de parámetros tiene tres niveles: real, aleatorio y personalizado, y el valor por defecto cae en «real». La resolución de pantalla, los núcleos de CPU y la memoria del dispositivo toman directamente las características reales del equipo actual, y Canvas y WebGL se emiten tal cual, sin montajes añadidos ni ruido. La vista previa de ajustes de la web describe esta acción como «el sistema construye automáticamente un entorno de navegador razonable, real y lógicamente coherente», y «lógicamente coherente» corresponde justo a la prueba cruzada entre parámetros de la que hablamos antes.

Los apartados ligados a la región, como zona horaria e idioma, vienen por defecto en «según la IP»: donde se fija la salida, allí se alinean, sin el desfase de una línea en una región y una hora en otra. Por qué se fijan así los principios de realidad y coherencia lo desarrolla el artículo sobre los cuatro principios de diseño de MostMate.

Con el entorno creado, el límite también queda trazado. La web llama Profile al entorno y cada Profile guarda su propio juego de parámetros: dos Profile creados en el mismo ordenador dan huellas separadas que no se mezclan. Cómo se rellena el formulario de arriba abajo ya está, en orden, en los cuatro pasos desde la vista previa hasta el primer entorno; al terminar, repasa el cotejo entre ajuste manual de huella y configuración recomendada y confirma el nivel de cada apartado.

Qué cubre esta herramienta en la gestión de varias cuentas lo cuenta por completo la página de producto.

¿Cuándo se pueden cambiar los parámetros de huella?

Estabilidad no es inmovilidad: un cambio debe tener motivo real.

La actualización de versión mayor del navegador es un cambio normal y no requiere gestión: todos los usuarios se suman en la misma quincena, el modelo de la plataforma ya conoce ese ritmo y un entorno que sigue al equipo real no se equivoca.

Cambiar de equipo o de línea obliga a mover el conjunto completo: los parámetros nuevos forman un todo coherente, los apartados de región se alinean con la línea nueva y el cambio se hace de una sola vez, con la cuenta tranquila. El salto puntual es lo peligroso; sustituir el conjunto no lo es.

Si la cuenta acaba de mostrar una anomalía o sus datos oscilan, detente: cualquier ajuste de parámetros amplifica el riesgo. Si dudas, mide otra vez: una medición antes y otra después, con cero contradicciones y lecturas coincidentes, y se sigue.

Preguntas frecuentes

¿El modo aleatorio es totalmente inutilizable?

No está prohibido; lo que no vale es como política por defecto de una cuenta. El modo de parámetros de MostMate conserva el nivel «aleatorio», útil para pruebas y depuración, escenarios que no necesitan una identidad duradera. Para cuentas que hay que sostener en el tiempo, el «real» por defecto es más firme.

¿Basta con cambiar solo el User-Agent?

No funciona. El User-Agent es uno de más de veinte apartados; el resto queda igual y el retrato del dispositivo no cambia. Además, mantiene correspondencia con los apartados medidos, como la tarjeta gráfica y las fuentes, así que tocar un solo punto desajusta el conjunto. Si hay que mover algo, se mueve todo de forma coherente: el cambio puntual es la peor opción.

¿Usar una huella real evita siempre el riesgo de la plataforma?

No hay que entenderlo así. Una huella real resuelve la capa de «si el dispositivo se lee como real»; el riesgo de la plataforma también mira el comportamiento, la calidad de la IP y el ritmo de operación, cosas que quedan fuera de la huella. Una huella real deja sólida la capa del dispositivo; no asegura la cuenta. Con esa capa estable, la cuenta todavía necesita hábitos de uso que la sostengan.

¿La revisión de coherencia de MostMate equivale al riesgo de la plataforma?

No, son dos cosas distintas. La revisión de coherencia de MostMate te ayuda a montar al crear un entorno con parámetros coherentes y alineados con la IP, y no toca ninguna regla de detección de plataforma. Cómo juzga la plataforma es cosa suya; lo que puedes hacer es ordenar tu entorno para que parezca un equipo real.

¿Se pueden rescatar las cuentas criadas con una extensión de aleatorización?

Sí, pero sin prisa. Detén primero la aleatorización, fija un juego de parámetros reales, alinea los apartados de región con la línea nueva y luego mantén todo quieto una temporada. Ajustar cada poco es más peligroso que mantener el estado actual.

Para terminar

La aleatorización busca estrenar cada vez; la plataforma premia lo estable. La clave de los parámetros es dar el límite al aislamiento del entorno y la continuidad a la estabilidad de los valores. Cada cosa en su sitio.

Si aún dudas entre las dos opciones, puedes descargar MostMate y crear dos entornos siguiendo este artículo: uno con el «real» por defecto y otro en «aleatorio». Mide cada uno dos veces pasados unos días y verás qué lectura resiste el cotejo.