Роман Зыков - Роман с Data Science. Как монетизировать большие данные [litres]

В российском сегменте интернета очень показательная история случилась со «счетчиком» Liveinternet.ru (li.ru). В статье «Почему крупнейшие сайты рунета убирают счетчик Liveinternet?» [96] приводится причина:

«Герман Клименко рассказывает про свой совместный проект с одним из банков. Из рассказа Германа примерно понятно, как работает его Fastscoring: если вы зашли на медицинский сайт, на котором стоит счетчик li.ru, и поискали какое-то лекарство от серьезной болезни или описание самой болезни, то банк, с которым работает Клименко, не выдаст вам кредит – никому не интересен тяжелобольной заемщик».

Меня в свое время это заявление тоже задело за живое – вызвало волну возмущения, и я тогда написал пост на своем сайте. Если задуматься, Герман Клименко выдал эту противоречивую информацию, чтобы пропиарить проект, но ведь есть куча сервисов, которые обладают ровно такой же информацией, просто молчат об этом. Кто гарантирует, что она не используется при определении платежеспособностей заемщика?

Я считаю, что главная причина злоупотребления данными пользователей – это то, что многие сервисы в интернете бесплатные. Практически 100 % контентных проектов и социальных сетей монетизируются за счет показа рекламы. Бесплатного ничего на самом деле нет – сервисам и сайтам необходимо оплачивать серверы, работу сотрудников. Есть, конечно, вариант брать деньги за подписку, как это делает YouTube, – если платишь, то рекламы нет, если не платишь, то есть. Подавляющее большинство пользователей не будут платить. У сервисов с рекламной моделью монетизации (а на рекламе много не заработать) возникает искушение заработать хоть как-то еще на данных пользователей.

Кроме того, утечка данных может произойти при установке на сайт «бесплатных» сервисов, например Google Analytics или Яндекс. Метрика, которые предоставляют аналитические услуги. Но я уверен, что они используют данные клиента не всегда по назначению – ведь должны они на чем-то зарабатывать. Любой бесплатный сервис – это троянский конь, надо об этом помнить. В какой-то момент еще придет мода на «приватные» аналитические сервисы, но они будут стоить приличных денег, и не каждый сайт их сможет себе позволить.

Я уже писал, что в компании Netflix довольно демократично относятся к доступу к данным, кроме платежной информации клиента. А что вообще является персональными данными клиента – имя, адрес и телефон? Да, это явные персональные данные, по ним можно сопоставить реального человека и его виртуальный ID. С другой стороны, чтобы найти реального человека, достаточно его геопозиции – значит, и ее можно отнести к персональным данным. Другой пример – данные конкурса Netflix Prize убрали из публичного доступа после того как авторы статьи «How To Break Anonymity of the Netflix Prize Dataset» [97] доказали: сопоставление информации из этого датасета с публичными базами данных оценок фильмов раскрыло личность и оценки некоторых людей. Что привело к судебному иску от Федеральной торговой комиссии США (FTC – аналог нашего Роспотребнадзора и ФАСа) к Netflix, удалению датасета из публичного поля и отмене второго конкурса. Для нас в Retail Rocket это стало хорошим уроком – при публикации нашего датасета [33] на kaggle.com мы полностью зашифровали все текстовые описания. Конечно, это сильно затруднило работу исследователей с такими данными, но задача конфиденциальности была полностью решена.

Под утечкой данных я понимаю выход каких-либо персональных данных за периметр безопасности внутри компании. Причем сама утечка может произойти и внутри компании, когда доступ к данным получают сотрудники, у которых его быть не должно. Посмотрим, как это получается. При проектировании хранилища данных контакты (телефон и email) и имя клиента часто хранятся в виде обычного текста. Чтобы минимизировать риски, эти данные должны быть зашифрованы, например хэш-функцией. Тогда не будет проблем с утечкой персональных данных из хранилища. Если же технической поддержке потребуется узнать причины проблемы по какому-либо из клиентов с известным email, им потребуется захешировать его, и тогда можно будет работать с хранилищем напрямую, используя этот хеш. Конечно, это очень неудобно – например, при составлении списка клиентов для рассылки придется предусмотреть отдельную операцию восстановления email. Но безопасность того стоит.

В нашу эпоху тотальной цифровизации проблема безопасности данных очень актуальна. Современный взломщик больше не ломает двери и не взрывает сейфы – ему нужно получить несанкционированный доступ и незаметно скопировать нужные данные. Причем необязательно это будут адреса, имена, пароли и явки – это могут быть простые тексты. Например, сообщение или письмо, содержащее информацию о человеке, и даже часть аудиозаписи из голосового помощника. Например, в статье «The Dark Side of Our Voice Assistants» [98] поднимается вопрос, что часть аудио, которое не было распознано автоматически, отправляется людям (сервис наподобие Яндекс. Толока) на расшифровку. Записи им вроде бы передаются в анонимизированном виде, но там можно встретить информацию, которую клиенты точно не хотели бы раскрывать. Обычно голосовые помощники активируются только после определенных слов (wake-word) и лишь после этого начинают транслировать ваш голос через интернет для распознавания. Чтобы проверить это, исследователи сделали проект и написали статью «LeakyPick: IoT Audio Spy Detector» [99]. Проект LickyPick детектировал отправку даже зашифрованных аудиосообщений от голосовых помощников, его авторам удалось обнаружить еще 89 «ошибочно» активирующих слов для колонки Amazon.