'Simulación de escritura manual: ¿qué hay "bajo el capó" de los navegadores antidetect más populares?'

Introducción

Hoy hablaremos de una función que se ha convertido en parte esencial del flujo de trabajo de cualquier usuario de navegadores antidetect.

Paste Like Human Print (también conocido como escritura humana simulada, o PLHP) es una emulación de escritura desde el portapapeles que imita el comportamiento de un usuario real.

Es una herramienta indispensable que ahorra mucho tiempo y elimina tareas rutinarias cuando se trabaja en el ámbito del multi-cuenta. Su objetivo principal es minimizar el riesgo de ser detectado o limitado por los sistemas antifraude al introducir texto en formularios web.

Cada producto nombra esta funcionalidad de manera diferente:

• Human Typing Simulation
• Paste as human typing
• Human typing emulation
• Smart Paste

Linken Sphere fue el primer navegador antidetect en implementar la función de escritura humana simulada y ofrecerla al mercado a finales de 2017. En ese entonces, la mayoría de sus competidores no se apresuraban a incluir una función similar, alegando que no era muy solicitada por el público general. Sin embargo, la práctica demostró lo contrario: pocos años después, esta tecnología fue implementada en casi todos los productos serios del sector, convirtiéndose en un estándar de la industria.

La influencia del método de entrada en el éxito de tu trabajo

En la práctica, a menudo se utilizan datos previamente preparados, como por ejemplo:

• Nombres, usuarios y correos electrónicos al registrar cuentas
• Datos de pago al crear cuentas publicitarias
• Textos de apelación para desbloquear cuentas publicitarias
• Comentarios y mensajes en actividades de SMM
• Etc.

No es ningún secreto que los sistemas antifraude llevan mucho tiempo rastreando y analizando el comportamiento de los usuarios. La introducción de texto en formularios no es una excepción. En la gran mayoría de los casos, el método de entrada realmente importa.

Si simplemente pegas texto con la combinación habitual Ctrl+V / Cmd+V, esto puede parecer sospechoso para el sistema en comparación con la escritura manual. Como resultado, es posible que tu cuenta y tus acciones reciban mayor atención.

Por otro lado, aunque la escritura manual parece completamente natural, es casi impracticable al trabajar con un gran volumen de cuentas. Primero, porque es agotador. Segundo, porque tu estilo único de escritura puede ser utilizado para vincular sesiones entre sí. Sí, vincular cuentas por el patrón de escritura no es paranoia — es una realidad. Más adelante mostraremos una forma visual de comprobar este tipo de detecciones.

Por lo tanto, la mejor solución sigue siendo Paste Like Human Print, diseñado para resolver todos los problemas mencionados. ¿Es el PLHP una panacea? Todo depende de su implementación técnica específica. Por eso realizamos nuestra propia investigación sobre los navegadores antidetect más populares del mercado.

Antes de pasar a los resultados, revisemos algunos aspectos técnicos clave que te ayudarán a comprender mejor cómo funciona el mecanismo de entrada en los navegadores.

¿Qué tipos de eventos de teclado existen y cuándo se utilizan?

Existen tres eventos principales de teclado: keydown, keypress y keyup. En los navegadores modernos (incluido Chrome), keydown y keyup son relevantes, mientras que keypress se considera obsoleto (aunque todavía puede activarse al escribir).

• keydown – ocurre al presionar una tecla y se activa para cualquier tecla (incluidas las teclas de función como Alt, Shift, etc.). Se utiliza para reaccionar en el momento de la pulsación (por ejemplo, para atajos de teclado o videojuegos). Si se mantiene presionada una tecla (por ejemplo t), se genera repetición automática: un evento keydown inicial seguido de eventos keydown repetidos (con event.repeat = true) hasta que se suelta la tecla.
• keypress – (obsoleto) se activa cuando se presiona una tecla que genera un carácter. Se usaba históricamente para rastrear la entrada de caracteres imprimibles (letras, números, etc.), mientras que keydown/keyup rastrean la pulsación física. No se genera para teclas que no insertan caracteres (como Shift o flechas), y actualmente se considera no recomendado. En su lugar, se recomienda usar event.key junto con keydown, o eventos de entrada específicos (ver más abajo).
• keyup – ocurre al soltar una tecla (una vez finalizada la pulsación). Se utiliza para manejar el evento después de que el usuario suelta la tecla — por ejemplo, para ejecutar una acción una vez ingresado un carácter o para detectar que la tecla ya no está activa.

Atributos obsoletos del teclado: ¿qué son charCode, keyCode y which, y por qué no se recomienda usarlos?

charCode, keyCode y which son propiedades del objeto de evento del teclado provenientes de versiones antiguas del DOM (legacy). Representaban el código de la tecla o del carácter, pero ahora están obsoletas y no se recomienda su uso. Los estándares modernos utilizan en su lugar las propiedades event.key y event.code.

Aquí tienes una descripción breve de cada propiedad legacy y por qué fue reemplazada:

Propiedad	Descripción (legacy)	Estado y reemplazo
event.keyCode	Código numérico de la tecla (generalmente correspondiente al código ASCII del carácter sin modificadores). Se usa en eventos keydown/keyup.	Obsoleto – en desuso. Varía entre navegadores y distribuciones del teclado, especialmente para caracteres con Shift/Alt. Usa event.key o event.code.
event.charCode	Código numérico Unicode del carácter, generado solo en el evento keypress (para teclas que ingresan texto).	Obsoleto – reemplazado por event.key, que devuelve directamente el carácter ingresado.
event.which	Propiedad unificada que devolvía el código de tecla o carácter, dependiendo del tipo de evento: duplicaba keyCode en keydown/keyup y charCode en keypress. También usada para botones del mouse.	Obsoleto – no estandarizado. Diferentes navegadores pueden devolver valores distintos. Para teclado usa event.key/event.code. Para mouse, usa event.button.

Modificadores (Shift, Ctrl, Alt, Meta): ¿cómo funcionan getModifierState() y sus propiedades?

Los eventos de teclado incluyen propiedades que indican el estado de las teclas modificadoras, así como un método para verificarlas.

• Propiedades event.shiftKey, event.ctrlKey, event.altKey y event.metaKey son true si la tecla modificadora correspondiente estaba presionada al generarse el evento. Por ejemplo, con la combinación Ctrl+X, el evento keydown de la tecla "X" tendrá ctrlKey = true. La propiedad metaKey representa la tecla Meta (en Windows: tecla ⊞ Windows, en Mac: ⌘ Command). Estas propiedades booleanas te permiten saber si Shift, Ctrl, Alt o Meta estaban presionadas junto a otra tecla.
• Método event.getModifierState(key) devuelve true o false dependiendo de si el modificador especificado está activo en ese momento. El parámetro key es una cadena como "Shift", "Control", "Alt", "Meta" o teclas de bloqueo como "CapsLock", "NumLock". Este método también devuelve true si la tecla está activada (por ejemplo, si CapsLock está encendido). Esto permite verificar el estado de modificadores que no tienen propiedades individuales.

Atributos de eventos (UI Events): ¿qué significan las propiedades key, code, location, repeat, isComposing, inputType, data?

El objeto moderno KeyboardEvent proporciona una variedad de propiedades con información sobre la tecla presionada. Además, los eventos InputEvent generados durante la introducción de texto ofrecen atributos adicionales.

A continuación se presentan los principales atributos y su significado:

Property	Value (what it represents)
key	Cadena que representa el valor de la tecla según la distribución del teclado y los modificadores. Para caracteres imprimibles, es el carácter introducido (por ejemplo, "a" o "A" según Shift); para teclas especiales — un nombre predefinido como "Enter", "Escape", etc.
code	Cadena que indica el código físico de la tecla en el teclado, independiente del layout. Refleja la posición física del teclado (scan code). Por ejemplo, presionar la tecla en la posición de "Q" siempre devuelve event.code = "KeyQ", sin importar el carácter que produce esa tecla. Útil para juegos o controles, pero no para obtener el carácter introducido — usa key para eso.
location	Número que indica la ubicación física de la tecla en el teclado. Ayuda a distinguir teclas idénticas en diferentes lados (ej. Shift izquierdo/derecho). Valores comunes: 0 (estándar), 1 (izquierda), 2 (derecha), 3 (numpad).
repeat	Booleano: true si el evento se genera repetidamente al mantener presionada la tecla. En el primer keydown es false; en eventos repetidos es true. En keyup siempre es false.
isComposing	Booleano: true si el evento ocurre durante una composición activa (ej. entrada mediante IME, como en chino/japonés). Se activa entre compositionstart y compositionend.
inputType	(Propiedad de InputEvent) Cadena que indica el tipo de modificación realizada en el campo. Ejemplos: "insertText", "deleteContentBackward", "insertFromPaste", etc. Útil para detectar cómo se modificó el contenido.
data	(Propiedad de InputEvent) Cadena con el texto introducido como resultado del evento. Puede ser vacío si se eliminaron caracteres, o null si el evento no está relacionado con datos textuales directamente.

¿Cómo interactúan los eventos del teclado con los campos de entrada?

Cuando el foco está en un campo de entrada (como <input> o <textarea>), las pulsaciones de teclas generan tanto eventos de teclado como eventos de entrada de texto.

La secuencia típica es la siguiente:

1. keydown – ocurre al presionar cualquier tecla. El evento se dispara en el elemento enfocado (el campo en sí). En esta etapa, el navegador todavía no ha insertado el carácter. Puedes evitar el comportamiento por defecto con event.preventDefault() para bloquear la escritura.
2. beforeinput – después (para teclas que generan texto), el campo emite un evento beforeinput, señalando la intención de modificar el contenido. Justo después se lanza el evento input, indicando que el contenido fue actualizado (por ejemplo, que se agregó una letra). Puedes consultar event.inputType y event.data para saber qué ocurrió exactamente (inserción, eliminación, pegado, etc.). Nota: en navegadores antiguos se usaba keypress, pero en Chrome modernos se utiliza beforeinput/input.
3. keyup – finalmente, al soltar la tecla, ocurre un evento keyup en el mismo elemento.

Los eventos de teclado (keydown/keyup) burbujean desde el elemento de entrada hacia arriba en el DOM (hasta document o incluso window). Por eso, pueden capturarse directamente en el campo, en elementos padres, o a nivel global. Si necesitas reaccionar específicamente al cambio de contenido textual (incluyendo pegado desde portapapeles o entrada por voz), lo mejor es usar el evento input, que se dispara ante cualquier modificación del valor del campo. Por otro lado, KeyboardEvent es útil para manejar interacciones con teclas directamente — como interceptar Escape, flechas, teclas de función, combinaciones, etc., o para prevenir o modificar un carácter antes de que aparezca en el campo.

¿Dónde verificar la escritura manual y Paste Like Human Print?

Para obtener una visión completa, las pruebas se realizan en varias etapas.

Keyboard Event Viewer

Este verificador proporciona la máxima información sobre eventos de entrada, incluidos atributos Legacy, Modifiers y UI Events.

1. Verificación de la escritura manual

Usando un navegador antidetección, ingresa manualmente los caracteres del conjunto de prueba uno por uno. Luego, compara los eventos generados con los de la escritura manual en Chrome real, en el mismo dispositivo.

2. Verificación de Paste Like Human Print

Utiliza la función Paste Like Human Print para insertar los mismos caracteres en el navegador antidetección. Después, compara los resultados con la escritura manual en Chrome real, en el mismo dispositivo.

Comportamiento esperado: en ambos casos, los eventos de entrada deben coincidir al máximo con los generados por Chrome real durante la escritura manual.

TypingDNA

Este servicio está diseñado para reconocer patrones de escritura analizando los intervalos entre pulsaciones de teclas, con el objetivo de identificar estilos únicos de entrada.

1. Verificación de la escritura manual

Usa un navegador antidetección para crear una cuenta, introduciendo datos únicos (correo, contraseña) manualmente. Después, repite el inicio de sesión varias veces utilizando los mismos datos, también de forma manual.

2. Verificación de Paste Like Human Print

Crea una cuenta pegando los datos mediante la función Paste Like Human Print. Luego, inicia sesión varias veces usando nuevamente PLHP.

Comportamiento esperado: registro e inicio de sesión exitosos, con incremento en el contador de Enrollments tras cada login. Un aumento en el contador indica que el sistema detecta coincidencia en el patrón de escritura entre sesiones.

Detalles adicionales

• Conjunto de caracteres de prueba: tT@.
• Sistema operativo: Windows 11
• La función PLHP fue activada desde el menú contextual (clic derecho) en todos los casos, para evitar interferencia de atajos de teclado como Ctrl+V.

Resultados de las pruebas

Linken Sphere 2 v2.4.0 ⭐

Keyboard Event Viewer

El comportamiento durante la escritura manual coincide completamente con el funcionamiento de Chrome real.

Al comparar Paste Like Human Print con la escritura manual en Chrome, los eventos generados coinciden totalmente dentro del conjunto de caracteres de prueba. Así es como debe funcionar una implementación correcta de PLHP.

La captura de pantalla muestra una comparación detallada entre el comportamiento de PLHP y la escritura manual en Chrome.

TypingDNA

La entrada manual funciona correctamente.

Al usar PLHP, el registro e inicio de sesión se completan con éxito y el contador de Enrollments aumenta — lo que indica que el sistema detecta un patrón de escritura estable y consistente dentro de una misma sesión.

Octo Browser v2.5.5

Keyboard Event Viewer

El comportamiento durante la escritura manual coincide completamente con el funcionamiento habitual de Chrome.

PLHP está mejor implementado que en la mayoría de las demás soluciones, pero aún presenta algunas deficiencias.

Al comparar el comportamiento de PLHP con la escritura manual en Chrome, se observaron las siguientes particularidades:

• Al escribir caracteres en mayúscula como T y algunos símbolos especiales como @, se utiliza la tecla Shift, pero su estado no queda reflejado en los Modifiers (getModifierState, shift).

TypingDNA

La escritura manual funciona correctamente.

Al usar PLHP, el contador de Enrollments no aumenta, o bien se producen errores durante el registro o inicio de sesión. Esto sugiere que cada vez se genera un nuevo patrón de escritura, lo que puede ser interpretado negativamente por los sistemas antifraude.

Dolphin Anty v2025.152.125.0

Keyboard Event Viewer

Escritura manual: al presionar teclas como Shift, Meta o Control (por ejemplo, al escribir T en mayúscula o caracteres como @ que requieren modificadores), se registra un evento keypress adicional con valores cero en charCode, keyCode y which.

Esto puede servir como señal para los sistemas antifraude: incluso durante la entrada manual, el comportamiento de Dolphin Anty difiere del estándar, lo que podría llevar a la detección del navegador antidetección.

PLHP en Dolphin Anty es la peor implementación del mercado.

Al comparar su comportamiento con la escritura manual en Chrome real, se detectaron los siguientes problemas:

• En lugar de emular escritura real, se pega texto carácter por carácter. El valor de inputType en este caso es insertFromPaste, lo que delata que es una acción de pegado.
• Incluso ese pegado hecho con PLHP es diferente al pegado estándar desde el menú contextual (clic derecho), ya que no se generan eventos beforeinput.

Aunque visualmente parezca funcionar como en otros navegadores, un análisis técnico muestra diferencias evidentes.

TypingDNA

La entrada manual funciona correctamente.

Al usar PLHP, el sitio no detecta ninguna entrada, lo cual era esperable: se trata de una operación de pegado, no de una emulación real de escritura.

Undetectable v2.32.1

Keyboard Event Viewer

El comportamiento durante la escritura manual coincide completamente con el funcionamiento habitual de Chrome.

Al comparar PLHP con la escritura manual en Chrome real, se detectaron los siguientes problemas:

• En los eventos keydown y keyup, los valores legacy keyCode y which son siempre 0, lo cual es incorrecto — una entrada válida requiere códigos reales de tecla.
• En los eventos keydown, keyup y keypress, no se incluye el atributo code de UI Events.
• Al escribir caracteres en mayúscula como T o símbolos especiales como @, la tecla Shift no se activa — no hay eventos keydown / keyup, por lo tanto, los modificadores no se registran.

TypingDNA

La entrada manual funciona correctamente.

Al usar PLHP, el contador de Enrollments no aumenta o se producen errores durante el registro o inicio de sesión. Esto sugiere que en cada intento se genera un nuevo patrón de escritura, algo que puede ser considerado riesgoso por los sistemas antifraude.

Adspower v6.12.6.0

Keyboard Event Viewer

El comportamiento durante la escritura manual coincide completamente con el funcionamiento habitual de Chrome.

Al comparar PLHP con la escritura manual en Chrome real, se detectaron los siguientes problemas:

• En los eventos keydown, keyup y keypress, los atributos legacy charCode, keyCode y which siempre son 0 en lugar de los valores esperados.
• En esos mismos eventos, faltan los atributos key y code de UI Events.
• Los modificadores (Shift, Meta, etc.) se comportan de manera antinatural — se registra el mismo patrón de activación sin importar qué se está escribiendo, incluso cuando no deberían activarse.
• En el evento input, la propiedad data siempre es 'null'.
• Falta el evento beforeinput. En su lugar, el evento input se lanza dos veces, y solo el segundo contiene inputType = "insertText".
• El orden de los eventos está alterado: no sigue la secuencia natural de escritura y permanece incorrecto sin importar el contenido.

TypingDNA

La entrada manual funciona correctamente.

Al usar PLHP, los datos no se insertan en el formulario, y aparece el error: "This input field does not support Paste It".

0detect browser (ex AQUM) v3.7.40

Keyboard Event Viewer

El comportamiento durante la escritura manual coincide completamente con el funcionamiento habitual de Chrome.

Al comparar PLHP con la escritura manual en Chrome real, se detectaron los siguientes problemas:

• En los eventos keydown y keyup, los atributos legacy charCode, keyCode y which siempre son 0 en lugar de los valores esperados.
• En los eventos keydown, keyup y keypress faltan los atributos key y code de UI Events.
• Al escribir caracteres en mayúscula como T y símbolos especiales como @, la tecla Shift no se activa — no se generan eventos keydown / keyup, por lo tanto, los modificadores no se registran.

TypingDNA

La entrada manual funciona correctamente.

Al usar PLHP, en algunos campos de entrada no ocurre nada — los datos no se insertan. Sin embargo, en otros campos (como la barra de búsqueda de Google), sí funciona correctamente.

GoLogin v3.3.83.79

Keyboard Event Viewer

El comportamiento durante la escritura manual coincide completamente con el funcionamiento habitual de Chrome.

Al comparar el comportamiento de PLHP con la escritura manual en Chrome real, se identificaron los siguientes problemas:

• En los eventos keydown y keyup, los atributos legacy charCode, keyCode y which siempre son 0 en vez de los valores correctos.
• En los eventos keydown, keyup y keypress faltan los atributos key y code de UI Events.
• Al escribir caracteres en mayúscula como T y símbolos como @, la tecla Shift no se activa — no se generan eventos keydown / keyup y los modificadores no se registran.

TypingDNA

La escritura manual funciona correctamente.

Al usar PLHP, el contador de Enrollments no aumenta o se producen errores durante el inicio de sesión o el registro. Esto indica que se forma un nuevo patrón de entrada cada vez, lo que puede ser interpretado como inestable o sospechoso por los sistemas antifraude.

Vision v3.0.38

Keyboard Event Viewer

El comportamiento durante la escritura manual coincide completamente con el funcionamiento habitual de Chrome.

La implementación de PLHP en Vision es prácticamente idéntica a la de Dolphin Anty, compartiendo los mismos defectos. En su estado actual, es una de las peores soluciones entre todos los productos probados.

Al comparar el comportamiento de PLHP con la escritura manual en Chrome real, se identificaron los siguientes problemas:

• En lugar de emular escritura real, se utiliza una inserción carácter por carácter. El valor de inputType es insertFromPaste, lo que delata inmediatamente que se trata de un pegado desde el portapapeles.
• Incluso ese pegado, realizado mediante PLHP, difíere del pegado estándar a través del menú contextual, ya que no se generan eventos beforeinput.

La captura de pantalla muestra comparaciones técnicas que evidencian estas diferencias.

TypingDNA

La escritura manual funciona correctamente.

Al usar PLHP, el sitio no detecta ninguna entrada — lo cual es esperado, ya que se trata de un pegado, no de una emulación de escritura.

Bonus: Asociación de cuentas mediante el estilo único de escritura manual del usuario

Lo mencionamos en la introducción, y ahora lo demostraremos en la práctica. A continuación, un método de verificación simple que prueba que: la asociación de cuentas mediante el estilo de escritura manual no solo es posible, sino que ya se utiliza activamente por sistemas antifraude.

Y esto funciona incluso entre sesiones distintas, perfiles diferentes o dispositivos separados. El principal identificador en este caso eres tú — y tu patrón de escritura único.

Procedimiento de prueba

1. Crea una primera sesión/perfil en tu navegador antidetección.

2. Accede a la página de prueba TypingDNA

3. Crea un login y contraseña únicos, y anótalos (no necesitas verificar el correo electrónico).

4. Regístrate escribiendo los datos manualmente.

5. Inicia sesión varias veces con los mismos datos (recomendado: 4–5 veces) para que el contador de Enrollments aumente y el modelo de comportamiento se refine.

6. Crea una nueva sesión o perfil (incluso puedes usar otro dispositivo).

7. Vuelve a ingresar a TypingDNA

8. Inicia sesión nuevamente con las mismas credenciales — también escritas manualmente, pero desde esta nueva sesión/dispositivo.

Resultados de la entrada manual

Como resultado del acceso desde otro dispositivo, el contador de Enrollments aumenta. Esto indica que el sistema reconoció tu estilo de escritura único y asoció dos sesiones o dispositivos completamente diferentes.

Esta es una de las amenazas principales que una implementación sólida de PLHP debe mitigar.

Resultados de PLHP en Linken Sphere

Al perfeccionar la función PLHP en Linken Sphere, se consideró específicamente este factor conductual. Cada sesión en Linken Sphere genera su propio patrón de escritura único.

Por eso, una prueba similar utilizando PLHP en distintas sesiones produce un resultado totalmente distinto.

Primera sesión

Registro e inicio de sesión exitosos. El contador de Enrollments aumenta.

Segunda (o cualquier otra) sesión

Pueden darse dos escenarios:

• Ocurre un error de inicio de sesión (el nuevo patrón no coincide con el anterior).
• O bien el acceso tiene éxito, pero el sistema no incrementa el contador de Enrollments, y solicita reintroducir las credenciales — para registrar un nuevo patrón.

Esto demuestra que cada sesión en Linken Sphere genera una huella conductual independiente, como debe ser en una implementación correcta de PLHP. Este enfoque previene eficazmente la vinculación entre cuentas al usar PLHP en diferentes sesiones.

¿Estás seguro de que el PLHP de tu navegador antidetección está funcionando correctamente? ¿O podría ser simplemente otro factor de riesgo más?

Pon a prueba tu navegador tú mismo — y descubre si realmente te protege o, por el contrario, facilita tu desanonimización.

Conclusiones

Producto (versión)	Eventos – manual	Eventos – PLHP	TypingDNA – manual	TypingDNA – PLHP
Linken Sphere 2 v2.4.0 ⭐	Excelente	Excelente	Excelente	Excelente
Octo Browser v2.5.5	Excelente	Bueno	Excelente	Malo
Dolphin Anty v2025.152.125.0	Malo	Terrible	Excelente	Terrible
Undetectable v2.32.1	Excelente	Malo	Excelente	Malo
Adspower v6.12.6.0	Excelente	Terrible	Excelente	Terrible
0detect browser (ex AQUM) v3.7.40	Excelente	Malo	Excelente	Terrible
GoLogin v3.3.83.79	Excelente	Malo	Excelente	Malo
Vision v3.0.38	Excelente	Terrible	Excelente	Terrible

Según los resultados de esta prueba comparativa, queda claro que no todas las implementaciones de Paste Like Human Print son igual de fiables o seguras.

Linken Sphere es el líder indiscutible. Es el único producto que demostró un comportamiento correcto tanto en entrada manual como con PLHP.

Su comportamiento a nivel de eventos coincide completamente con la escritura manual en Chrome, y los resultados en TypingDNA confirman una implementación correcta de patrones de entrada independientes por sesión. PLHP no solo “funciona” — funciona correctamente.

Además de introducir innovaciones — muchas de las cuales fuimos los primeros en llevar a la industria — mantenemos activamente nuestras funciones existentes y respondemos rápidamente a nuevas amenazas de los sistemas antifraude.

Y lo más importante: no confíes ciegamente en un producto solo porque alguna vez te funcionó. El antifraude evoluciona constantemente, así que la herramienta que utilizas para conectarte no solo debe funcionar — debe ir siempre un paso por delante.