Жизненный цикл и приватность Web Push

Web Push не является постоянным разрешением или долговечным идентификатором. Браузер может выдать разрешение на уведомления, создать подписку с endpoint и ключами, заменить её, а затем удалить. BotBrowser может сохранить объявленное состояние разрешения в авторизованном контролируемом профиле, чтобы команда проверила собственный поток. Он не выдаёт разрешение, не доставляет сообщения, не принимает решение за пользователя и не удаляет endpoint у push-сервиса. Руководство по политике разрешений отделяет допустимость функции политикой от состояния разрешения.

Спецификация Push API, справочник Push API на MDN и спецификация Service Workers описывают объекты и события браузера. Документация BotBrowser о разрешениях рассматривает разрешение как вход профиля; она не описывает жизненный цикл подписки, очистку устаревших endpoint после unsubscribe() и ограничение хранения endpoint и ключей.

TL;DR

• Разделяйте Notification.permission, PushSubscription и запись на сервере.
• Создавайте подписку только после видимого действия и ясного объяснения будущих уведомлений.
• Храните endpoint и открытые ключи только для заявленной цели, с владельцем, сроком и удалением.
• Сверяйте pushsubscriptionchange, ошибки доставки, выход, закрытие аккаунта и unsubscribe().
• Endpoint является маршрутизируемой связуемой величиной, но не ключом личности.

Содержание

• Разделить разрешение, подписку и доставку
• Создать подписку с явным намерением
• Моделировать ротацию endpoint и события сервис-воркера
• Очистить отписку и переходы аккаунта
• Минимизировать приватность и хранение endpoint
• Вести доказательный журнал жизненного цикла
• Практический итог

Разделить разрешение, подписку и доставку

Notifications API показывает состояние разрешения, а Push API создаёт PushSubscription для регистрации сервис-воркера. Это разные состояния. Notification.permission === "granted" означает лишь, что текущий контекст может использовать уведомления; это не доказывает наличие подписки, вход в аккаунт или доставку провайдером. Подписки может не быть даже при сохранённом разрешении.

Держите три автомата. Разрешение: default, denied или granted. Подписка: none, active, rotating, unsubscribed или expired. Доставка: unknown, accepted, rejected или stale по ответу push-сервиса. Единственное поле push_enabled смешивает владельцев и скрывает незавершённую очистку.

registration.pushManager.getSubscription() возвращает подписку или null. null описывает именно эту регистрацию, origin и scope; это не доказательство, что человек никогда не подписывался в другом контексте. Читайте разрешение и подписку вместе, объясняя следующий шаг без вывода о личности. Минимальная запись может содержать случайный внутренний ID, origin, scope worker, необратимую ссылку для дедупликации, протокольные ключи, даты, состояние и причину удаления. Полный endpoint нельзя помещать в аналитику или URL.

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

Создать подписку с явным намерением

До subscribe() объясните категорию, частоту и способ отключения уведомлений. Не вызывайте его при загрузке страницы или скрытым таймером. Сначала зарегистрируйте сервис-воркер, дождитесь navigator.serviceWorker.ready, проверьте scope и вызовите getSubscription(). Если подписки нет, покажите видимый выбор пользователя.

Кнопка включения должна иметь столь же понятный путь выключения. «Включить уведомления о заказе» лучше, чем «Разрешить уведомления». Экран настроек показывает состояние приложения и направляет к настройкам браузера при отказе. Приложение не может отменить отказ браузера.

applicationServerKey связывает подписку с открытым ключом сервиса. Версию ключа меняйте только при запланированной миграции и храните номер версии, а не закрытый материал. Отправляйте endpoint, обязательные открытые ключи, origin и короткий ID запроса через аутентифицированный идемпотентный обмен. Endpoint не доказывает владение аккаунтом.

Различайте отказ, недоступный worker, запрещённый контекст, ошибку провайдера и ошибку ответа приложения. Сохраняйте текущую задачу и предлагайте обычные обновления внутри приложения. Не открывайте отказавшийся prompt снова и не отправляйте неотредактированный endpoint или исключение в общую телеметрию.

Моделировать ротацию endpoint и события сервис-воркера

Endpoint может измениться. Событие pushsubscriptionchange в глобальной области сервис-воркера является сигналом сверки, но не обещанием, что его выдаст каждый браузер. Worker может получить текущую подписку, отправить аутентифицированное обновление и пометить старую строку. Если замены нет, сохраните unknown rotation до следующего явного посещения.

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

Ответ провайдера «endpoint отсутствует» позволяет поставить stale и остановить отправку. Временная ошибка требует ограниченного повторения, а не немедленного удаления. Успешно принятая отправка также не доказывает, что пользователь увидел уведомление. Отделяйте подтверждение доставки от вовлечённости.

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

Очистить отписку и переходы аккаунта

PushSubscription.unsubscribe() удаляет локальную подписку и возвращает boolean. true не удаляет серверную строку, очередь провайдера или внешний журнал. Отправьте отдельный аутентифицированный запрос отключения и учтите офлайн-клиент.

Endpoint очистки должен быть идемпотентным: проверить владельца, отметить строку неактивной и удалить endpoint и ключи из хранилища доставки. Небольшой tombstone может сохранить случайный ID, дату и причину на период защиты от случайной реактивации, но не полный endpoint.

Выход из аккаунта и закрытие аккаунта различаются. Выход может отключить доставки текущей сессии; закрытие отзывает строки аккаунта по политике хранения и удаляет копии приложения. Закрытие вкладки или остановка worker не доказывают ни одно из этих действий.

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

Минимизировать приватность и хранение endpoint

Непрозрачный endpoint всё равно является связуемым маршрутом. Рассматривайте его и открытые ключи как персональные данные или чувствительный псевдоним. Храните их в закрытом хранилище доставки; аналитике нужны только событие, цель и необратимый внутренний ID. Маскируйте значения в поддержке, резервных копиях и экспортируемых файлах.

Срок определяйте целью. Активная строка живёт, пока пользователь согласен получать заявленные уведомления. Устаревшая, неподтверждённая или отозванная строка должна быстро истекать. По окончании цели, закрытии аккаунта или истечении срока удалите либо необратимо скройте endpoint и ключи, оставив причину.

Минимизируйте содержимое уведомления. Оно может попасть на общий экран, а push-сервис обработать метаданные. Лучше передавать непрозрачную ссылку на страницу с обычной авторизацией. Не соединяйте события «subscribed», «rotated», «clicked» и «unsubscribed» с независимыми сигналами браузера для построения постоянного профиля.

Вести доказательный журнал жизненного цикла

Записывайте цель, origin, scope, разрешение, состояние, версию ключа, скрытый ID, действие, время и дату окончания хранения. Безопасный пример формы:

{
  "purpose": "order-status",
  "origin": "https://shop.example",
  "serviceWorkerScope": "/app/",
  "permission": "granted",
  "subscriptionState": "active",
  "keyVersion": "v2",
  "recordId": "psr_7f2c",
  "lastReconciledAt": "2026-10-25T14:00:00Z",
  "retentionUntil": "2026-11-24T14:00:00Z",
  "nextAction": "send"
}

Это форма-заготовка, а не настоящая подписка. Если разрешение granted, а подписка none, предложите явный opt-in; если active, но stale, остановите отправки и проведите сверку; если unsubscribed, удалите активные данные и не подписывайте снова молча; после срока хранения удалите строку и запросите новое решение.

Наблюдение	Значение	Владелец	Безопасный шаг
permission=granted, subscription=null	Браузер разрешает уведомления, локальной подписки нет	Страница и пользователь	Объяснить и предложить opt-in
subscription=active, провайдер говорит gone	Маршрут доставки больше не работает	Сервис доставки	Пометить stale и сверить
unsubscribe() вернул true, строка активна	Локальная очистка завершена, серверная ожидает	API приложения	Повторить идемпотентное отключение
permission=denied, строка активна	Выбор браузера противоречит намерению доставки	Пользователь и приложение	Остановить отправки и объяснить настройки
Срок истёк	Цель закончилась или строка заброшена	Владелец данных	Удалить endpoint и ключи

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

FAQ

Означает ли выданное разрешение активную подписку?

Нет. Подписку ещё нужно создать, зарегистрировать на сервере и сопоставить со своей строкой.

Является ли endpoint fingerprint устройства?

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

Что делать после unsubscribe()?

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

Должна ли ротация создать новый аккаунт?

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

Может ли BotBrowser включить Web Push?

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

Источники

• Push API, W3C
• Push API, MDN
• Service Workers, W3C
• Документация BotBrowser о разрешениях

Практический итог

Рассматривайте Web Push как жизненный цикл: разрешение включает возможность, регистрация сервис-воркера владеет подпиской, сервер разрешает доставку, а очистка завершает цель. Сверяйте ротацию, ошибки, изменения разрешения, выход, закрытие аккаунта и unsubscribe(). Не помещайте endpoint и ключи в аналитику и системы идентичности. BotBrowser повторяет авторизованный ввод разрешения, но намерение пользователя, доставка и удаление остаются ответственностью приложения и провайдера.