Почему Google уменьшает «время жизни» cookies, полученных с помощью HTTP

Еще в начале года в компании Google сообщили, что с июля (когда выходит Chrome 68) все сайты, использующие HTTP, будут помечаться как небезопасные. В компании считают, что это позволит повысить конфиденциальность пользователей в сети.

Однако на этом работа ИТ-гиганта с HTTP не закончилась. В прошлом месяце стало известно, что Google дополнительно уменьшит «время жизни» cookies, полученных с применением незащищенного протокола, до одного года. Подробнее о ситуации расскажем далее.

/ Flickr / Jeff Herbst / PD

Отправка cookies по HTTP в Google называют риском безопасности. Представители компании отмечают, что «cookie-долгожители» позволяют проводить атаку, получившую название «всеобъемлющий мониторинг» (Pervasive Monitoring). Это масштабное (и часто скрытое) отслеживание передаваемой информации путем сбора артефактов протокола, метаданных (например, заголовков) и данных приложений. Примером ситуации, в которой был замешан этот тип мониторинга, может быть история, когда NSA использовало PREF cookie для слежения за пользователями сети.

Google заявляют, что от подобного типа атак защищает HTTPS. Но так как на более защищенный протокол перешли не все (лишь 81 из 100 сайтов используют HTTPS по умолчанию), исследователи решили пойти дальше и уменьшить время жизни cookies.

Согласно данным телеметрии Google, cookie, полученные по HTTP, «живут» больше года. Разработчики Chrome планируют ограничить время жизни cookie. И сделать это постепенно: сперва сократить до одного года, потом — до нескольких дней. Они убеждены, что так будет сложнее отследить действия пользователей в интернете на разных сайтах.

Это изменение реализуют в обновлении Chrome 70, которое выйдет в конце октября 2018 года.

Суть предложения

Инженеры Google предлагают изменить формат передачи cookie следующим образом.

При формировании заголовка для исходящего запроса на незащищенный URL, сперва будет проверяться дата создания каждого cookie. Если «возраст» больше некоторого порогового значения (12 месяцев, а позднее — несколько дней), то cookie не добавляется в заголовок, а удаляется. Также предлагается изменить алгоритм установки времени создания cookie. Если содержимое осталось прежним, то время создания нового cookie согласуется со временем создания старого.

Как это скажется на работе веб-сервисов?

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

1. Все же перейти на HTTPS.
2. Внедрить систему, похожую на ротацию ID в DoubleClick, значение которых повторно шифруется и обновляется каждый день. Это решение подойдет для тех, кто по каким-то причинам не может перейти на HTTPS.
3. Отказаться от cookies как идентификаторов и использовать вместо них localStorage.

/ Flickr / Joi Ito / CC

А что с другими браузерами?

Разработчики других браузеров также пытались внедрить что-то подобное. Например, 2 года назад представители Mozilla предлагали превратить некоторые cookie браузера Firefox в сеансовые (1 и 2), но от этого предложения отказались.

Идея была в том, чтобы устанавливать cookies на сессию, если они не имели флага secure. Однако тестирование инициативы показало, что слишком малое число сайтов выставляют этот флаг. Даже сайты, которые используют HTTPS (в том числе google.com), пренебрегали этим.

Что касается предложения Google, то в компании надеются, что их решение сократить время жизни cookie подтолкнет сообщество к тому, чтобы сделать HTTPS «стандартом» в веб-среде.

О чем еще мы пишем в корпоративном блоге 1cloud:

Let's block ads! (Why?)