Защита приватности в мобильных приложениях: как кейс против Google усилить диплом по информационной безопасности
В 2026 году стало известно о коллективном иске к Google — миллионы пользователей Android могут получить до $100 за передачу данных через мобильные соединения без их согласия. Суть претензий — в фоновой синхронизации приложений, которая использует трафик даже при отключённом Wi-Fi. Это не просто юридический прецедент, а технический сигнал: устаревшие подходы к управлению сетевыми запросами и отсутствие прозрачности в обработке данных становятся критичными уязвимостями. Для студентов IT-специальностей — особенно в направлениях информационной безопасности, мобильной разработки и системного анализа — это повод сделать диплом не просто формальным документом, а актуальным исследованием реальных угроз. Такой кейс позволяет глубоко проработать архитектурные решения, обосновать выбор стека и показать практическую ценность проекта.
Темы ВКР на основе кейса против Google
1. Разработка безопасного мобильного клиента с контролем сетевой активности
Актуальность: Инцидент с Google показал, что пользователи теряют контроль над фоновыми запросами. Современные приложения должны не только собирать данные, но и честно информировать о каждом соединении.
Цель: Создать архитектуру мобильного приложения, минимизирующую несанкционированный обмен данными и обеспечивающую прозрачность сетевой активности.
- Проанализировать механизмы фоновой синхронизации в Android (WorkManager, JobScheduler, Foreground Services)
- Разработать модель разрешений на уровне приложения и ОС
- Интегрировать механизм логирования и уведомлений о сетевых запросах
- Оценить влияние на энергопотребление и производительность
Структура:
Глава 1 – Анализ уязвимостей в управлении сетевыми запросами в Android
Глава 2 – Проектирование архитектуры с контролем трафика и согласованием действий
Глава 3 – Тестирование эффективности, энергопотребления и юзабилити
2. Система мониторинга и аудита сетевой активности мобильных приложений
Актуальность: Юридические риски растут — компании должны доказать, что не собирают данные без согласия. Это требует технических решений для аудита.
Цель: Построить систему, способную фиксировать и классифицировать сетевые запросы мобильных приложений в реальном времени.
- Изучить протоколы HTTPS, DNS, HTTP/2 и методы перехвата трафика (через proxy, VPN-сервисы)
- Выбрать стек: MITM-прокси (mitmproxy), анализ пакетов (tshark), интеграция с OpenTelemetry
- Реализовать классификацию запросов по типу данных, получателю, частоте
- Разработать отчётность для пользователей и администраторов
Структура:
Глава 1 – Анализ стандартов приватности (GDPR, CCPA) и технических требований к аудиту
Глава 2 – Архитектура системы мониторинга с использованием микросервисов и брокера сообщений
Глава 3 – Тестирование точности детектирования, нагрузочное тестирование, экономика внедрения
3. Оптимизация сетевого взаимодействия мобильных приложений с учётом приватности
Актуальность: Google обвиняют в использовании трафика без ведома пользователя. Это указывает на необходимость баланса между функциональностью и уважением к ресурсам устройства.
Цель: Разработать стратегию сетевого взаимодействия, минимизирующую использование мобильного интернета и повышающую уровень согласия пользователя.
- Проанализировать поведение популярных приложений (Google Services, Facebook, Instagram)
- Разработать алгоритм приоритезации запросов (по типу данных, срочности, источнику)
- Внедрить кэширование, батчинг и синхронизацию только по Wi-Fi
- Оценить выигрыш в объёме трафика и энергопотреблении
Структура:
Глава 1 – Анализ поведения мобильных приложений в условиях ограниченного трафика
Глава 2 – Проектирование оптимизированной стратегии сетевого взаимодействия
Глава 3 – Измерение эффективности: сравнение с базовым сценарием, расчёт TCO
Аналитическая глава: как использовать кейс в обосновании выбора решений
В первой главе ВКР важно не просто пересказать статью, а провести технический разбор. Например:
- Какие именно данные передавались? (аналитика, рекламные ID, логи ошибок)
- По каким протоколам? (HTTP/2, gRPC, WebSockets)
- Какие фреймворки использовались? (Firebase, Google Play Services)
- Какие стандарты были нарушены? (ISO/IEC 25010 — надёжность, безопасность; GDPR — согласие на обработку)
Это позволяет обосновать выбор архитектуры. Например:
| Подход | Плюсы | Минусы | Соответствие стандартам |
|---|---|---|---|
| Фоновая синхронизация через WorkManager | Гибкость, поддержка условий (Wi-Fi, зарядка) | Возможность обхода через Foreground Services | Частично (требует явного согласия) |
| Ручное управление запросами (Retrofit + EventBus) | Полный контроль, прозрачность | Сложнее поддерживать | Высокое (соответствует GDPR) |
| Интеграция с системными настройками (AppOps) | Глубокая интеграция с ОС | Ограниченная поддержка в разных версиях Android | Высокое (если реализовано корректно) |
Сравнение помогает не просто описать технологии, а аргументировать выбор — что критически важно при защите.
Проектная часть: схемы, алгоритмы, интеграция
Во второй главе покажите, как вы решаете проблему. Например:
Архитектура приложения с контролем трафика
[UI]
↓ (запрос данных)
[ViewModel]
↓
[Network Interceptor] → Проверка: Wi-Fi? Разрешено?
↓ (если да)
[API Client (Retrofit)] → [Cache (Room)]
↓
[Analytics Block] → Логирование запросов → [User Dashboard]
Ключевые решения:
- Использование Interceptor в OkHttp для перехвата всех запросов
- Хранение истории запросов в локальной БД (Room) с метками времени, объёмом, получателем
- Интеграция с AppOpsManager для проверки системных разрешений
- Отправка отчётов только при наличии Wi-Fi и разрешения пользователя
Такой подход соответствует требованиям ГОСТ 34.602-89 к разработке ТЗ — вы определяете функциональные и нефункциональные требования, включая безопасность и энергоэффективность.
Тестирование и метрики: как доказать эффективность
Третья глава — не просто "запустили и всё работает". Нужны измеримые результаты. Используйте:
- Нагрузочное тестирование: Симуляция 1000 запросов в фоне — сколько трафика сэкономлено при отключении мобильного интернета?
- Метрики производительности: Время отклика, RTO (время восстановления), RPO (объём потерянных данных при сбое)
- Мониторинг: Интеграция с OpenTelemetry для сбора логов, трейсов, метрик
- Юзабилити-тесты: Опрос пользователей: насколько прозрачна система контроля трафика?
Пример таблицы результатов:
| Сценарий | Объём трафика (Мб/день) | Разряд батареи (%) | Уровень доверия (по опросу) |
|---|---|---|---|
| Стандартная синхронизация | 120 | 35 | 3.2 / 5 |
| С контролем трафика | 28 | 18 | 4.6 / 5 |
Это позволяет сделать выводы: "Предложенное решение сокращает объём фонового трафика на 76%, снижает энергопотребление на 49% и повышает уровень доверия пользователей". Такие формулировки — золото на защите.
Чему вы научитесь, работая над такой темой
- Глубокому анализу архитектуры Android-приложений: как работают сервисы, бродкасты, менеджеры задач
- Проектированию систем с учётом безопасности и приватности — не как опция, а как основа
- Работе с современными инструментами: OpenTelemetry, mitmproxy, Retrofit, Room, CI/CD-пайплайны (для автоматизации тестов)
- Обоснованию выбора технологий через сравнение и метрики — а не через "так все делают"
- Оформлению технической документации по ГОСТ: ТЗ, ПЗ, схемы, отчёты
Типичные ошибки студентов
Ошибка 1: Подмена понятий "приватность" и "безопасность" без технического обоснования
Многие пишут: "приложение безопасно, потому что шифрует данные". Но это не про приватность. Приватность — это контроль, согласие, прозрачность. Используйте ISO/IEC 25010 как основу: разделите "security" и "confidentiality".
Ошибка 2: Отсутствие метрик в выводах
"Решение эффективно" — это не вывод. Нужно: "снижение трафика на X%, сокращение времени обработки на Y мс". Используйте JMeter, Android Profiler, Firebase Performance Monitoring.
Ошибка 3: Игнорирование требований ГОСТ 34.602-89 при оформлении ТЗ
В ТЗ должны быть: назначение, требования к функциональности, к надёжности, к условиям эксплуатации. Не копируйте шаблоны — адаптируйте под свой проект. Укажите: "приложение должно запрашивать разрешение перед использованием мобильного интернета".
FAQ
Насколько сложно реализовать перехват трафика в приложении?
На Android 10+ требуется root или использование собственного VPN-сервиса. Для учебного проекта достаточно перехвата на уровне приложения (через OkHttp Interceptor). Это не даст полного контроля, но покажет принцип — и соответствует уровню ВКР.
Обязательно ли писать код в дипломе?
Да, особенно если вы на специальности разработки. Но код — не цель. Важно показать архитектуру, обосновать выбор решений, протестировать. Достаточно 500–1000 строк ключевых компонентов (например, NetworkInterceptor, ViewModel, тесты).
Как правильно оформить UML-диаграммы?
Используйте стандарты: диаграмма классов, последовательности, развёртывания. Инструменты: PlantUML, draw.io, StarUML. Включите в приложение. Ссылайтесь в тексте: "См. рис. 3.2 — диаграмма последовательности авторизации".
Где брать тестовые данные для анализа трафика?
Используйте: 1) собственные логи приложений (через Charles Proxy или Wireshark), 2) открытые датасеты (например, CICIDS2017), 3) симуляцию через JMeter. Укажите источник в дипломе — это повысит доверие.
Чек-лист «Что проверить перед сдачей»
- Соответствуют ли задачи цели и выводам?
- Есть ли схемы архитектуры и диаграммы (UML)?
- Приведены ли метрики эффективности (объём трафика, время, энергопотребление)?
- Ссылки на источники — включая статью ZDNet и нормативные документы (ГОСТ, ISO)?
- Проверено ли оформление по требованиям вуза (шрифт, поля, нумерация)?
- Есть ли приложение с кодом, схемами, инструкцией по запуску?
Не знаете, как начать? У нас вы можете заказать диплом или получить бесплатную консультацию по теме. Наши эксперты помогут с выбором актуальной темы, подбором метрик и защитой. В среднем студент тратит 120 часов на ВКР — мы поможем сэкономить время и избежать ошибок. Помощь с дипломом — это не про "написать за вас", а про "сделать сильнее".
Источник: Android users can get up to $100 each from this class action suit - see if you're eligible (опубликовано 2026-04-08)