Трекеры активности в приложениях: что скрывает фоновый сбор данных

По исследованиям, от 70% до 75% приложений продолжают фоновую активность после выгрузки из списка запущенных.

Это не обязательно означает, что каждое приложение непрерывно шпионит за владельцем телефона. Но разница между тем, что человек считает выключенным, и тем, что программа продолжает делать, вполне реальна. Разбираю, как устроены трекеры активности в приложениях, почему скрытый сбор данных трудно заметить и что можно предпринять без обещаний полной невидимости.

Закрыто — только на экране

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

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

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

Свайп закрывает карточку. Он не подписывает за вас договор о прекращении всех фоновых процессов.

Если хочется разобраться, что происходит именно на телефоне, нужен не только взгляд на экранное время. Экранное время показывает, сколько вы пользовались приложением, но не объясняет, что оно отправляло в сеть после закрытия. Для этого полезен анализ трафика мобильных приложений: он помогает увидеть соединения и частоту запросов. Однако и здесь нет волшебной кнопки «показать всю правду»: шифрование ограничивает содержимое, а часть сетевой активности может выглядеть как обычный обмен с сервисной инфраструктурой.

Что именно утекает — и почему доступ к датчику ещё не весь сюжет

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

Аудиты выявляли обращения приложений к буферу обмена, контактам и журналам звонков. В одном из технических разборов Android-софта сервисные вызовы обращались к буферу обмена до 16 раз в коде приложения. Это не доказывает, что каждый такой вызов приводил к отправке содержимого на сервер. Но сам факт доступа без понятной пользователю причины — уже повод спросить, зачем он нужен.

По данным исследования Pradeo, 20% приложений передавали наружу фотографии, видео или аудиофайлы, а 14% отправляли на сторонние серверы контакты пользователей. Эти цифры не следует читать как утверждение, что любая программа из магазина выгружает вашу галерею. Они показывают другое: передача личных данных встречается не только в теоретических моделях угроз.

Особенно много вопросов возникает у фитнес-сервисов. Приложение для тренировок может иметь понятную причину собирать маршрут пробежки или показатели активности. Но доступ к геолокации не становится автоматически безобидным только потому, что на иконке нарисована кроссовка. Маршруты и расписание занятий способны раскрыть бытовые привычки. А если данные передаются дальше, пользователь может не знать, кто ещё получает к ним доступ и как долго они хранятся.

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

Data Safety: полезная этикетка, но не гарантия

Карточки Data Safety в Google Play и App Privacy в App Store дают представление о том, какие категории данных разработчик заявляет и как их описывает. Смотреть на них полезно. Принимать за независимый аудит — нет.

Исследование сборок приложений выявляло расхождения между фактическими рисками утечки данных и тем, что было указано в официальных разделах приватности. В частности, более 77% проверенных программ содержали уязвимости, связанные с конфиденциальной информацией, и не отражали реальный сбор в декларациях магазина. Это не означает, что все карточки заведомо ложны или что у каждого приложения одинаковый риск. Но витрина магазина не может гарантировать, что декларация полностью совпадает с поведением каждой версии программы и всех встроенных в неё SDK.

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

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

На практике я бы смотрел на сочетание сигналов, а не на одну красивую отметку:

• Приложение просит доступ, без которого его основная функция явно работает.
• Фоновая передача данных продолжается, хотя синхронизация и связанные функции отключены.
• В политике конфиденциальности неясно описаны получатели данных или цели обработки.
• Сервис требует создать аккаунт и предоставить дополнительные сведения для функции, которой можно пользоваться локально.
• После отказа в разрешении приложение ломается там, где этот доступ не должен быть нужен.

Ни один пункт сам по себе не доказывает злой умысел. Но если совпало несколько, бесплатная утилита начинает напоминать не подарок, а способ доить базу: продукт продаёт удобство, а пользователь расплачивается данными, которые не собирался отдавать.

Кейс Google: выключатель, который выключал не всё

Показательный пример — история с настройками геолокации Android. По материалам расследования, отключение «Хронологии местоположений» не останавливало сбор, связанный с функцией «Активность в Интернете и приложениях». Пользователь мог решить, что запретил отслеживание местоположения, тогда как другой механизм продолжал собирать геоданные.

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

Это важный урок для любого приложения, а не только для карт и соцсетей. Один переключатель часто управляет одним видом обработки, но не всеми путями, по которым данные могут попасть к сервису. Геолокация, например, может быть связана не только с разрешением операционной системы, но и с настройками аккаунта, историей активности, синхронизацией и разрешениями отдельных компонентов. Нельзя исходить из того, что выключение пункта с подходящим названием обрубает всю цепочку.

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

Как ограничить фоновый сбор, не сломав телефон

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

Я бы начал с самого простого: раз в несколько месяцев открыть список разрешений и пройтись по геолокации, микрофону, камере, контактам и фото. Не по принципу «запретить всё», а с вопросом: когда именно программе нужен этот доступ? Для некоторых приложений подходит режим «только во время использования». Для других разумнее выбрать ограниченный доступ к фотографиям, а не ко всей медиатеке. Если функция перестала быть нужной, разрешение можно отозвать.

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

С блокировкой трекеров на смартфоне тоже лучше без чудесных обещаний. Системные настройки приватности, ограничения фоновых данных, DNS-фильтрация или сетевой экран могут пресечь часть соединений. Но они не гарантируют остановку всех SDK, не расшифровывают автоматически весь трафик и иногда ломают нужные функции. Если после блокировки перестали работать авторизация или уведомления, это ещё не доказывает, что фильтр поймал шпиона: он мог задеть обычный сервисный запрос.

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

И наконец, не вводить в приложения лишнее. Не давать номер телефона там, где он не нужен для функции. Не подключать адресную книгу ради удобства поиска, если можно найти человека вручную. Не использовать один и тот же аккаунт в десятке сервисов без необходимости. Эти меры не остановят фоновые трекеры, но сократят объём данных, который вообще можно связать с вами.

Телефон передаёт данные не только тогда, когда вы на него смотрите

Главная ошибка — считать, что приватность сводится к одному разрешению или кнопке «закрыть». Фоновая активность складывается из поведения самого приложения, сторонних SDK, системных служб и настроек аккаунта. Один слой не всегда знает, что делает другой, а пользователь обычно видит лишь часть картины.

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

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