Introducción

Hoy hablaremos sobre una función que se ha convertido en una parte integral del flujo de trabajo de cada usuario de navegadores anti-detect.

Paste Like Human Print (también conocido como entrada similar a la humana, o abreviado como HLI) es una emulación de entrada de texto desde el portapapeles que imita el comportamiento de un usuario real.

Es una herramienta indispensable que ahorra mucho tiempo y elimina acciones rutinarias al trabajar en el ámbito de multi-cuentas. Su objetivo principal es minimizar el riesgo de restricciones por parte de los sistemas antifraude al introducir texto en formularios en sitios web.

Cada producto llama a esta función de manera diferente:

• Simulación de escritura humana
• Pegar como escritura humana
• Emulación de escritura humana
• Pegado inteligente

Linken Sphere fue el primer navegador anti-detect en implementar entrada similar a la humana y ofrecerla al mercado a finales de 2017. En ese momento, la mayoría de los competidores no se apresuraron a introducir una función similar, alegando que no tenía una gran demanda entre el público general. Sin embargo, la práctica demostró lo contrario: en un par de años, la tecnología fue implementada en casi todos los productos importantes del segmento, convirtiéndose en un estándar de la industria.

El impacto del método de entrada en tu éxito

En la práctica, a menudo trabajamos con datos pre-preparados, por ejemplo:

• Nombres, inicios de sesión y direcciones de correo electrónico al registrar cuentas
• Datos de pago al crear cuentas publicitarias
• Textos de apelación al desbloquear cuentas publicitarias
• Comentarios y mensajes para actividades de SMM
• Y así sucesivamente

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

Si simplemente pegas texto usando la combinación familiar Ctrl+V / Cmd+V, puede parecer sospechoso para el sistema en comparación con escribirlo manualmente. Como resultado, tu cuenta y tus acciones podrían estar bajo mayor vigilancia.

Por otro lado, escribir manualmente, aunque parece lo más natural, es casi impráctico cuando se manejan grandes volúmenes de cuentas. Primero, es simplemente agotador. Segundo, tu patrón único de escritura puede ser usado para vincular sesiones entre sí. Sí, asociar cuentas por estilo de escritura no es paranoia — es la realidad en la que vivimos. Más adelante, mostraremos un método para probar visualmente este tipo de detecciones.

Por lo tanto, la solución óptima sigue siendo Paste Like Human Print, que está diseñado para eliminar todos los problemas mencionados. ¿Es HLI una solución mágica? Todo depende de la implementación técnica específica. Por eso realizamos nuestra propia investigación sobre los navegadores anti-detect más populares del mercado.

Antes de pasar a los resultados, revisemos los aspectos técnicos clave que 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?

Hay 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 se activa durante la escritura).

• keydown – ocurre cuando se presiona una tecla y se activa para cualquier tecla (incluyendo teclas de control como Alt, Shift, etc.). Se usa para responder inmediatamente a las pulsaciones (por ejemplo, para atajos o juegos). Si se mantiene presionada la tecla (por ejemplo, t), se activa la repetición automática: un keydown al inicio y 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. Históricamente se utilizaba para detectar entrada de caracteres imprimibles (letras, dígitos, etc.), mientras que keydown/keyup rastreaban las pulsaciones físicas. No se activa para teclas que no producen caracteres (como Shift o flechas) y ahora se considera desactualizado. En su lugar, usa la propiedad event.key con keydown o usa eventos de entrada especializados (ver más abajo).
• keyup – ocurre cuando se suelta una tecla después de haber sido presionada. Se utiliza para manejar acciones después de que el usuario haya soltado la tecla — por ejemplo, para ejecutar una acción una vez que se ha escrito un carácter o para detectar que una tecla ya no está siendo presionada.

Atributos de Teclado Obsoletos: ¿Qué son charCode, keyCode y which, y por qué deberían evitarse?

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

Aquí tienes una breve descripción de cada propiedad heredada y por qué se dejó de usar:

Propiedad\tDescripción (legado)\tEstado y Reemplazo \ event.keyCode\tCódigo numérico de la tecla (generalmente coincide con el código ASCII del carácter sin modificadores). Se usa en eventos keydown / keyup.\tObsoleto – desactualizado. Varía entre navegadores y diseños de teclado, especialmente para caracteres imprimibles con Shift/Alt. Debe reemplazarse por event.key o event.code. \ event.charCode\tCódigo Unicode numérico del carácter, generado solo en el evento keypress (para teclas que producen texto).\tObsoleto – desactualizado. Se usaba para obtener el carácter durante keypress, ahora se reemplaza por event.key para obtener el carácter ingresado. \ event.which\tPropiedad unificada que devuelve el código de la tecla o carácter dependiendo del tipo de evento: básicamente duplica keyCode para keydown/keyup y charCode para keypress. También se usaba para botones del mouse.\tObsoleto – desactualizado. No está estandarizado (diferentes navegadores podían devolver valores distintos). Para entrada de teclado, usa event.key y event.code (para mouse – usa event.button).

Modificadores (Shift, Ctrl, Alt, Meta): ¿Cómo funcionan getModifierState() y las propiedades relacionadas?

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

• Las propiedades event.shiftKey, event.ctrlKey, event.altKey y event.metaKey son true si la tecla modificadora correspondiente estaba presionada en el momento en que se generó el evento. Por ejemplo, con la combinación Ctrl+X, el evento keydown para la tecla "X" tendrá ctrlKey = true. La propiedad metaKey corresponde a la tecla Meta (en Windows – tecla ⊞ Windows, en Mac – ⌘ Command). Estas propiedades booleanas permiten detectar si Shift, Ctrl, Alt o Meta estaban presionadas junto con otra tecla.
• El método event.getModifierState(key) devuelve true o false dependiendo de si el modificador especificado está activo en el momento del evento. El parámetro key es una cadena con el nombre de la tecla modificadora, como "Shift", "Control", "Alt", "Meta", o teclas de bloqueo como "CapsLock" y "NumLock". El método devolverá true si el modificador está actualmente presionado o habilitado (por ejemplo, si CapsLock está activado). Esto permite verificar el estado de teclas como CapsLock, que no se reflejan directamente en propiedades individuales del evento.

Atributos de Eventos de Interfaz: ¿Qué significan las propiedades key, code, location, repeat, isComposing, inputType y data?

El objeto moderno KeyboardEvent proporciona una variedad de propiedades con información sobre la tecla presionada. Además, los eventos InputEvent se generan durante la entrada de texto, ofreciendo propiedades adicionales.

Aquí están los principales atributos y sus significados:

Propiedad\tValor (lo que representa) key\tUna cadena que representa el valor de la tecla según el diseño del teclado y el estado de los modificadores. Para caracteres imprimibles, es el carácter real introducido (por ejemplo, \"a\" o \"A\" según Shift); para teclas especiales, un nombre predefinido (por ejemplo, \"Enter\", \"Escape\"). code\tUna cadena que indica el código físico de la tecla en el teclado. No depende del diseño actual; refleja la tecla específica presionada según su posición/código de escaneo (por ejemplo, presionar \"Q\" siempre da \"KeyQ\" sin importar el diseño). location\tUn número que indica la ubicación de la tecla en el teclado. Valores: 0 (Estándar), 1 (Izquierda), 2 (Derecha), 3 (Teclado numérico). repeat\tBooleano: true si el evento se activa repetidamente mientras se mantiene presionada la tecla (repetición de tecla). En el keydown inicial, es false; en eventos repetidos posteriores, es true. En keyup, siempre es false. isComposing\tBooleano: true si el evento ocurrió durante una sesión de composición (IME), por ejemplo, entre compositionstart y compositionend. inputType\t(Propiedad de InputEvent) Una cadena que indica el tipo de cambio realizado en el campo de entrada o contenido editable. Ejemplos: \"insertText\", \"deleteContentBackward\", \"insertFromPaste\", etc. data\t(Propiedad de InputEvent) Una cadena con los datos de texto insertados como resultado del evento de entrada. Puede estar vacía si se eliminaron caracteres o ser null si no está directamente asociada con datos de texto.

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

Cuando el foco está dentro de 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:

• keydown – ocurre cuando se presiona cualquier tecla. El evento se activa en el elemento enfocado (el propio campo de entrada). En esta etapa, el navegador aún no ha insertado el carácter en el campo. Puedes cancelar el comportamiento predeterminado aquí usando event.preventDefault() para bloquear la entrada de caracteres.
• beforeinput – luego (para teclas que producen caracteres), el campo emite un evento beforeinput, indicando la intención de cambiar el contenido. Inmediatamente después, se dispara el evento input, indicando que el contenido ha sido actualizado (por ejemplo, se añadió una letra). Puedes inspeccionar event.inputType y event.data en estos eventos para determinar qué ocurrió exactamente (entrada de carácter, eliminación de texto, pegado, etc.). Nota: en algunos casos antiguos, se podía disparar un evento keypress en lugar de beforeinput, pero en los navegadores modernos como Chrome, se utiliza beforeinput/input.
• keyup – finalmente, cuando se suelta la tecla, ocurre un evento keyup en el mismo elemento.

Los eventos de teclado keydown/keyup se propagan desde el elemento de entrada a través del árbol del DOM (desde document hasta window), por lo que pueden capturarse en el propio input, sus elementos padre o de forma global. Si necesitas responder específicamente a la entrada de texto en el campo (incluyendo entradas no provenientes del teclado como pegado desde el portapapeles o entrada por voz), es mejor usar el evento input, que se activa ante cualquier cambio en el valor del campo. KeyboardEvent, por su parte, es útil para manejar interacciones directas con teclas — por ejemplo, interceptar Escape, teclas de flechas, teclas de función, combinaciones, etc. Para entrada de caracteres, es más útil cuando necesitas prevenir o modificar el carácter escrito antes de que aparezca en el campo.

¿Dónde probar la entrada manual y el pegado como escritura humana?

Para una imagen completa, las pruebas se realizan en varias etapas.

Keyboard_Event_Viewer[https://w3c.github.io/uievents/tools/key-event-viewer.html]

Este comprobador proporciona la máxima información sobre eventos de entrada, incluidos los atributos heredados, modificadores y eventos de interfaz de usuario.

1. Prueba de entrada manual

Usando un navegador anti-detect, ingresa manualmente los caracteres del conjunto de prueba uno por uno. Luego, compara los eventos resultantes con los de la entrada manual en Chrome real en el mismo PC.

2. Prueba de pegado como escritura humana

Usando un navegador anti-detect, inserta los mismos caracteres utilizando la función de pegado como escritura humana. Compara los resultados con la entrada manual en Chrome real en el mismo dispositivo.

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

TypingDNA[https://www.typingdna.com/demo-login.html]

Este servicio se centra en reconocer patrones de escritura analizando los intervalos entre pulsaciones para detectar estilos de escritura únicos e identificar usuarios.

1. Prueba de entrada manual

Usando un navegador anti-detect, crea una cuenta ingresando manualmente datos únicos (correo electrónico, contraseña). Luego repite el proceso de inicio de sesión varias veces usando los mismos datos — también manualmente.

2. Prueba de pegado como escritura humana

Crea una cuenta pegando los datos usando la función de pegado como escritura humana. Luego inicia sesión varias veces, cada vez usando HLI para la entrada.

Usando un navegador anti-detect, crea una cuenta pegando los datos con la función de pegado como escritura humana. Luego inicia sesión múltiples veces, cada vez usando HLI para la entrada.

Comportamiento esperado: registro e inicio de sesión exitosos, con el contador de Inscripciones aumentando en cada inicio de sesión repetido. Un aumento en el contador indica coincidencia en el patrón de escritura entre sesiones.

Detalles adicionales

• Conjunto de caracteres de prueba: tT@.
• Sistema operativo: Windows 11
• La función de pegado como escritura humana se activó mediante el menú contextual (clic derecho) en todos los casos para evitar interferencias con atajos de teclado.

Resultados de la prueba

Linken Sphere 2 v2.4.0 ⭐

Visor de eventos del teclado

El comportamiento durante la entrada manual coincide completamente con el de Chrome normal.

Al comparar el pegado como escritura humana con la entrada manual real en Chrome, los eventos de entrada coinciden completamente dentro del conjunto de caracteres de prueba. Así es exactamente como debe funcionar un HLI bien implementado.

Una comparación detallada del comportamiento de HLI y la entrada estándar en Chrome se muestra en la captura de pantalla.

TypingDNA

La entrada manual funciona correctamente. Al usar HLI, el registro y el inicio de sesión son exitosos, y el contador de Inscripciones aumenta — lo que indica que el sistema detecta un patrón de escritura estable y repetible en una sola sesión.

Octo Browser v2.5.5

Visor de eventos del teclado

El comportamiento durante la entrada manual coincide completamente con Chrome estándar.

HLI está mejor implementado que en la mayoría de las otras soluciones, pero no está exento de fallos.

Al comparar el comportamiento de HLI con la entrada manual real en Chrome, se observaron las siguientes peculiaridades:

Al escribir caracteres en mayúscula como T y algunos caracteres especiales como @, se usa la tecla Shift, pero su estado no se refleja en los modificadores (getModifierState, shift)

La comparación detallada del comportamiento de HLI y la entrada normal en Chrome se muestra en la captura de pantalla.​

TypingDNA

La entrada manual funciona correctamente. Al usar HLI, el contador de Inscripciones no aumenta o se producen errores de registro/inicio de sesión. Esto indica que se forma un nuevo patrón de escritura cada vez, lo cual puede ser percibido negativamente por los sistemas antifraude.

Dolphin Anty v2025.152.125.0

Visor de eventos del teclado

Entrada manual: al presionar teclas como Shift / Meta / Control (por ejemplo, al escribir la T mayúscula o caracteres como @ que requieren Shift), se registra un evento de pulsación adicional con valores cero para charCode / keyCode / which.

Esto puede servir como un desencadenante para los sistemas antifraude: incluso durante la entrada manual, el comportamiento de Dolphin Anty se desvía del estándar, lo que puede llevar a la detección del navegador anti-detect.

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

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

En lugar de emular una escritura real, usa un pegado primitivo carácter por carácter. El valor de inputType en este caso es insertFromPaste, lo cual revela inmediatamente que se trata de un pegado desde el portapapeles.

Incluso el propio pegado realizado con HLI difiere del pegado estándar mediante el menú contextual (clic derecho), ya que no hay eventos de beforeinput.

Sí, visualmente puede parecer que todo funciona igual que en otros productos. Sin embargo, un análisis detallado revela claras diferencias.

La comparación detallada del comportamiento de HLI y la entrada estándar en Chrome se muestra en la captura de pantalla.

TypingDNA

La entrada manual funciona correctamente. Al usar HLI, el sitio no detecta ninguna entrada, lo cual es esperado: se trata de una operación de pegado, no de una emulación real de escritura.

Undetectable v2.32.1

Visor de eventos del teclado

El comportamiento durante la entrada manual coincide completamente con Chrome estándar.

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

En los eventos keydown y keyup, los valores Legacy de keyCode y which siempre son 0, lo cual es inaceptable — una entrada adecuada requiere códigos de tecla válidos

El atributo code de los eventos UI no está presente en los eventos keydown, keyup o keypress

Al escribir caracteres en mayúscula como T y caracteres especiales como @, la tecla Shift no se activa — no hay eventos keydown / keyup y, por lo tanto, no se activan los modificadores correspondientes

La comparación detallada entre el comportamiento de HLI y la entrada normal en Chrome se muestra en la captura de pantalla.

TypingDNA

La entrada manual funciona correctamente. Al usar HLI, el contador de registros no aumenta o se producen errores de registro/inicio de sesión. Esto sugiere que se genera un nuevo patrón de escritura cada vez, lo cual puede ser percibido negativamente por los sistemas antifraude.

Adspower v6.12.6.0

Visor de eventos del teclado

El comportamiento durante la entrada manual coincide completamente con Chrome estándar.

Al comparar el comportamiento de HLI con la entrada manual en Chrome real, se identificaron 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 los mismos eventos, faltan los atributos key y code de UI Events
• Los modificadores (por ejemplo, Shift y Meta) se comportan de forma antinatural — se registra el mismo patrón de activación independientemente del contenido introducido, aunque no deberían activarse en la mayoría de los casos
• En el evento de entrada UI, el atributo data siempre es 'null'
• Falta el evento beforeinput. En su lugar, el evento input se dispara dos veces, y solo el segundo contiene inputType = insertText
• El orden de los eventos está roto: no coincide con la secuencia natural de escritura y permanece incorrecto independientemente de la entrada

La comparación detallada entre el comportamiento de HLI y la entrada estándar en Chrome se muestra en la captura de pantalla.

TypingDNA

La entrada manual funciona correctamente. Al usar HLI, los datos no se introducen en el formulario y aparece un error: "Este campo de entrada no admite Paste It".

Navegador 0detect (ex AQUM) v3.7.40

Visor de eventos del teclado

El comportamiento durante la entrada manual coincide completamente con Chrome estándar.

Al comparar el comportamiento de HLI con la entrada 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 lugar de los valores esperados
• En los eventos keydown, keyup y keypress, faltan los atributos key y code de UI Events
• Al ingresar caracteres en mayúscula como T y caracteres especiales como @, la tecla Shift no se activa — faltan los eventos keydown / keyup y no se activan los modificadores

La comparación detallada entre el comportamiento de HLI y la entrada estándar en Chrome se muestra en la captura de pantalla.

TypingDNA

La entrada manual funciona correctamente. Al usar HLI, los datos no se introducen en algunos campos — no ocurre nada. Sin embargo, en otros campos (como la barra de búsqueda de Google), la entrada funciona correctamente.

GoLogin v3.3.83.79

Visor de eventos del teclado

El comportamiento durante la entrada manual coincide completamente con Chrome estándar.

Al comparar el comportamiento de HLI con la entrada 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 lugar 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 caracteres especiales como @, la tecla Shift no se activa — no se generan eventos keydown / keyup y no se activan los modificadores

La comparación detallada entre el comportamiento de HLI y la entrada estándar en Chrome se muestra en la captura de pantalla.

TypingDNA

La entrada manual funciona correctamente. Al usar HLI, el contador de registros no aumenta o se produce un error durante el inicio de sesión/registro. Esto indica que se genera un nuevo patrón de escritura cada vez, lo cual puede ser percibido negativamente por los sistemas antifraude.

Vision v3.0.38

Visor de eventos del teclado

El comportamiento durante la entrada manual coincide completamente con Chrome estándar.

La implementación de HLI es prácticamente idéntica a la solución de Dolphin Anty, con defectos similares. En su estado actual, es una de las peores implementaciones entre los productos probados.

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

• En lugar de una emulación real de escritura, se utiliza un simple pegado carácter por carácter. El valor de inputType en este caso es insertFromPaste, lo que indica claramente el uso del portapapeles
• Incluso el propio pegado hecho mediante HLI difiere del pegado estándar desde el menú contextual, ya que faltan los eventos beforeinput

La comparación detallada entre el comportamiento de HLI y la entrada estándar en Chrome se muestra en la captura de pantalla.

TypingDNA

La entrada manual funciona correctamente. Al usar HLI, el sitio no detecta ninguna entrada — lo cual es esperado, ya que se trata de una operación de pegado y no de una emulación real de escritura.

Bonus: Vinculación de cuentas mediante el estilo único de escritura de un usuario

Lo mencionamos en la introducción y ahora lo demostraremos en la práctica. A continuación, se muestra una prueba sencilla que demuestra: vincular cuentas mediante el comportamiento único de escritura manual no solo es posible, sino que se utiliza activamente en los sistemas antifraude.

Y funciona independientemente de las sesiones, perfiles o incluso dispositivos. El identificador principal en este caso eres tú, y tu patrón de escritura único.

Procedimiento de prueba

1. Crea la primera sesión/perfil en tu navegador antidetect

2. Ve a la página de prueba de TypingDNA[https://www.typingdna.com/demo-login.html]

3. Crea un inicio de sesión y una contraseña únicos, apúntalos (no se requiere confirmación por correo electrónico)

4. Registra una cuenta ingresando los datos manualmente

5. Inicia sesión varias veces con las mismas credenciales (se recomienda 4–5 veces) para aumentar el contador de registros y mejorar la precisión del modelo de comportamiento

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

7. Ve a la página de prueba de TypingDNA[https://www.typingdna.com/demo-login.html]

8. Inicia sesión nuevamente con el mismo inicio de sesión y contraseña — ingrésalos manualmente, pero ahora en una nueva sesión o en un nuevo dispositivo

Resultados de la prueba de entrada manual

Como resultado del inicio de sesión desde un nuevo dispositivo, el contador de registros aumenta. Esto indica que el sistema reconoció correctamente tu comportamiento único de escritura y vinculó dos sesiones o dispositivos completamente diferentes.

Esta es una de las principales amenazas que una implementación adecuada de Paste Like Human Print debe eliminar.

Resultados de la prueba HLI en Linken Sphere

Al perfeccionar la función HLI en Linken Sphere, tomamos en cuenta este factor de comportamiento. Cada sesión en Linken Sphere genera su propio patrón único de escritura.

Por eso, una prueba similar usando HLI en Linken Sphere produce un resultado completamente diferente.

Primera sesión

El registro e inicio de sesión son exitosos, y el contador de registros aumenta.

Segunda sesión (u otra cualquiera)

Se pueden dar dos escenarios:

• Ocurre un error de inicio de sesión (el nuevo patrón no coincide con el anterior)
• O el inicio de sesión es exitoso, pero el sistema no aumenta el contador de registros y solicita volver a ingresar las credenciales — para capturar un nuevo patrón.

Esto demuestra que se genera una huella comportamental única para cada sesión de LS, como debe ser en una implementación adecuada de Paste Like Human Print. Este enfoque evita eficazmente la vinculación de cuentas entre sesiones al usar HLI en diferentes sesiones.

¿Estás seguro de que HLI en tu navegador antidetect funciona correctamente? ¿O es solo otro factor de riesgo que deberías considerar?

Prueba tú mismo tu navegador antidetect — y descubre si realmente te protege, o si en realidad contribuye a la desanonimización.

Resumamos

Producto (versión) Eventos – manual Eventos – HLI TypingDNA – manual TypingDNA – HLI 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 Odeteсt 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

Con base en los resultados de las pruebas comparativas, queda claro que no todas las implementaciones de Paste Like Human Print son igual de confiables o seguras.

Linken Sphere es el líder indiscutible. Es el único producto que demostró un comportamiento correcto tanto durante la entrada manual como al usar Paste Like Human Print.

Su comportamiento a nivel de eventos coincide completamente con el de una entrada manual real en Chrome, y los resultados de TypingDNA confirman un sistema bien implementado de patrones de entrada independientes por sesión. HLI no solo ‘funciona’ — funciona correctamente.

Además de introducir innovaciones — muchas de las cuales somos los primeros en traer a la industria — mantenemos activamente las funciones existentes y respondemos de manera oportuna a las amenazas emergentes de los sistemas antifraude.

Y lo más importante — no confíes ciegamente en un producto solo porque funcionó una vez. El antifraude está en constante evolución, por lo que la herramienta que uses para conectarte debe no solo funcionar — debe ir un paso por delante.