Мы разобрали APK курьерского приложения — и нашли лишние данные Яндекса

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

Первый звонок: почему клиент заподозрил неладное

К нам обратилась логистическая компания из Москвы — чуть больше тридцати курьеров развозят заказы на личных Android-смартфонах, приложение для них заказывали у другого подрядчика три года назад и с тех пор почти не трогали. Повод для звонка оказался конкретным: бухгалтерия сверяла отчёт оператора по корпоративным SIM-картам и увидела расход трафика по ночам и в выходные — когда приложение никто не открывал, а телефоны заряжались дома или лежали в карманах. Само по себе это не катастрофа, но компания как раз готовилась расширять парк курьеров под контракт с федеральной розничной сетью, а в договоре с сетью был пункт про проверку обработки персональных данных перед подключением к их логистике. Оставлять вопрос без ответа до подписания было рискованно.

Что нашли внутри APK: AppMetrica и что это такое на самом деле

Мы декомпилировали приложение и нашли пакет com.yandex.metrica с обращениями к startup.mobile.yandex.net и report.appmetrica.yandex.ru. Это AppMetrica — обычный аналитический SDK Яндекса, его используют тысячи российских приложений: он ловит крэши, считает сессии, показывает разработчику воронку установок. Сам по себе SDK не спрятанный шпионский модуль — Яндекс публично описывает в документации для разработчиков, какие данные собирает AppMetrica и зачем. Проблема была не в факте установки SDK, а в том, что конфигурация осталась дефолтной с самого первого релиза: точный режим геолокации вместо режима по сети, сессии без ограничения по времени бездействия и ни одного экрана согласия при первом запуске приложения.

Как мы смотрели код без доступа к исходникам

У клиента не сохранился контакт с прежним подрядчиком и, соответственно, исходный код. Мы работали с готовым APK: jadx превращает байткод обратно в читаемую Java-структуру, apktool разбирает манифест и ресурсы. По манифесту сразу видно список запрошенных разрешений — в этом приложении был ACCESS_BACKGROUND_LOCATION, хотя по логике сервиса геолокация нужна только во время смены. По декомпилированному коду видно, какие параметры разработчик передаёт в событие аналитики — и вот там нашлось то, что не имеет отношения к телеметрии SDK вообще.

Что конкретно уходило на сервера Яндекса

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

• ✓рекламный идентификатор устройства и модель телефона — стандартная телеметрия SDK, ожидаемо и безопасно;
• ✓точные координаты в фоне, включая нерабочее время — избыточно и без обоснования в интерфейсе приложения;
• ✓ФИО и номер телефона водителя в параметрах события — персональные данные, которых в аналитическом SDK быть не должно в принципе.

Почему винить только Яндекс — соблазнительно, но неточно

Заголовки про «слежку Яндекса» разлетаются легко, потому что звучит как история про корпорацию против пользователя. На практике Яндекс в этой цепочке — получатель данных, которые ему сам отправил чужой код. AppMetrica не выбирает, что логировать: разработчик сам вызывает метод с параметрами события и сам решает, что туда положить. Тот же SDK в приложении с аккуратной конфигурацией не соберёт ничего лишнего — а без него компания рисковала бы остаться вообще без аналитики падений и потерять возможность быстро находить баги на реальных устройствах пользователей. Вопрос не «убрать Яндекса», а «проверить, что именно и на каких условиях мы туда отправляем».

Похожая история типична не только для курьерских сервисов: склад, выездные монтажники, мобильные бригады сервисной службы — везде B2B-приложение чаще всего заказывают один раз у подрядчика, запускают и потом годами не заглядывают внутрь, пока не возникает конкретный повод — новый контракт, проверка контрагента, жалоба сотрудника. Оставленный без присмотра SDK — это не история про злой умысел, а история про то, что настройки по умолчанию редко совпадают с тем, что нужно конкретному бизнесу.

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

Цена бездействия: что теряла компания

Розничная сеть прямо прописала в договоре аудит обработки персональных данных перед подключением курьеров к своей логистике — с ФИО и телефонами в аналитике компания такой аудит не прошла бы, и старт контракта сдвинулся бы минимум на новый цикл согласований. Отдельно 152-ФЗ обязывает указывать в политике конфиденциальности, какие данные собираются и кому передаются — передача ФИО и телефона стороннему SDK без единого слова об этом в политике даёт любому водителю формальное основание для жалобы в Роскомнадзор, если он решит проверить, что стоит у него на телефоне. Плюс Google Play отдельно проверяет в консоли разработчика декларацию фонового доступа к геолокации — расхождение между тем, что заявлено, и тем, что реально делает приложение, может закончиться снятием обновления с публикации до исправления.

Показательно, что сама компания узнала о проблеме не от Яндекса, не от Google и не от Роскомнадзора — а случайно, по строчке в отчёте оператора связи. Это обычная ситуация для B2B-приложений: пока нет внешнего триггера вроде нового контракта, тендера или проверки, никто не открывает APK и не смотрит, что именно происходит внутри. Разработчик, который писал код три года назад, мог уже сменить работу, а исходники — потеряться вместе с доступом к репозиторию. В таких условиях единственный способ понять реальное состояние дел — декомпилировать то, что уже установлено на устройствах, и свериться с тем, что написано в политике конфиденциальности и в карточке приложения в Google Play.

Отдельный практический момент для тех, кто уже опубликовал приложение и только сейчас решил проверить похожие вещи у себя: если менять список собираемых данных или разрешений, это нужно синхронно обновить в трёх местах — в самом коде, в политике конфиденциальности на сайте и в декларации Data Safety в консоли Google Play. Расхождение между тем, что написано в карточке магазина, и тем, что реально делает код, магазин находит быстрее, чем кажется, а объяснительная переписка с модерацией занимает больше времени, чем сама доработка.

Три варианта закрыть вопрос

Мы предложили компании три варианта — от быстрого патча до пересборки телеметрии на своей инфраструктуре, потому что не каждому бизнесу нужен самый дорогой путь сразу.

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

Что получил клиент в итоге

Начали с быстрого закрытия рисков: убрали ФИО и телефон из параметров событий, ограничили сбор геолокации временем смены, обновили политику конфиденциальности и добавили экран согласия при первом запуске. Пока розничная сеть проверяла обновлённую политику, мы вместе с клиентом спроектировали вторую часть — перенос операционной телеметрии на собственный бэкенд, синхронизированный с 1С компании, вместо стороннего SDK. Решение оказалось оправданным из-за масштабирования: чем больше курьеров, тем дороже держать в приложении инструмент, за поведением которого нужно отдельно следить самим, а не полагаться на настройки по умолчанию.

Такую доработку мы закладываем в разработку мобильных приложений с нуля — она начинается от 500 000 руб за проект, а перенос телеметрии на собственную инфраструктуру делаем как часть интеграции приложения с 1С. Для курьерского сервиса, где расписания, склад и начисления и так ведутся в 1С, такая архитектура ближе к B2B-приложению с 1С, чем к обычному розничному приложению с чужой аналитикой внутри. Точную стоимость под объём курьерского парка и список нужных отчётов считаем индивидуально — ориентиры и состав есть на странице тарифов.

❓ Частые вопросы

Нужно ли предупреждать пользователей, что в приложении стоит AppMetrica?

Да. 152-ФЗ обязывает указывать в политике конфиденциальности, какие данные собираются и передаются третьим лицам. Если приложение отправляет геолокацию или идентификатор устройства Яндексу, это нужно прописать в политике, а для фонового доступа к геолокации — показать пользователю явный экран согласия при первом запуске приложения.

Как понять, что наше приложение уже отправляет лишние данные?

Нужно декомпилировать APK через jadx и посмотреть, какие параметры разработчик передаёт в события аналитики, либо запросить исходный код у подрядчика напрямую. Частая ошибка — в отладочные события попадают ФИО, телефон или адрес, которые никто не убрал перед публикацией в Google Play.

Можно ли вообще не использовать SDK Яндекса и других сервисов аналитики?

Да, если построить собственную телеметрию на бэкенде компании — например, синхронизированном с 1С — и передавать только операционные события: начало и завершение доставки, статус заказа. Это дороже на этапе разработки, зато данные вообще не покидают инфраструктуру заказчика.

Сколько стоит аудит существующего приложения на такие проблемы?

Зависит от объёма кода и количества экранов в приложении — такой аудит мы обычно закладываем в доработку или разработку мобильного приложения с нуля, которая начинается от 500 000 руб за проект. Точную оценку под конкретное приложение считаем после короткого разбора APK.

Что делать, если приложение уже опубликовано в Google Play, а проблему нашли только сейчас?

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