Flags de huella digital

La identidad se controla con switches de línea de comandos de Chromium. El SDK los configura a partir de opciones con nombre; con el build abierto también puedes pasarlos como args a tu propio launcher.

La mayoría de los switches están en ambos builds. Algunos son exclusivos del build con licencia (Gratis con GitHub o Pro): la lista de switches de más abajo los marca con la revisión del motor que los introdujo. Sin una clave de licencia, el SDK ejecuta el build abierto, donde esas opciones no tienen ningún efecto.

El modelo de seed

Todo gira en torno a --fingerprint=<seed>. El seed (un entero o cualquier cadena) deriva la persona de forma determinista y, además, perturba las dos superficies renderizadas que se detallan más abajo, en la sección qué recibe farbling:

Desde la compilación licenciada de Chromium 156 (r51) esa derivación se hace en el servicio de personas de Clearcote: el lanzador lo consulta en cada inicio con el token de ejecución de la licencia y entrega al navegador la persona firmada, sin la cual no arranca. Mismo seed, misma identidad que en r50. Las licencias sin conexión se quedan en r50 hasta que exista un paquete de personas sin conexión.

• Mismo seed ⇒ misma identidad en cada lanzamiento en la misma máquina y la misma versión del navegador: un visitante que vuelve. Todo lo que una página puede leer se mantiene idéntico: la GPU, la pantalla, el hardware, las fuentes y las voces, y los resultados de canvas, WebGL y audio. La única excepción es la estimación de la velocidad de conexión (el tiempo de ida y vuelta y el ancho de banda de navigator.connection), que sigue a tu red real, igual que en Chrome.
• Seed nuevo ⇒ una identidad nueva y plausible.
• El ruido de canvas y WebGL se deriva por sitio (inspirado en el farbling de Brave), así que esos hashes cambian de un dominio a otro. La persona en sí —GPU, pantalla, hardware, fuentes— es la misma en todas partes, como lo sería la de una máquina real.

El mismo seed en máquinas distintas

La tarjeta gráfica que declara una persona es del fabricante de la tarjeta con la que la máquina renderiza de verdad (NVIDIA, Intel o AMD), así que los píxeles y los límites gráficos que mide una página corresponden al tipo de tarjeta que se le reporta a la página. En una máquina sin tarjeta gráfica, la persona declara gráficos integrados: de Intel o de AMD desde 154 r37 y solo de Intel en r36. Por eso, un seed reporta una tarjeta gráfica distinta en máquinas cuyas tarjetas son de fabricantes distintos, y es así por diseño.

En el build con licencia desde 154 r36, el fabricante de GPU de la máquina también puede cambiar el resto del hardware. Una computadora de gama de entrada no trae una tarjeta gráfica dedicada, así que en una máquina con una tarjeta NVIDIA, un seed que declararía hardware de gama de entrada (de 4 a 6 hilos de procesador, de 4 a 8 GB de memoria, una pantalla pequeña) declara en su lugar hardware de gama media o superior, y nunca una pantalla táctil. Por eso, alrededor de la mitad de los seeds reportan una cantidad distinta de hilos de procesador y de memoria en una máquina NVIDIA que en una Intel, AMD o sin GPU, y algunos, otro tamaño de pantalla. En máquinas con el mismo fabricante de GPU, la identidad de un seed es la misma.

Desde 154 r37, la gama de tarjetas entre las que eligen las máquinas de un fabricante sale del tráfico real de navegadores: cada modelo es tan probable como en el mundo real, así que una flota de personas se ve como una flota de máquinas reales. Por eso, la mayoría de los seeds declaran en r37 una tarjeta distinta que en r36; el resto del hardware se deriva como en r36.

Desde el 2026-10-26 (r52, y también los lanzamientos de r51, porque el servicio de personas deriva la identidad), el valor predeterminado es el esquema de persona 7: la tarjeta gráfica determina el tipo de máquina: portátil o de escritorio, generación del procesador, hilos, memoria y pantalla, incluida la escala de pantalla con la que realmente funcionan las portátiles. Un seed obtiene una máquina distinta de la que obtenía antes de esa fecha.

Para que un seed conserve una sola identidad en distintas máquinas:

• Ejecútalo en máquinas con el mismo fabricante de GPU: por ejemplo, un solo tipo de servidor en producción.
• Fija el fabricante de GPU pasando --fingerprint-gpu-host-vendor=nvidia (o intel, amd) en los args de tu launcher. Así, la persona deriva su identidad como lo haría en una máquina con una tarjeta de ese fabricante, dondequiera que se ejecute. Fija el fabricante de las máquinas en las que más se ejecuta la persona: en una máquina cuya tarjeta es de otro fabricante, la tarjeta que declara ya no coincide con la que renderiza.
• Conserva las identidades creadas en r45 a r51 (antes del 2026-10-26) con persona_schema=5 / personaSchema: 5 (--fingerprint-schema=5), y las de 154 r37 a 155 r44 con persona_schema=4 / personaSchema: 4. Ambos esquemas están congelados: un seed deriva siempre la misma identidad con ellos.
• Conserva las identidades creadas en 154 r36 con persona_schema=3 / personaSchema: 3 (--fingerprint-schema=3). Así, cada seed deriva exactamente lo que derivaba en r36, campo por campo, incluida la tarjeta gráfica.
• Conserva las identidades creadas antes de r36 con persona_schema=2 / personaSchema: 2 (--fingerprint-schema=2). Así, cada seed deriva exactamente lo que derivaba de 153 r29 a 154 r35, campo por campo: la tarjeta gráfica sigue al fabricante de la máquina; el resto del hardware, no.

Sin un seed no hay una identidad por persona: todos los lanzamientos en el mismo tipo de máquina se ven iguales. Dale a cada identidad su propio seed.

¿Prefieres la identidad de una máquina real en lugar de la sintética que deriva del seed? Captura un Chrome donante con el recolector e impórtalo con --fingerprint-profile=<gzip+base64 JSON> (o con la opción fingerprint_profile / fingerprintProfile del SDK, que hace el gzip+base64 por ti) en lugar de un seed. Los campos presentes en el perfil sobrescriben lo que el navegador reportaría; los ausentes recurren a los valores por defecto del navegador. No pases un seed de --fingerprint junto con un perfil: el seed añade ruido al canvas, que la puntuación estricta interpreta como manipulación junto a los valores de una máquina real, y el perfil ya aporta la identidad (consulta Perfiles y persistencia). Ambos builds leen perfiles importados; en el build con licencia se aplican por completo desde 151 r19. Consulta la guía de Playwright para ver cómo importar un perfil capturado desde el SDK.

Qué recibe farbling y qué queda fuera a propósito

Perturbar una superficie te da no vinculabilidad a costa de coherencia, y ese intercambio no compensa en todas partes. Clearcote aplica farbling a las dos superficies donde el ruido se parece más a la variación normal del hardware y deja el resto sin perturbar, porque en esas un valor perturbado llama más la atención que uno compartido. Eso sí, sin perturbar no es lo mismo que intacto: algunos valores se siguen sustituyendo por completo con los de la persona, como detallan la tabla y la nota que la sigue. Algunos tests todavía pueden señalar el propio ruido; cuando eso importa, fingerprintNoise: false lo desactiva y conserva la identidad (consulta Cómo funciona la detección).

La consecuencia práctica para el trabajo con varias cuentas: canvas y WebGL separan tus identidades; el audio renderizado y los client rects, no. Son propiedades de la máquina subyacente: el mismo host renderiza el mismo pipeline de audio y compone el texto con las mismas fuentes y el mismo pixel ratio sea cual sea el seed cargado, igual que pasaría con dos personas distintas en hardware idéntico. Si un sitio correlaciona precisamente con esas señales, la solución son máquinas separadas, no otro switch.

Hay una excepción que conviene conocer: los tres escalares de AudioContext sí siguen a la persona. sampleRate, baseLatency y outputLatency se sirven desde la persona siempre que haya una activa (un seed de --fingerprint o un perfil importado), así que varían entre identidades en lugar de exponer el backend de audio del host. Si no hay ninguno de los dos, los tres llegan tal cual desde la máquina real. Una frecuencia que la página pide explícitamente se sigue respetando, y outputLatency sigue pasando por el cuantizador propio de Chrome, que depende de los permisos. Desde 153 r26, baseLatency también sigue el tamaño de render que pide la página, y un contexto que todavía no empezó a renderizar reporta la misma latencia que un Chrome normal.

Dónde cae el ruido (r57)

Desde r57, en la build con licencia el ruido de lectura de canvas y WebGL solo cambia un píxel cuando ninguno de sus cuatro vecinos tiene el mismo color. Las zonas planas — una forma sólida, un bloque relleno, un fondo borrado — se leen exactamente como se dibujaron, como en hardware real. Los bordes del texto, las curvas y los degradados siguen llevando el ruido de la semilla, así que los perfiles mantienen hashes de canvas distintos. Antes de r57 también se añadía ruido a una zona plana dentro de una lectura, de modo que un verificador que dibuja una forma sólida y calcula su hash (el «Masking detected» de PixelScan) podía demostrar que los píxeles se habían modificado.

Un readPixels parcial de WebGL (un rectángulo más pequeño que el canvas) no ve los píxeles justo fuera de él. Por eso, por defecto, el motor lee el rectángulo junto con un margen de un píxel a su alrededor en una sola lectura de la GPU, de modo que cada píxel del borde recibe exactamente el ruido que le da una lectura completa del canvas, y la lectura cuesta lo mismo que en Chrome.

Ambos ajustes se aplican a todas las formas en que una página puede leer los píxeles (getImageData, toDataURL, toBlob, readPixels), así que las lecturas de un mismo canvas siguen coincidiendo. Los motores anteriores a r57 siempre se comportan como flatAreaNoise: true, y el SDK y el Profile Manager omiten ambos ajustes ahí. En Docker, define CC_FLAT_AREA_NOISE y CC_WEBGL_READ_MARGIN. Los ajustes llegan con el SDK 0.68.8 y el Profile Manager 0.40.0.

Superficies secundarias coherentes

Más allá de las señales con ruido, el motor hace que las superficies secundarias de la persona coincidan con las de un Chrome real en la plataforma de esa persona. El SDK usa por defecto el sistema operativo de tu host como plataforma; los valores específicos de Windows que aparecen abajo se aplican a una persona de Windows.

• Los límites de WebGL (WebGL1 + WebGL2) siguen a la GPU de la persona siempre que esta máquina pueda respaldarlos. Nunca se reporta un límite más alto del que aplica el driver real, así que en un renderizador por software algunos valores son más bajos que los de la GPU indicada.
• UNMASKED_RENDERER / UNMASKED_VENDOR son constantes durante toda la sesión: una sola GPU en todos los sitios, que sigue a la persona, en lugar de una señal delatora por origen.
• navigator.getBattery() reporta un equipo de escritorio conectado a la corriente (cargando, nivel 1.0, sin descarga), y navigator.connection, un perfil residencial (effectiveType 4g, rtt/downlink redondeados, saveData desactivado).
• navigator.keyboard.getLayoutMap() devuelve un mapa US-QWERTY y, con una persona de Windows, AudioContext reporta la frecuencia de muestreo y la latencia de la pila de audio de Windows.
• Claro u oscuro: desde 154 r32, la persona prefiere un esquema de colores (cerca de una de cada tres, el oscuro; --fingerprint-color-scheme=light|dark permite elegirlo), y prefers-color-scheme, matchMedia, el header Sec-CH-Prefers-Color-Scheme y los colores del sistema de CSS concuerdan entre sí. El SDK (0.41.0+) deja desactivada la emulación de esquema de colores de Playwright en un build así, para que nada lo contradiga.
• Fuentes: con una persona de Windows, el texto tiene las alturas de línea y los anchos de las fuentes comunes de una máquina Windows, y las fuentes que una página pide por nombre se comportan como en Windows (154 r32). Una fuente genuina instalada en la máquina se usa tal cual; en Linux, indica las tuyas con fontDirs.
• window.getScreenDetails() reporta un único monitor coherente; @media (pointer: fine) / (hover: hover) corresponden a un equipo de escritorio con mouse.
• URLs: con una persona de Windows, new URL("C:/").protocol devuelve file: y, desde 153 r26, todas las formas en que una página puede construir una URL dan la misma respuesta. navigator.share / canShare están expuestos para coincidir con el UA de Windows.
• WebGPU: la información del adaptador y los límites/features de navigator.gpu siguen a la misma GPU que WebGL (en el build con licencia, acotados a lo que el host puede ofrecer).
• Configuración regional: Accept-Language, navigator.language, la lista completa de navigator.languages e Intl (hilo principal + workers) salen todos de una misma lista (acceptLanguage, o geoip). El SDK configura --accept-lang y --lang por ti; con switches directos, pasa ambos.
• Síntesis de voz: speechSynthesis ofrece el conjunto de voces de la persona, incluidas las voces de red de Google que lista un Chrome de esa versión (153 r27). fingerprintVoices: false conserva, en cambio, las voces propias de la máquina (152 r22).
• Hardware: la lectura de velocidad del procesador (navigator.cpuPerformance) sigue a la persona y no al procesador real (152 r20), y el límite de memoria para scripts (performance.memory.jsHeapSizeLimit) sigue la memoria que declara la persona (153 r26).
• Códecs & dispositivos: MediaCapabilities.decodingInfo() reporta una matriz de códecs de la persona, y enumerateDevices(), un conjunto de dispositivos multimedia de la persona (ids estables por seed, etiquetas vacías antes de conceder permisos).
• UA-CH de alta entropía: bitness=64 / wow64=false / model; con una persona de Linux, platformVersion queda vacío, tal como lo reporta el Chrome genuino en Linux (153 r26). navigator.storage.estimate() reporta una cuota de disco realista cuando defines storageQuota.

Experimental: canvas bridge con GPU real

De forma opcional, reenvía las operaciones de canvas / WebGL a un host remoto con GPU real para que las lecturas (getImageData / toDataURL / readPixels / measureText) sean coherentes con la GPU que presentas, incluso en hardware que no puede renderizarla localmente. Como reenvía las operaciones (no imágenes pregrabadas), funciona con la mayoría de los canvas, no solo con pruebas conocidas. Actívalo con --canvas-bridge-url=ws://host:port (más --no-sandbox); si no lo defines, todo es local, exactamente como antes. El servidor de render controla un navegador en el host con GPU real (un Chrome normal por CDP, o un Clearcote headless). Consulta la guía del canvas bridge para la configuración completa.

Overrides nativos de metadatos & light_stealth

Además de la persona derivada del seed, un conjunto de overrides nativos de un solo valor te permite falsear valores individuales de navigator/screen directamente: hardwareConcurrency, deviceMemory, colorDepth, devicePixelRatio, maxTouchPoints y (de forma opcional) las dimensiones de screen/avail*. Cada uno lo lee directamente su getter con la precedencia flag > persona de --fingerprint > host real, así que un valor fijado a mano gana sobre cualquier seed y los overrides funcionan con o sin un seed de --fingerprint: nunca activan la maquinaria de la persona.

El SDK agrupa un subconjunto ligero detrás de un solo flag, light_stealth: aplica uno de unos pocos paquetes de metadatos coherentes (hardwareConcurrency, deviceMemory, colorDepth, devicePixelRatio, maxTouchPoints) solo mediante esos switches nativos. El seed solo elige el paquete y no se pasa al motor, así que no hay ruido de canvas ni de WebGL, y todas las sesiones light_stealth de una misma máquina comparten el hash de canvas del host: usa un seed de fingerprint por cuenta sin lightStealth cuando esos hashes deban ser distintos. El ClientHello de TLS y la versión real del navegador no cambian. Las dimensiones de screen no se falsean por defecto, a propósito (se activan de forma opcional con screenWidth, etc.), porque una pantalla falsa que no se puede conciliar con la superficie de render real es fácil de detectar; en una pantalla sin escalado, comprueba que el devicePixelRatio elegido le corresponda, o fíjalo tú mismo. Una opción explícita siempre gana sobre el preset.

import { launch } from "clearcote";
// one coherent metadata bundle; "my-seed" only picks which one — no seed reaches the engine, so no canvas noise:
const browser = await launch({ lightStealth: true, fingerprint: "my-seed" });

// or set individual values by hand (no --fingerprint needed):
const b2 = await launch({
  hardwareConcurrency: 8,
  deviceMemory: 8,
  devicePixelRatio: 1.25,
  maxTouchPoints: 0,
});

Todos los switches

Filtra por nombre o efecto, o limita la lista a un subsistema. Haz clic en un switch para leer qué hace y ver su forma válida más corta.

Ejemplos

Estos son conjuntos de flags de línea de comandos en bruto. Para flujos completos en Python y Node, consulta Ejemplos.

Una identidad de Windows completa y coherente:

--fingerprint=acme-tenant-7 \
--fingerprint-platform=windows \
--fingerprint-brand=Chrome \
--accept-lang=en-US,en \
--lang=en-US \
--timezone=America/New_York \
--fingerprint-hardware-concurrency=8

Una identidad de Windows con cadenas de GPU personalizadas, en el formato en que las reporta ANGLE en Windows:

--fingerprint=42 \
--fingerprint-platform=windows \
--fingerprint-gpu-vendor="Google Inc. (NVIDIA)" \
--fingerprint-gpu-renderer="ANGLE (NVIDIA, NVIDIA GeForce RTX 3060 (0x00002504) Direct3D11 vs_5_0 ps_5_0, D3D11)"

Las cadenas cambian lo que se reporta, no lo que se dibuja: los píxeles siguen saliendo de la GPU de esta máquina. Indica la GPU con la que realmente renderizas, o usa el canvas bridge. La plataforma macos en el build abierto solo cambia las cadenas de identidad (UA, client hints, navigator.platform); en el build con licencia desde 155 r47 describe una Mac real, con el chip, los hilos, la memoria, la pantalla, el renderer gráfico, la versión de macOS y las voces que corresponden. Y android es una persona móvil de tipo best-effort.

Fija una ubicación junto con su zona horaria para que la geolocalización y el reloj coincidan:

--fingerprint=nyc-1 \
--timezone=America/New_York \
--fingerprint-location=40.7128,-74.0060

Importa los valores de una máquina real

En lugar de un seed sintético, puedes reportar los valores exactos que reportó un Chrome real: cadenas de GPU + tabla de getParameter, pantalla, fuentes, voces, audio. Los valores se sustituyen; el renderizado lo sigue haciendo tu propia máquina, así que un perfil no les da a dos cuentas canvas distintos (eso lo consigue un seed de --fingerprint por cuenta). Usa uno u otro, no ambos: un perfil para los valores de una máquina real, un seed para separar el renderizado por cuenta. Toma un perfil de la biblioteca clearcote-profiles, una colección curada (miles de perfiles de máquinas reales, etiquetados por fabricante de GPU), o captura el tuyo con el recolector; luego cárgalo y comprueba que se cargó:

import { launch } from "clearcote";
// path to a captured .json profile, a profile object, or a JSON string
const browser = await launch({ fingerprintProfile: "./real-machine.json" });
// fields present in the profile override what the browser would report;
// absent fields keep the browser's defaults. Pass no fingerprint seed alongside a profile.

Flujo de captura: abre la página del recolector en un Chrome real que quieras clonar, exporta el JSON y pásalo con fingerprintProfile (SDK) / --fingerprint-profile (motor). Verifícalo con tools/fingerprint-collect/verify_profile.py.

Qué hace cada parche

Cada switch del build abierto corresponde a un parche legible del motor: los diffs están en patches/, con un resumen de una línea de cada uno en patches/README.md. Los switches marcados como “build con licencia” vienen del conjunto de parches propio del build con licencia, que no es público.

La coherencia importa más que cualquier valor aislado: mantén la plataforma, la zona horaria, la configuración regional y la GPU plausibles en conjunto. Consulta Arquitectura para ver cómo el motor las mantiene consistentes, y Cómo funciona la detección para entender por qué esto es mejor que el spoofing desde JavaScript.