Імітація ручного введення тексту — що "під капотом" у популярних антидетектів?

Вступ

Сьогодні ми поговоримо про функцію, яка міцно увійшла в робочий процес кожного користувача антидетект-браузерів.

Paste Like Human Print (також відомий як людиноподібне введення, або скорочено ЛПВ) — це емуляція введення тексту з буфера обміну, що імітує поведінку справжнього користувача.

Це незамінний інструмент, який економить купу часу та позбавляє від рутинних дій у сфері мультиакаунтингу. Його основне завдання — мінімізувати ризик обмежень з боку антифрод-систем під час введення тексту у форми на сайтах.

Кожен продукт називає цю функцію по-своєму:

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

Linken Sphere став першим антидетект-браузером, який впровадив функцію людиноподібного введення і запропонував її ринку ще наприкінці 2017 року. Тоді більшість конкурентів не поспішали впроваджувати аналогічне рішення, стверджуючи, що така функція не затребувана масовим користувачем. Але практика показала інше: за кілька років технологія була реалізована майже у всіх серйозних продуктах цього сегменту, ставши галузевим стандартом.

Вплив методу введення на успішність вашої роботи

Під час роботи часто доводиться оперувати заздалегідь підготовленими даними, наприклад:

• Іменами, логінами та email-адресами при реєстрації акаунтів
• Платіжними даними при створенні рекламних кабінетів
• Текстами апеляцій при розблокуванні рекламних акаунтів
• Коментарями та повідомленнями в рамках SMM-активності
• І т. д.

Ні для кого не секрет, що антифрод-системи давно відстежують і аналізують поведінку користувачів. Введення тексту у форми — не виняток. У переважній більшості випадків метод введення справді має значення.

Якщо ви просто вставите текст за допомогою звичної Ctrl+V / Cmd+V, це може здатися системі підозрілим у порівнянні з ручним набором. У результаті можливе підвищене увага до вашого акаунту та дій.

З іншого боку, ручне введення хоч і виглядає максимально природно, майже непридатне при роботі з великим обсягом акаунтів. По-перше, це банально виснажливо. По-друге, унікальний стиль введення може бути використаний для зв'язку сесій між собою. Так, зв’язок між акаунтами за стилем введення — не параноя, а реальність, у якій ми живемо. Далі ми покажемо спосіб наочної перевірки таких детекцій.

Тож оптимальним рішенням залишається Paste Like Human Print, покликаний усунути всі описані вище проблеми. Чи є ЛПВ панацеєю? Все залежить від конкретної технічної реалізації. Саме тому ми провели власне дослідження популярних антидетект-браузерів на ринку.

Перш ніж перейти до результатів, пропонуємо ознайомитися з ключовими технічними аспектами, які допоможуть краще зрозуміти логіку роботи механізму введення в браузерах.

Які бувають типи подій клавіатури і коли вони використовуються?

Існує три основні події клавіатури: keydown, keypress і keyup. У сучасних браузерах (включно з Chrome) актуальними є keydown та keyup, а подія keypress вважається застарілою (однак все ще передається під час друку).

• keydown – виникає при натисканні клавіші і спрацьовує для будь-якої клавіші (включно зі службовими, напр. Alt, Shift тощо). Використовується для реакції в момент натискання (наприклад, для гарячих клавіш або ігор). Якщо клавішу утримувати (наприклад, t), буде відбуватися авто-повтор: одна подія keydown при первинному натисканні і подальші повторні keydown (з event.repeat = true) до моменту відпускання клавіші.
• keypress – (застаріле) подія, що спрацьовує при натисканні клавіші, якщо вона вводить символ. Історично використовувалася для відстеження введення друкованих символів (літер, цифр тощо), тоді як keydown/keyup застосовуються для фіксації фізичних натискань. Подія keypress не генерується для клавіш, які не вводять символ (наприклад, Shift або стрілки) і в актуальних стандартах вважається застарілою. Замість неї слід використовувати властивість event.key у зв’язці з keydown або спеціальні події введення (див. нижче).
• keyup – виникає при відпусканні клавіші (після завершення натискання). Використовується для обробки дій після того, як користувач відпустив клавішу — наприклад, щоб виконати дію після введення символу або виявити, що клавішу більше не утримують.

Застарілі атрибути клавіатури: що таке charCode, keyCode, which і чому їх не рекомендують використовувати?

charCode, keyCode та which — це властивості об'єкта події клавіатури зі старих версій DOM (legacy). Вони представляли код натиснутої клавіші або символу, але зараз є застарілими й не рекомендовані до використання. Замість них сучасні стандарти використовують властивості event.key та event.code.

Ось короткий опис кожної з legacy-властивостей і причини їх знецінення:

Властивість	Опис (legacy)	Статус і заміна
event.keyCode	Числовий код клавіші (зазвичай відповідає ASCII-коду символу без модифікаторів). Використовується у подіях keydown/keyup.	Застаріле – значення відрізняються між браузерами та розкладками, особливо з Shift/Alt. Слід використовувати event.key або event.code.
event.charCode	Unicode-код символу, який генерується лише у події keypress (для клавіш, що вводять текст).	Застаріле – замінене на event.key, яке дозволяє отримати введений символ.
event.which	Уніфікована властивість, що повертала код клавіші або символу залежно від типу події: дублює keyCode для keydown/keyup і charCode для keypress. Також використовувалась для кнопок миші.	Застаріле – не стандартизоване. Для клавіатури замість цього слід використовувати event.key та event.code, а для миші — event.button.

Модифікатори (Shift, Ctrl, Alt, Meta): як працюють getModifierState() та відповідні властивості?

Події клавіатури містять властивості, що вказують на стан клавіш-модифікаторів, а також метод для їх перевірки.

• Властивості event.shiftKey, event.ctrlKey, event.altKey, event.metaKey дорівнюють true, якщо відповідна клавіша-модифікатор була натиснута на момент генерації події. Наприклад, при комбінації Ctrl+X подія keydown для клавіші "X" матиме ctrlKey = true. Властивість metaKey відповідає клавіші Meta (у Windows — ⊞ Windows, у Mac — ⌘ Command). Ці булеві властивості дозволяють визначити, чи були натиснуті Shift, Ctrl, Alt або Meta одночасно з іншою клавішею.
• Метод event.getModifierState(key) повертає true або false залежно від того, активний зазначений модифікатор у момент події. Параметр key — це рядок із назвою клавіші-модифікатора: "Shift", "Control", "Alt", "Meta" або клавіші блокування — "CapsLock", "NumLock" тощо. Метод поверне true, якщо модифікатор наразі натиснутий або активований (наприклад, якщо CapsLock увімкнено). Це дозволяє перевіряти стан клавіш, як-от CapsLock, які не мають окремої властивості в самій події.

Атрибути подій (UI Events): що означають властивості key, code, location, repeat, isComposing, inputType, data?

Сучасний об'єкт KeyboardEvent надає низку властивостей з інформацією про натиснуту клавішу. Крім того, під час введення тексту генеруються події InputEvent, які надають додаткові параметри.

Ось основні атрибути та їхні значення:

Властивість	Значення (що показує)
key	Рядок, що представляє значення клавіші з урахуванням розкладки та стану модифікаторів. Для друкованих символів — це введений символ ("a" або "A" залежно від Shift); для службових клавіш — стандартні назви ("Enter", "Escape" тощо).
code	Рядок, що вказує фізичне розташування клавіші на клавіатурі, незалежно від розкладки. Наприклад, натискання клавіші у позиції "Q" завжди поверне "KeyQ", навіть якщо символ буде інший. Це корисно для керування в іграх, але не підходить для отримання символу (для цього краще використовувати key).
location	Числове значення, що вказує розташування клавіші на клавіатурі: 0 — стандартне, 1 — лівий бік (LEFT), 2 — правий (RIGHT), 3 — цифровий блок (NUMPAD).
repeat	true, якщо подія викликана повторно при утриманні клавіші (автоповтор). При першому keydown — false, у наступних — true. У keyup ця властивість завжди false.
isComposing	true, якщо подія відбувається під час складання складного введення (IME), наприклад, при наборі ієрогліфів. Між подіями compositionstart і compositionend.
inputType	(властивість InputEvent) Рядок, що показує тип зміни у полі: "insertText" (введення), "deleteContentBackward" (видалення символу), "insertFromPaste" (вставка з буфера) тощо.
data	(властивість InputEvent) Рядок із текстом, вставленим або введеним внаслідок події. Якщо символи видалено — буде порожній рядок, якщо подія не пов’язана з введенням — null.

Як події клавіатури взаємодіють із полями введення?

Коли фокус знаходиться в полі введення (наприклад, <input> або <textarea>), натискання клавіш генерує як події клавіатури, так і події текстового введення.

Типова послідовність виглядає так:

1. keydown – виникає при натисканні будь-якої клавіші. Подія спрацьовує на елементі з фокусом (самому полі). На цьому етапі браузер ще не ввів символ. Можна скасувати поведінку за замовчуванням через event.preventDefault() — це блокує введення символу.
2. beforeinput – далі (для символів) поле ініціює подію beforeinput, що сигналізує про намір змінити вміст. Одразу після неї виникає подія input, яка вказує, що контент справді змінився (наприклад, додано символ). У цих подіях можна перевірити event.inputType і event.data, щоб дізнатися, що саме сталось: введення, вставка, видалення тощо. Примітка: у застарілих реалізаціях замість beforeinput могла генеруватись keypress, але в сучасних Chrome використовується саме beforeinput/input.
3. keyup – коли клавішу відпускають, виникає подія keyup на тому ж елементі.

Клавіатурні події keydown / keyup "спливають" вгору по DOM-дереву (від елемента через document до window), тож їх можна обробляти локально чи глобально.

Для реакції саме на зміну тексту в полі (включно з не клавіатурними джерелами, як-от вставка з буфера чи голосовий ввід) краще використовувати подію input, яка реагує на будь-яку зміну значення.

KeyboardEvent же зручний для обробки конкретних клавіш: Escape, стрілки, функціональні клавіші, комбінації тощо. А також — коли потрібно втрутитися у введення символу ще до його появи.

Де перевірити ручне введення та Paste Like Human Print?

Для повноцінної оцінки, тестування проводиться у кілька етапів.

Keyboard Event Viewer

Цей інструмент надає максимум інформації про події введення, включаючи Legacy-атрибути, Modifiers та UI Events.

1. Перевірка ручного введення

Використовуючи антидетект-браузер, вручну по черзі вводьте символи з тестового набору. Потім порівняйте отримані події з результатами ручного введення у звичайному Chrome на тому ж ПК.

2. Перевірка Paste Like Human Print

Використовуючи антидетект-браузер, вставте ті самі символи за допомогою функції Paste Like Human Print. Порівняйте результат із ручним введенням у Chrome на тому ж пристрої.

Очікувана поведінка: у обох випадках події введення мають максимально відповідати тим, які генерує реальний Chrome під час набору вручну.

TypingDNA

Цей сервіс аналізує інтервали між натисканнями клавіш, щоб розпізнати унікальний стиль введення та ідентифікувати користувача.

1. Перевірка ручного введення

Використовуючи антидетект-браузер, створіть акаунт шляхом ручного введення унікальних даних (email, пароль). Потім кілька разів авторизуйтесь, кожного разу вводячи ті самі дані вручну.

2. Перевірка Paste Like Human Print

Створіть акаунт, вставляючи дані через Paste Like Human Print. Потім виконайте авторизацію кілька разів, щоразу використовуючи ЛПВ.

Очікувана поведінка: успішна реєстрація та авторизація, при кожному повторному вході лічильник Enrollments має зростати. Це свідчить про те, що система фіксує стабільний патерн введення між сесіями.

Додаткові деталі

• Тестовий набір символів: tT@.
• Операційна система: Windows 11
• Виклик Paste Like Human Print у всіх випадках здійснювався через контекстне меню (ПКМ), щоб уникнути впливу гарячих клавіш

Результати тестування

Linken Sphere 2 v2.4.0 ⭐

Keyboard Event Viewer

Поведінка при ручному введенні повністю відповідає роботі звичайного Chrome.

При порівнянні Paste Like Human Print із реальним ручним введенням у Chrome — повний збіг подій у межах тестового набору символів. Саме так і повинна працювати якісно реалізована функція ЛПВ.

На скріншоті наведено детальне порівняння поведінки ЛПВ та звичайного введення у Chrome.

TypingDNA

Ручне введення працює коректно. При використанні ЛПВ реєстрація та авторизація проходять успішно, а лічильник Enrollments зростає — це означає, що система фіксує стабільний і повторюваний патерн введення в межах однієї сесії.

Octo Browser v2.5.5

Keyboard Event Viewer

Поведінка при ручному введенні повністю відповідає стандартному Chrome.

ЛПВ реалізовано краще, ніж у більшості інших рішень, однак не без недоліків.

При порівнянні поведінки ЛПВ із реальним ручним введенням у Chrome виявлено таку особливість:

• При введенні символів верхнього регістру T і спеціальних символів, таких як @, використовується клавіша Shift, однак її стан не відображається в Modifiers (getModifierState, shift).

TypingDNA

Ручне введення працює коректно. При використанні ЛПВ — лічильник Enrollments або не зростає, або виникають помилки авторизації/реєстрації. Це вказує на те, що кожного разу формується новий патерн введення — що може сприйматись антифрод-системами як нестабільна поведінка.

Dolphin Anty v2025.152.125.0

Keyboard Event Viewer

Ручне введення: при натисканні клавіш Shift / Meta / Control (наприклад, для введення великої T або символу @) реєструється зайва подія keypress з нульовими значеннями charCode / keyCode / which.

Це може бути тригером для антифрод-систем: навіть при введенні вручну поведінка відхиляється від стандартної, що потенційно видає використання антидетект-браузера.

Paste Like Human Print у Dolphin Anty — найгірша реалізація серед усіх протестованих.

Виявлені критичні проблеми:

• Замість емуляції реального введення — використовується примітивна посимвольна вставка. Значення inputType — insertFromPaste, що одразу видає, що це вставка з буфера, а не набір.
• Навіть сама вставка (через ЛПВ) відрізняється від звичайної вставки через контекстне меню (ПКМ): події beforeinput взагалі відсутні.

Візуально може здаватися, що все працює як у інших — але аналіз подій однозначно показує відмінності.

TypingDNA

Ручне введення працює правильно. При використанні ЛПВ введення не реєструється взагалі — і це очікувано: відбувається вставка, а не імітація набору.

Undetectable v2.32.1

Keyboard Event Viewer

Поведінка при ручному введенні повністю відповідає стандартному Chrome.

Однак при порівнянні роботи ЛПВ із ручним введенням у реальному Chrome виявлено серйозні порушення:

• У подіях keydown та keyup значення keyCode і which (legacy) завжди дорівнюють 0 — що неприпустимо, оскільки для коректного введення потрібні валідні коди клавіш.
• У подіях keydown, keyup та keypress відсутній атрибут code із UI Events.
• При введенні символів верхнього регістру T або спецсимволів @ клавіша Shift не спрацьовує — немає подій keydown / keyup, відповідно не активуються й Modifiers.

На скріншоті показано точне порівняння ЛПВ з поведінкою Chrome.

TypingDNA

Ручне введення працює як слід. При використанні ЛПВ — Enrollments або не зростає, або виникає помилка авторизації/реєстрації. Це свідчить про нестабільний патерн, який щоразу відрізняється — і може розцінюватися системою як ризик.

Adspower v6.12.6.0

Keyboard Event Viewer

Поведінка при ручному введенні повністю відповідає стандартному Chrome.

При роботі ЛПВ виявлено серйозні порушення у всіх типах подій:

• У подіях keydown, keyup, keypress значення charCode, keyCode та which (legacy) — завжди 0 замість очікуваних значень.
• У тих самих подіях відсутні атрибути key і code з UI Events.
• Modifiers (Shift, Meta) працюють неприродно — записується один і той самий шаблон, незалежно від введеного тексту. У більшості випадків ці модифікатори взагалі не мали б активуватись.
• У події input значення data завжди null, що аномально при введенні тексту.
• Відсутня подія beforeinput. Замість неї подія input спрацьовує двічі, і лише друга містить inputType = insertText.
• Порушено порядок подій — він не відповідає природній послідовності набору і залишається некоректним незалежно від введення.

На скріншоті — приклад такої аномальної поведінки.

TypingDNA

Ручне введення працює нормально. При використанні ЛПВ введення у форму не відбувається, з'являється повідомлення: "This input field does not support Paste It" — тобто браузер не здатен навіть вставити дані, не кажучи вже про емулювання набору.

0detect browser (ex AQUM) v3.7.40

Keyboard Event Viewer

Поведінка при ручному введенні повністю відповідає стандартному Chrome.

При тестуванні Paste Like Human Print зафіксовано кілька серйозних проблем:

• У подіях keydown та keyup значення charCode, keyCode, which (legacy) — завжди дорівнюють 0, що суперечить нормальній поведінці.
• У подіях keydown, keyup, keypress відсутні атрибути key і code з UI Events.
• При введенні верхнього регістру T або спецсимволів @ не спрацьовує клавіша Shift — немає keydown / keyup подій для Shift, відповідно Modifiers не активуються.

Поведінка явно не відповідає стандарту, навіть у простих сценаріях.

TypingDNA

Ручне введення — без зауважень.

При використанні ЛПВ:

• У деякі поля дані взагалі не вставляються — система не реагує.
• В інших (наприклад, у полі пошуку Google) все працює, тобто реалізація нестабільна й залежить від поля.

Це додатково підтверджує, що Paste Like Human Print реалізований неякісно і не є універсальним.

GoLogin v3.3.83.79

Keyboard Event Viewer

Поведінка при ручному введенні повністю відповідає стандартному Chrome.

При роботі Paste Like Human Print спостерігаються типові проблеми, аналогічні до інших слабких реалізацій:

• У подіях keydown і keyup значення charCode, keyCode і which (legacy) — завжди 0, що недопустимо.
• У подіях keydown, keyup, keypress відсутні атрибути key і code з UI Events.
• При введенні символів верхнього регістру T або @ не спрацьовує клавіша Shift — події keydown / keyup не фіксуються, Modifiers не активуються.

Ці ознаки вказують на те, що ЛПВ у GoLogin не імітує реальне введення, а лише частково формує події.

TypingDNA

Ручне введення працює добре.

При використанні ЛПВ:

• Enrollments не збільшується,
• або виникає помилка входу / реєстрації.

Це означає, що кожного разу формується новий патерн — і система не розпізнає попередній стиль введення. Стабільності немає, що для антифроду — червоний прапорець.

Vision v3.0.38

Keyboard Event Viewer

Поведінка при ручному введенні повністю відповідає стандартному Chrome.

Однак реалізація Paste Like Human Print практично ідентична до тієї, що в Dolphin Anty, із усіма притаманними їй недоліками.

Під час тестування виявлено:

• Замість повноцінної емулювання введення використовується проста посимвольна вставка. Подія input має inputType = insertFromPaste, що прямо вказує на вставку з буфера, а не ручне введення.
• Навіть сама вставка, виконана через ЛПВ, відрізняється від звичайної вставки ПКМ: події beforeinput відсутні, що чітко виокремлює цю поведінку як штучну.

Це одна з найслабших реалізацій серед усіх протестованих.

TypingDNA

Ручне введення працює коректно. При використанні ЛПВ сайт взагалі не реєструє жодного введення — що логічно, адже відбувається вставка, а не набір тексту. TypingDNA очікує реальну клавіатурну активність, а не події insertFromPaste.

Бонус: Зв’язок акаунтів за унікальною манерою ручного введення користувача

Ми згадували про це у вступі, а тепер продемонструємо на практиці. Нижче — простий тест, який доводить: зв’язок акаунтів за манерою введення — не фантазія, а реальний інструмент антифрод-систем.

І працює він незалежно від сесій, профілів чи навіть пристроїв. Головний ідентифікатор — ви самі, а саме — ваш унікальний стиль набору тексту.

Алгоритм перевірки

1. Створіть першу сесію або профіль в антидетект-браузері

2. Перейдіть на тестову сторінку TypingDNA

3. Придумайте унікальний логін і пароль, запишіть їх (підтвердження пошти не потрібне)

4. Пройдіть реєстрацію, вводячи все вручну

5. Повторіть вхід кілька разів (рекомендується 4–5 разів), щоб збільшити лічильник Enrollments

6. Створіть нову сесію або профіль (можна навіть інший пристрій)

7. Знову перейдіть на TypingDNA

8. Введіть ті самі дані вручну — але вже в новій сесії або з іншого пристрою

Результати перевірки ручного введення

У результаті входу з нового пристрою лічильник Enrollments зростає — це означає, що система успішно розпізнала ваш стиль введення і пов’язала дві окремі сесії або пристрої між собою.

Саме такий механізм і має блокувати якісно реалізований Paste Like Human Print.

Результати перевірки ЛПВ у Linken Sphere

Під час доопрацювання функції Paste Like Human Print у Linken Sphere було враховано фактор поведінкового аналізу. Кожна сесія в Linken Sphere формує унікальний патерн введення.

Саме тому аналогічний тест із використанням ЛПВ у Linken Sphere показує інший результат, ніж при ручному введенні.

Перша сесія

Реєстрація і вхід проходять успішно, а лічильник Enrollments зростає — все, як має бути.

Друга (або будь-яка інша) сесія

Можливі два сценарії:

• Виникає помилка входу, оскільки новий патерн не збігається з попереднім
• Або вхід успішний, але Enrollments не збільшується, і система просить повторити введення — щоб зафіксувати новий стиль

Це означає, що для кожної сесії створюється унікальний поведінковий відбиток, що й очікується від правильно реалізованої функції ЛПВ.

Ви впевнені, що ЛПВ у вашому антидетект-браузері працює як слід? Чи це просто ще один фактор ризику, який сприяє деанонімізації?

Протестуйте самостійно — і дізнайтесь, чи захищає вас ваш інструмент, чи, навпаки, розкриває.

Підсумуємо

Продукт (версія)	Події – вручну	Події – ЛПВ	TypingDNA – вручну	TypingDNA – ЛПВ
Linken Sphere 2 v2.4.0 ⭐	Відмінно	Відмінно	Відмінно	Відмінно
Octo Browser v2.5.5	Відмінно	Добре	Відмінно	Погано
Dolphin Anty v2025.152.125.0	Погано	Жахливо	Відмінно	Жахливо
Undetectable v2.32.1	Відмінно	Погано	Відмінно	Погано
Adspower v6.12.6.0	Відмінно	Жахливо	Відмінно	Жахливо
0detect browser (ex AQUM) v3.7.40	Відмінно	Погано	Відмінно	Жахливо
GoLogin v3.3.83.79	Відмінно	Погано	Відмінно	Погано
Vision v3.0.38	Відмінно	Жахливо	Відмінно	Жахливо

На основі результатів порівняльного тестування можна з упевненістю сказати: не кожна реалізація Paste Like Human Print однаково надійна або безпечна.

Linken Sphere — беззаперечний лідер.

Це єдиний продукт, який продемонстрував:

• Повну відповідність Chrome під час ручного введення
• Ідентичну поведінку при Paste Like Human Print
• Стабільність патернів в TypingDNA
• Генерацію унікального патерну для кожної сесії, що блокує зв’язок між акаунтами

Ми першими впроваджуємо багато інновацій в індустрії, підтримуємо актуальність функцій та оперативно реагуємо на виклики від антифрод-систем.

Не покладайтесь на продукт лише тому, що він одного разу спрацював. Антифрод постійно еволюціонує — інструмент, з яким ви виходите в мережу, повинен не просто функціонувати, а бути на крок попереду.