GDPR, для тех кто в танке. Пара вопросов знатокам

У меня есть пара вопросов к тем, кто подгонял приложения под эти требования. Я оч прошу, не писать в комментах что gdpr это маразм и перекладывание ответственности, просто блочь граждан ес, грабли суда тебя не достанут, etc. Цель довольно таки простая — прикрыть своё и чужое мягкое место от проблем, при этом если есть возможность — не отображать плашку с «вы согласны принимать куки и юзать localStorage?».

1. Считается ли auth token личными данными пользователя? Формально это не личные данные, но т.к. по токену можно идентифицировать пользователя, то он подпадает под «личные» из ec.europa.eu/...​orm/what-personal-data_en «Different pieces of information, which collected together can lead to the identification of a particular person, also constitute personal data»

2. Если использовать анонимизацию в гугле аналитике, developers.google.com/...​js/ip-anonymization?hl=ru то можно ли не просить посетителя использовать куки? Если кто-то использовал уже анонимизацию, ухудшилась ли выдача отчетов в аналитике?

3. В русскоязычном сегменте ходит интересное трактование Right to restriction of processing, согласно которому «Если пользователь включил этот режим, то персональная информация не должна быть больше доступна ни в публичном доступе, ни другим пользователям и даже администраторам системы. Как позиционирует GDPR, для пользователя это альтернатива полного удаления из системы.», что выполнимо для админа быть не может. По www.itgovernance.eu/...​ht-to-restrict-processing отписано «Upon request, an organisation must stop using an individual’s personal data, although it can continue storing it.», что более правильно, на мой взгляд, трактует «Right to restriction of processing»

4. Как вы поступаете со сторонними скриптами, которые заталкивают в приложения ваши пользователи? Напр., гугле аналитика, jivosite и т.п. По идее, посетителей нужно предупреждать о этих сторонних куках по cookie law и расписывать их, но предусмотреть каждый чих админа то тоже нельзя%)

5. Есть ли какие-то подводные камни, когда компания ЗАО «рога и копыта» выступает SaaS вендором для покупателей? ЗАО «рога и копыта» собирает и хранит данные, но не использует их. Их использует покупатель. Получается, если посетитель хочет получить/удалить/анонимизировать свои данные, то «рога и копыта» предоставляет механизмы и уведомляет покупателя, но сами «рога и копыта» ничего не удаляют/отправляют/анонимизируют, так? Также вендор должен во всех privacy & co расписать и свою роль?

а вообще, меня поражает, что на www.thetimes.co.uk www.welt.de и www.bundesregierung.de либо никаких плашек нет либо они информационного (а не вопросительного) характера%)
так что либо на этот gdpr организованно забили, либо я что-то не понимаю, и есть куча лазеек как не кошмарить пользователя всплывающими плашками.

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Я тут мимокрокодил.
Этот идиотизм со всплывающим окном про куки — такая же дуристика, как писать «Без ГМО» на каждой единице жратвы

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

Если Ваши вопросы касательно cookies еще актуальны, будем рады ответить на них здесь: dou.ua/forums/topic/27638

Может кому пригодится, есть хороший онлайн конструктор, который поможет сгенерировать политику конфиденциальности в соответствии с требованиями GDPR для своего сайта , блога или мобильного приложения profiset.org/gdpr

Зайдите с европейского айпишника на какой-то европейский сайт и сами посмотрите как там все с плашками и куками. Подсказка — пока на куки не согласишься кина не будет.

я в конце 1 сообщения привел как пример сайты times, welt и немецкого бундестага. можете сами посмотреть как там, и какое кино работает. подсказка: на сайте бундестага вообще никаких плашек не выводится, хотя если покопаться в их стораджах и кукисах, то там ооочень явные такие куки по которым отслеживается сессия.

Ну вот, напрмер, скриншот таймса screenshot.net/kq75wa3. Там внизу скромная табличка про прайваси полиси. И большинство сайтов на территории ЕС показывают что-то подобное, степень блокировки взаимодействия с сайтом разнится от скромной надписи внизу до полного игнора пользовательского ввода пока не согласишься.

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

Вы на указанные вами сайты с европейского IP заходили?

я через vpn, знакомый в чехии тоже смотрел

Local storage — хранилище на стороне пользователя. Пока данные остаются там — разрешений не надо. Как только эти данные перекочуют на сторону сайта/сервиса — разрешение надо.

Привет, я занимался GDPR с технической стороны.
На самом деле много тонкостей, в каждом домене свои решения — adtech, telco, fintech, ecommerce — все по разному решили проблему. По поводу юриста +1
Если коротко, то вот с чем я сталкивался:

1. Считается ли auth token личными данными пользователя?

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

3. В русскоязычном сегменте ходит интересное трактование Right to restriction of processing

Это относится к user consent, но у нас было другое. Собственно user consent это и есть плашка, которую надо показать один раз

Как позиционирует GDPR, для пользователя это альтернатива полного удаления из системы.

есть еще right to be forgotten и на самом деле надо удалять старые данные, в том числе старые бекапы. Есть исключения, например когда банк по закону обязан хранить данные 10 лет.

4. Как вы поступаете со сторонними скриптами

Content Security Policy и securityheaders.com

5. Есть ли какие-то подводные камни, когда компания ЗАО «рога и копыта» выступает SaaS вендором для покупателей?

Между компаниями подписывается Data Processing Agreement (DPA)

а вообще, меня поражает, что

Плашки с куки это на самом деле другой закон — The Cookie Law
просто все стало строже, например Apple автоматом удаляет куки через месяц или типа того.
Из-за этого пострадали некоторые компании типа criteo

есть еще right to be forgotten и на самом деле надо удалять старые данные, в том числе старые бекапы. Есть исключения, например когда банк по закону обязан хранить данные 10 лет.

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

Плашки с куки это на самом деле другой закон — The Cookie Law

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

спасибо громадное за ответы!

Я в компании в Лондоне занималась реализацией третьего пункта. Мы обязаны явно спросить пользователя, можем ли мы обрабатывать его данные с маркетинговой целью. Например, определить сегмент пользователя( VIP или обычный, как пример), чтобы рассылать релевантные предложения в имейлах. Если пользователь всегда просматривает страницы про лошадей, то смысл ему читать рекламу про кошек? Чтобы это понять, нужно обработать активность пользователя. Разрешение на это и надо спросить.

аэм. третий пункт же про анонимизацию данных по требованию посетителя. или вы про другой пункт?

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

1. Считается ли auth token личными данными пользователя?

Как я где-то читал про куки, их делят на такие, без которых сайт не сможет работать и остальные. Про первые вроде можно просто предупреждать в полисях и они не отключаются. Вторые должны быть расписаны зачем нужны и в идеале по отдельности отключаемые.

2. Если использовать анонимизацию в гугле аналитике, developers.google.com/...​js/ip-anonymization?hl=ru то можно ли не просить посетителя использовать куки? Если кто-то использовал уже анонимизацию, ухудшилась ли выдача отчетов в аналитике?

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

3. В русскоязычном сегменте ходит интересное трактование

В русскоязычном сегменте очень много интересных толкований. Некоторые из них основаны вообще хз на чем, я бы русскоязычным источникам не верил.

4. Как вы поступаете со сторонними скриптами, которые заталкивают в приложения ваши пользователи? Напр., гугле аналитика, jivosite и т.п. По идее, посетителей нужно предупреждать о этих сторонних куках по cookie law и расписывать их, но предусмотреть каждый чих админа то тоже нельзя%)

Тот же кукибот говорит что нужно не только предупреждать, но и не включать пока пользователь не согласится. Технически это возможно, но реализация зависит от того на чем сайт написан (фреймворк/не фреймворк, с админкой или статика и т.д).

5. Есть ли какие-то подводные камни, когда компания ЗАО «рога и копыта» выступает SaaS вендором для покупателей? ЗАО «рога и копыта» собирает и хранит данные, но не использует их. Их использует покупатель. Получается, если посетитель хочет получить/удалить/анонимизировать свои данные, то «рога и копыта» предоставляет механизмы и уведомляет покупателя, но сами «рога и копыта» ничего не удаляют/отправляют/анонимизируют, так? Также вендор должен во всех privacy & co расписать и свою роль?

Там есть 2 понятия: data controller и data procesor. В данном случае рога и копыта является процессором. Они должны предпринять меры чтобы дать контроллеру возможность управлять данными. Правда по закону штрафы если что контроллеру, с процессора вроде вообще спроса нет. То есть, если на вашем сайте пользователь ввел данные — вы отвечаете за что, что случилось потом, если вы их передали процессору, а он их потерял/продал/использовал ещё как-то незаконно.

а вообще, меня поражает, что на www.thetimes.co.uk www.welt.de и www.bundesregierung.de либо никаких плашек нет либо они информационного (а не вопросительного) характера%)

Я сейчас перестал следить за этой темой, но за пару недель до даты х писали что готово к закону только 20% сайтов. Так что если кто-то не показывает никаких плашек, это не значит что стоит их копировать, может они просто забили или еще не успели привести сайт в порядок.

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

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

>> Как я где-то читал про куки, их делят на такие, без которых сайт не сможет работать и остальные. Про первые вроде можно просто предупреждать в полисях и они не отключаются. Вторые должны быть расписаны зачем нужны и в идеале по отдельности отключаемые.
теперь они делятся на другие 2 вида — на те, по которым можно идентифицировать пользователя и остальные. при этом описывать что они делают обязательно первые, а вторые (как я понял) необязательно. спрашивать разрешение на использование нужно именно 1 тип. при этом различия меж localStorage и куками cookie law не делает. также забавно что многие пользователи неделями не закрывают браузер, и sessionStorage тоже должен был быть покрыт этими гдпр. но этого не сделали.

>> То есть, если на вашем сайте пользователь ввел данные — вы отвечаете за что, что случилось потом, если вы их передали процессору, а он их потерял/продал/использовал ещё как-то незаконно.
мне кажется, процессор не отвечает за то, как контроллер использовал данные. иначе по этому гдпр гуглеаналитику уже б по миру пустили. по www.gdpreu.org/...​ntrollers-and-processors получается что за обработку данных отвечает контроллер. при этом процессор обязан обрабатывать данные только так, как ему сказал контроллер.
ну и по логике в любом случае, процессор не может контролировать что случилось с данными после того, как их получил контроллер.

сейчас пишут запрос в оф органы в чехии чтоб разъяснили

Я на 99% уверен что не разъяснят. Потому что толкует закон суд, а не органы. И суд рассматривает конкретное дело, а не в общем.

можно. но хотелось бы без плашек.

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

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

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

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

Ну извините, вы пришли в сообщество с проблемой и спросили совета. Вам все сказали своё мнение. Нет такого решения, какое вы хотите найти, сколько бы мы не вчитывались в тему. Хотите — рискуйте и делайте без плашки. В конце-концов, если ответственность не прописана в договоре, то платить штрафы не вам.

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

Вот бы еще эти блдские попапы на весь экран с жалобными просьбами подписаться и полайкать сайт на ФБ убирали.

Во-во, это раздражает куда больше, на некоторых сайтах ещё и настройки не запоминает и показывает при каждом визите. Заходишь одну новость прочесть, а тебе лезут с этими лайками на весь экран.

и тут вдруг, посреди всей вот этой красоты тусуется плашка-гдпр.

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

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

Гуглу не уродство, Фейсбуку не уродство, а вам уродство. Почему?

Я допускаю, что может быть уродство, но что же тогда у вас за сайт уникальный такой?

Глянул на цифру и такой, «ой, да, 2020! это ж далекое будущее после ядерной зимы и 3-го восстания машин», потом пауза и...всего полтора года до 2020 года. Время летит ппц ((

но следить за развитием темы надо

ты ща про восстание машин или про ядерную зиму? :-))))

у нас сейчас есть gdpr, который гораздо строже чем то что есть в америке. при этом gdpr является общим на всем ес. на мой взгляд, сейчас лучше чем раньше. теперь хоть не нужно по каждой стране изучать (хоть в этих доках слишком много размытостей) и достаточно реализовать только требования gdpr.
и я очень просил конструктива=) я и сам готов на каждом углу кричать, что приватность пользователей — это их проблема, но от этого требования по закону не исчезнут.

Китай внутренний пишет (или написал, не помню), говорят вдохновились гдпр. Позиция власти там — что с данными можно делать партии, нельзя бизнесу.

просто блочь граждан ес

и калифорнии

Підписатись на коментарі