Изоляция аккаунтов в браузере: независимые настройки

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

Кратко

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

Содержание

• Пять сигналов, которые могут связать один аккаунт с другим
• Один экземпляр с несколькими контекстами или несколько экземпляров
• Как назначить независимые настройки каждой идентичности
• Как проверять каждую идентичность отдельно
• Практическое заключение

Пять сигналов, которые могут связать один аккаунт с другим

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

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

• Сетевой маршрут. Два аккаунта, которые входят с одного IP-адреса, легко связать. У каждой идентичности должен быть свой одобренный маршрут, и этот маршрут должен исходить от проверенного вами поставщика.
• Сигналы отпечатка. Результаты отрисовки Canvas и WebGL, характеристики звука, размеры экрана и значения navigator происходят от оборудования и операционной системы, поэтому повторяются во всем, что работает на одном компьютере, пока их ничто не меняет.
• Cookies и хранилище. Cookies, localStorage, IndexedDB, кеш и service workers хранят состояние. Любое совместное использование здесь связывает аккаунты напрямую, без всяких догадок.
• Географические метаданные. Часовой пояс, региональные настройки и язык должны согласоваться между собой и с маршрутом. Аккаунт, который будто бы входит из Берлина, но сообщает часовой пояс Нью-Йорка, противоречит сам себе.
• Время активности. Аккаунты, которые всегда начинают, прерываются и действуют в одни и те же моменты с одного компьютера, образуют закономерность, которую не может устранить ни одна настройка браузера.

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

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

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

Один экземпляр с несколькими контекстами или несколько экземпляров

Схема	Граница хранилища	Граница конфигурации идентичности	Эксплуатационный компромисс
один экземпляр, много объектов BrowserContext	одно изолированное хранилище на контекст	профиль, маршрут, locale и seed для каждого контекста	меньше расход памяти; для отпечатка на контекст нужна лицензия ENT Tier3
один экземпляр на идентичность	один каталог пользовательских данных на процесс	один файл профиля и маршрут на экземпляр	более ясная область влияния; выше время запуска и расход памяти

Браузеры на основе Chromium разделяют хранилище по контекстам просмотра. Playwright описывает контекст как изолированный сеанс браузера: у каждого свои cookies, локальное хранилище, данные IndexedDB, кеш и service workers, и тест может открыть много таких контекстов в одном браузере с малыми затратами. Это стандартное поведение, и оно не зависит от какой-либо особой сборки. Оно закрывает третье измерение из списка выше и объясняет, почему контекст служит естественной единицей для одной идентичности.

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

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

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

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

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

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

Как назначить независимые настройки каждой идентичности

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

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

Маршрут и географические метаданные должны согласоваться. Когда вы назначаете прокси контексту через его настройки BotBrowser, BotBrowser определяет часовой пояс, региональные настройки и язык по адресу выхода этого маршрута. Документация также позволяет указать адрес выхода самостоятельно, что пропускает поиск и ускоряет создание контекста. В ней предупреждается, что прокси, заданный только встроенной опцией Playwright, оставляет часовой пояс несогласованным с маршрутом, поэтому для маршрутов отдельных контекстов используйте параметр BotBrowser --proxy-server. Явные значения часового пояса, региональных настроек и языка по-прежнему доступны, если нужно переопределить выведенные, как описано в материале Настройка часового пояса, региональных параметров и языка.

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

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

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

Как проверять каждую идентичность отдельно

Считываемое значение	Ожидаемое сравнение	Поле в реестре
публичный адрес	отличается и совпадает с утвержденным маршрутом	exitIp
locale и часовой пояс браузера	согласуются с регионом утвержденного маршрута	locale и timeZone
вывод Canvas и WebGL	отличается, когда должны различаться выбранный профиль или seed	canvasHash и webglRenderer
cookies и хранилище	отсутствуют вне принадлежащего контекста	storagePartition

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

1. Публичный IP-адрес различается между идентичностями и совпадает с маршрутом, назначенным каждой из них.
2. Сообщаемые часовой пояс, региональные настройки и язык соответствуют региону этого маршрута.
3. Результат отрисовки Canvas различается между идентичностями, использующими разные профили или зерна шума.
4. Строка средства отрисовки WebGL различается между идентичностями, использующими разные профили.
5. Cookies и данные хранилища, записанные в одной идентичности, отсутствуют во всех остальных.

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

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

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

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

Практическое заключение

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

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

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

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

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

BotBrowser позволяет назначить отдельный профиль, прокси, часовой пояс, региональные настройки и зерно шума каждому BrowserContext в одном экземпляре браузера (отпечаток для каждого контекста требует описанной в документации лицензии ENT Tier3) либо запускать отдельные экземпляры со своими профилями и каталогами пользовательских данных, так что каждая идентичность получает независимые настройки отпечатка и сети, а вы можете разделять аккаунты без содержания полного парка компьютеров. BotBrowser не может гарантировать, что аккаунты никогда не будут связаны: он не предоставляет прокси и репутацию IP-адресов, не контролирует корреляцию по поведению и времени, то, как вы обращаетесь с cookies, и политику аккаунтов платформы, и не заменяет продуманного операционного разделения аккаунтов.

Источники

• BotBrowser: Multi-Account Isolation
• BotBrowser: Per-Context Fingerprint
• BotBrowser: Per-Context Proxy
• Playwright: Isolation with browser contexts
• Playwright: HTTP proxy