Браузеры, запущенные через Selenium, могут отличаться от обычных по отладочным портам, доступным странице свойствам и способу запуска. Часть параметров разумно согласовывать, а попытки скрыть сам факт автоматизации хрупки, необязательны и часто быстро теряют эффективность.
При автоматизации через Selenium бывает, что логика скрипта написана правильно, но нужного результата всё равно нет. Частая первая реакция — изменить один-два параметра, однако среду обычно выдаёт не отдельный переключатель, а сочетание различий на нескольких уровнях. Если рассматривать эти уровни отдельно, становится понятнее, что действительно стоит настраивать, а что почти не даст результата.
Отладочные порты и артефакты среды выполнения
Способ, которым Selenium управляет браузером, оставляет два типа следов. Во-первых, при запуске браузер может открыть отладочный порт, через который внешнее ПО способно получить управление страницей. Во-вторых, в среде выполнения могут появиться дополнительные элементы: глобальные переменные с префиксом cdc_, внедрённые драйвером, дополнительные объекты драйвера в window и изменённые части некоторых прототипов объектов.
Источник этих элементов — не веб-страница, а сам драйвер. При стандартном запуске они присутствуют независимо от качества написания скрипта.
Свойства, которые может прочитать страница
Другой тип следов находится не в драйвере, а в JavaScript-среде, доступной странице. Самый часто упоминаемый пример — navigator.webdriver.
У этого свойства могут быть три значения. true означает, что браузер управляется инструментом автоматизации, false — что такого управления нет, а undefined — что соответствующая информация недоступна, обычно потому, что браузер не раскрывает это свойство или оно было обработано. При обычном использовании человеком значение бывает false или undefined, а при стандартном запуске Selenium — true.
Рядом с ним существует целый набор параметров: User-Agent, операционная система и версия браузера, разрешение экрана, часовой пояс, язык, Canvas, WebGL, AudioContext, список шрифтов, модель GPU и число ядер CPU. Вместе они образуют то, что обычно называют отпечатком браузера. У реальных пользователей отпечатки естественно различаются из-за разных систем, программ и привычек. Браузеры с настройками автоматизации по умолчанию, напротив, могут давать очень похожие комбинации, поэтому их проще отнести к известным шаблонам.
Различия из-за способа запуска и времени рендеринга
Третья категория не связана с одним конкретным свойством, а возникает из общего способа запуска и рендеринга браузера.
Запуск с флагами автоматизации, работа в режиме headless, несоответствие размера окна параметрам экрана, странное сочетание рендеринга шрифтов и графического драйвера или слишком равномерное время от загрузки страницы до готовности к взаимодействию сами по себе не являются доказательством. Но вместе они могут сформировать среду, которая мало похожа на устройство реального пользователя.
Headless — типичный пример. В новых версиях Chrome режим headless гораздо ближе к обычному браузеру, чем несколько лет назад, но всё же может легче раскрывать признаки автоматизации по сравнению с обычным режимом, особенно на сайтах со строгим контролем рисков.
Что можно разумно настраивать
Часовой пояс, язык, разрешение экрана и список шрифтов не являются уникальными для автоматизации. Реальные устройства также естественно отличаются по этим параметрам. Главное требование — внутренняя согласованность: часовой пояс должен соответствовать региону сетевого выхода, язык — обычному региону использования, а разрешение не должно противоречить аппаратному профилю.
Проще говоря, цель не в том, чтобы сделать среду необычной, а в том, чтобы она была логичной внутри. Если устройство выглядит так, будто подключается из Германии, но браузер сообщает часовой пояс западного побережья США, системный язык только английский, а разрешение похоже на типичное виртуальное отображение, такое сочетание уже достаточно заметно.
Поэтому настройки среды лучше хранить в постоянном профиле. Изменить сегодня часовой пояс, а завтра забыть про язык — значит создать больше несоответствий, чем если вообще ничего не менять.
Что пытается скрыть саму автоматизацию и почему это не стоит усилий
Есть другой класс подходов, направленных прямо на следы: удалить navigator.webdriver, очистить переменные, внедрённые драйвером, спрятать объекты драйвера или иным способом не дать системе проверки прочитать состояние автоматизации.
Проблема в том, что такие методы меняют поверхность, а не основу. Проверки давно не ограничиваются одним свойством; чтение атрибутов — лишь самый верхний слой. Обновление драйвера, изменение порядка выполнения проверочного скрипта или система, которая вообще обходит JavaScript и анализирует низкоуровневые результаты рендеринга и комбинации характеристик устройства, может сделать прежние исправления бесполезными. Затраты на поддержку остаются высокими, а выгода продолжает снижаться.
Кроме того, на практике такие действия часто попадают именно в ту область, которую условия использования платформ определяют как обход технических мер защиты. Аккуратно написанный скрипт не меняет характера действия только потому, что в нём изменено несколько свойств.
Сетевой уровень нельзя исправить в скрипте
Даже если браузерная среда выглядит согласованной, сетевой уровень всё ещё может идентифицировать сессию. Может учитываться, принадлежит ли IP дата-центру, облачному серверу или прокси-сети; историческая репутация диапазона IP и его ASN; геолокация; плотность запросов с одного IP; а также доступ к нескольким аккаунтам или страницам за короткое время. Cookies, Sessions и состояние входа, передаваемые в запросах, тоже могут сопоставляться.
Это нельзя решить внутри скрипта — вопрос относится к уровню среды: отдельный сетевой выход для каждой задачи, соответствие региона выхода региону среды и контролируемый темп запросов. При изоляции нескольких задач возможности вроде PurpleMark обычно работают именно здесь, предоставляя каждой задаче независимую браузерную среду и сетевой выход при согласованных географических параметрах.
Практический порядок проверки при блокировке
Разумный порядок такой: сначала проверить сетевой уровень — тип IP, стабильность и географическую согласованность; затем убедиться, что внутри среды не противоречат друг другу часовой пояс, язык, разрешение и шрифты; после этого посмотреть на ритм поведения, например на постоянные значения ожидания или мгновенный ввод; и только в конце перейти к свойствам автоматизации на уровне драйвера.
Причина проста: артефакты драйвера уже не являются главным объектом проверки. Если начинать диагностику с них, чаще всего это просто потеря времени.
Границы
Технические меры могут снизить вероятность идентификации, но есть границы, которые не следует переходить: соблюдать правила robots и условия использования целевого сайта, не собирать персональную информацию, не обходить технические меры защиты, контролировать частоту запросов и не мешать нормальной работе чужого сервиса.
