WebDriver BiDi — стандарт W3C, на котором Puppeteer и другие управляют Chrome и Firefox. Что он меняет для детекта ботов и что остаётся заметным.
Годами «автоматизировать Chrome» почти означало «говорить на Chrome DevTools Protocol». Сейчас это меняется: WebDriver BiDi — стандартный протокол W3C, который даёт инструментам автоматизации такое же живое, событийное управление, но уже в нескольких браузерах. Для тех, кто выявляет автоматизацию, и для тех, чьи CI-сессии попадают под подозрение, вопрос в том, что станет с сигналами, привязанными к старому каналу. В статье разбираем, что такое BiDi, какие сигналы детекта он ослабляет, а каких не касается вовсе.
Ключевые выводы
- WebDriver BiDi — стандартный двусторонний протокол. Он работает поверх WebSocket, позволяет браузеру самому отправлять события клиенту автоматизации и разрабатывается рабочей группой W3C по тестированию браузеров и инструментам. Спецификация пока остаётся рабочим черновиком (Working Draft).
- Он создан, чтобы заменить привычку «CDP для всего». CDP привязан к Chrome DevTools и не является общим публичным стандартом, а BiDi сочетает кросс-браузерную стандартизацию WebDriver Classic с низкоуровневым событийным управлением в духе CDP.
- Один класс сигналов слабеет. Детект, опирающийся на побочные эффекты самого CDP, например на поведение
Runtime.enableиз нашего разбора детекта CDP-автоматизации, может ничего не увидеть, если тот же скрипт управляет браузером через BiDi. - Большинству остального стека протокол безразличен.
navigator.webdriver, отличия headless-рендеринга, поведенческие тайминги и сетевые отпечатки описывают браузер и его трафик, а не формат передачи, который выбрал клиент автоматизации. - Правильный ответ — многослойная оценка, а не единственный признак. Защитникам стоит считать «есть побочный эффект CDP» одним из входов, который со временем будет срабатывать реже.
Что такое WebDriver BiDi
У WebDriver два поколения. WebDriver Classic — протокол «запрос — ответ», на котором вырос Selenium: клиент шлёт команду, браузер отвечает, а обо всём, что происходит между ними, клиенту приходится узнавать опросом. Chrome DevTools Protocol (CDP) — противоположный компромисс: быстрый, двусторонний и низкоуровневый, но созданный для собственных DevTools Chrome и не являющийся общим публичным стандартом.
Спецификация WebDriver BiDi стремится взять лучшее от обоих. По словам команды Chrome в статье-введении в протокол, это новый стандартный протокол автоматизации, который должен объединить лучшее из WebDriver Classic и CDP: двусторонний обмен сообщениями, низкоуровневый контроль и стандарт W3C за спиной. «Двусторонний» означает, что браузер может отправить клиенту событие — сообщение консоли, сетевой запрос, переход — в момент, когда оно случилось, а не ждать вопроса.
Та же статья прямо говорит, что BiDi — не просто CDP под новым именем. В CDP есть части, специфичные для Chrome и DevTools, и их нельзя перенести в кросс-браузерную спецификацию; кроме того, BiDi должен обходиться малым числом обращений туда-обратно, ведь клиент и браузер могут находиться на разных машинах. Из-за этих ограничений команды и события BiDi выглядят иначе, чем в CDP, а для детекта это важно: наблюдаемые побочные эффекты тоже другие.
Как идёт внедрение
Ход внедрения фиксируют объявления самих инструментов, поэтому лучше приводить даты, чем гадать о дорожной карте. В статье команды Chrome о готовности WebDriver BiDi к продакшену сказано, что Firefox 129 и Puppeteer 23 получили готовую к продакшену поддержку: начиная с Puppeteer 23 он обеспечивает стабильную автоматизацию Firefox через BiDi, а поддержка CDP остаётся без изменений.
До этого поддержка Firefox в Puppeteer держалась на том, что Mozilla реализовала и поддерживала в Firefox подмножество CDP; в статье это названо временным решением, которое не могло гарантировать работу всего API Puppeteer. BiDi заменяет такую схему общим стандартом. Практический вывод: автоматизация Firefox перешла на BiDi первой, а Chromium через Puppeteer по-прежнему часто использует CDP. «Замена CDP» — это направление движения, а не завершённый переход. Прежде чем решать, какой протокол использовала конкретная сессия, проверьте актуальные заметки о выпуске вашего фреймворка.
Что меняется для детекта
Значимый для детекта момент узок, и его стоит сформулировать точно. Приёмы, которые делают вывод «подключён клиент CDP» по тому, что CDP делает внутри рендерера, — например побочный канал из нашего разбора детекта CDP, — зависят от включённого домена CDP. Если скрипт управляет браузером через BiDi, эти конкретные эффекты могут просто не возникнуть. Детектор, опиравшийся на эту единственную проверку, увидит меньше срабатываний — не потому что трафик стал человеческим, а потому что сменился канал управления.
Две оговорки, чтобы не преувеличивать масштаб перемен. Во-первых, реализации BiDi новые, и то, как конкретный фреймворк или сборка браузера настраивает сессию, — деталь реализации, которая может меняться между версиями; утверждения о конкретном инструменте стоит сверять с его документацией. Во-вторых, браузером можно управлять сразу по нескольким протоколам, и некоторые фреймворки всё ещё используют CDP рядом с BiDi для функций, которые BiDi пока не покрывает, поэтому сессия не обязательно свободна от CDP только потому, что в ней есть BiDi.
Что остаётся заметным при любом протоколе
Протокол — лишь канал между клиентом автоматизации и браузером. Всё, что описывает сам браузер и его поведение, остаётся прежним.
| Сигнал | Почему протокол его не меняет |
|---|---|
navigator.webdriver | Спецификации WebDriver определяют состояние «webdriver-active» для браузера под удалённым управлением, и обработка сессий BiDi устанавливает и снимает его. Раскрывается ли флаг в конкретной сессии, зависит от браузера и фреймворка — проверяйте, а не предполагайте. |
| Признаки headless-рендеринга | Программный рендеринг графики, отсутствие плагинов и размеры окна по умолчанию зависят от способа запуска браузера. См. обнаружение headless-браузеров. |
| Поведенческие тайминги | Идеально ровные интервалы ввода и отсутствие движений указателя — свойства скрипта. См. поведенческое обнаружение ботов. |
| Сетевые отпечатки | Отпечатки TLS и HTTP/2 берутся из сетевого стека браузера и репутации IP, а не из канала управления. |
Поэтому зрелые системы детекта складывают много слабых сигналов в одну оценку. Потеря одного класса ожидаема; остальной стек показан в обзоре методов обнаружения ботов.
Если вы запускаете автоматизацию и попадаете под подозрение
Тестировщики и команды мониторинга часто оказываются по другую сторону детекта: легитимная CI-задача упирается в страницу проверки. Смена протокола — не решение, и эта статья такого не советует. Полезные шаги вполне будничные: запускайте тесты против сайтов, которые вы контролируете или на тестирование которых есть разрешение, согласуйте с владельцем сайта белый список IP-адресов вашего CI и пользуйтесь официальным путём там, где он есть: сервисы, готовые принимать автоматизированный трафик, обычно дают клиентам способ представиться, например API или подписанные запросы, и это куда надёжнее попыток сойти за человека. О том, как заново проводится граница между «ботом» и «программой, действующей от имени человека», мы пишем в материале про ИИ-агентов в браузере.
Чтобы увидеть, что выдаёт ваша собственная сессия, откройте инструмент проверки на бота: он показывает, какие флаги автоматизации поднимает текущая сессия, — это тот же класс проверок, который объединяет настоящий стек детекта.
Часто задаваемые вопросы
WebDriver BiDi заменит CDP?
Не полностью и не везде. BiDi — стандарт, призванный дать кросс-браузерной автоматизации событийное управление, которое раньше в основном давал CDP. Firefox 129 и Puppeteer 23 достигли готовой к продакшену поддержки BiDi, но поддержка CDP в Puppeteer сохранилась, и автоматизация Chromium нередко всё ещё её использует.
Делает ли BiDi автоматизацию необнаружимой?
Нет. Он убирает одно семейство сигналов — побочные эффекты подключённого клиента CDP, — но navigator.webdriver, отличия headless-рендеринга, поведенческие тайминги и сетевые отпечатки не зависят от того, каким протоколом переданы команды.
Остаётся ли navigator.webdriver при работе через BiDi?
Спецификации WebDriver связывают это свойство с тем, что браузер находится под удалённым управлением, и сессии BiDi участвуют в том же механизме «webdriver-active». Как именно его настраивает конкретная сборка браузера или фреймворк, может отличаться, поэтому смотрите документацию для ваших точных версий, а не полагайтесь на догадки.
Почему BiDi важен для защитников?
Потому что детектор, настроенный на побочные эффекты CDP, будет молча занижать результат по мере перехода трафика на BiDi. Следите за долей срабатываний этого сигнала во времени и опирайтесь на сигналы, не зависящие от протокола, — так покрытие останется стабильным.
