GDPR вступил в силу уже четыре года назад, однако его понимание и практика применения до сих пор развиваются (однако мои предыдущие статьи по-прежнему актуальны: первая, вторая). Как показывают последние новости, далеко не все преуспели в борьбе за соответствие – в январе французский регулятор выписал Google и Facebook серьёзные штрафы (на €150 млн и €60 млн соответственно) за нарушения законодательства в отношении cookies, причём для Google это уже второй штраф за них (предыдущий был на €100 млн).
Именно тема cookies постепенно становится "горячей": ей занялись не только регуляторы, но и активисты – например, прошлым летом прогремел случай noyb с массовой рассылкой жалоб.
Что говорят законы
Правила, действующие в отношении cookies, основываются частью на GDPR, частью – на ePrivacy Directive (идущий ей на смену ePrivacy Regulation уже несколько лет в статусе draft). В этой статье собрано текущее понимание этих правил для практического применения.
GDPR говорит, что только некоторые cookies могут быть идентифицированы как персональные данные – те, что могут быть использованы для построения профилей физических лиц и, в конечном счёте, для их идентификации. Если бы cookies регулировались только положениями GDPR, законные основания (lawful bases) потребовались бы только для тех из них, которые могут помочь в идентификации физического лица и при этом не связаны с основным функционалом сайта (использование которого и является целью посещения – в терминах GDPR это считается контрактом). Например, согласие (consent) не пришлось бы получать ни на какие cookies настроек (показывать/не показывать что-то, сортировать так или эдак – они не могут облегчить идентификацию) и на любые cookies основного функционала, включая идентифицирующие пользователя. Так же GDPR допускает другие законные основания, помимо согласия – например, общественные интересы или законные интересы владельца сайта.
ePrivacy Directive требует, чтобы все cookies за исключением строго необходимых обрабатывались одинаково – только согласие физического лица может быть законным основанием для сохранения на пользовательском устройстве cookies помимо строго необходимых. В отличие от GDPR, никакие другие законные основания не допускаются! Необходимыми считаются те cookies, без которых невозможно предоставление пользователю запрошенной услуги или которые требуются для соответствия законодательству, например, в части обеспечения безопасности.
В черновике ePrivacy Regulation попытались немного смягчить это правило, добавив исключений, но это изменение совсем небольшое, да и сроки завершения этого долгостроя неизвестны.Обязанность получить согласие (consent) перед сохранением cookies означает обязанность соответствовать всем требованиям, налагаемым GDPR на согласие (а их немало – кратко можно ознакомиться в моей предыдущей статье). В том числе, это означает (и именно на этих требованиях погорели Google и Facebook в этот раз), что предоставление или не предоставление согласия должны быть одинаково простыми, так же как отзыв ранее предоставленного согласия в любой момент.
Как это должно выглядеть на практике
Выбор "принять только необходимые cookies" присутствовать должен обязательно – как вариант, в виде "принять выбранные" с отмечанием по умолчанию только необходимых.
Согласие для опциональных cookies не должно никаким образом быть предварительно выбрано.
Вариант "принять все cookies" не обязан присутствовать, но вам наверняка захочется его реализовать. Выделять каким-либо образом этот вариант в сравнении с "принять только необходимые" – незаконно!
Список необходимых cookies не должен включать те, без которых возможна корректная (функционально и юридически) работа сайта. Говоря проще, если какие-то cookies можно убрать, при этом сайт продолжит работать и владельца не накажут за нарушение какого-нибудь закона, значит эти cookies нельзя включать в необходимые.
Все cookies должны быть описаны простым понятным языком.
Все cookies должны быть осмысленно и честно категоризованы.
Настройки согласий на cookies должны быть легко доступны в любой момент.
Согласия должны логироваться – на что конкретно согласился, когда и кто (идентификатор).
Важно понимать, что несоответствие требованиям часто означает не "небольшую недоработку", а недействительность собранных согласий со всеми вытекающими.
Когда cookies не просто cookies
Необходимо осознавать, что согласие на сохранение конкретной cookie – это просто согласие на сохранение этой cookie и ничего больше. Если за этим стоит функционал, связанный с передачей третьей стороне данных, которые могут быть идентифицированы как персональные – согласие на такую передачу не распространяется. С учётом широкого толкования понятия персональных данных в GDPR (кратко описано в моей первой статье), практически любая принесённая сторонним скриптом cookie несёт угрозу в этом аспекте.
Тонкий нюанс географии действия
В рамках разбирательства с маркетингом, могут ли они хоть в каком-то объёме сохранить отслеживание пользователей через Google Analytics и подобные сервисы, мне пришлось тщательно изучить "территориальный вопрос": должны ли мы использовать одинаковые правила для cookies для всех посетителей наших сайтов или мы можем запрашивать согласие на сохранение cookies только у посетителей из EU? Для компании не из Европы всё было бы просто – на не-европейцев не распространяются ни GDPR, ни ePrivacy Directive. А для европейских компаний (как наша) всё сложно – есть только маленький зазор между GDPR и ePrivacy Directive:
Как европейская компания, мы должны соблюдать GDPR в отношении любых физических лиц, что влияет только на cookies, которые напрямую содержат персональные данные или могут быть использованы для построения профилей физических лиц.
ePrivacy Directive применяется ко всем cookies, но только при нахождении конечного пользователя/терминала на территории ЕС.
Выглядит так, что у нас есть возможность не запрашивать согласие для cookies, которые не содержат персональные данные и не могут быть использованы для построения профилей физических лиц в случае, когда запрос приходит не с территории ЕС... Поскольку все cookies сторонних трекеров безусловно подпадают под GDPR, единственный способ использовать этот зазор заключается в реализации собственного трекера, тщательно выверенного для соответствия GDPR – в общем случае, это имеет мало смысла.
В заключение
Проблема cookies для сайтов, работающих на европейскую аудиторию, является очень актуальной – большинство ещё не оштрафованы только потому, что регуляторы не успевают их "обслужить". И хотя реализация идеального решения очень сложна (даже сайт Еврокомиссии нельзя считать образцом), имеет смысл приложить некоторые разумные усилия, чтобы привести свой сайт хотя бы к состоянию "ну мы правда старались". Если же ваш сайт бросает вызов властям, то рано или поздно они явятся – итог вам точно не понравится.
Комментарии (25)
olku
08.07.2022 00:32+1Куки лишь один из множества способов идентификации, есть смысл заменить это слово в статье. На Consent есть отдельный документ регулятора, уже вторая версия.
S0krat Автор
08.07.2022 08:33Вы правы, речь идёт не только о cookies непосредственно, но и всех подобных решениях - ePrivacy Directive определяет их через "использование способностей пользовательского терминала к сохранению или доступ к информации сохраненной на пользовательском терминале", но даже в тексте закона обычно называет просто cookies.
Consent - отдельная большая тема, её просто невозможно впихнуть довеском в эту статью.olku
08.07.2022 09:11Ничего, впихнем. :) Регулятор постарался, вместе с канцеляритом дает примеры.
Версия 2018 года https://habr.com/ru/post/494364/
Версия 2020 года, на Хабре не дублировал, отличается разъяснением о "стене куки" https://medium.com/noleaks-eu/согласие-на-обработку-персональных-данных-2020-ce513eef6073S0krat Автор
08.07.2022 10:43Уважаю ваш труд, но входящему в тему GDPR необходимо уметь читать как минимум английский, а лучше немецкий.
olku
08.07.2022 10:52Не понял критику. Так можно и Вашу статью дезавуировать, и половину контента Хабра вместе с авторами.
S0krat Автор
08.07.2022 11:00+1Почему критика-то? :) На Хабре у вашей публикации куча прочтений, плюсиков и закладок - очевидно, кому-то она была полезна.
Я просто заметил, что если людям нужен перевод - у них большие проблемы... Мне кое-что по теме приходится читать в гуглопереводе с немецкого - это очень тяжело. :( А даже на английском этих материалов нет и всё.
Lelant0s
09.07.2022 10:33Входящему в тему GDPR достаточно английского, т.к. во-первых сам GDPR публикуется в первую очередь на английском, во-вторых, второй важный документ (DPA - аналог GDPR для Великобритании) - также на английском. Роль UK в IT бизнесе Евразии в разы больше, чем Германии, важные пояснения регулятора (ICO) к DPA - также, разумеется, на английском.
S0krat Автор
10.07.2022 20:06Аналог GDPR для Великобритании называется UK GDPR, поскольку является форком исходного GDPR после выхода UK из EU.
DPA - это совсем другое.
Английского, в общем, достаточно, но допольнительный немецкий был бы очень полезен, поскольку именно немцы дают очень интересные судебные случаи.Lelant0s
10.07.2022 20:19GDPR-UK это, условно говоря, "ламерское" (не имею в виду вас - его повсеместно так называют те, кто не в теме деталей) название DPA. В Великобритании основным документом является DPA, выступающий реинкарнацией GDPR в рамках Великобритании: https://www.gov.uk/data-protection
S0krat Автор
10.07.2022 21:55UK GDPR - это то название, которое использует британский регулятор. Весь смысл принятия Data Protection Act 2018 - зафиксировать отмену Data Protection Act 1998 в пользу GDPR, поскольку GDPR в рамках ЕС является законом прямого действия (в отличие от ePrivacy Directive, например). После выхода Британии из ЕС, конечно, его модифицировали, чтобы сохранить GDPR под именем UK GDPR уже.
perezanov
08.07.2022 00:37сделали несколько крупных штрафов для гигантов, юристы потом в частном порядке тоже попытались заработать и всё сдулось. У коньяка в вашем примере будет 100 лет выдержки, пока кто-то возьмется за его куки
S0krat Автор
08.07.2022 08:36Штрафуют и не гигантов тоже - прессе не интересно рассказывать о штрафах в несколько десятков тысяч евро на какие-то никому не известные локальные конторы, поэтому эти случаи не на слуху.
olku
08.07.2022 09:20Я общался с этим австрийским адвокатом. Нарушения монетизировать не выходит, суды закончились ничем. Это корова национальных регуляторов.
eimrine
08.07.2022 08:55+2Ну почему, почему эту байду нельзя было реализовать на стороне браузера как Do Not Track?
Куки-баннеры это одно из худших нововведений Интернетов: я не хочу ничего там кликать, у меня автоудаление всех кук, я лучше прочитаю статью через уменьшенный в 10 раз вьюпорт (куки-баннеры, как правило, перекрывают контент) но моего царского клика они не получат. Я считаю очень неправильным прийти по ссылке, но тратить внимание на что-либо кроме контента, а удалять все куки после сеанса меня ещё в универе научили так что в следующее посещение баннер для меня будет всё там же хоть что бы я не кликал.S0krat Автор
08.07.2022 09:02I know that feel bro...
Кстати, соответствующий законодательству куки баннер в этом плане наименьшее зло - кнопка "принять только необходимые cookies" (или "отвергнуть все") в нём присутствует в обязательном порядке.
Хуже, когда куки баннер не соответствует требованиям - там отказ от лишнего может быть спрятан очень глубоко.
Lelant0s
09.07.2022 10:36Все очень просто. Инициативы типа DoNotTrack или P3P рубятся рекламной индустрией на стадии их входа в W3.org для попытки стать стандартом на уровне индустрии. Оба проекта сейчас полудохлые именно по этой причине.
hardtop
08.07.2022 11:21А как правильно это реализовать технически? Например, на сайте есть Корзина (эту сессию, наверное можно включать по-умолчанию - или нет?), счётчик Яндекса и счётчик Гугла.
Я показываю плашку о согласии на куки, где есть 2 чек-бокса: Яндекс - [да\нет], Google - [да\нет]. Пользователь согласился на куки от Яндекса. И сайт должен включить код для него, а для гугла не включать?
Как правильно это делать? Ведь код счётчика уже зашит в шаблон. Запоминать выбор пользователя и через js вызывать? Есть какой-нить толковый пример по теме? Спасибо!
S0krat Автор
08.07.2022 12:54+1Технически всё зависит от вашего технологического стека и выбранного куки баннера, а дальше просто гуглите, например, "как интегрировать cookiebot и wordpress" и получаете рецепты.
> Корзина (эту сессию, наверное можно включать по-умолчанию - или нет?)
Для интернет-магазина можно считать необходимой - человек пришел в магазин, тем самым он изъявил намерение что-то купить, для чего технически нужна эта сессия. Чтобы решение было бесспорным, лучше не ставить вообще никаких кук до выбора "принять только необходимые" или "принять все" - тогда случайный посетитель может просто уйти и не получить никаких кук, что идеально.
dm_deko
08.07.2022 17:26Где-то столкнулся, что в соглашении о куках рекомендуется описывать их типы:
Статистические
Технические
Маркетинговые
Ещё какие-то..
Насколько это корректно для внутрироссийских сайтов?
Просто это не слишком коррелирует с описанием с английского сайта.
S0krat Автор
10.07.2022 20:10Да, категоризация. Обычно реализуется разрешение/запрещение кук по категориям.
Не очень понимаю, зачем это в принципе для внутрироссийских сайтов.
Lelant0s
09.07.2022 10:41Для компании не из Европы всё было бы просто – на не-европейцев не распространяются ни GDPR, ни ePrivacy Directive.
Повторю то, что писал в одном из комментов к вашей прошлой статье: GDPR/ePrivacy работает по принципу "компания европейская" ИЛИ "серверы обработки данных находятся в ЕС" ИЛИ "пользователь физически находится в ЕС".
Если китаец, находящийся в командировке в Германии, заходит на сайт японской компании, чьи сервера расположены в ЮАР, он подпадает под действие GDPR/ePrivacy.
Другое дело, что принудить такую компанию к выполнению GDPR/ePrivacy пока сложно. Но мы говорим о сути этих законов/директив сейчас, и она именно такова, как я описал выше.
S0krat Автор
10.07.2022 19:58Я не понимаю, что вы пишете. Вы привели цитату из той части статьи, где я пишу о разнице в применимости GDPR и ePrivacy Directive, при этом пишете о них через слэш как если бы разницы никакой не было.
Lelant0s
10.07.2022 20:13Я прокомментировал ваше высказывание, что на компанию не из Европы не распространяются GDPR/ePrivacy. Распространяются при условиях, которые я перечислил.
Пишу GDPR и ePrivacy через слеш, т.к. в контексте написанного мной (их применения для [не]европейских компаний) они "идентичны". Они очень схожи и без моего контекста - ePrivacy это более гранулярный вариант некоторых положений GDPR: если наш случай не подпадает напрямую под GDPR, но подпадает под ePrivacy - делаем как говорит ePrivacy. Это если вкратце. Так что слеш уместен с какой стороны ни глянь. :)
Zibx
Согласия должны логироваться – на что конкретно согласился, когда и кто (идентификатор)Но ведь после этого никакие другие сookies больше и не нужны.
S0krat Автор
Технически, такое возможно реализовать.
Практически, сайты состоят из множества готовых "кубиков", каждый из которых тащит свой набор кук. Тот же куки баннер, обычно, является сторонним скриптом - Cookiebot, Cookie-Script или подобным.