Границы браузерной идентичности для командных аккаунтов
Разделяйте браузерные идентичности команды с ясными границами хранилища, прав, владения и передачи.
BotBrowser Team
Нужна структурированная документация по теме Идентичность?
Эта статья относится к редакционной библиотеке. Для пошаговой настройки, справки и постоянных обновлений переходите сразу в соответствующий раздел docs.
BotBrowser может повторить разрешённый сценарий командного аккаунта в объявленных контексте и профиле. Он не выдаёт доступ, не делает совместное использование учётных данных безопасным, не обходит правила origin или разрешений и не доказывает отсутствие связи между аккаунтами. Разделение идентичности является границей владения и приватности, а не способом обхода правил платформы.
Назначьте владельца до открытия context
Укажите владельца аккаунта, цель, разрешённых операторов, контакт восстановления и дату проверки. У командного аккаунта должен быть один ответственный владелец. Отметьте, предназначен ли контекст для production, синтетического fixture, поддержки или проверки. Не помещайте личные учётные данные в общий скрипт и не считайте профиль записью разрешения.
Разделяйте context и состояние сайта
Cookie, веб-хранилище, IndexedDB, кэш-хранилище и регистрации сервисного worker являются состоянием браузера, ограниченным origin. Отдельный BrowserContext или каталог данных разделяет локальное состояние, но не передаёт владение сервером, не отзывает удалённую сессию и не удаляет журналы. WHATWG HTML и API хранилища MDN описывают эти границы, но не универсальный переносимый формат командной идентичности.
Для каждого аккаунта используйте одну цель и одного владельца context. Тестовые fixture должны быть синтетическими. Никогда не копируйте между аккаунтами cookie, сохранённые пароли, токены или выгрузки хранилища. При выходе или выводе из эксплуатации различайте локальную очистку и серверный отзыв и фиксируйте реально выполненное действие.
Применяйте минимальные права и видимые разрешения
Выдавайте только нужную роль и разрешения браузера. Запрос разрешения является решением пользователя, а не доказательством владения аккаунтом. Повторно проверяйте доступ при изменении оператора, цели, назначения или срока хранения. Принципы приватности W3C поддерживают ограничение цели и минимизацию данных, но за политику отвечает владелец приложения.
Ведите реестр владельца, оператора, цели, области, срока и пути отзыва. Отдельно проверяйте расширения, загрузки, уведомления, буфер обмена и разрешения устройств. Чистый локальный context не превращает широкую серверную роль в минимальную.
Передача, восстановление и вывод из эксплуатации
При передаче отзовите доступ уходящего оператора, выдайте его через утверждённый поток сервиса и подтвердите область нового оператора. Не передавайте архив профиля вместо управления аккаунтом. Храните только необходимое доказательство, без учётных данных и личного содержимого. Используйте состояния: запланировано, доступ отозван, локальное состояние очищено, серверное действие ожидается, завершено.
Если context смешан или учётные данные раскрыты, остановите соответствующее использование, сообщите владельцу, выполните ротацию через утверждённый путь и создайте чистый context. Не исправляйте общий архив незаметно и не называйте его изолированным.
Возможности и ограничения BotBrowser
BotBrowser может повторить разрешённый сценарий с объявленными профилем и контекстом и сравнить видимые результаты между утверждёнными версиями браузера. Он не определяет владельца, не выдаёт и не отзывает серверные роли, не обходит origin или разрешения, не гарантирует удаление удалённых записей локальной очисткой и не делает общие учётные данные безопасными. Сопоставляйте его доказательства с журналами доступа и проверкой приватности.
Практический список
- Назначьте владельца и цель context.
- Разделите cookie, хранилище, кэш, worker, разрешения и загрузки.
- Используйте минимальные права со сроком и отзывом.
- Различайте локальную очистку и отзыв на сервере.
- При передаче или раскрытии отзовите, ротируйте и создайте чистый context.
Связанные материалы: Очистка данных сайта и границы аккаунтов и Изоляция браузера для нескольких аккаунтов.
Перед открытием общего аккаунта проверьте назначение, требуемую роль и срок хранения. Если данных не хватает, остановите сценарий и обратитесь к ответственному владельцу.
Описывайте сбои как ограниченные наблюдения. Указывайте версию, context и видимый результат, не превращая отказ в разрешении в утверждение обо всём аккаунте.
При передаче доказательств удаляйте учётные данные, личные URL и значения хранилища. Оставляйте версию, цель, видимый результат и подтверждение сервиса.
Отделяйте наблюдение браузера от подтверждения сервиса. Видимый результат не доказывает отзыв удалённой сессии.
Пересматривайте срок хранения при смене оператора или цели. Локальная очистка и удаление на сервере должны иметь разные состояния.
Если никто не может объяснить, кто утверждает следующий шаг, остановите сценарий и передайте решение владельцу аккаунта.
Чёткая граница помогает исправить доступ, не раскрывая частное состояние браузера.
Sources
WHATWG HTML о веб-хранилище, API хранилища MDN, Принципы приватности W3C, NIST SP 800-63B и изоляция нескольких аккаунтов BotBrowser.
Похожие статьи
Переведите BotBrowser из исследований в продакшн
Используйте эти руководства, чтобы понять модель, а затем перейти к кроссплатформенной валидации, изолированным контекстам и масштабируемому браузерному развертыванию.