Кроссплатформенные профили: одна идентичность на каждом хосте

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

TL;DR

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

Содержание

• Строка User-Agent не равна идентичности
• Семейства сигналов, которые профиль должен держать согласованными
• Хосты, цели и документированная матрица поддержки
• Сравнение хостов и разбор расхождений
• Кроссплатформенные профили и режим Per-Context
• Что обеспечивает BotBrowser и где проходит граница
• Итог

Строка User-Agent не равна идентичности

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

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

User-Agent Client Hints делают это наглядным. MDN описывает API User-Agent Client Hints как способ передавать сведения о браузере и платформе через заголовки запроса и ответа и интерфейс JavaScript: небольшой набор значений отправляется по умолчанию, а дополнительные подробности возвращаются, только когда их запрашивает сервер. Эти значения должны согласовываться со строкой User-Agent, друг с другом и с остальным профилем. Если изменить строку, а структурированные значения оставить такими, какими их задает хост, получится именно то несоответствие, которого должна избегать согласованная идентичность.

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

Конкретный случай показывает, что это значит. Допустим, профиль с целью Windows запущен на сервере Linux. Название платформы, структурированные значения бренда, набор шрифтов, параметры экрана и описание GPU должны описывать настольный компьютер с Windows, хотя физическая машина это сервер Linux. Рабочий процесс при этом должен вести себя на странице так же, как на настоящей цели Windows. Если хотя бы одно семейство сигналов по-прежнему отражает хост Linux, идентичность применена лишь частично, и именно этот разрыв должно выявить сравнение между хостами.

Семейства сигналов, которые профиль должен держать согласованными

До сравнения хостов запишите userAgent, platform, brands, screen.width, screen.height, devicePixelRatio, languages, locale и timeZone.

Удобнее думать семействами сигналов, а не отдельными свойствами. Для выбранной целевой платформы профиль должен держать согласованными между собой такие семейства:

• Платформа и бренд браузера: строка User-Agent, структурированные значения Client Hints и бренд в заголовках должны называть одну и ту же платформу и одну и ту же версию браузера.
• Экран и параметры устройства: разрешение, глубина цвета, плотность пикселей и поддержка касаний должны соответствовать классу устройства цели, будь то настольный монитор или телефон Android.
• Шрифты и отрисовка текста: набор установленных шрифтов и способ вёрстки текста должны следовать целевой платформе, включая текст на восточноазиатских языках, где это применимо.
• Графическое поведение: описание GPU и поведение отрисовки canvas и WebGL должны оставаться в пределах класса устройства, который описывает профиль.
• Язык, региональные параметры и время: списки языков, региональное форматирование и часовой пояс должны согласовываться друг с другом и с регионом, который призван представлять рабочий процесс.
• Мультимедийные возможности и хранилище: кодеки, класс памяти и похожие значения должны быть правдоподобными для целевого устройства.

Семейство сигналов	Что записать до сравнения хостов	Когда считать это расхождением
Идентичность браузера	userAgent, platform, brands	заявленная цель различается между полями
Экран	screen.width, screen.height, devicePixelRatio	значение описывает другой класс устройства
Региональные параметры	languages, locale, timeZone	значения указывают на несовместимые регионы

Этот список служит картой того, что сравнивать. Каждое семейство можно проверять на общем уровне: ведет ли себя страница как ожидалось и совпадают ли значения на репрезентативном хосте с базой, которую утвердила ваша команда. Не нужно читать каждое низкоуровневое значение, чтобы заметить, что профиль с целью Windows сообщает платформу Linux или что профиль с целью Android всё ещё показывает экран настольного компьютера.

Руководство MDN по User-Agent Client Hints показывает, почему первое семейство требует внимания. По умолчанию отправляется небольшой набор значений, таких как бренд браузера, признак мобильного устройства и название платформы. Более подробные значения, например версия платформы, архитектура и модель устройства, возвращаются, только если сервер их запросил. Согласованный профиль должен одинаково отвечать и на значения по умолчанию, и на запрошенные, чтобы ответ, который получает сайт, не зависел от того, какой вопрос он задал первым.

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

Хосты, цели и документированная матрица поддержки

Два термина помогают планировать ясно. Хост это машина и операционная система, на которых запускается браузер. Цель это платформа, которую описывает профиль. В модели, управляемой профилем, они могут различаться намеренно: профиль с целью Windows может работать на ноутбуке macOS во время разработки и на сервере Linux в рабочей среде.

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

Цель профиля	Хост Windows	Хост macOS	Хост Linux (ENT Tier1)
Профиль Windows	Поддерживается	Поддерживается	Поддерживается
Профиль macOS	Поддерживается	Поддерживается	Поддерживается
Профиль Android	Поддерживается	Поддерживается	Поддерживается

Остальные требования: установка BotBrowser на каждом хосте и файл профиля в формате .enc или .json. Хосты Linux и Ubuntu требуют ENT Tier1. Документация по Android Emulation описывает профили с целью Android как возможность лицензии PRO, а статья о тестировании профилей Android показывает, как профиль с целью Android запускается с настольного хоста или сервера.

Документированные сценарии повторяют обычные пути поставки. Команда может разрабатывать на macOS и развертывать на Linux, храня один файл профиля в системе контроля версий или в хранилище секретов и разворачивая его без изменений. Задача CI может запускать один и тот же профиль на раннерах Windows, macOS и Linux и сравнивать ключевые результаты. Парк машин можно переносить между облачными хостами без повторного создания профилей идентичности. Во всех случаях в команде запуска меняется только путь к исполняемому файлу, а файл профиля и параметры запуска остаются прежними.

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

Сравнение хостов и разбор расхождений

Строка сравнения содержит hostOs, botBrowserVersion, profileRevision, launchFlags, displayMode и result; Windows 11, macOS 15 и Ubuntu 24.04 сопоставимы только при одинаковых profileRevision и launchFlags.

Утверждение о согласованности полезно, только когда за ним есть доказательства. Доказательства дает простое контролируемое сравнение во время разрешенного тестирования: держите входные данные неизменными, меняйте только хост и записывайте, что происходит.

1. Зафиксируйте входные данные. Запишите в протокол теста версию BotBrowser, файл профиля и параметры запуска.
2. Выберите репрезентативные хосты. Используйте как минимум один хост Windows, один хост macOS и один хост Linux, похожий на рабочую среду, включая настройку дисплея и графики.
3. Выполните один разрешенный сценарий, который отражает реальную работу, от запуска до ожидаемого состояния страницы.
4. Сравните основные семейства сигналов и поведение страницы с базой выпуска: значения платформы, экрана, языка и времени, шрифты и отрисовку.
5. Храните снимки экрана, заметки и утвержденное решение вместе, чтобы следующий выпуск можно было сравнить с этим.

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

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

Хосты Linux требуют отдельной проверки готовности. Документация по настройке сервера без графического интерфейса описывает базу для Linux, а руководство по бэкенду отрисовки в Linux объясняет, как выбор бэкенда отрисовки влияет на графическое поведение и стоимость развертывания. Считайте настройку дисплея и отрисовки обязательным условием выпуска, а не деталью, которую обнаруживают после развертывания.

Тот же метод подходит для задачи CI. Документация предлагает запускать профиль на раннерах Windows, macOS и Linux и сравнивать ключевые результаты: значения платформы, языки, значения экрана и результаты отрисовки. Держите сравнение на этом уровне. Широкое семейство либо совпадает с базой, либо нет, а расхождение это повод разобраться до выпуска. Более подробно о протоколах приемки, ответственности за развертывание и стоимости работы читайте в материале как оценить согласованность браузера между платформами до развертывания.

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

• Расхождение версий: на одном хосте другая версия BotBrowser.
• Расхождение профилей: использован другой файл профиля или более старая копия того же файла.
• Расхождение параметров: параметры запуска различаются на машине разработчика и на раннере CI.
• Бэкенд отрисовки: различия, связанные с GPU, могут проявляться в режиме без графического интерфейса, и документация отсылает к руководству по настройке сервера без графического интерфейса и к настройке режима GPU.
• Шрифты и отрисовка текста: восточноазиатский текст может отличаться между хостами, и для него есть отдельное руководство.
• Неподдерживаемый хост: хост Linux без ENT Tier1 находится за пределами документированной матрицы поддержки.

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

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

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

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

Кроссплатформенные профили и режим Per-Context

До первой страницы свяжите с контекстом profileRevision, locale, timeZone и метку вроде retailer-de-desktop, чтобы найти его на другом хосте.

Командам, которым нужно много идентичностей, часто приходит вопрос, обязательно ли запускать отдельный браузер на каждую. Документация Per-Context Fingerprint описывает альтернативу: назначать отдельный набор отпечатка каждому контексту браузера внутри одного экземпляра, что снижает накладные расходы и разделяет учетные записи. Per-Context Fingerprint относится к возможностям ENT Tier3.

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

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

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

Что обеспечивает BotBrowser и где проходит граница

BotBrowser может сохранять выбранный профиль источником User-Agent, экрана, шрифтов, GPU и набора языков, поэтому один файл профиля запускается на поддерживаемых хостах Windows, macOS и Linux, а ваша команда может сравнивать результаты на этих хостах при одной версии и одних параметрах запуска. Так у человека, утверждающего выпуск, есть общая база для проверки вместо отдельного результата на каждой машине. BotBrowser не может гарантировать идентичные результаты на каждом хосте и сайте, не заменяет проверку на репрезентативных хостах и не контролирует, как сайт трактует сигналы браузера. Хосты Linux дополнительно требуют ENT Tier1.

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

Пересматривайте план, когда меняются источники. Матрицу поддержки, требования Per-Context и рекомендации по Client Hints ведут их владельцы, поэтому перед обновлением утверждений о поддерживаемых хостах или идентичности в документе о развертывании заново проверьте источники, перечисленные ниже.

Итог

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

Источники

• Документация BotBrowser по кроссплатформенным профилям
• MDN: User-Agent Client Hints API
• Документация BotBrowser по Per-Context Fingerprint