Cómo funciona la detección de bots y por qué Clearcote parchea el motor
El enfoque habitual parchea navigator.webdriver, falsea el vendor de WebGL y sobrescribe navigator.plugins desde un script. Los detectores lo siguen señalando, y el motivo es estructural: no se trata de una propiedad más que quedó sin cubrir.
Una falsificación en JavaScript se delata sola
Una falsificación en JS es una función colocada donde debería haber una nativa. Un detector deja de lado el valor devuelto y examina si lo que lo devuelve es nativo:
| La señal delatora | Por qué atrapa una falsificación en JS |
|---|---|
toString que se delata solo | Un método nativo, convertido a cadena, da function get vendor() { [native code] }; un override da su propio código fuente: basta un .toString() para atraparlo. |
Descriptor / hasOwnProperty | getOwnPropertyDescriptor expone las propiedades redefinidas, y hasOwnProperty('toString') devuelve true en una función manipulada, donde una nativa devuelve false. |
TypeError con un this incorrecto | Los getters nativos lanzan un TypeError específico con el receptor equivocado; un shim ingenuo no dice nada, y ese silencio es la señal. |
| Readquisición desde otro realm | Un detector toma un Function.prototype.toString intacto de un iframe o un Web Worker nuevo y lo aplica a tu getter, desde un realm distinto al de tu parche en el mundo principal. Devuelve tu código fuente. Atrapado. |
Clearcote no tiene esa capa. El getter de navigator.userAgent es el getter de C++: reporta [native code] porque es código nativo, idéntico en todos los realms: frame principal, iframe y worker. No hay ningún secuestro de JavaScript que detectar.
Las tres capas de la detección de bots
Los sistemas antibot modernos leen tres superficies estructuralmente distintas, en tres lugares separados. Rara vez una sola herramienta resuelve las tres:
| Capa | Las señales delatoras | Dónde está la solución | Clearcote |
|---|---|---|---|
| A · driver / binario | variables cdc_ de ChromeDriver, la superficie del protocolo WebDriver | Controlar CDP directamente, sin chromedriver | ✅ un binario de Chromium normal, sin artefactos de driver |
| B · efectos secundarios de CDP | fugas de Runtime.enable, init-scripts inyectados, ejecución en el mundo principal, el viewport que la automatización usa por defecto | La capa de control / cliente CDP | ✅ el motor neutraliza la fuga de Runtime.enable, el SDK no inyecta scripts por defecto y las opciones de lanzamiento por defecto evitan el viewport típico de la automatización (dónde ejecuta tu cliente sus propios scripts depende de él) |
| C · superficie de huella digital | canvas, WebGL, audio, fuentes, navigator, TLS, en el frame principal, iframes y workers | El motor (C++), porque los overrides en JS se delatan solos | ✅ esto es Clearcote |
Lo que más importa: ninguna costura entre lo falso y lo real
Como los controles viven en el motor, el JavaScript que ve una página y el handshake de red que hay debajo salen de un mismo Chromium real. No hay ninguna costura entre JS falseado y TLS real que pueda atrapar una verificación cruzada, que es justo el modo de fallo que delata a las herramientas basadas en inyección. Un solo seed de --fingerprint produce una única máquina, internamente consistente, en canvas, WebGL, audio, fuentes y hardware. El handshake de TLS y HTTP/2 que hay debajo es el propio del motor, y coincide porque la persona reporta la versión que el motor realmente es: deja brandVersion sin definir para que siga siendo así.
Y cuando el propio ruido es la señal delatora, desactívalo: canvas y WebGL devuelven sus valores naturales mientras la identidad falseada sigue activa (el audio renderizado y los client rects no se perturban en ningún caso, y los escalares de frecuencia/latencia de AudioContext siguen a la persona; aquí está el porqué):
await launch({ fingerprint: "u1", fingerprintNoise: false }); // identity on, per-site farbling offCon el ruido desactivado, las identidades de una misma máquina comparten un mismo hash de canvas. canvasNoise: false desactiva solo canvas 2D y mantiene el ruido de WebGL (build con licencia, 150 r12+).
Coherencia de red y de configuración regional
La persona es solo la mitad: la zona horaria, el idioma y la dirección de WebRTC también tienen que coincidir con el lugar de donde sale el tráfico. Detrás de un proxy, lanza con geoip: el SDK consulta la IP de salida del proxy, configura la zona horaria, la lista de idiomas, la geolocalización y la dirección de WebRTC para esa región, y detiene el lanzamiento si no puede resolverla. Sin esa opción, la zona horaria sigue al idioma (en-US significa Nueva York), sin importar en qué país esté el proxy. Consulta Playwright & Puppeteer para ver las opciones.
Por eso Clearcote parchea el motor en C++ en lugar de inyectar JavaScript. Consulta Flags de huella digital para ver qué controlas, y Arquitectura para ver cómo el motor mantiene todas las señales coherentes entre sí.
Lecturas relacionadas