Комментарии 32
Согласия должны логироваться – на что конкретно согласился, когда и кто (идентификатор)
Но ведь после этого никакие другие сookies больше и не нужны.
Куки лишь один из множества способов идентификации, есть смысл заменить это слово в статье. На Consent есть отдельный документ регулятора, уже вторая версия.
Вы правы, речь идёт не только о cookies непосредственно, но и всех подобных решениях - ePrivacy Directive определяет их через "использование способностей пользовательского терминала к сохранению или доступ к информации сохраненной на пользовательском терминале", но даже в тексте закона обычно называет просто cookies.
Consent - отдельная большая тема, её просто невозможно впихнуть довеском в эту статью.
Ничего, впихнем. :) Регулятор постарался, вместе с канцеляритом дает примеры.
Версия 2018 года https://habr.com/ru/post/494364/
Версия 2020 года, на Хабре не дублировал, отличается разъяснением о "стене куки" https://medium.com/noleaks-eu/согласие-на-обработку-персональных-данных-2020-ce513eef6073
Уважаю ваш труд, но входящему в тему GDPR необходимо уметь читать как минимум английский, а лучше немецкий.
Не понял критику. Так можно и Вашу статью дезавуировать, и половину контента Хабра вместе с авторами.
Почему критика-то? :) На Хабре у вашей публикации куча прочтений, плюсиков и закладок - очевидно, кому-то она была полезна.
Я просто заметил, что если людям нужен перевод - у них большие проблемы... Мне кое-что по теме приходится читать в гуглопереводе с немецкого - это очень тяжело. :( А даже на английском этих материалов нет и всё.
Входящему в тему GDPR достаточно английского, т.к. во-первых сам GDPR публикуется в первую очередь на английском, во-вторых, второй важный документ (DPA - аналог GDPR для Великобритании) - также на английском. Роль UK в IT бизнесе Евразии в разы больше, чем Германии, важные пояснения регулятора (ICO) к DPA - также, разумеется, на английском.
Аналог GDPR для Великобритании называется UK GDPR, поскольку является форком исходного GDPR после выхода UK из EU.
DPA - это совсем другое.
Английского, в общем, достаточно, но допольнительный немецкий был бы очень полезен, поскольку именно немцы дают очень интересные судебные случаи.
GDPR-UK это, условно говоря, "ламерское" (не имею в виду вас - его повсеместно так называют те, кто не в теме деталей) название DPA. В Великобритании основным документом является DPA, выступающий реинкарнацией GDPR в рамках Великобритании: https://www.gov.uk/data-protection
UK GDPR - это то название, которое использует британский регулятор. Весь смысл принятия Data Protection Act 2018 - зафиксировать отмену Data Protection Act 1998 в пользу GDPR, поскольку GDPR в рамках ЕС является законом прямого действия (в отличие от ePrivacy Directive, например). После выхода Британии из ЕС, конечно, его модифицировали, чтобы сохранить GDPR под именем UK GDPR уже.
Я не думаю, что тут имеет смысл долгая дискуссия, приведу лишь цитату с сайта упоминаемого вами британского регулятора (ICO): https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/
...the UK General Data Protection Regulation (UK GDPR), tailored by the Data Protection Act 2018
Ключевое слово "tailored". Таким образом, то, что называется GDPR-UK зиждется на DPA 2018, и, соответственно, DPA является первичным и основным документом.
Я считаю правильным мыслить именно в парадигме законов а не "названий", потому что когда вас потащат в суд, то вопросы задавать будут конкретные - в разрезе "как вы обеспечили информирование пользователя о сторонах, которым вы передавали его данные", и ссылаться при этом будут на DPA.
В любом случае, желаю удачи - тема непростая, но интересная.
сделали несколько крупных штрафов для гигантов, юристы потом в частном порядке тоже попытались заработать и всё сдулось. У коньяка в вашем примере будет 100 лет выдержки, пока кто-то возьмется за его куки
Штрафуют и не гигантов тоже - прессе не интересно рассказывать о штрафах в несколько десятков тысяч евро на какие-то никому не известные локальные конторы, поэтому эти случаи не на слуху.
Я общался с этим австрийским адвокатом. Нарушения монетизировать не выходит, суды закончились ничем. Это корова национальных регуляторов.
Куки-баннеры это одно из худших нововведений Интернетов: я не хочу ничего там кликать, у меня автоудаление всех кук, я лучше прочитаю статью через уменьшенный в 10 раз вьюпорт (куки-баннеры, как правило, перекрывают контент) но моего царского клика они не получат. Я считаю очень неправильным прийти по ссылке, но тратить внимание на что-либо кроме контента, а удалять все куки после сеанса меня ещё в универе научили так что в следующее посещение баннер для меня будет всё там же хоть что бы я не кликал.
I know that feel bro...
Кстати, соответствующий законодательству куки баннер в этом плане наименьшее зло - кнопка "принять только необходимые cookies" (или "отвергнуть все") в нём присутствует в обязательном порядке.
Хуже, когда куки баннер не соответствует требованиям - там отказ от лишнего может быть спрятан очень глубоко.
Все очень просто. Инициативы типа DoNotTrack или P3P рубятся рекламной индустрией на стадии их входа в W3.org для попытки стать стандартом на уровне индустрии. Оба проекта сейчас полудохлые именно по этой причине.
А как правильно это реализовать технически? Например, на сайте есть Корзина (эту сессию, наверное можно включать по-умолчанию - или нет?), счётчик Яндекса и счётчик Гугла.
Я показываю плашку о согласии на куки, где есть 2 чек-бокса: Яндекс - [да\нет], Google - [да\нет]. Пользователь согласился на куки от Яндекса. И сайт должен включить код для него, а для гугла не включать?
Как правильно это делать? Ведь код счётчика уже зашит в шаблон. Запоминать выбор пользователя и через js вызывать? Есть какой-нить толковый пример по теме? Спасибо!
Технически всё зависит от вашего технологического стека и выбранного куки баннера, а дальше просто гуглите, например, "как интегрировать cookiebot и wordpress" и получаете рецепты.
> Корзина (эту сессию, наверное можно включать по-умолчанию - или нет?)
Для интернет-магазина можно считать необходимой - человек пришел в магазин, тем самым он изъявил намерение что-то купить, для чего технически нужна эта сессия. Чтобы решение было бесспорным, лучше не ставить вообще никаких кук до выбора "принять только необходимые" или "принять все" - тогда случайный посетитель может просто уйти и не получить никаких кук, что идеально.
Где-то столкнулся, что в соглашении о куках рекомендуется описывать их типы:
Статистические
Технические
Маркетинговые
Ещё какие-то..
Насколько это корректно для внутрироссийских сайтов?
Просто это не слишком коррелирует с описанием с английского сайта.
Для компании не из Европы всё было бы просто – на не-европейцев не распространяются ни GDPR, ни ePrivacy Directive.
Повторю то, что писал в одном из комментов к вашей прошлой статье: GDPR/ePrivacy работает по принципу "компания европейская" ИЛИ "серверы обработки данных находятся в ЕС" ИЛИ "пользователь физически находится в ЕС".
Если китаец, находящийся в командировке в Германии, заходит на сайт японской компании, чьи сервера расположены в ЮАР, он подпадает под действие GDPR/ePrivacy.
Другое дело, что принудить такую компанию к выполнению GDPR/ePrivacy пока сложно. Но мы говорим о сути этих законов/директив сейчас, и она именно такова, как я описал выше.
Я не понимаю, что вы пишете. Вы привели цитату из той части статьи, где я пишу о разнице в применимости GDPR и ePrivacy Directive, при этом пишете о них через слэш как если бы разницы никакой не было.
Я прокомментировал ваше высказывание, что на компанию не из Европы не распространяются GDPR/ePrivacy. Распространяются при условиях, которые я перечислил.
Пишу GDPR и ePrivacy через слеш, т.к. в контексте написанного мной (их применения для [не]европейских компаний) они "идентичны". Они очень схожи и без моего контекста - ePrivacy это более гранулярный вариант некоторых положений GDPR: если наш случай не подпадает напрямую под GDPR, но подпадает под ePrivacy - делаем как говорит ePrivacy. Это если вкратце. Так что слеш уместен с какой стороны ни глянь. :)
Вы спорите с тезисом, которого в моём тексте нет и не может быть, поскольку я писал прямо противоположное ещё в первой статье.
Они не могут быть идентичны ни в каком контесте, поскольку это вообще разного класса сущности. Строго говоря, ePrivacy Directive вообще не имеет прямого действия - она лишь обязывает государства ЕС привести свои национальные законодательства в соответствие с установленными директивой положениями. И с экстерриториальным действием, соответственно, у неё принципиальные сложности.
ePrivacy имеет пока что рекомендательный хар-р - в этом отличие от GDPR, поэтому его (ePrivacy) реализация в каждой стране "гуляет" из стороны в сторону, но сущностно - это уточнение пунктов GDPR (упрощенно говоря). И таковым (сущностно) и останется, когда перейдет в статус закона (если его просто не сольют воедино с GDPR, что было бы на мой взгляд правильнее).
ePrivacy Directive имеет обязательный характер - нюанс в том, для кого/чего обязательныый.
ePrivacy Directive никак не может нести "уточнение пунктов GDPR" - она была принята задолго до появления GDPR даже в черновике. После появления GDPR дорабатывали для совместимости с ним как раз саму ePrivacy Directive.
ePrivacy Directive никогда не "перейдет в статус закона" - она будет заменена ePrivacy Regulation, о чём я упомянул этой в статье.
Regulation - это и есть закон, обязательный к исполнению, в отличии от директивы, имеющей рекомендательный характер.
Я уже понял, что вы не из тех, кто признает ошибки, поэтому просто констатирую факт, что вы не юрист и выражу надежду на то, что не вы ответственный за имплементацию требований GDPR в вашей компании. В противном случае, она явно in trouble.
Английский тоже рекомендую подтянуть - вы и в нем ошибки делаете, что мешает вам разобраться в вопросе, как это в свое время сделал я.
Всё о cookies в свете GDPR и не только