Несколько аккаунтов в соцсетях с изоляцией браузера

Как платформы могут связать один аккаунт с другим

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

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

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

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

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

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

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

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

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

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

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

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

Отдельная идентичность браузера для каждого аккаунта

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

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

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

Второй способ - набор параметров для каждого контекста. Запускается один экземпляр браузера с базовым профилем, и каждый аккаунт получает свой контекст браузера. BotBrowser документирует, что каждый контекст может иметь собственный профиль, User-Agent, часовой пояс, региональные настройки, зерно шума, прокси и большинство параметров BotBrowser, а страницы одного контекста не могут увидеть или изменить отпечаток другого. Параметры применяются командой BotBrowser.setBrowserContextFlags в сеансе уровня браузера и должны быть применены до открытия первой страницы этого контекста. В документации в качестве требования для этого режима указана лицензия ENT Tier3. Контексты Playwright тоже по замыслу хранят cookie и localStorage раздельно, так что разделение хранилища приходит вместе с разделением отпечатка.

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

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

Прокси, региональные настройки и хранилище сеанса для каждого аккаунта

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

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

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

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

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

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

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

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

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

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

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

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

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

Что покрывает BotBrowser и где он останавливается

BotBrowser может назначить каждому аккаунту собственный профиль, прокси, часовой пояс, региональные настройки и зерно шума, либо как выделенный экземпляр, либо как набор параметров контекста, заданный через BotBrowser.setBrowserContextFlags, так что каждый аккаунт сохраняет отдельную, устойчивую в течение сеанса идентичность браузера и отдельное хранилище. Это помогает команде не допустить, чтобы сигналы отпечатка, хранилища и сети связывали аккаунты. BotBrowser не гарантирует, что платформа не свяжет и не ограничит аккаунты, и не может контролировать поведенческие шаблоны, общие или низкокачественные IP прокси, проверку аккаунтов, 2FA и условия платформы.

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

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

Источники

• Документация BotBrowser по изоляции нескольких аккаунтов
• Контексты браузера Playwright
• Служба httpbin, возвращающая IP