«Киберлайфхак»: бесплатная еда с помощью GDPR Статьи редакции
Как уязвимость в законодательстве, промокоды и плохо спроектированные базы данных могут позволить не платить за еду в Европе.
13 декабря технологический блогер Vas3k (Василий Зубарев) поделился в своём Telegram-канале размышлениями о том, как можно неоднократно использовать любые промоакции и скидки с помощью GDPR и ошибок в базах данных в компаниях.
Для этого достаточно после первого заказа сделать запрос на удаление пользовательских данных из базы сервиса по заказу еды — отказаться компания не имеет права, иначе будет выплачивать крупный штраф. Но это работает только там, где ИТ-специалисты не хранят адреса отдельно от других персональных данных пользователей.
Миша @tauspace вчера в баре рассказал топовый киберлайфхак. Для него нужны две вещи — скидосики и GDPR. Сразу поясню: скидосики в Германии — часть культуры. Нет скидосика, пробного периода, подарка — немец никогда не купит, наверное это для туристов. Скидосики есть на всё.
Что общего у тридцатицентового пива, SIM-карты и скоростного поезда в Амстердам? Всё это можно купить за полцены, если хорошо поискать. Больше ищешь — больше скидосик, вплоть до бесплатного. Хочешь прямо сейчас — наверное, ты занятой бизнесмен, плати полную цену. Социализм. Приезжие студенты занимаются этим как спортом. Теперь сам лайфхак.
В Берлине есть сервисы доставки продуктов по подписке. Раз в неделю тебе к двери приносят ящик со всякими макарошками, брокколи и рецептами внутри. Кстати, неплохими. Новых пользователей завлекают акциями типа «первая коробка в подарок». Больше одного раза зарегаться не прокатит — адрес квартиры остаётся в базе.
А теперь вспоминаем GDPR. Заказываем первую бесплатную коробку, шлём запрос на удаление данных из БД, заказываем снова. SCHМЕКАЛÖЧКА. Не прислали бесплатной еды — прямо нарушили GDPR, будьте добры занести пару миллионов евро штрафа регулятору. Прислали — поздравляю, вы великолепны!
На самом деле Зубарев признает, что это в большей степени шутка — у компаний есть технические решения, чтобы избежать «безлимитных заказов», но их нужно учитывать во время проектирования ИТ-системы.
Так. Похоже не все уловили, что предыдущий пост — выдуманная шутка из бара и никто не собирался проверять это всерьез. Технические решения тоже есть — надо хранить адреса в другой таблице и при GDPR-запросе рвать связь с пользователем (в чате даже прозвучало забытое слово «биекция»). Но я удивлён насколько мало айтишников всё еще не думает об этом, проектируя свои системы. GDPR-то всех касается, даже если вы не в Европе.
Мда, вот так глупая пьяная шутка попадает на VC. Чо началось-то!
Охренеть, Вася — мой новый вилсаком!
Это не лайфхак, а рассуждения на тему.
Сразу было понятно, что GDPR это заплыв против течения, попытка остановить прогресс... очередные социалистические уступки...
Это ещё начало. Дальше веселее будет.
Сгниёт ЕС?
Понятия не имею по поводу ЕС. GDPR не будет работать как хотят. Эта надстройка какая-то мертворожденная. Уже высказывал свое мнение, если интересно, поищите по комментам.
Комментарий недоступен
Даже если нельзя. Как доказать, что это хеши адресов? Если подсолить - никак вообще, кроме просмотра исходников. Не думаю что до этого дойдет.
Комментарий недоступен
черт возьми. руки чешутся это проверить
А что, по GDPR нельзя адрес сохранить без привязки к пользователю? Как "адрес, участвовавший в акции".
Ой. И без этой фигни с горе-маркетологами можно почти почти бесплатно юзать букинг в некоторых случаях, но геморроя конечно слишком много.
А как у нас пару лет все школьники почти бесплатно ездили на такси еще хорошо вспомнить. Думаю тогда агрегаторы хорошо подняли отчетность по количеству пользователей и поездок.
Вообще, эта шутка напоминает мне те мысли, что мне в голову после переезда приходили. Например:
1. Карты и финансовые документы в Германии спокойно отправляют по почте. Можно спокойно изъять из почтового ящика письмо, даже не обладая ключами, лишь бы рука была поменьше да со стороны створки пролезала.
2. Есть SEPA - что-то вроде разрешения списывать деньги с твоего счета напрямую. Ничто не мешает "подделать" эту SEPA, вставив данные карты и/или счета другого человека.
Короче, многие вещи с точки зрения безопасности выглядят дико. Ну, мол, как так, как народ так беспечно к этому относится
Комментарий недоступен
Можно сохранять адрес без привязки к пользователю.
В Германии с этим чуть сложнее. Здесь нет номеров квартир — пишется номер дома и фамилия. Фамилия — персональное данное. Вот и выкручивайся. Но вариантов обойти всё равно целая гора, просто я впервые задумался о таком сценарии.
Хеш от такого адреса сохранять и все тут.
Привязки никакой нет, т.к. обратно его не преобразуешь, а проверить была ли доставка можно очень просто.
... если не добавить пробел между "ул" и названием улицы
нормализованную строку адреса хешировать конечно-же
До этого они дойдут не сразу) Потом можно немного ошибочно писать названия улиц - человек будет распознавать и доставлять, а хеш будет другой. Хотя можно ввести проверку и исправление адреса до этапа доставки. Но как правильно написали выше - как суду и юристам доказать, что у тебя хранятся ХЕШИ, а не сам адрес? :)
Комментарий недоступен
Льва Толстого 16 или Ленинградский проспект 39c79, например.
Улица Пушкина, дом Колотушкина
А что если другой человек купил дом по этому адресу? Получается пользователь то другой? Или я неправильно понял суть алгоритма защиты?
Комментарий удален модератором
Комментарий удален модератором