Собственно, она могла этого захотеть и до GDPR. Здесь дело в том, как прописан с ней договор, и какая мотивация отказа. Если, например, снимок получился слишком откровенным, а в контракте речи об этом не шло — тогда это очень даже оправдано. Но и в других случаях она может запретить вам публиковать снимки с ней, и имеет шансы добиться этого через суд даже если в контракте вроде бы полностью передала вам все права. Другое дело, что придется возвращаться деньги, а также немотивированные капризы плохо сказываются на репутации.
По мессенджерам и чатам на первый взгляд все просто: все логи также являются собственностью пользователей, которые хранит компания-оператор средства общения. То есть, если кто-то потребует удаления своих данных, то и все логи должны быть удалены. Хотя моменты тоже есть. Например, является ли диалог собственностью двух пользователей, или каждого по отдельности? Если один будет настаивать на удалении лога, а второй захочет его сохранить, должен ли диалог удалиться полностью, или только реплики отдельного участника? Но обычно все же сервисы прописывают в соглашениях с клиентами возможность «отказа от предоставления услуг без объяснения причин», поэтому, наверное, лучше удалить лишнее, чем оставить что-то сомнительное. Впрочем, могу ошибаться, нюансов действительно много.
Речь идет об информации, которая собирается СОЗНАТЕЛЬНО. Приведу примеры.
Ситуация 1. Если на сайте есть форма, где нужно заполнить имя, адрес, телефон, почту — то эти данные подпадают под GDPR без сомнения.
Ситуация 2. Кто-то ведет блог на вашем сайте, где упоминает данные неких третьих лиц. Логично, что и вам, и автору контента хочется, чтобы публикация была доступна всегда и в будущем на нее можно было бы ссылаться, поэтому настраивать автоматическое удаление публикаций (представим на секундочку, что это сделают на Хабре) — не вариант. Также логично, что формат блога не предусматривает обязательное появление в нем чьих-то персональных данных, но не может гарантировать, что там не будет, например, фотографий с третьими лицами или упоминаний их имен-фамилий. То есть, они все же могут там появиться.
В чем же разница между 1 и 2? Дело в том, что закон — о защите персональных данных. В том числе, от использования со злым умыслом. В случае 1 хакеры могут попытаться взломать базу, и они при этом уверены, что там хранится информация пользователей и они смогут ее использовать каким-то образом. В случае 2 информация и так доступна публично. Тем не менее, в случае 2 упомянутые в блоге лица также вправе требовать удаления данных с упоминаниями о себе, что вы, вероятно, должны сделать и без GDPR. Но вы не обязаны это делать автоматически, так как вы не могли предусмотреть их появления в этом месте.
Да, ждать СМСки которая придет либо вам, либо тому, кому вы поручили приглядывать за сайтом, что исключает аргументы «я забыл». Также, при отсутствии СМС, можно быть уверенным что все работает и не беспокоиться зря. А еще вы во многих случаях сразу знаете причину проблемы, что значительно ускоряет поиски причастных и собственно ее устранение.
Мы ведем на Хабре блог, в котором детально описываем все наши функции и другие интересные вещи. И даже есть отдельная рубрика «обзоры», начиная с этой статьи. Там все описано подробно, но это очень много текста. Эта же публикация ставила перед собой цель собрать все вместе и кратко описать возможности к началу периода отпусков.
Оригинальная база сама по себе обновляется не мгновенно. Мы гарантируем оповещение в течении 6-8 часов. Гарантировать быстрее, по техническим причинам, на данный момент невозможно. К слову, к провайдерам информация идет дольше, поэтому некоторое время на реакцию есть.
Согласен, что пример получился не самый удачный. Сейчас берется только первый адрес из DNS записей. Но я пообщался с разработчиками, сегодня к вечеру обещали проверять все.
Вот другой пример — сайт doc.qt.io. Его IP адрес находится в заблокированном диапазоне, хотя домен формально — нет. Указанный вами сайт его тоже не находит, а ХТ это ловит.
Нашим же сервисом. Мы выгружаем базу (конечно же, с адреса, отличного от адреса нашего сайта) и мониторим. Наш сервис распределен, и позволяет проверять сам себя.
Собственно, на данный момент в опросе из вот этой публикации более 43% читателей выбрали вариант «хорошо уже не будет». Поэтому это скорее популярное мнение сообщества, а не пропаганда.
Работает. Наш сервис представлен во многих странах, поэтому убирать смысла нет. Было бы неуместно упоминать об этом в данной публикации, разве что юморнуть (сверху уже целая ветка комментариев по поводу юмора). Потому что если работать перестанет, Вы об этом и не узнаете — оповещение не придёт.
Это пожелание? Спасибо, подумаем. Раньше у нас была интеграция с Телеграмом как контактом для получения оповещений. Также через него можно запускать мгновенные проверки, см. описание функции.
Ситуация 1. Если на сайте есть форма, где нужно заполнить имя, адрес, телефон, почту — то эти данные подпадают под GDPR без сомнения.
Ситуация 2. Кто-то ведет блог на вашем сайте, где упоминает данные неких третьих лиц. Логично, что и вам, и автору контента хочется, чтобы публикация была доступна всегда и в будущем на нее можно было бы ссылаться, поэтому настраивать автоматическое удаление публикаций (представим на секундочку, что это сделают на Хабре) — не вариант. Также логично, что формат блога не предусматривает обязательное появление в нем чьих-то персональных данных, но не может гарантировать, что там не будет, например, фотографий с третьими лицами или упоминаний их имен-фамилий. То есть, они все же могут там появиться.
В чем же разница между 1 и 2? Дело в том, что закон — о защите персональных данных. В том числе, от использования со злым умыслом. В случае 1 хакеры могут попытаться взломать базу, и они при этом уверены, что там хранится информация пользователей и они смогут ее использовать каким-то образом. В случае 2 информация и так доступна публично. Тем не менее, в случае 2 упомянутые в блоге лица также вправе требовать удаления данных с упоминаниями о себе, что вы, вероятно, должны сделать и без GDPR. Но вы не обязаны это делать автоматически, так как вы не могли предусмотреть их появления в этом месте.