Google против веб-разработчиков: как изменение в кэшировании может повлиять на безопасность всего Интернета

Google против веб-разработчиков: как изменение в кэшировании может повлиять на безопасность всего Интернета

Допустимо ли обманывать ожидания разработчиков ради сомнительного прироста скорости?

image

Компания Google объявила о значительном изменении в поведении кэша для функции BFCache, обеспечивающую мгновенное отображение ранее просмотренных страниц с помощью кнопок «Вперёд» и «Назад» в Chrome. Теперь веб-страница может храниться в кэше, даже если веб-мастер указал не сохранять эту страницу. То есть прямо игнорировать заданные команды.

Как объясняется на сайте web.dev, принадлежащем Google, «BFCache — это кэш в памяти, который хранит полный снимок страницы (включая кучу JavaScript), когда пользователь уходит с неё».

Функция позволяет браузеру быстро и легко восстанавливать страницу, если пользователь решает на неё вернуться. При этом администраторы сайтов могут указывать, как их веб-страницы должны храниться в кэше браузера, используя заголовок «Cache-control:». Одним из вариантов является «Cache-control: no-store» (сокращённо CCNS), который предотвращает сохранение ответа веб-сайта в кэше браузера.

Однако при соблюдении этой команды такие страницы вызывали очевидные проблемы с производительностью, вынуждая браузер загружать их заново, в связи с чем Google предлагает сохранять веб-страницы в BFCache даже при наличии заголовка «Cache-control: no-store» на страницах HTTPS. По мнению компании, это увеличит количество мгновенных навигаций назад/вперёд, улучшая пользовательский опыт.

Фергал Дэйли, инженер Google, заявляет, что основная цель заголовка «Cache-control: no-store» — не предотвращение восстановления страниц с конфиденциальными данными, а избежание восстановления страниц с конфиденциальными данными, к которым пользователь больше не должен иметь доступа.

То есть, при отсутствии изменений в cookie предполагается, что HTTP-запросы браузера и, следовательно, решения о доступе — остаются неизменными. А значит тратить время и трафик на повторную загрузку страницы не имеет смысла.

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

Google работает над решением этих проблем и сначала запустит функцию на тестовых каналах, где соберёт достаточно данных для понимания её влияния.

Некоторые разработчики выражают опасения, что это изменение может нарушить обещание, что заголовок «Cache-control: no-store» означает, что браузер не будет кэшировать веб-страницу. Однако Дэйли утверждает, что этот заголовок обещает только не сохранять веб-страницу в обычном кэше браузера, а не в BFCache.

«Нет явного обещания, что CCNS предотвращает кэширование BFCache. Заголовок CCNS, как и все директивы Cache-control, предназначены для управления HTTP-кэшированием, так что явное обещание касается только HTTP-кэша», — объясняет Дэйли.

«В BFCache не входит HTTP-кэширование, и разработчики не должны интерпретировать заголовок CCNS как обещание того, что страница не будет кэшироваться в BFCache».

Таким образом, переопределив взаимодействие BFCache с директивой CCNS, разработчики Google Chrome надеются создать более отзывчивый опыт просмотра без ущерба для безопасности и конфиденциальности пользователей. Простым пользователям остаётся лишь наблюдать за ситуацией со стороны, ожидая, к чему это приведёт.

Домашний Wi-Fi – ваша крепость или картонный домик?

Узнайте, как построить неприступную стену