Постоянные сессии и согласие на куки в соответствии с GDPR

Поддержка
1

Я настраиваю форум на Discourse в среде, где особое внимание уделяется конфиденциальности. Сейчас я столкнулся с проблемой настройки параметра persistent sessions (постоянные сеансы), то есть функции «Запомнить меня» при входе. Насколько я понимаю, GDPR требует от пользователя явного согласия на хранение функциональных или предпочтительных cookies, включая постоянные сеансы, поскольку cookie, используемый для управления постоянным сеансом (а точнее, его срок жизни, выходящий за пределы сессии браузера), не является строго необходимым.

Это приводит к двум крайне непривлекательным вариантам:

  1. Отключить persistent sessions, заставив каждого пользователя входить в систему при каждом посещении форума, либо предложить/заставить их использовать хранение учетных данных в браузере, если они хотят избежать ручного входа каждый раз. Однако, поскольку мы будем использовать SSO для доступа к форуму, и через этот вход в SSO осуществляется доступ ко многим другим сервисам, предложение пользователям хранить учетные данные SSO исключительно для доступа к форуму — не лучшая политика. Это может принести больше вреда, чем пользы.

  2. Включить persistent sessions. Но здесь я не вижу жизнеспособного способа интеграции баннера с уведомлением о cookies в Discourse, который бы обрабатывал значение флага постоянных сеансов для каждого конкретного пользователя. Последнее критически важно, поскольку согласие должно быть получено от пользователя, включая возможность его отозвать, что требует наличия решения в виде баннера или системы управления cookies.

Я активно участвую в ряде форумов на Discourse, где persistent sessions включены, но нет опции согласия на использование cookies (включая этот мета-форум). И мне кажется, что они действуют в нарушение GDPR?

Не ошибаюсь ли я в своей трактовке (я ведь не юрист)? И действительно ли нет доступных хороших решений, которые интегрируют баннер согласия на использование cookies в Discourse и при этом позволяют настраивать постоянные cookies для каждого пользователя?

Редактирование: Я прочитал Cookie Consent, GDPR, and Discourse и такие посты, как Session Timeout - #56 by sam, перед публикацией, но они не затрагивают суть вопроса о постоянных сеансах.

2

Теперь речь идёт о двух разных вещах.

С юридической точки зрения, в соответствии с GDPR/законами о защите данных, согласие не требуется для постоянного сеанса. Это технический cookie для пользователя, и он не используется для сбора персональных данных. Конечно, вы должны сообщить о его наличии, но если пользователь хочет избежать запоминания, ему следует выходить из системы каждый раз. Вы всё ещё можете предложить эту опцию.

А вот это:

Это совершенно другая игра и другая игровая площадка. Здесь, в странах Северной Европы, все сайты, работающие в сфере банковского обслуживания, здравоохранения, государственные или местные органы власти и т. д., автоматически завершают сеанс через определённое время или после периода бездействия (надеюсь, это верно для всего мира), и тогда постоянные сеансы становятся невозможными. То же самое верно и для сайтов, которые по своим собственным причинам очень строго относятся к конфиденциальности.

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

Но в целом согласие пользователя для этого не требуется. Однако могут быть особые случаи, когда вы вообще не можете предложить такую опцию.

3

Суть не в том, что cookie не собирает персональные данные. Cookie _t идентифицирует вас как личность, поскольку он напрямую связан с вашей пользовательской сессией на сервере Discourse. Таким образом, наличие файла аутентификации в вашем браузере означает, что сервер может идентифицировать вас каждый раз, когда вы используете этот браузер для посещения веб-сайта, установившего его (и, следовательно, вы не анонимны). Согласно Мнению рабочей группы по защите данных Европейской комиссии WP 29 Opinion 04/2012 о освобождении от согласия на использование cookie - 00879/12/EN WP 194:

Постоянные файлы cookie для входа, хранящие токен аутентификации между сеансами браузера, не подпадают под освобождение по КРИТЕРИЮ B. Это важное различие, поскольку пользователь может не сразу осознавать, что закрытие браузера не очищает его настройки аутентификации. Он может вернуться на веб-сайт, полагая, что действует анонимно, хотя на самом деле он все еще входит в систему. Обычный метод использования флажка и простой информационной заметки, такой как «Запомнить меня (использует cookie)» рядом с формой отправки, будет подходящим способом получения согласия, тем самым устраняя необходимость применения освобождения в данном случае.

Обратите внимание, что они предлагают простое решение, которое веб-сайты могут реализовать: флажок «Запомнить меня» в форме входа, который, конечно же, доступен почти везде в наши дни (но не в Discourse). Это решение было принято в 2012 году, до вступления в силу GDPR, но я не вижу информации о том, что оно было отменено (например, статья Cookie Consent Exemptions: Strictly Necessary Cookies - CookieYes, обновленная в августе 2023 года, все еще указывает, что для постоянных файлов cookie аутентификации требуется согласие). Однако возможно, что существуют некоторые правовые последствия или разработки, о которых я не знаю.

4

Неверно. Это и есть единственная суть.

Это не сбор и хранение персональных данных, которые могут или будут использованы для идентификации пользователя. Форум и так знает, кто вы.

5

Как форум узнает, кто вы, если вы заходите на него с браузера, в котором этот cookie не установлен? И вы должны иметь возможность пользоваться форумом без неявного отслеживания, если только вы не дали явного согласия на это — в данном случае, что вы разрешаете cookie _t сохраняться после окончания сеанса браузера.

6

Для ясности: вышеуказанная информация неверна.

@paulmelis, думаю, вы правы, и это важное замечание.

Для постоянного cookie требуется явное разрешение, даже если он обеспечивает определённый функционал для пользователя: пользователь должен был явно запросить этот функционал.

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

Таким образом, даже если на вашем форуме есть баннер согласия на использование cookie, если включена функция постоянных сессий, вы всё равно нарушаете GDPR.

При этом, я сомневаюсь, что на практике это станет большой проблемой, но для тех, кто стремится к 100% соответствию требованиям, это действительно проблема.

На данный момент ваш единственный вариант — отключить настройку persistent sessions.

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

8

Нет, это не так. Это многократно обсуждалось с юристами ЕС в крупных компаниях, и ничего не менялось.

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

9

@paulmelis привёл цитаты из официальных документов ЕС, в которых прямо указано, что это не разрешено GDPR.

Если у вас есть другая информация, я весь во внимании, но, пожалуйста, укажите источники и предоставьте ссылки на оригинальные документы.

10

В этом нет ничего подобного.

Без обид, но это так же сложно и в некотором смысле бессмысленно — предлагать официальное законодательство в качестве источника, как бессмысленно направлять к секретам команды man swapon. Для этого требуется определённый уровень знаний: я могу читать эти страницы руководства, но не понимаю, что именно там написано.

Я работаю с этим ежедневно, и ни один из этих вопросов не является для меня новым. Вот почему я даю две рекомендации:

  • приобретите необходимое программное обеспечение и узнайте, на что именно требуется согласие для всего (это не поможет, потому что в конечном счёте важно то, как используются данные, а не само согласие как таковое);
  • если предприятие достаточно велико (как, например, CDCK), и существует реальный риск получения штрафов, то необходимо обращаться в юридический отдел компании или к профессиональным сторонним специалистам уровня 3.
11

Да, именно это я сейчас и делаю (к сожалению).

Мне очень интересно, как вы прочитали этот документ. Я имею в виду, что раздел 3.2 Cookies аутентификации излагает всё довольно чётко:

Cookies аутентификации используются для идентификации пользователя после входа в систему (например, на сайте онлайн-банкинга). Эти cookies необходимы для того, чтобы пользователи могли аутентифицироваться при повторных посещениях сайта и получать доступ к защищённому контенту, например, просматривать свой баланс, транзакции и т. д. Cookies аутентификации обычно являются cookies сеанса. Использование постоянных cookies также возможно, но их нельзя считать идентичными, как обсуждается ниже.

Здесь признаётся необходимость cookies аутентификации (обратите внимание, они не называются техническими cookies). Чётко указывается, что срок их действия — сеансовый или постоянный — подразумевает разный подход к ним.

Когда пользователь входит в систему, он явно запрашивает доступ к контенту или функционалу, на который у него есть права. Без использования токена аутентификации, сохранённого в cookie, пользователю пришлось бы вводить имя пользователя и пароль при каждом запросе страницы. Следовательно, эта функция аутентификации является неотъемлемой частью услуги информационного общества, которую пользователь явно запрашивает. Поэтому эти cookies освобождаются согласно КРИТЕРИЮ B.

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

Вход в систему означает, что пользователь дал согласие на вход в систему, но не на другие виды использования данных через любые установленные cookies аутентификации.

Постоянные cookies входа в систему, которые хранят токен аутентификации между сеансами браузера, не освобождаются согласно КРИТЕРИЮ B. Это важное различие, поскольку пользователь может не сразу осознавать, что закрытие браузера не очистит его настройки аутентификации. Он может вернуться на сайт, полагая, что остаётся анонимным, хотя на самом деле всё ещё вошёл в систему. Обычный метод использования флажка и простого информационного сообщения, например «запомнить меня (использует cookies)» рядом с формой отправки, был бы подходящим способом получения согласия, тем самым устраняя необходимость применять освобождение в данном случае.

КРИТЕРИЙ B гласит:

cookie «строго необходим для того, чтобы провайдер услуги информационного общества, явно запрошенной подписчиком или пользователем, мог предоставить эту услугу».

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

Да, законодательство размыто и сложно, с множеством различных обновлений почти за два десятилетия. И даже официальные сайты ЕС, которые я изучал, кажутся очень запутанными в том, как они обрабатывают cookies и формулируют свои политики.