Защита отпечатков браузера при сборе веб-данных

Почему прокси и заголовки не описывают весь браузер

Команды, которые собирают общедоступные веб-данные с разрешения владельцев, обычно начинают с одного и того же набора: прокси для сетевого маршрута, разумный заголовок User-Agent и браузер, умеющий выполнять JavaScript. Этот набор решает реальные задачи, но не описывает браузер, который видит страница. Страница получает всю среду выполнения: как рисуется текст на canvas, какие графические возможности заявлены, какие шрифты установлены, сколько времени занимают обычные операции, какие языки и часовой пояс сообщает браузер и согласуются ли эти значения с сетевым маршрутом.

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

Защита отпечатков браузера работает на этом уровне. В документации BotBrowser профиль описывает конкретную среду браузера и устройства, а браузер последовательно сообщает эту среду на страницах, в воркерах и в новых контекстах. Цель состоит в приватности и повторяемости авторизованной работы. Это не обещание доступа к конкретному сайту, и в разделах ниже прямо указано, где ответственность возвращается команде, которая ведет рабочий процесс.

Коротко:

• Отрисовка, шрифты и время должны соответствовать выбранному профилю браузера.
• Регион прокси, часовой пояс, локаль и язык должны согласовываться друг с другом в одной сессии.
• Частичное изменение нескольких свойств JavaScript оставляет пробелы, которых полный профиль избегает.
• Темп запросов, проверки, политика аккаунтов и условия сайта остаются на стороне команды, которая ведет рабочий процесс.

Семейства сигналов, которые сообщает браузер для сбора данных

Полезно назвать семейства значений, доступных странице, потому что проверка согласованности должна охватывать все из них. Запоминать их как список свойств не нужно. Важно, чтобы каждое семейство описывало одно и то же устройство.

• Отрисовка canvas. Страницы могут рисовать текст и фигуры и считывать результат отрисовки. Canvas API является стандартным, а результаты зависят от операционной системы, графического стека и шрифтов.
• WebGL и графика. WebGL API раскрывает графические возможности и сведения об отрисовщике. Описание графики, не подходящее к заявленной операционной системе, часто становится источником несогласованности.
• Обработка звука. Web Audio API дает результат, который слегка отличается между платформами и сборками.
• Значения navigator и экрана. Платформа, языковые предпочтения, характеристики устройства и размеры экрана описывают заявленное устройство.
• Шрифты. Набор установленных шрифтов и способ измерения текста сильно зависят от операционной системы. Сервер Linux, который заявляет устройство Windows, но отрисовывает текст другим набором шрифтов, внутренне противоречив.
• Client Hints и заголовки. Марка браузера, платформа и архитектура, отправляемые с запросами, должны совпадать с тем, что видят скрипты на странице.
• Время и мощность. Измерения производительности, заявленное число процессоров и класс памяти показывают, насколько мощным выглядит устройство.
• Региональные настройки. Часовой пояс, локаль и языки сообщают, где, по заявлению браузера, он находится и какой язык предпочитает пользователь.

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

Почему частичные изменения в JavaScript оставляют пробелы

Многие конфигурации для сбора данных начинаются со скриптов, которые переопределяют несколько свойств браузера при загрузке страницы. Это понятно: такой способ быстро проверить, и он работает для изменяемого свойства. Но именно здесь появляется несогласованность.

Скрипт внутри страницы меняет значения, когда страница уже начала существовать. В некоторых контекстах код страницы и встроенные фреймы могут выполниться раньше, чем применится изменение. У выделенных воркеров, общих воркеров и сервис-воркеров есть собственная глобальная область, поэтому значение, измененное на главной странице, внутри воркера может отличаться. Новый iframe или новый контекст браузера снова начинает с исходных значений, пока то же изменение не повторено и там. Каждый такой случай является пробелом, который команде приходится отслеживать.

Вторая проблема касается охвата. Смена строки User-Agent не меняет отрисовку canvas, список шрифтов, поведение звукового вывода и описание графики. Одно переопределенное свойство обычно противоречит другим, оставленным без изменений. Например, строка платформы с одной операционной системой рядом со списком шрифтов, принадлежащим другой, означает, что два семейства описывают разные устройства.

Третья проблема связана с сопровождением. Выпуски браузера меняют внутренние детали, и каждый патч, зависящий от них, приходится перепроверять. Запуски в режиме headless добавляют еще один слой: различия между headless и обычным режимом с окном, например размер окна, список плагинов или детали отрисовки, обычно обрабатываются по одному. Команда в итоге поддерживает растущий список исключений вместо одного описания среды.

Подход на основе профиля меняет модель. Вместо точечных правок браузер запускается с профилем, который задает всю среду, и с самого начала сообщает эту среду на страницах, в воркерах и в новых контекстах. Документация BotBrowser описывает это по каждой поверхности, включая согласованность в воркерах для значений navigator и звука. Именно на этом ограниченном утверждении строится текст: согласованность заявленной среды, а не гарантия того, как отреагирует сайт.

Регион прокси, часовой пояс, локаль и язык в одной сессии

Из всех семейств сигналов региональные настройки проще всего проверить и проще всего настроить неверно, поэтому им стоит уделить отдельное внимание.

Прокси определяет сетевой маршрут и публичный адрес, который видят сайты. Он не решает, какой часовой пояс сообщает браузер, какая локаль форматирует числа и даты и какие языки указаны в предпочтениях браузера. Эти значения берутся из браузера. Если оставить их по умолчанию, взятыми с хост-машины, сервер сбора, находящийся в одном регионе, сообщит часовой пояс этого региона, даже если прокси указывает на другой.

По умолчанию BotBrowser определяет часовой пояс, локаль и язык по IP-адресу прокси: в документации это называется режимом auto. Все три значения остаются согласованными с регионом прокси и друг с другом, поэтому сессия с выходом в Германии сообщает немецкий часовой пояс, подходящую локаль и подходящий список языков без дополнительных флагов. Ручное переопределение каждого значения доступно как опция лицензионного уровня. Ручное значение имеет приоритет для той настройки, которую оно задает, а настройки в режиме auto продолжают следовать за прокси.

Стоит запомнить три практических детали из документации:

1. Доверьте управление прокси браузеру. Автоопределение работает, когда прокси задан собственной опцией браузера при запуске. Если вместо этого использовать опцию прокси самого фреймворка, часовой пояс может остаться таким, как на хост-машине.
2. Результат определяют данные о расположении прокси. Режим auto следует за расположением, которому соответствует IP-адрес прокси. Если данные поставщика о расположении неверны или адрес выхода соответствует не тому региону, который ожидался, определенные значения повторят это соответствие. Это повод проверить, а не гадать.
3. Сообщите браузеру адрес выхода, если он известен. Документация описывает опцию --proxy-ip (ENT Tier1) для явного указания публичного IP выхода прокси: она избавляет от поиска IP на каждой странице и делает результат предсказуемым, если адрес уже известен.

Минимальный запуск с режимом auto требует только профиля и прокси:

chromium-browser \
  --bot-profile="path/to/profile.enc" \
  --proxy-server=socks5://user:pass@de-proxy.example.com:1080

Полный перечень опций и лицензионных уровней смотрите в документации BotBrowser о часовом поясе, локали и языке. О том, как определяется выход прокси, читайте в нашем руководстве по настройке прокси.

DNS и WebRTC требуют такой же явной проверки. Решите осознанно, где разрешаются имена (опция --bot-local-dns, ENT Tier1, разрешает их локально, а --bot-local-dns=false оставляет разрешение за прокси), и убедитесь, что WebRTC не раскрывает адрес вне маршрута прокси; BotBrowser включает защиту WebRTC по умолчанию, а для полной защиты рекомендуется прокси. Руководство по согласованности прокси, DNS и WebRTC описывает эту проверку.

Как проверить согласованность до начала сбора данных

Не считайте согласованность само собой разумеющейся: подтверждайте ее один раз для каждого сочетания маршрута прокси и профиля, прежде чем запускать задачу в больших объемах. Проверки ниже используют только то, что человек видит в обычном окне браузера, и у каждой есть ожидаемый результат.

1. Подтвердите регион прокси. С помощью инструментов поставщика прокси или надежного определителя адресов запишите регион, которому соответствует адрес выхода. С ним сравниваются все остальные значения.
2. Считайте часовой пояс, который сообщает страница. Откройте консоль разработчика в сессии и вычислите Intl.DateTimeFormat().resolvedOptions().timeZone, что описано в справочнике MDN по resolvedOptions. Результатом должен быть часовой пояс из региона прокси.
3. Считайте список языков. Справочник Navigator.languages описывает упорядоченный список предпочитаемых языков. Вычислите navigator.languages и убедитесь, что первая запись соответствует нужному региону, а порядок похож на обычный список предпочтений.
4. Сравните форматы. Откройте страницу с датой, числом с десятичным разделителем и денежной суммой. Форматы должны соответствовать ожидаемой локали.
5. Повторите в новом контексте. Откройте второй контекст и страницу, использующую воркер, и повторите первые четыре проверки. Значения должны совпасть со значениями первого контекста: это подтверждает, что настройка применилась не только к одной странице.
6. Запишите результат. Сохраните метку маршрута прокси, имя профиля, часовой пояс и первый язык. Короткая запись помогает объяснить последующие расхождения.

Если проверка не проходит, меняйте что-то одно за раз. Убедитесь, что прокси настроен на уровне браузера, проверьте, какому расположению соответствует IP-адрес прокси, и сравните используемый профиль с задуманным устройством. Начать с нового контекста обычно понятнее, чем править контекст, в котором уже есть cookies и данные хранилища от неверной конфигурации.

Проверка отрисовки, шрифтов и параметров устройства

Та же привычка применима и за пределами региональных настроек, хотя правильных ответов, привязанных к региону, здесь нет. Вопрос в том, согласуются ли семейства друг с другом и с профилем.

Короткая таблица проверки делает разговор конкретным:

Область	Что подтвердить
Отрисовка	Поведение canvas и WebGL соответствует операционной системе и классу графики, которые описывает профиль
Шрифты	Доступные шрифты и измерение текста соответствуют заявленной операционной системе
Устройство и экран	Платформа, размер экрана и заявленные возможности описывают одно устройство
Заголовки и скрипты	Client Hints, отправляемые с запросами, совпадают со значениями, которые скрипты читают на странице
Время	Заявленные процессор и класс памяти соответствуют профилю и реальной мощности хоста
Региональные настройки	Регион прокси, часовой пояс, локаль и язык совпадают в каждом контексте
Границы сессии	Cookies и хранилище принадлежат одному профилю и одному маршруту

Проведите проверку для одного профиля на каждое семейство операционных систем, которое вы собираетесь использовать, а результат применяйте как эталон. Если позднейший запуск дает иную страницу, чем эталон, вы сможете сравнить конфигурации, а не гадать.

Действуют две оговорки. Во-первых, согласованный профиль не скрывает реальную мощность хоста: профиль скромного ноутбука на очень большом сервере все равно даст время, отражающее хост, поэтому держите ожидания умеренными, а профиль реалистичным. Во-вторых, запуски headless и запуски с окном нужно проверять отдельно, потому что результат в одном режиме не доказывает другой.

Сессии, профили и вариативность в задачах сбора данных

Задача сбора данных редко сводится к одной странице. Это серия сессий, и у каждой сессии должна быть ясная идентичность. Документация BotBrowser описывает профили как полные среды, а лицензионные уровни добавляют такие возможности, как детерминированные зерна шума и отдельные отпечатки для отдельных контекстов браузера.

Две идеи делают это управляемым.

Одна сессия, одна среда. Держите вместе cookies, хранилище, профиль и маршрут прокси на протяжении всей жизни сессии. Если маршрут меняется, считайте сессию новой, а не подменяйте маршрут под существующими cookies. Смешанную историю трудно интерпретировать позже, и она часто служит источником непонятного поведения страниц.

У вариативности есть цель. Разные профили полезны, когда процесс должен представлять разные классы устройств или регионы, которые он вправе представлять. Вариативность ради нее самой лишь увеличивает число сред, которые нужно проверять. Когда команда использует зерно, чтобы повторить результат, документация описывает, что одно и то же зерно дает один и тот же результат; это помогает воспроизвести проблему и сравнить запуски. Считайте зерно частью записанной конфигурации, чтобы последующий запуск мог взять то же значение.

Каждый добавленный профиль или маршрут увеличивает стоимость проверки. Начните с наименьшего набора, покрывающего авторизованную работу, проверьте его и расширяйте только при появлении задокументированной потребности.

Темп запросов, повторные попытки и политика аккаунтов

Согласованность браузера является лишь одним из факторов, определяющих ответ сайта. Остальные находятся в руках команды, и никакая настройка браузера их не меняет.

• Темп запросов. Распределение запросов во времени с соблюдением опубликованных ограничений сайта входит в авторизованный сбор. Делайте паузы между загрузками страниц, избегайте всплесков и замедляйтесь, когда сайт возвращает ошибку или ответ об ограничении частоты.
• Повторные попытки. Цикл, повторяющий один и тот же запрос без паузы, только ухудшает ситуацию. Используйте возрастающие паузы и предел числа попыток и останавливайтесь, если сайт продолжает отказывать.
• Интерактивные проверки. BotBrowser не решает интерактивные проверки. Если процесс регулярно с ними сталкивается, правильный ответ состоит в том, чтобы выяснить, авторизован ли сбор, есть ли официальный источник данных или API и может ли владелец сайта предоставить доступ.
• Политика аккаунтов. Сбор данных под учетной записью регулируется условиями аккаунта. Профиль браузера не меняет того, что разрешает соглашение об аккаунте.
• Качество прокси. Поставщик прокси отвечает за качество адреса выхода, данные о расположении и доступность. Хорошо согласованный браузер за неудачно расположенным прокси все равно сообщит регион, которому соответствует этот прокси.

Это не крайние случаи. Именно по этим причинам две команды с одинаковой конфигурацией браузера могут получать очень разные результаты.

Планирование мощности без догадок

Команды часто спрашивают, сколько сессий выдержит одна машина. Честный ответ: это зависит от оборудования и от собираемых страниц. Страница с одним текстом и страница с тяжелыми скриптами, видео или крупными изображениями потребляют очень разное количество памяти и процессорного времени. Любое число, названное без описания оборудования и типа страниц, следует считать в лучшем случае приблизительной оценкой для планирования.

Лучше измерить собственную нагрузку. Запустите небольшое число сессий на характерных страницах, наблюдайте за использованием памяти и процессора и увеличивайте нагрузку постепенно, проверяя, что страницы по-прежнему загружаются за разумное время. Документация BotBrowser по производительности описывает несколько факторов, влияющих на пропускную способность: запросы при запуске, загрузку профиля, выбор графического бэкенда и использование нескольких контекстов браузера в одном экземпляре вместо запуска множества отдельных экземпляров. Используйте ее как отправную точку и храните собственные измерения рядом с конфигурацией.

При работе в контейнерах применяйте тот же метод: рассчитывайте размер контейнера по измерениям, а не по опубликованным цифрам, и храните файлы профилей на быстром локальном диске. Подробнее о настройке контейнеров рассказывает наше руководство по развертыванию в Docker.

Вопросы, которые задают команды

Гарантирует ли защита отпечатков доступ к сайту?

Нет. Она сохраняет согласованность среды браузера. Примет ли сайт сессию, зависит от его собственных политик, вашего темпа запросов, качества прокси и условий, применимых к данным. Стоит предусмотреть отказы и иметь официальный канал для запроса доступа там, где он существует.

Почему нельзя просто задать User-Agent и несколько свойств?

Потому что эти значения составляют лишь часть того, что может прочитать страница. Измененный User-Agent рядом с неизмененными отрисовкой, шрифтами и региональными настройками оставляет несколько семейств, которые говорят разное. Полный профиль описывает их вместе, а браузер сообщает ту же среду на страницах, в воркерах и в новых контекстах.

Нужно ли задавать часовой пояс, локаль и язык вручную?

Обычно нет. Если прокси настроен на уровне браузера, режим auto определяет все три значения по IP-адресу прокси. Ручные значения нужны, когда известно, что данные о расположении прокси неверны или процессу нужен конкретный регион, и это опция лицензионного уровня. В любом случае проверьте результат по шагам выше.

Можно ли использовать мой существующий код на Playwright или Puppeteer?

В целом да. Документация описывает запуск исполняемого файла BotBrowser с профилем и прокси из любого из этих фреймворков. Не забывайте задавать прокси через аргументы запуска браузера, а не через собственную опцию прокси фреймворка, чтобы региональное согласование работало, как описано.

Нужен ли отдельный профиль для каждой сессии?

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

Законно ли собирать данные с защитой отпечатков?

Законность зависит от юрисдикции, вида данных, условий использования сайта и таких норм, как GDPR или CCPA. BotBrowser является инструментом приватности, а пользователи сами отвечают за то, чтобы их сбор данных был авторизован и соответствовал применимым правилам.

Место BotBrowser в этом процессе

В авторизованных сессиях сбора данных BotBrowser по умолчанию может определять часовой пояс, локаль и язык по IP-адресу прокси (режим auto), поэтому они согласованы с регионом прокси и друг с другом, а сессия сообщает согласованные региональные данные. Так вы избегаете типичного расхождения, когда прокси находится в одной стране, а браузер настроен на другую. BotBrowser не может гарантировать, что сайт примет сессию, и не может решать интерактивные проверки, а также не контролирует качество и геоданные прокси, темп запросов, политику аккаунтов и условия сайта.

Используйте проверки выше как предварительную процедуру, храните записанную конфигурацию рядом с каждой задачей и оставляйте более серьезные изменения на случай, когда проверка не проходит. Чтобы начать с профиля, скачайте BotBrowser или обратитесь к корпоративной команде за помощью в планировании крупных развертываний.

Для дальнейшего чтения: Кросс-платформенные профили браузера помогут спланировать профили для разных операционных систем.

Источники

• BotBrowser: часовой пояс, локаль и язык
• BotBrowser: справочник по опциям командной строки
• MDN: Intl.DateTimeFormat resolvedOptions()
• MDN: Navigator.languages
• MDN: Canvas API
• MDN: WebGL API