Приложениям необязательно тайком включать микрофон, чтобы анализировать сведения о ваших привычках, а затем использовать в своих целях. Достаточно анализировать действия, технические сведения об устройстве и данные, к которым пользователь сам предоставил доступ.
Хорошо, когда собранные сведения задействуются только для рекомендаций. Плохо, когда разработчик решает подзаработать и перепродать персональную информацию рекламной сети.
Разбираемся, как эти данные превращаются в пользовательский профиль и что можно ограничить в настройках Android и iOS.
Что приложения знают о вас
То, что вы сообщаете сами. Самый очевидный источник — информация, которую пользователь добровольно оставляет сервису. Имя, номер телефона, электронная почта, дата рождения, адрес доставки, поисковые запросы, покупки, переписка, добавленные в избранное товары и любые заполненные формы уже находятся внутри приложения или на его сервере.
Действия и технические сведения. Практически любое действие можно превратить в аналитическое событие: запуск программы, открытие определённого экрана, нажатие кнопки, добавление товара в корзину, просмотр видео, оформление подписки или ошибка при оплате.
Для этого в код встраиваются аналитические системы — например, в Android-экосистеме популярен пакет Google Analytics for Firebase. Он записывает запуски, продолжительность сеансов, модель устройства, ОС и некоторые действия внутри приложения. Этого достаточно, чтобы отличать повторные посещения и анализировать поведение, даже если пользователь не зарегистрирован.
Телеметрия не обязательно связана с рекламой. Технические сведения могут пригодиться, чтобы понять, какими функциями пользуются чаще, где пользователи бросают оформление покупки или почему новая версия приложения работает хуже старой.
Данные с датчиков и из памяти устройства. Эту категорию приложения получают через систему разрешений. Такая есть и в iOS, и в Android. Когда программе нужна геолокация устройства, она отправляет операционной системе команду — и пользователь видит запрос на доступ.
Категорий разрешений — множество. Приложение может запрашивать доступ к камере, микрофону, физической активности, сканированию локальной сети, файлам в накопителе и так далее.
В Android система разрешений включает и доступы, которые не требуют обязательной санкции со стороны пользователя. Например, чтобы программа могла выходить в интернет, разработчику достаточно прописать соответствующее разрешение в коде.
Иногда у приложений есть альтернативный способ узнать нужные данные даже в случае отказа пользователя. Например, определить приблизительное местоположение можно через IP-адрес.
Как собираются данные
Система разрешений. Здесь всё просто. В операционной системе есть API-интерфейс, который управляет доступом к защищённым данным. Приложение запрашивает разрешение через системный диалог. Отказ пользователя ограничивает доступ, и обойти его без взлома платформы нельзя.
Разрешения разделены по ресурсам и объёму доступа. Доступ к камере позволяет снимать, но не открывает автоматически всю фотобиблиотеку. В последние годы iOS и Android всё сильнее разделяют разрешения. Например, вместо точной геолокации в Android 12 и новее можно выбрать приблизительную — система сама вычислит точку на карте, которая поможет понять, в какой части города вы находитесь, но не раскроет лишнего.
Как правило, системные разрешения действительно нужны для конкретных функций приложения. Но ничто не гарантирует, что доступ используется правомерно. Приложение может запрашивать больше данных, чем необходимо, обращаться к ним чаще, чем следует, или использовать полученную информацию для дополнительных целей — например, аналитики, персонализации или рекламы.
Самостоятельно или через SDK. Сегодня разработчики редко сами пишут системы сбора аналитики и трекинга. Проще подключить SDK — готовые программные компоненты.
Например, разработчик добавляет Firebase Analytics и получает систему продуктовой аналитики. Подключает Crashlytics — получает отчёты о сбоях. Система вроде Adjust помогает понять, из какой рекламной кампании пришёл пользователь и совершил ли нужное действие после установки. Все эти данные могут уходить не только владельцу приложения, но и на сервер соответствующего поставщика.
Насколько подробным может быть такой пакет данных, демонстрирует эксперимент разработчика Тимофея Хирьянова. Протестированная им мобильная игра сразу после запуска отправила в рекламную сеть Unity Ads версию ОС и модель смартфона, уровень заряда батареи, яркость и громкость экрана, объём свободной памяти, оператора связи, тип интернет-соединения, IP-адрес, текущую геолокацию и даже маркер согласия на рекламную слежку, хотя автор эксперимента ничего подобного не разрешал.
Как события объединяются в профиль. Чтобы связать два события, нужен общий признак. Например, рекламный идентификатор: в Android с сервисами Google Play используется Google Advertising ID (AAID), на iPhone — Identifier for Advertising (IDFA). Идентификатор не раскрывает личность пользователя, но позволяет объединить разные сессии, приложения и рекламные показы в один и тот же профиль.
Например, SDK видит, что пользователь с конкретным идентификатором полистал каталог кроссовок в интернет-магазине. Через час он снова проявился в игре — там ему и покажут рекламу тех самых кед.
Но вообще идентификатором может служить любой стабильный кусок данных вроде адреса электронной почты. Его даже можно хешировать для анонимизации, но затем использовать для сопоставления с данными из других баз. Многие популярные SDK для аналитики и рекламы также назначают пользователям собственные идентификаторы.
И даже если создать общий ID не получается, есть другой способ — фингерпринтинг. Версия ОС, модель устройства, часовой пояс, заряд батареи и ещё несколько десятков характеристик объединяются вместе. По отдельности ни один параметр не уникален, но их сочетание может оказаться достаточно редким, чтобы отличать одного пользователя от другого. Это не такой точный способ профилирования, как рекламный идентификатор, но вполне рабочий.
Куда уходят данные
Что плохого в том, что приложение собирает информацию? Ведь навигатору действительно нужна текущая геолокация, интернет-магазину — адрес доставки, а их разработчикам — сведения об ошибках.
Главный риск в том, как эти данные будут использоваться дальше. Их объединяют с другой информацией, передают партнёрам или продают брокерам данных.
Сначала — владельцу приложения. В идеальном сценарии сведения о пользователе остаются внутри компании-разработчика. Так работает большая часть продуктовой аналитики и персонализации: история прослушиваний в плеере нужна для рекомендаций, а карта активности в интерфейсе — для улучшения пользовательского опыта.
Но чем больше разрозненных событий связываются с одним аккаунтом, тем подробнее становится профиль. В итоге компания может определить привычки, интересы, типичные места пребывания и многое другое, выведенное из паттернов поведения.
Потом — аналитическим и рекламным платформам. Приложение может использовать сторонние SDK или передавать события партнёрам со своего сервера. Необязательно весь профиль целиком: порой достаточно идентификатора устройства и названия события.
Пример — приложение для отслеживания менструального цикла Flo. Оно передавало Google, AppsFlyer, Flurry и другим аналитическим и маркетинговым компаниям идентификаторы устройств вместе с собственными событиями. В том числе с чувствительными данными, например, сведениями о беременности. То есть пользователь осознанно делился с программой медицинскими сведениями, но не рассчитывал, что они станут строчками в сторонних базах данных для таргетинга рекламы.
Дальше — агрегаторам и брокерам данных. Это отдельная индустрия, которая занимается сбором, объединением и продажей информации. Брокер может получить данные из нескольких источников, а затем сшить между собой и перепродать клиентам.
Особенно ценна мобильная геолокация. Так, брокер Mobilewalla собрал более 500 млн уникальных рекламных идентификаторов, связанных с точной геопозицией, сформировал на их основе выборку женщин, посещавших центры помощи беременным, а затем предложил её рекламодателям, которые заинтересованы в аудитории беременных женщин.
И даже заявленная анонимизация идентификаторов спасает не всегда. Если устройство каждую ночь находится в одном частном доме, а по будням приезжает в конкретный офис, круг возможных владельцев резко сокращается. К этому можно добавить информацию из других баз с тем же идентификатором: предпочтения из маркетплейса, круг знакомых из соцсети, историю кликов на рекламу из мобильной игры. И так на руках аналитиков появляется подробная карта жизни человека.
Ещё одна проблема заключается в том, что данные передаются между посредниками и партнёрами практически бесконтрольно. Удалить аккаунт в приложении-источнике зачастую недостаточно: аналитика уже ушла на десятки сторонних серверов и стала частью выборок для рекламодателей.
Что в итоге
- Приложения собирают не только то, что вы вводите сами. Они могут анализировать действия внутри интерфейса, характеристики устройства, сетевые данные, геолокацию и другую доступную телеметрию.
- Значительная часть сбора происходит через сторонние SDK для аналитики, рекламы и диагностики. Поэтому информация может уходить не только разработчику приложения, но и внешним платформам.
- Разрозненные события связываются с помощью рекламных идентификаторов. Если общего ID нет, для распознавания устройства могут использовать комбинацию технических характеристик — фингерпринтинг.
- Чем больше источников удаётся связать, тем подробнее получается профиль пользователя. В нём могут оказаться не только покупки и интересы, но и предполагаемое место жительства, работа, привычки и сведения, выведенные из истории перемещений.
- Полностью остановить сбор данных одним переключателем нельзя ни на iPhone, ни на Android. Но можно заметно сократить его объём: запретить ненужные разрешения, ограничить рекламное отслеживание и периодически проверять, какие данные приложения запрашивают и декларируют.