Как обрабатывать новые правила для файлов cookie сторонних производителей, начиная с Chrome 80? - PullRequest
4 голосов
/ 01 ноября 2019

Начиная с Chrome 80, сторонние куки будут заблокированы, если они не имеют SameSite=None и Secure в качестве атрибутов. С None в качестве нового значения для этого атрибута. https://blog.chromium.org/2019/10/developers-get-ready-for-new.html

В приведенном выше сообщении в блоге говорится, что Firefox и Edge планируют внедрить эти изменения на неопределенную дату. И здесь есть список несовместимых браузеров, перечисленных здесь https://www.chromium.org/updates/same-site/incompatible-clients.

Что было бы лучшим решением для решения этой ситуации для кросс-браузерной совместимости?

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

1 Ответ

2 голосов
/ 04 ноября 2019

Вы столкнулись с тем, что по мере того, как браузеры переходят на более эффективные методы сохранения конфиденциальности пользователей, это меняет подход сайтов к обработке данных. Определенно существует противоречие между компоновкой / встраиваемостью веб-страниц и проблемами конфиденциальности и безопасности этого смешанного контента. Я думаю, что в настоящее время это выходит на первый план в конфликте между блокировкой векторов дактилоскопии, чтобы предотвратить отслеживание пользователей, которые часто являются теми же сигналами, которые используются сайтами для обнаружения мошенничества. Вечная проблема, заключающаяся в том, что если у вас есть идеальная конфиденциальность по «веским» причинам, это означает, что все люди, совершающие «плохие» поступки (например, перебирая партию украденных кредитных карт), также имеют идеальную конфиденциальность.

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

В краткосрочной перспективе есть несколько вариантов на https://web.dev/samesite-cookie-recipes:

  1. Используйте дванаборы файлов cookie, один с текущими заголовками формата, а другой без перехвата всех браузеров.
  2. Перехватите useragent для возврата соответствующих заголовков в браузер.

Вы также можете сохранить первыйсторонние файлы cookie, например SameSite=Lax или SameSite=Strict, которые вы используете для обновления межсайтовых файлов cookie, когда пользователь посещает ваш сайт в контексте верхнего уровня. Например, если вы предоставляете встраиваемый виджет, который предоставляет персонализированный контент, в случае, если нет файлов cookie, вы можете отобразить сообщение в виджете, которое связывает пользователя с исходным сайтом для входа. Таким образом, вы явно сообщаете значениедля вашего пользователя, позволяющего идентифицировать их через эту границу сайта.

Для более долгосрочного просмотра вы можете посмотреть на предложения, подобные HTTP State Tokens , в которых описывается один контролируемый клиентомтокен с явным межсайтовым соглашением. Также существует предложение isLoggedIn , которое касается предоставления возможности указать браузеру, что для отслеживания сеанса пользователя используется определенный токен.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...