Summary

  • Первый опубликованный проект W3C 2015 года показал изнанку выхода из учётной записи: данные сайта лежат в разных частях браузера, а сценарий страницы не может очистить их одним приёмом.
  • Проект 2017 года описал заголовок ответа Clear-Site-Data с отдельными командами для cache, cookies, storage, executionContexts и общей *.

На экране сеанс завершён. В браузере ещё лежит его имущество. В кэше хранятся файлы, в локальном хранилище — материал для работы без сети, в другом месте — cookie. Соседняя вкладка может продолжать исполнять код. Табличка «Закрыто» у входа не отправляет уборщика в подсобку.

В августе 2015 года W3C опубликовала первый открытый проект, посвящённый этой подсобке. JavaScript способен удалить часть данных, но cookie с атрибутом HttpOnly специально выведены из его досягаемости. Чтобы убрать их ответами HTTP, сайту приходится помнить, какие cookie он установил, и истекать их по одному. Локальное хранилище и кэш устроены иначе. Нажатие одной кнопки превращалось в обход отделов с разными ключами.

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

Проект ноября 2017 года придал записке точную форму. Заголовок Clear-Site-Data перечисляет значения в кавычках: "cookies", "storage", "cache", "executionContexts". Их можно сочетать. "*" охватывает все известные типы, включая будущие дополнения. Вместо загадочного «сотрите что-нибудь» сайт передаёт список конкретных шкафов.

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

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

Самая хитрая часть — живые страницы. Очистка cookie не останавливает открытую вкладку по щелчку пальцев. Фоновый worker тоже может удерживать прежнее состояние. Если список содержит "executionContexts", проект 2017 года готовит затронутые контексты, удаляет указанные данные и перезагружает нужные страницы. Иначе пол только что вымыли, а сотрудник уже несёт новую корзину мусора.

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

История публикаций W3C перечисляет открытые рабочие проекты 2015, 2016 и 2017 годов. В них зафиксирован момент, когда браузер перестал быть просто окном для просмотра и превратился в контору с архивом. Для слова «прощай» понадобилась опись имущества.