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

Вступ

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

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-властивостей і причини їх знецінення:

Модифікатори (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, які надають додаткові параметри.

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

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

Коли фокус знаходиться в полі введення (наприклад, або </code>), натискання клавіш генерує як події клавіатури, так і події текстового введення.</p><p>Типова послідовність виглядає так:</p><ol><li><strong>keydown</strong> – виникає при натисканні будь-якої клавіші. Подія спрацьовує на елементі з фокусом (самому полі). На цьому етапі браузер ще не ввів символ. Можна скасувати поведінку за замовчуванням через <code>event.preventDefault()</code> — це блокує введення символу.</li><li><strong>beforeinput</strong> – далі (для символів) поле ініціює подію beforeinput, що сигналізує про намір змінити вміст. Одразу після неї виникає подія <strong>input</strong>, яка вказує, що контент справді змінився (наприклад, додано символ). У цих подіях можна перевірити <code>event.inputType</code> і <code>event.data</code>, щоб дізнатися, що саме сталось: введення, вставка, видалення тощо. Примітка: у застарілих реалізаціях замість <code>beforeinput</code> могла генеруватись <code>keypress</code>, але в сучасних Chrome використовується саме <code>beforeinput/input</code>.</li><li><strong>keyup</strong> – коли клавішу відпускають, виникає подія <code>keyup</code> на тому ж елементі.</li></ol><p>Клавіатурні події <code>keydown</code> / <code>keyup</code> "спливають" вгору по DOM-дереву (від елемента через <code>document</code> до <code>window</code>), тож їх можна обробляти локально чи глобально.</p><p>Для реакції саме на зміну тексту в полі (включно з не клавіатурними джерелами, як-от вставка з буфера чи голосовий ввід) краще використовувати подію <strong>input</strong>, яка реагує на будь-яку зміну значення.</p><p><code>KeyboardEvent</code> же зручний для обробки конкретних клавіш: Escape, стрілки, функціональні клавіші, комбінації тощо. А також — коли потрібно втрутитися у введення символу ще до його появи.</p>

Де перевірити ручне введення та 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 для Shift, відповідно не активуються й 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 не збільшується, і система просить повторити введення — щоб зафіксувати новий стиль

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

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

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

Підсумуємо

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

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

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

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

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

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