Разделение хранилища браузера и конфиденциальность

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

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

Что меняет ключ разделения

Cookies, созданное скриптом хранилище и другое клиентское состояние могут зависеть от сайта верхнего уровня. Обзор State Partitioning на MDN описывает общую модель, а материал Privacy Sandbox рассматривает ее в контексте Chromium. Конкретные API и правила зависят от браузера и версии.

Один origin поэтому может увидеть разные данные под сайтами A и B. Выбор согласия, настройка или сессия из одного контекста могут отсутствовать в другом. Компонент должен иметь понятный путь первого запуска и объяснять, когда требуется снова выбрать учетную запись или настройку.

Навигация верхнего уровня отличается от встраивания. Сервис, открытый как основной сайт, работает в контексте первой стороны; тот же сервис во frame подчиняется правилам встроенного контекста. Успешный вход на основном сайте не доказывает, что встроенный вход получит то же состояние.

Разделение может затрагивать service workers, cache, IndexedDB и локальные настройки. Ресурс, сохраненный в другом контексте, иногда приходится загрузить повторно. Продукт должен определить, что можно скачать заново, какой выбор нужно повторить и как сохранить текущую задачу пользователя.

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

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

Что подтверждает каждое наблюдение

• Разделение хранилища: Если синтетическое значение читается во встроенном frame под сайтом A, но не под сайтом B, это согласуется с разными разделами; такой результат не устанавливает личность человека и не доказывает, что разделены все API. Сравните запись и чтение в одном и том же frame и origin в обоих контекстах. Privacy Sandbox описывает эту границу для API хранилища, включая локальное хранилище и IndexedDB.
• Серверная авторизация: Успешный ответ показывает, что сервер разрешил именно этот запрос для тестовой учетной записи с примененной политикой; он не показывает, что хранилище браузера не разделено, и не подтверждает доступ к другим конечным точкам. Сравните ответы на один разрешенный и один запрещенный тестовый запрос.
• Исключение доступа к хранилищу: Успешный запрос к API доступа к хранилищу показывает, что доступ предоставлен этому документу в данном контексте; он не доказывает постоянный или универсальный доступ. Запишите результат API и результат одного последующего чтения в собственном тестовом frame.
• Поток данных встроенного компонента: Наблюдаемый запрос показывает, какие данные достигли этой конечной точки в данном тесте; он не доказывает, что другие данные не отправляются или что именно сохраняет сервер. Проверьте назначение и синтетическую нагрузку одного собственного запроса и сравните их с выбором пользователя.

Проектирование встроенного приложения

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

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

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

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

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

Конфиденциальность и минимизация данных

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

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

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

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

Руководство по cookies рассматривает сессии и хранение, а материал о квоте хранилища объясняет наблюдения емкости. Квота не доказывает верхний контекст, а разделение не оправдывает сбор дополнительных измерений.

Тестирование разделенного состояния

Используйте два собственных верхних сайта и один собственный встроенный сервис. Начните с чистых профилей. Создайте синтетическую настройку под сайтом A и повторите под сайтом B. Ожидание формулируйте как пользовательское правило, например отдельный выбор согласия для каждого сайта.

Отдельно проверяйте первую сторону и встраивание. Первый сценарий покрывает обычный аккаунт и настройки; второй покрывает пустой раздел, отказ в доступе и переход на страницу сервиса. Не отправляйте реальные аккаунты и документы на тестовый endpoint.

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

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

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

Диагностика совместимости

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

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

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

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

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

Проверка релиза и эксплуатация

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

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

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

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

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

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

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

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

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

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

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

Открытые источники

• MDN: State Partitioning
• Privacy Sandbox: разделение хранилища