Назад к блогу
Идентичность

Границы браузерной идентичности для командных аккаунтов

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

BotBrowser Team

Документация

Нужна структурированная документация по теме Идентичность?

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

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

Нейтральная к языку схема отдельных context, границ локального хранилища, минимальных прав и контролируемой передачи.

Назначьте владельца до открытия 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

Переведите BotBrowser из исследований в продакшн

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