Как устроена browser automation
Framework управляет браузером через automation protocol/driver. Сценарий задаёт navigation, DOM selectors, clicks, forms, screenshots и извлечение данных. Для масштабирования добавляются proxy pool, profile management, task queue и retry logic.
Selenium, Playwright, Puppeteer и другие
Разные frameworks оставляют разные технические артефакты, но браузеры и библиотеки быстро меняются. Поэтому production detection должен опираться только на проверяемые markers и иметь versioned signatures.
Отдельные продукты вроде BAS/ZennoPoster могут использовать стандартные Chromium-техники. Если уникального артефакта нет, корректный Decision Trace пишет AUTOMATION_MARKER_GENERIC, а не придумывает название продукта.
Какие browser signals полезны
- navigator.webdriver и подтверждённые runtime artifacts;
- UA / Client Hints / platform consistency;
- screen / viewport / touch consistency;
- WebGL capability class;
- fingerprint churn/reuse;
- probe loaded/completed;
- header/browser mismatch.
Почему нужен behavioral слой
Хорошо замаскированный браузер может не иметь прямого marker. Но массовая автоматизация часто повторяет маршруты, интервалы, глубину обхода и ошибки. Sequence evidence помогает увидеть это на уровне популяции.
Как защищаться
Сначала COLLECT/SHADOW, затем scoped rules и Challenge на подтверждённые сценарии. Не стоит превращать отсутствие telemetry в риск само по себе: CSP, privacy extensions или JS disabled — легитимные состояния.
Browser automation в AntiPF 10.050
Browser Signals Lite — bounded collector с versioned protocol, strict schema, signed token и replay protection. Его evidence поступает в Risk/Decision Trace, но core AntiPF должен работать даже при ошибке browser subsystem.