navigator.webdriver — самый дешевый сигнал automation detection и самый частый ложный “фикс”

navigator.webdriver — самый дешевый сигнал automation detection и самый частый ложный “фикс”

В Chromium это не “магическое поле”, а флаг, который отражает режим управления браузером через WebDriver/BiDi/automation hooks. Для антифрода он ценен не сам по себе, а как коррелирующий признак: если он true, дальше обычно сверяют permissions, timing, стек вызовов и паттерны событий ввода.

Разберем энтропию данного параметра: • значение property; • наличие дескриптора в prototype chain; • поведение в iframe и worker-контекстах; • совпадение с другими low-level индикаторами, включая headless-маршрутизацию и неестественные задержки между DOM-событиями. Один подмененный getter редко спасает, потому что детект идет на уровне согласованности модели браузера.

Типовая ошибка — “спуфинг через инъекцию JS-кода” без контроля за дескрипторами. Если просто вернуть false, ломается совместимость с feature detection, а в логах виден след от нестандартного accessor. Более корректно проверять, откуда пришел флаг, и не создавать расхождений между window.navigator, worker navigator и внешним поведением JS runtime.

Под капотом Chromium API это поле не стоит воспринимать как самостоятельную защиту: оно работает только в связке с остальными сигналами. Поэтому в лаборатории его тестируют через Pixelscan, CreepJS и собственный harness, где сравнивают descriptor shape, enumerable/configurable, stack traces и сетевые аномалии.

Практика простая: не лечите один симптом. Сначала снимите профиль всех navigator-полей, затем проверьте согласованность с TLS Client Hello, DOM events и WebGL/Canvas, иначе false→false не превратит автоматизацию в “живой” профиль.