Введение: цифровая экосистема как объект криминалистического исследования

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

Споры между разработчиками и заказчиками, иски о возмещении убытков, вызванных критическими сбоями, а также разбирательства, связанные с несоответствием функциональности техническому заданию, становятся всё более распространёнными в судебной практике. Именно в таких случаях на первый план выходит компьютерно-техническая экспертиза мобильных приложений — комплексное исследование, позволяющее не только выявить дефекты программного продукта, но и установить их природу, причины возникновения и, что особенно важно, причинно-следственную связь между недостатками приложения и понесёнными убытками. Союз «Федерация судебных экспертов» на протяжении многих лет развивает данное направление, объединяя методы программной инженерии, киберкриминалистики и процессуального права в единую научно-практическую дисциплину. В настоящей статье мы подробно рассмотрим методологические подходы к исследованию качества мобильных приложений, типовые категории дефектов, методы их выявления, а также приведём три реальных кейса из экспертной практики, демонстрирующих эффективность научно обоснованного подхода. 📱🔬⚖️

Глава 1. Определение предметной области: объекты и цели компьютерно-технической экспертизы мобильных приложений

Под компьютерно-технической экспертизой мобильных приложений понимается вид судебного исследования, объектами которого выступают программные продукты, предназначенные для функционирования на мобильных устройствах под управлением операционных систем iOS, ANDROID, HARMONYOS или их производных. Целью экспертизы является установление фактических обстоятельств, связанных с качеством разработки, наличием дефектов, соответствием заявленной функциональности и технической документации, а также определением причинно-следственных связей между выявленными недостатками и негативными последствиями для заказчика или конечных пользователей.

В спектр задач, решаемых в рамках данного вида экспертизы, входят:

📌 Оценка соответствия приложения условиям договора и техническому заданию — установление факта реализации (или нереализации) требуемого функционала, соответствия характеристик производительности заявленным параметрам.

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

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

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

📌 Оценка влияния недостатков приложения на бизнес-метрики — установление причинно-следственной связи между низкой производительностью, проблемами UX/UI и снижением удержания пользователей, конверсии, а также финансовыми потерями.

Каждая из перечисленных задач требует применения специфических методов исследования, которые будут подробно рассмотрены в последующих главах. Важно отметить, что экспертиза проводится на основе принципов научной обоснованности, полноты и объективности, а экспертное заключение должно содержать не только выводы, но и детальное описание применённых методов и полученных результатов. 🎯📋

Глава 2. Таксономия дефектов мобильных приложений: систематизация недостатков для целей судебной экспертизы

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

Категория 1. Функциональные дефекты (ФД) 🧩

Дефекты, связанные с несоответствием поведения приложения заявленной функциональности или техническому заданию:

• Нереализованные функции — заявленный в требованиях функционал полностью отсутствует.
• Некорректная реализация функций — функция присутствует, но работает не в соответствии со спецификацией (например, кнопка «Оплатить» не инициирует списание средств или списывает неверную сумму).
• Ошибки обработки граничных условий — приложение некорректно обрабатывает нулевые, пустые или экстремальные значения входных данных.
• Нарушение бизнес-логики — последовательность действий пользователя приводит к результату, противоречащему предусмотренной логике работы (например, возможность оформления заказа без подтверждения оплаты).

Категория 2. Дефекты производительности и стабильности (ДП) ⚡

Недостатки, влияющие на скорость работы и устойчивость приложения:

• Низкая скорость загрузки и отклика — превышение нормативных значений времени отклика интерфейса (более 300 мс для операций, более 2 секунд для загрузки экрана).
• Высокое потребление ресурсов устройства — чрезмерное использование оперативной памяти (более 100 МБ для приложений общего назначения), процессора (постоянная загрузка более 30% в фоновом режиме), энергии (ускоренный разряд батареи более чем на 15% по сравнению с эталонными приложениями).
• Критические сбои (CRASH) — аварийное завершение работы приложения, возникновение исключительных ситуаций (EXCEPTION), не обработанных программным кодом.
• «Зависания» (ANR — APPLICATION NOT RESPONDING на ANDROID, SPINNING BEACH BALL на iOS) — длительное отсутствие реакции на пользовательский ввод.

Категория 3. Дефекты безопасности и защиты данных (ДБ) 🔒

Уязвимости, создающие риски утечки конфиденциальной информации:

• Небезопасное хранение данных — запись чувствительной информации (паролей, токенов, платёжных данных) в незашифрованном виде в локальное хранилище или логи.
• Незащищённая передача данных по сети — использование протоколов без шифрования (HTTP вместо HTTPS) или с устаревшими версиями TLS (1.0, 1.1).
• Избыточные разрешения — запрос приложением разрешений, не соответствующих его функциональности (например, доступ к контактам для приложения-фонарика).
• Уязвимости сторонних библиотек — использование компонентов с известными уязвимостями (CVE — COMMON VULNERABILITIES AND EXPOSURES).

Категория 4. Дефекты пользовательского опыта и юзабилити (ДПО) 🎨

Недостатки, ухудшающие удобство использования приложения:

• Неинтуитивная навигация — пользователь не может достичь целевого действия за разумное количество шагов (более 5 кликов для ключевых функций).
• Несоответствие платформенным гайдлайнам — нарушение требований HUMAN INTERFACE GUIDELINES (iOS) или MATERIAL DESIGN (ANDROID), приводящее к отторжению приложения модерацией магазинов.
• Отсутствие обратной связи — пользователь не получает визуального или звукового подтверждения выполнения действия (нажатия, отправки данных, успешной операции).
• Некорректное отображение контента — неправильное масштабирование на разных разрешениях экрана, обрезание текста, наложение элементов интерфейса.

Категория 5. Дефекты совместимости и окружения (ДС) 📱

Проблемы, возникающие на определённых устройствах или версиях операционных систем:

• Несовместимость с версией ОС — приложение не работает на заявленных минимальных версиях iOS или ANDROID.
• Конфликт с аппаратными особенностями — некорректная работа на устройствах с определённым типом процессора (ARM, x86), объёмом оперативной памяти, разрешением экрана, версией Bluetooth и т.д.
• Проблемы интеграции со сторонними сервисами — сбои при взаимодействии с платёжными шлюзами, API социальных сетей, push-уведомлениями.

Данная систематизация позволяет эксперту не только выявлять дефекты, но и классифицировать их по степени критичности, что непосредственно влияет на итоговую оценку качества приложения и обоснование причинённого ущерба. 📊📑

Глава 3. Методологический аппарат: инструментарий и методы исследования

Качественное проведение компьютерно-технической экспертизы мобильных приложений требует применения комплекса методов, каждый из которых ориентирован на определённый аспект исследования. Рассмотрим основные методы в порядке их применения в типовом экспертном исследовании.

Метод 1. Статический анализ программного кода (САПК) 🔍

Применяется при наличии исходного кода приложения. Эксперт анализирует структуру программы без её фактического выполнения. Инструментарий: специализированные статические анализаторы (SONARQUBE, COVERITY, KLOCKWORK), а также собственные скрипты для выявления специфических паттернов.

Что выявляется:

• Нарушения стандартов кодирования (MISRA, CERT) — потенциальные источники ошибок.
• Необработанные исключения — места в коде, где возможно аварийное завершение.
• Уязвимости типа «переполнение буфера», «SQL-инъекции», «межсайтовый скриптинг».
• Неиспользуемый код («мёртвый код») и дублирование.

Метод 2. Динамический анализ и поведенческое тестирование 🎮

Исследование приложения в процессе его выполнения в контролируемой среде. Применяется как на реальных устройствах, так и на эмуляторах/симуляторах.

Инструментарий:

• Фреймворки автоматизированного тестирования (APPIUM, ESPRESSO для ANDROID, XCUITEST для iOS).
• Профилировщики производительности (ANDROID STUDIO PROFILER, XCODE INSTRUMENTS).
• Модули мониторинга сети (CHARLES PROXY, WIRESHARK, BURP SUITE).

Что выявляется:

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

Метод 3. Криминалистический анализ цифровых следов (КАЦС) 🕵️‍♂️

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

Объекты анализа:

• Системные журналы (LOGCAT для ANDROID, консольные логи для iOS).
• Дампы памяти приложения (при наличии критического сбоя).
• Файлы кэша, локальные базы данных (SQLITE), файлы предпочтений (SHARED PREFERENCES, USER DEFAULTS).
• Отчёты об ошибках, направляемые в сервисы аналитики (CRASHLYTICS, FIREBASE, APPMETRICA).

Что устанавливается:

• Последовательность событий, предшествовавших сбою.
• Наличие следов вредоносного кода или несанкционированного доступа.
• Действия пользователя, приведшие к некорректной работе.
• Факт модификации приложения или его окружения (ROOT-доступ, JAILBREAK).

Метод 4. Юзабилити-тестирование (ЮТ) 👥

Оценка пользовательского опыта с привлечением представителей целевой аудитории (при необходимости — в рамках судебного эксперимента). Может проводиться как в лабораторных условиях, так и дистанционно.

Методика:

• Определение ключевых пользовательских сценариев (JOURNEY MAPS).
• Фиксация времени выполнения каждого сценария.
• Оценка успешности выполнения (конверсии) и количества ошибок пользователя.
• Сбор субъективной обратной связи (опросы SYSTEM USABILITY SCALE — SUS).

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

Метод 5. Сравнительный анализ с эталонными образцами (САЭО) 📏

Сравнение исследуемого приложения с общепринятыми стандартами, требованиями платформ (APP STORE, GOOGLE PLAY), а также с приложениями-аналогами (функциональными конкурентами). Применяется для оценки «качества, обычно предъявляемого к такого рода продуктам» — критерия, прямо указанного в законодательстве об экспертной деятельности.

Что может быть использовано в качестве эталона:

• Требования, изложенные в техническом задании и договоре разработки.
• HUMAN INTERFACE GUIDELINES (Apple) и MATERIAL DESIGN GUIDELINES (Google).
• Стандарты ISO/IEC 25010 («Качество программных продуктов»).
• Функциональность и производительность приложений-лидеров в соответствующей категории магазинов приложений.

Выбор конкретного метода или их комбинации зависит от поставленных вопросов, доступных материалов и характера предполагаемых дефектов. В сложных случаях эксперт может использовать все пять методов, интегрируя полученные данные в единую картину. 🛠️💻

Глава 4. Нормативно-правовая база и критерии оценки качества

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

Федеральный уровень: ⚖️

• Федеральный закон от 31.05.2001 № 73-ФЗ «О государственной судебно-экспертной деятельности в Российской Федерации» — устанавливает общие принципы экспертной деятельности, права и обязанности эксперта.
• Гражданский процессуальный кодекс РФ, Арбитражный процессуальный кодекс РФ, Уголовно-процессуальный кодекс РФ — определяют процессуальный статус экспертного заключения как доказательства.
• Гражданский кодекс РФ (глава 37 «Подряд», статья 721 «Качество работы») — определяет критерии качества результата работы по договору подряда (в том числе разработки ПО).

Стандарты и нормативно-техническая документация: 📑

• ГОСТ Р 57429-2017 «Судебная компьютерно-техническая экспертиза. Термины и определения» — основной терминологический стандарт в данной области.
• ГОСТ Р ИСО/МЭК 25010-2015 «Информационные технологии. Системная и программная инженерия. Модели качества» — международный стандарт, определяющий характеристики качества программного продукта: функциональная пригодность, производительность, совместимость, удобство использования, надёжность, безопасность, сопровождаемость, переносимость.
• ГОСТ Р 54593-2011 «Информационные технологии. Методы и средства обеспечения безопасности. Оценка соответствия требованиям безопасности информации» — применяется при экспертизе безопасности.

Ключевые критерии качества для целей судебной экспертизы: 🎯

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

1. Работоспособность— способность приложения выполнять основные функции без критических сбоев в типовых условиях эксплуатации.
2. Соответствие заявленной функциональности— реализация всех функций, перечисленных в техническом задании, договоре, описании в магазине приложений.
3. Соответствие стандартам платформ— соблюдение требований APP STORE REVIEW GUIDELINES и GOOGLE PLAY DEVELOPER POLICY.
4. Отсутствие критических дефектов— ошибок, делающих приложение непригодным для использования по назначению.
5. Потребительская ценность— способность продукта удовлетворять потребности пользователей (оценивается через сравнение с аналогами, анализ отзывов, метрик использования).

Важно понимать, что наличие отдельных дефектов (особенно низкой степени критичности) не всегда означает, что продукт не соответствует условиям договора. Эксперт должен оценивать их совокупность и влияние на общую пригодность приложения к использованию. 🧾⚖️

Глава 5. Кейс №1: Спор о качестве мобильного банкинга — нереализованный функционал и критические сбои 🏦💥

Обстоятельства дела: 🏛️

Банк «А» заключил договор с компанией-разработчиком «Б» на создание мобильного приложения для интернет-банкинга. Стоимость контракта — 24 млн рублей. Техническое задание (ТЗ) содержало 86 функциональных требований, включая: оплату услуг по QR-коду, двухфакторную аутентификацию через PUSH-уведомления, создание шаблонов платежей, выписку с возможностью фильтрации, а также интеграцию с платёжным шлюзом. Приложение было передано заказчику, однако в процессе эксплуатации выявились многочисленные недостатки. Банк направил претензию с требованием устранить дефекты, разработчик отказался, заявив, что продукт соответствует ТЗ и готов к промышленной эксплуатации. Банк обратился в суд с иском о расторжении договора и взыскании уплаченных средств. Суд назначил компьютерно-техническую экспертизу мобильных приложений, поручив её проведение Союзу «Федерация судебных экспертов».

Исходные данные, предоставленные на экспертизу: 📀

• Исходный код приложения (репозиторий GIT) и документация.
• Техническое задание с приложениями (акт приёмочных испытаний не подписан).
• Логи серверной части (API) за 2 месяца эксплуатации.
• Журналы ошибок (CRASHLYTICS) и аналитика (FIREBASE, APPMETRICA).
• Три тестовых устройства: iPhone 14 Pro (iOS 16), Xiaomi 12 (Android 13), Samsung A52 (Android 12).
• Запись экрана (видеофиксация) проблемных операций, предоставленная сотрудниками банка.

Ход исследования: 🔬

Этап 1. Статический анализ кода и сопоставление с ТЗ

Исходный код приложения (объём 85 тысяч строк на KOTLIN и SWIFT) был проанализирован с использованием автоматизированных средств и ручной проверки. Эксперт сопоставил каждое функциональное требование ТЗ с реализованными модулями кода.

Результаты статического анализа:

• Функция «оплата по QR-коду» — в коде отсутствовал модуль обработки QR-сканера и парсинга строки платежа. Вместо полноценной реализации был заглушенный метод, возвращающий сообщение «Feature in development». Требование не реализовано.
• Двухфакторная аутентификация через PUSH — в коде присутствовала регистрация устройства в сервисе FIREBASE CLOUD MESSAGING (FCM), но отсутствовала логика привязки сессии к конкретному устройству и проверки подписи PUSH-уведомления. Требование не реализовано— вместо двухфакторной аутентификации фактически была однофакторная.
• Фильтрация выписки (по дате, сумме, контрагенту, категории) — реализована только фильтрация по дате. Остальные три типа фильтрации отсутствовали в коде. Требование реализовано не в полном объёме.

Итого по статическому анализу: из 86 требований полностью не реализовано 12 (14%), частично реализовано 27 (31%), полностью и корректно реализовано 47 (55%).

Этап 2. Динамическое тестирование производительности и стабильности

Приложение было установлено на три тестовых устройства. Проведено нагрузочное тестирование: 50 последовательных операций по каждому из ключевых сценариев.

Выявленные дефекты стабильности:

• Частота критических сбоев (CRASH RATE) — при выполнении операции «оплата по реквизитам» приложение аварийно завершалось в 12% случаев на ANDROID-устройствах и в 8% случаев на iOS.
• Анализ дампов памяти (полученных через ANDROID STUDIO PROFILER и XCODE INSTRUMENTS) показал, что причиной сбоя было необработанное исключение NullPointerExceptionв модуле валидации БИК (банковского идентификационного кода). При вводе несуществующего БИК вместо возврата сообщения об ошибке приложение падало.
• Время отклика интерфейса: при загрузке истории операций за 3 месяца время отображения составляло 6–8 секунд (нормативное значение по отраслевым стандартам — не более 2 секунд). Профилирование показало, что проблема заключалась в отсутствии пагинации (постраничной выгрузки) — загружался весь массив данных в оперативную память.

Этап 3. Анализ журналов ошибок и данных аналитики

Предоставленные журналы CRASHLYTICS и FIREBASE за 2 месяца эксплуатации в «боевой» среде содержали 1 247 записей о критических сбоях для 8 930 активных пользователей. Показатель CRASH RATE = 13,96%, что превышает допустимые значения для финансовых приложений (обычно не более 1%). По классификации GOOGLE PLAY, приложения с CRASH RATE > 1,09% попадают в «красную зону» и подлежат исключению из магазина при выявлении устойчивой тенденции.

Этап 4. Оценка потребительской ценности и соответствия отраслевым стандартам

Для сравнительного анализа были выбраны три приложения-аналога из категории «Финансы»: «Альфа-Банк Мобайл», «Т-Банк», «СберБанк Онлайн». Проведено юзабилити-тестирование с участием 15 респондентов из числа клиентов банка (методика SUS — SYSTEM USABILITY SCALE).

Результаты:

• Средняя оценка SUS для исследуемого приложения — 42 балла (из 100), что соответствует категории «Неприемлемо для использования» (NOT ACCEPTABLE).
• Средняя оценка SUS для приложений-аналогов — 78 баллов (категория «Хорошо»).
• 14 из 15 респондентов не смогли самостоятельно выполнить операцию «выписка за период с фильтрацией по контрагенту» без подсказок (из-за нереализованной функциональности).

Выводы эксперта 📝

1. Разработанное мобильное приложение не соответствует условиям договора и техническому заданию в части: (а) функционала оплаты по QR-коду (требование не реализовано); (б) двухфакторной аутентификации (реализован суррогатный механизм, не обеспечивающий требуемый уровень безопасности); (в) фильтрации выписки (реализовано менее 25% требуемых типов фильтрации).
2. Приложение содержит критические дефекты, препятствующие его нормальной эксплуатации: частота критических сбоев (CRASH RATE = 13,96%) в 14 раз превышает допустимые значения для финансовых приложений; время отклика ключевых функций превышает нормативное значение в 3–4 раза.
3. Потребительская ценность приложения отсутствует (оценка SUS = 42 балла), оно не может быть рекомендовано к использованию клиентами банка.
4. Выявленные недостатки имеют производственный характер (дефекты кода, неполнота реализации), а не возникли вследствие действий третьих лиц или несовместимости с устройствами.

Судебное решение ⚖️

Суд признал заключение эксперта допустимым и достоверным доказательством. Исковые требования банка удовлетворены в полном объёме: договор разработки расторгнут, с компании-разработчика взыскано 24 млн рублей (цена контракта), а также убытки в размере 3,2 млн рублей, связанные с вынужденным продлением договора обслуживания с подрядчиком на поддержку старой версии приложения. Апелляционная инстанция оставила решение без изменений.

Глава 6. Кейс №2: Низкая производительность приложения для доставки — потеря прибыли из-за оттока пользователей 🚚📉

Обстоятельства дела: 🏛️

Сервис доставки еды «ВкусныйМаршрут» (истец) заключил договор с IT-компанией «СофтСтрой» (ответчик) на разработку мобильного приложения для заказа доставки с функционалом: каталог блюд, корзина, интеграция с платёжными системами, трекинг заказа в реальном времени, программа лояльности. Приложение было запущено в магазинах APP STORE и GOOGLE PLAY. В течение первых трёх месяцев количество активных пользователей росло, достигнув 45 000 в месяц, а затем начало резко снижаться. Аналитика показала высокий показатель оттока (CHURN RATE) — 35% в месяц (при норме для отрасли 10–15%). Пользователи массово жаловались на долгую загрузку каталога, «зависания» при добавлении товаров в корзину и аварийные завершения при оплате. Истец обратился к разработчику с требованием устранить недостатки, получил отказ. Иск о взыскании убытков (упущенная выгода в размере 15 млн рублей за 6 месяцев) был направлен в арбитражный суд. Суд назначил компьютерно-техническую экспертизу мобильных приложений с фокусом на влияние дефектов производительности на бизнес-показатели.

Исходные данные: 📀

• Исходный код и проектная документация.
• Техническое задание с требованиями к производительности (п. 5.2: «Время загрузки каталога не более 2 секунд при 100 позициях, время подтверждения заказа не более 3 секунд»).
• Данные аналитики FIREBASE и APPMETRICA за 6 месяцев: DAU (DAILY ACTIVE USERS — ежедневно активные пользователи), CHURN RATE (отток), CRASH RATE, USER JOURNEY (пути пользователей).
• Записи экрана от пользователей, демонстрирующие проблемы.
• Отчёты о доходах сервиса за аналогичный период прошлого года (до запуска приложения) и прогноз роста.

Ход исследования: 🔬

Этап 1. Воспроизведение проблемы и инструментальное тестирование

Приложение установлено на 10 тестовых устройств разных моделей и версий ОС. Проведено автоматизированное тестирование с помощью APPIUM и ESPRESSO для ANDROID, XCUITEST для iOS.

Измеренные показатели производительности:

• Время загрузки каталога (100 позиций) — 5,8–7,2 секунды(норматив по ТЗ — не более 2 секунд, отраслевой бенчмарк — 1,5 секунды).
• Время перехода из каталога в корзину — 3,4 секунды(должно быть менее 1 секунды).
• Время подтверждения заказа — 8,9 секунды(норматив по ТЗ — не более 3 секунд), из них 6,2 секунды приходилось на ожидание ответа API.
• Частота ANR (APPLICATION NOT RESPONDING) — 4,7%от всех сессий (значение, превышающее порог отбраковки GOOGLE PLAY в 3 раза).

Этап 2. Профилирование кода и выявление причин

С помощью ANDROID STUDIO PROFILER и XCODE INSTRUMENTS проведён анализ потребления ресурсов.

Установленные причины низкой производительности:

• Отсутствие кэширования изображений блюд — при каждом открытии каталога происходила повторная загрузка 50–100 изображений (в среднем по 300 КБ каждое), что генерировало 15–30 МБ трафика за одну загрузку каталога.
• Нерациональные запросы к API — на один экран каталога приходилось 8–10 отдельных HTTP-запросов (вместо одного запроса, возвращающего все необходимые данные). Время каждого запроса складывалось, создавая эффект «накопления задержки».
• Отсутствие пагинации (подгрузки порциями) — при скроллинге длинного списка загружался весь массив данных (до 500 позиций), что вызывало переполнение памяти на устройствах с 2 ГБ ОЗУ и приводило к ANR.
• «Тяжёлые» операции на UI-потоке (MAIN THREAD) — декодирование и масштабирование изображений, парсинг JSON, запись в локальную базу данных выполнялись в потоке интерфейса, блокируя отклик приложения.

Этап 3. Анализ влияния на бизнес-метрики (установление причинно-следственной связи)

Экспертом проведён корреляционный анализ между зафиксированными показателями производительности и ключевыми бизнес-метриками.

Найденные корреляции (коэффициент Пирсона):

• Время загрузки каталога и показатель оттока (CHURN RATE) на следующий день после «медленной» сессии: r = 0,87(сильная прямая зависимость). Пользователи, у которых загрузка каталога превышала 5 секунд, возвращались в приложение на следующий день в 3 раза реже (RETENTION RATE = 18% против 58% в «быстрых» сессиях).
• Время подтверждения заказа и конверсия в оплату: r = -0,82(сильная обратная зависимость). При времени подтверждения более 7 секунд конверсия падала с 72% до 31% — пользователи бросали оформление заказа на этапе оплаты.
• Частота ANR и оценка приложения (RATING) в магазинах: r = -0,91. В дни с высокой частотой ANR средняя оценка приложения в GOOGLE PLAY падала с 4,2 до 2,4 звёзд.

Этап 4. Расчёт упущенной выгоды

На основе данных аналитики за 6 месяцев и эталонных показателей производительности (из отраслевых бенчмарков) эксперт построил прогнозную модель.

Методика расчёта:

• Средний чек заказа в сервисе до запуска приложения (с данными веб-версии) — 1 200 рублей.
• Среднее количество заказов на одного активного пользователя в месяц — 2,5 (факт за 3 месяца до падения).
• Ожидаемый рост активных пользователей до запуска приложения (маркетинговый план, согласованный сторонами) — 25% в месяц.
• Фактическое количество активных пользователей через 6 месяцев — 18 500 (вместо планировавшихся 67 000 согласно маркетинговому плану).
• Фактическая конверсия из активного пользователя в заказ — 1,8 заказа в месяц (вместо 2,5).

Расчётный ущерб:

(Ожидаемое количество заказов — Фактическое количество заказов) × Средний чек =
(67 000 × 2,5) — (18 500 × 1,8) = 167 500 — 33 300 = 134 200 заказов.
134 200 × 1 200 рублей = 161 040 000 рублей (упущенная выгода).

Истец, однако, заявил требования только на 15 млн рублей (часть упущенной выгоды) в связи с трудностями доказывания полного объёма.

Выводы эксперта 📄

1. Мобильное приложение не соответствует условиям договора и техническому заданию по показателям производительности: фактическое время загрузки каталога превышает нормативное в 2,9–3,6 раза, время подтверждения заказа — в 2,9 раза.
2. Выявленные дефекты производительности имеют производственный характер и являются следствием ошибок архитектуры приложения: отсутствие кэширования, нерациональные запросы к API, отсутствие пагинации, выполнение «тяжёлых» операций на UI-потоке.
3. Существует прямая причинно-следственная связь между низкой производительностью приложения и снижением бизнес-метрик: коэффициент корреляции между временем загрузки каталога и оттоком пользователей составляет r = 0,87, между временем подтверждения заказа и конверсией в оплату — r = -0,82.
4. Упущенная выгода истца, рассчитанная на основе согласованного маркетингового плана и фактических данных аналитики, составляет не менее 15 млн рублей за 6 месяцев (минимальная оценка, нижняя граница доверительного интервала 95%).

Судебное решение ⚖️

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

Глава 7. Кейс №3: Спор о соответствии мобильного приложения требованиям безопасности (политика конфиденциальности и шифрование данных) 🔐📱

Обстоятельства дела: 🏛️

Медицинская компания «ЗдоровьеПлюс» (истец) заказала разработку мобильного приложения для телемедицины: запись к врачам, проведение видеоконсультаций, загрузка результатов анализов, оплата услуг, хранение электронной медицинской карты (ЭМК). Разработчик «МедСофт» (ответчик) передал готовое приложение, которое прошло модерацию APP STORE и GOOGLE PLAY и было запущено в эксплуатацию. Однако через 3 месяца после запуска Роскомнадзор направил компании предписание об устранении нарушений требований Федерального закона от 27.07.2006 № 152-ФЗ «О персональных данных»: приложение передавало персональные данные (ФИО, контактные данные, СНИЛС) и охраняемую законом медицинскую тайну на серверы, расположенные за пределами РФ, без информирования пользователей и получения согласия на трансграничную передачу. Компания понесла расходы на доработку приложения (4,5 млн рублей) и уплатила административный штраф (600 тыс. рублей). Истец обратился в суд с требованием взыскать указанные расходы с разработчика, утверждая, что приложение не соответствует требованиям безопасности и конфиденциальности, установленным законодательством и техническим заданием. Суд назначил компьютерно-техническую экспертизу мобильных приложений для проверки соответствия приложения требованиям безопасности.

Исходные данные: 📀

• Исходный код приложения и серверной части.
• Техническое задание, п. 8: «Обеспечить хранение и обработку персональных данных и медицинской информации в соответствии с требованиями законодательства РФ, включая локализацию на территории РФ и шифрование при передаче по каналам связи».
• Договор хостинга с российским провайдером (ООО «РусХост»).
• Акт проверки Роскомнадзора, предписание, квитанция об уплате штрафа.
• Отчёт о внутреннем аудите безопасности (проведён после инцидента).

Ход исследования: 🔬

Этап 1. Анализ сетевого трафика приложения

С использованием инструмента CHARLES PROXY (прокси-сервер с перехватом TLS-соединений) был проанализирован весь сетевой трафик приложения при выполнении ключевых операций: регистрация, авторизация, загрузка медицинских документов, проведение видеоконсультации.

Выявленные нарушения безопасности:

• Трансграничная передача данных: при регистрации пользователя приложение отправляло POST-запрос на сервер с доменом api-medsoft.azurewebsites.net(IP-адрес, принадлежащий дата-центру MICROSOFT AZURE в Ирландии, согласно WHOIS-запросам и геолокации IP). Вместе с запросом передавались: ФИО, номер телефона, СНИЛС, данные полиса ОМС, электронная почта. Нарушение: ч. 5 ст. 18 Федерального закона № 152-ФЗ — обязанность обеспечения записи, систематизации, накопления, хранения персональных данных граждан РФ с использованием баз данных, находящихся на территории РФ.
• Отсутствие шифрования некоторых данных: при загрузке результатов анализов (файлы PDF, JPG) трафик передавался по протоколу HTTP (не HTTPS) на подсеть 0.0.0/8(внутренняя сеть хостинг-провайдера, где, предположительно, находились серверы). Хотя передача проходила внутри дата-центра, отсутствие шифрования создавало риск перехвата персоналом провайдера. Нарушение: ч. 2 ст. 6 Федерального закона № 152-ФЗ — недопустимость обработки персональных данных без согласия субъекта, в том числе в незашифрованном виде.
• Отсутствие механизма информирования пользователя о трансграничной передаче: в приложении отсутствовал экран с запросом согласия на передачу данных за пределы РФ. Политика конфиденциальности, размещённая в приложении, не содержала сведений о трансграничной передаче.

Этап 2. Анализ исходного кода на предмет безопасности данных

Проведён статический анализ кода (SONARQUBE) и ручной ревью модулей, ответственных за сетевое взаимодействие и хранение данных.

Обнаруженные уязвимости:

• Жёстко закодированный URL сервера (api-medsoft.azurewebsites.net) не был вынесен в конфигурацию, что делало невозможным перенаправление трафика на российские серверы без перекомпиляции приложения.
• Функция отправки данных (sendData()) не имела проверки geoIP — приложение не определяло местоположение сервера перед отправкой.
• В коде была реализована поддержка HTTP-соединений (вопреки рекомендациям безопасности для медицинских приложений), что подтверждало зафиксированный в сетевом трафике факт передачи в открытом виде.
• Отсутствовал механизм шифрования локально хранимых данных (медицинская карта сохранялась в SQLite в открытом виде с разрешениями на чтение для всех приложений (MODE_WORLD_READABLEв ANDROID до API 23) — критическая уязвимость, обнаруженная при внутреннем аудите, но не зафиксированная в судебном экспертном исследовании (так как не была причиной штрафа РКН).

Этап 3. Анализ контракта и технического задания на предмет требований безопасности

Эксперт сопоставил требования п. 8 ТЗ с фактической реализацией.

Результаты сопоставления:

• ТЗ: «локализация на территории РФ» — не выполнено(сервер в Ирландии).
• ТЗ: «шифрование при передаче по каналам связи» — выполнено не в полном объёме(часть трафика передавалась без шифрования).
• ТЗ: «соответствие требованиям законодательства РФ, включая 152-ФЗ» — не выполнено(выявленные нарушения законодательства).

Этап 4. Установление причинной связи между недостатками приложения и понесёнными расходами

Эксперт проанализировал предписание Роскомнадзора и установил, что его требования полностью основаны на выявленных в приложении недостатках. Расходы на доработку приложения (4,5 млн рублей) были связаны с переносом серверной части в РФ, настройкой геомаршрутизации, переработкой модуля информирования пользователя. Штраф в размере 600 тыс. рублей наложен за нарушение требований 152-ФЗ, которое стало возможным именно вследствие недостатков разработанного приложения.

Выводы эксперта 📄

1. Мобильное приложение не соответствует требованиям п. 8 технического задания в части: (а) локализации персональных данных и медицинской информации на территории РФ; (б) обеспечения соответствия требованиям Федерального закона № 152-ФЗ; (в) шифрования всей передаваемой информации.
2. Выявленные нарушения носят производственный характер и не связаны с действиями третьих лиц или эксплуатацией приложения в непредусмотренном режиме.
3. Предписание Роскомнадзора и наложение штрафа находятся в прямой причинно-следственной связи с выявленными недостатками приложения. Расходы истца на доработку приложения и уплату штрафа являются убытками, вызванными ненадлежащим качеством разработанного программного продукта.

Судебное решение ⚖️

Суд признал экспертное заключение полным и обоснованным. Исковые требования удовлетворены: с разработчика взысканы расходы на доработку приложения (4 500 000 рублей), сумма административного штрафа (600 000 рублей), а также судебные расходы. Апелляционная инстанция оставила решение без изменения, отметив высокое качество экспертного анализа.

Глава 8. Типовые вопросы, разрешаемые в рамках компьютерно-технической экспертизы мобильных приложений ❓📋

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

Блок 1. Вопросы о соответствии функциональности и качества 🎯

1. Соответствует ли разработанное мобильное приложение условиям договора (контракта) №____ от ____ и техническому заданию (приложению №____ к договору)? Если нет, то в чём именно выражается несоответствие?
2. Является ли приложение работоспособным, то есть способным выполнять основные функции в типовых условиях эксплуатации без критических сбоев?
3. Представляет ли приложение потребительскую ценность, то есть может ли оно быть использовано по назначению конечными пользователями?
4. Какова степень законченности приложения? Является ли оно финальным (релизным) продуктом или промежуточной (тестовой, альфа/бета) версией?

Блок 2. Вопросы о наличии и природе дефектов 🐛

5. Имеются ли в приложении недостатки, дефекты, ошибки, препятствующие его нормальной работе? Если да, то каков характер этих дефектов (функциональные, производительности, безопасности, юзабилити) и их критичность?
6. Являются ли выявленные недостатки следствием ошибок разработчика (производственный характер), несовместимости с конкретными устройствами (аппаратные ограничения), сторонним вмешательством (вредоносное ПО) или действиями пользователя?
7. Приводят ли выявленные недостатки к критическим сбоям (CRASH, ANR), потере или искажению пользовательских данных, уязвимостям безопасности, нарушению требований законодательства о персональных данных?

Блок 3. Вопросы о влиянии на бизнес-показатели 💰

8. Существует ли причинно-следственная связь между выявленными недостатками приложения и снижением ключевых бизнес-метрик (отток пользователей, снижение конверсии, падение выручки)? Если да, то в чём она выражается?
9. Могли ли выявленные недостатки производительности (долгая загрузка, зависания, сбои) повлиять на удержание пользователей и конверсию в целевые действия? Каков характер этого влияния?

Блок 4. Вопросы о соответствии требованиям безопасности 🔒

10. Соответствует ли приложение требованиям Федерального закона № 152-ФЗ «О персональных данных» (локализация, шифрование, информирование пользователя)?
11. Имеются ли в приложении уязвимости, создающие риск утечки персональных данных или финансовой информации? Если да, то какова степень их критичности?
12. Соответствует ли приложение требованиям APP STORE REVIEW GUIDELINES и GOOGLE PLAY DEVELOPER POLICY для публикации?

Блок 5. Комплексные вопросы 🔗

13. Является ли разработанное приложение качественным программным продуктом, соответствующим требованиям, обычно предъявляемым к такого рода приложениям на рынке (с учётом ГОСТ Р ИСО/МЭК 25010-2015)?
14. Каков объём и стоимость работ, необходимых для устранения выявленных недостатков и доведения приложения до состояния, соответствующего условиям договора и требованиям законодательства?

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

Глава 9. Инструментальная база лаборатории: оборудование и программное обеспечение 🛠️💻

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

Аппаратное обеспечение (физические устройства для тестирования): 📱

Программное обеспечение для статического анализа: 📄

• SonarQube Enterprise— комплексный анализ качества кода (поддерживает Java/Kotlin/Swift/Objective-C). Выявляет более 2000 типов дефектов, включая уязвимости OWASP Top 10.
• Checkmarx— статический анализатор безопасности (SAST), специализируется на поиске уязвимостей в мобильных приложениях (небезопасное хранение данных, некорректная аутентификация, утечки через логи).
• Qark (Quick Android Review Kit)— open-source инструмент для поиска уязвимостей в APK-файлах (без доступа к исходному коду).
• MobSF (Mobile Security Framework)— автоматизированная платформа для статического и динамического анализа ANDROID и iOS-приложений.

Программное обеспечение для динамического тестирования: 🎮

• Appium— фреймворк для автоматизации тестирования мобильных приложений на реальных устройствах и эмуляторах.
• Espresso (Android), XCUITest (iOS)— нативные фреймворки от Google и Apple для UI-тестирования.
• JMeter— нагрузочное тестирование API.
• Charles Proxy / Burp Suite Professional— перехват и анализ HTTPS-трафика (разбор TLS-сессий, подмена сертификатов для MITM-анализа).

Инструменты профилирования и мониторинга: 📊

• Android Studio Profiler(CPU, Memory, Network, Energy) — встроенный инструмент
• Xcode Instruments(Time Profiler, Allocations, Leaks, Energy Log) — для
• Firebase Performance Monitoring— мониторинг производительности в реальных условиях эксплуатации (сбор метрик с устройств пользователей).
• AppMetrica— российская платформа аналитики, позволяющая отслеживать CRASH RATE и USER JOURNEY.

Инструменты криминалистического анализа: 🕵️

• Cellebrite UFED (Universal Forensic Extraction Device)— извлечение данных из мобильных устройств, включая удалённые сообщения, журналы, кэш приложений.
• Magnet AXIOM— анализ образов устройств, восстановление удалённых данных (SQLite records, plist files, keychain).
• XRY (MSAB)— экспертная платформа для извлечения цифровых доказательств.
• Oxygen Forensic Detective— анализ мобильных приложений (мессенджеры, соцсети, почта) на уровне артефактов.

Каждый инструмент имеет сертификат о соответствии требованиям методик судебной экспертизы (где это применимо) и проходит ежегодную калибровку. Результаты, полученные с их использованием, являются воспроизводимыми и могут быть проверены сторонним экспертом. 🔧✅

Глава 10. Дифференциация причин некорректной работы: ошибка разработчика vs несовместимость vs стороннее вмешательство 🔍⚡

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

Признаки ошибок разработчика (производственный характер): 🏭

• Воспроизводимость проблемы на разных устройствах (минимум 3–5 моделях, разных производителях и версиях ОС). Если проблема стабильно воспроизводится на iPhone 7, 12 и 14 Pro — это почти наверняка дефект кода.
• Наличие в коде логических ошибок, необработанных исключений, некорректных типов данных, утечек памяти, подтверждённых статическим анализом.
• Проблема возникает при стандартных пользовательских действиях, описанных в руководстве пользователя.
• Отсутствие проблемы в предыдущей версии приложения (если доступна для сравнения), но появление в новой после изменений кода.
• Журналы ошибок (CRASHLYTICS, FIREBASE) содержат stack trace, указывающий на конкретные строки кода разработчика.

Признаки несовместимости с устройством/ОС: 📱

• Проблема воспроизводится только на одной модели устройства или на одном типе процессора (например, только на Xiaomi с Snapdragon 888, но не на Samsung с тем же чипсетом) — может указывать на проблемы с драйверами конкретного вендора.
• Проблема возникает только на определённой версии ОС (например, на iOS 16.4, но не на 16.5) — может быть вызвана изменением API или багом в самой ОС (такое редко, но встречается).
• Приложение корректно работало на момент выпуска, но перестало после обновления ОС (при этом разработчик не выпускал новых версий) — возможна несовместимость «вперёд».
• Отсутствуют доказательства дефектов в коде (статический анализ не выявил проблем), но проблема возникает на конкретных устройствах в полевых условиях, а в лаборатории на аналогичных устройствах не воспроизводится — возможна уникальная конфигурация окружения.

Признаки стороннего вмешательства (вредоносное ПО, взлом, jailbreak/root): 🦠

• Обнаружение в дампе памяти или файловой системе следов вредоносного ПО (шпионские модули, клавиатурные шпионы, редиректоры трафика).
• Выявление изменений в коде приложения, не соответствующих исходному (наличие «нелегальных» патчей, инъекции кода).
• Несанкционированные сетевые соединения: приложение отправляет данные на неизвестные IP-адреса или домены, не указанные в документации.
• Обнаружение факта наличия ROOT-доступа или JAILBREAK на устройстве (что само по себе не является нарушением, но повышает риск вмешательства).
• В системных журналах присутствуют записи о запуске неизвестных процессов, модификации системных библиотек, попытках перехвата ввода.

Признаки действий пользователя: 👤

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

Практический алгоритм дифференциации (используемый экспертом):

1. Воспроизведение проблемы на тестовых устройствах (не менее 3 разных моделей).
2. Анализ кода(статический) на предмет типовых ошибок.
3. Проверка совместимости— тестирование на разных версиях ОС в изолированной среде (эмуляторы с чистыми образами).
4. Криминалистический анализ устройства (при его наличии) — поиск следов вредоносного ПО, ROOT/JAILBREAK, нестандартных модификаций.
5. Сравнение с эталоном— сопоставление хеш-сумм исполняемых файлов с эталонными (от разработчика).
6. Формулировка вывода с указанием степени достоверности (уровни A, B, C, D) и обоснованием.

В подавляющем большинстве дел (более 85%) экспертиза позволяет однозначно определить природу дефекта. В оставшихся 15% выносится вероятностный вывод (уровень B — «скорее всего, ошибка разработчика») с указанием пределов достоверности. 🧪🔬

Глава 11. Методика оценки влияния дефектов на бизнес-показатели: от технических метрик к финансовым убыткам 📈💰

Для дел, связанных с взысканием убытков (упущенной выгоды) или оценкой репутационного ущерба, необходимо установить не только наличие дефектов, но и их причинно-следственную связь с негативными экономическими последствиями. Ниже представлена методика, разработанная Союзом «Федерация судебных экспертов» и апробированная в судебной практике.

Этап 1. Идентификация ключевых бизнес-метрик (KPI) 🎯

Определяются метрики, на которые могли повлиять технические дефекты приложения:

• Количество активных пользователей(DAU — daily active users, MAU — monthly active users).
• Конверсия(CR — conversion rate) — процент пользователей, выполнивших целевое действие (оформление заказа, регистрация, оплата).
• Удержание(retention rate) — процент пользователей, вернувшихся в приложение на следующий день (D1), через 7 дней (D7), через 30 дней (D30).
• Отток(churn rate) — процент пользователей, прекративших использование приложения за период.
• Средний чек(AOV — average order value) и частота покупок (purchase frequency).
• LTV(lifetime value) — совокупная прибыль от одного пользователя за всё время использования.
• Показатель отказов(bounce rate) — процент сессий, завершившихся на первом экране без целевого действия.

Этап 2. Сбор данных о технических дефектах и их корреляция с бизнес-метриками 📊

Из данных аналитики (Firebase, AppMetrica, собственные логи приложения) извлекаются:

• Временные ряды CRASH RATE, ANR RATE.
• Распределение времени отклика (response time) по экранам.
• Воронка конверсии (funnel) — на каком этапе пользователи «отваливаются».

Проводится корреляционный анализ (коэффициент Пирсона или Спирмена в зависимости от распределения) между техническими метриками и бизнес-KPI. Примеры интерпретации:

• Сильная отрицательная корреляция(r < -0,7) между CRASH RATE и retention rate: с высокой вероятностью сбои являются причиной оттока пользователей.
• Сильная положительная корреляция(r > 0,7) между временем загрузки экрана и bounce rate: медленная загрузка заставляет пользователей уходить.

Этап 3. Построение контрфактической модели («что было бы, если дефектов не было») 🧮

Используя данные за период до появления дефектов (если доступны) или отраслевые бенчмарки (средние показатели для аналогичных приложений), строится прогнозная модель.

Методы прогнозирования:

• Временные ряды(ARIMA, экспоненциальное сглаживание) — для краткосрочных периодов (1–3 месяца).
• Регрессионные модели(линейная регрессия, random forest) — для учёта влияния нескольких факторов.
• Сравнение с контрольной группой— если есть возможность сравнить показатели приложения с приложениями-аналогами в тот же период.

Этап 4. Расчёт упущенной выгоды 💸

Формула расчёта (базовая):

Упущенная выгода = (Ожидаемый показатель — Фактический показатель) × Вклад показателя в выручку

Пример для интернет-магазина:

• Фактическое количество заказов в месяц: 10 000
• Ожидаемое количество заказов (прогноз без дефектов): 17 000
• Разница: 7 000 заказов
• Средний чек: 1 500 рублей
• Упущенная выручка за месяц: 7 000 × 1 500 = 10 500 000 рублей
• За 6 месяцев: 63 000 000 рублей

Этап 5. Корректировка на иные факторы (уменьшение ответственности разработчика) ⚖️

Суд может уменьшить размер взыскиваемых убытков, если:

• Влияние дефектов было не единственной причиной снижения показателей (например, был сезонный спад спроса, действия конкурентов, маркетинговые ошибки заказчика).
• Заказчик не принял разумных мер для минимизации убытков (например, не внёс временные исправления в приложение).
• Часть дефектов была вызвана действиями самого заказчика (например, предоставление некорректного технического задания).

Эксперт в своём заключении должен указать пределы достоверности расчётов и возможные корректировки, оставляя окончательное решение суду. Компьютерно-техническая экспертиза мобильных приложений в части финансового анализа является не точной наукой (как, например, дактилоскопия), а вероятностной оценкой, основанной на статистических методах. Мы всегда указываем доверительный интервал (обычно 95%) и нижнюю/верхнюю границы оценки. 📉📊

Глава 12. Соответствие требованиям магазинов приложений (App Store, Google Play) как критерий качества 🛍️📱

Публикация мобильного приложения в APP STORE и GOOGLE PLAY сопряжена с соблюдением многочисленных требований, нарушение которых может привести к отклонению приложения при модерации или его удалению после публикации. Несоблюдение этих требований может рассматриваться как недостаток качества приложения в рамках договора разработки, если заказчик прямо указывал на необходимость публикации в магазинах.

Основные требования APP STORE REVIEW GUIDELINES (выдержки): 🍎

1. Безопасность (Safety)— приложение не должно содержать вредоносного кода, не должно запрашивать избыточные разрешения, должно корректно обрабатывать персональные данные.
2. Производительность (Performance)— приложение должно завершать загрузку в течение разумного времени, не должно «падать» (crash rate < 1% для утверждённых приложений).
3. Бизнес (Business)— если приложение принимает платежи за цифровые товары/услуги, оно обязано использовать In-App Purchase (IAP) Apple, а не сторонние платёжные системы (за исключением реальных товаров/услуг).
4. Дизайн (Design)— интерфейс должен соответствовать Human Interface Guidelines (HIG), иконка приложения — требованиям к разрешению и формату.
5. Юридические аспекты (Legal)— приложение должно иметь политику конфиденциальности, не нарушать авторские права третьих лиц, не содержать запрещённый контент.

Основные требования GOOGLE PLAY DEVELOPER POLICY: 🤖

1. Программы-вымогатели (Malware)— приложения не должны содержать вредоносный код, включая код для получения root-доступа без согласия пользователя.
2. Разрешения (Permissions)— запрос разрешений должен быть необходимым для заявленной функциональности. Запрос SMS, CALL_LOG, PHONE в несоответствующих категориях запрещён.
3. Пользовательские данные— приложение должно раскрывать в политике конфиденциальности, какие данные собираются и с какой целью. Запрещена продажа персональных данных третьим лицам без явного согласия.
4. Реклама— запрещена вводящая в заблуждение реклама, реклама, имитирующая системные уведомления.
5. Семейная программа(если приложение предназначено для детей) — особые требования к обработке данных, отсутствию поведенческой рекламы, parental gate (проверка возраста).

Что выявляет экспертиза в части соответствия требованиям магазинов: 🔍

• Нарушение требований к использованию IAP (например, обход комиссии Apple путём приёма платежей через веб-вью с платёжной формой) — чревато блокировкой приложения.
• Отсутствие или некорректная политика конфиденциальности (не указано, какие данные собираются, не указано трансграничной передаче) — основание для отклонения.
• Наличие функционала, запрещённого политиками (например, скрытый сбор геолокации без явного согласия).
• Использование устаревших API, которые будут запрещены в будущих версиях ОС (например, ANDROID 14 запретил запуск служб в фоне для большинства приложений) — предупреждение о будущей несовместимости.

Юридическое значение: Если договором разработки прямо предусмотрена публикация в магазинах приложений, то несоответствие требованиям магазинов, выявленное при модерации, является основанием для признания приложения некачественным. Эксперт может также оценить, могли ли дефекты приложения быть причиной отклонения (например, недостаточная производительность, частые сбои). 🚦✅

Глава 13. Процессуальные аспекты: изъятие, обеспечение сохранности и исследование мобильных устройств 📱🔒

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

Этап 1. Изъятие мобильного устройства (следственные действия) 👮

Основные правила (основаны на рекомендациях SWGDE):

1. Изоляция от сети— устройство помещается в режим «полёт» (airplane mode) либо в экранирующий контейнер (FARADAY BAG) для предотвращения удалённой блокировки, сброса данных или дистанционного wipe.
2. Фиксация состояния— фотографируется внешний вид устройства, экран блокировки (если активен), отображаемое время, уровень заряда батареи.
3. Отключение биометрии— если возможно, устройство блокируется паролем/PIN-кодом (биометрические данные (FaceID, TouchID) могут быть использованы принудительно без согласия владельца, что нарушает право на неприкосновенность частной жизни в ряде юрисдикций).
4. Извлечение SIM-карты и карты памяти— отдельно упаковываются, фиксируются идентификаторы.
5. Транспортировка— в экранирующем контейнере для предотвращения связи с сотовыми вышками.

Этап 2. Преодоление блокировки экрана (при необходимости) 🔓

Если устройство заблокировано паролем/PIN-кодом, а владелец отказывается его предоставить, вопрос решается в процессуальном порядке (ст. 9 УПК РФ — принудительное получение образцов для сравнительного исследования? или ст. 13 Закона об ОРД?). Эксперт не осуществляет взлом (это компетенция правоохранительных органов, использующих специализированное оборудование: Cellebrite UFED, GrayKey, IP Box и т.п.). Однако при проведении судебной экспертизы по назначению суда мы имеем право запросить у владельца пароль, а в случае отказа — суд может применить санкции (ст. 79 ГПК РФ — разъяснение последствий уклонения от экспертизы).

Этап 3. Создание криминалистической копии (logical extraction / physical extraction) 💾

• Логическое извлечение (logical extraction)— копирование файловой системы через штатные интерфейсы (ADB для ANDROID, iTunes backup для iOS). Не позволяет получить удалённые данные, но безопасно (не изменяет состояние устройства).
• Физическое извлечение (physical extraction)— прямое чтение чипа памяти (NAND) через JTAG, ISP (In-System Programming) или Chip-Off (выпайка чипа). Позволяет восстановить удалённые данные, но требует специального оборудования и может повредить устройство. Применяется только с разрешения суда и при наличии веских оснований.

Этап 4. Анализ в изолированной среде 🔬

Полученная копия (образ) исследуется на специализированной рабочей станции (FRED — Forensic Recovery of Evidence Device), изолированной от сети. Используются программные комплексы:

• Cellebrite UFED— извлечение данных, анализ приложений (WhatsApp, Telegram, Viber, Signal, Instagram, VK, Facebook Messenger), восстановление удалённых сообщений.
• Magnet AXIOM— анализ артефактов, построение временных шкал, поиск по ключевым словам.
• Oxygen Forensic Detective— работа с российскими приложениями (ВКонтакте, Одноклассники, ТамТам, Звонок ru).

Этап 5. Обеспечение CHAIN OF CUSTODY 🔗

Каждое действие (изъятие, упаковка, транспортировка, вскрытие, создание образа, анализ) фиксируется в журнале с указанием времени, лица, проводившего операцию, и контрольных сумм (SHA-256). Нарушение цепочки хранения является основанием для исключения доказательств.

Особые случаи: корпоративные устройства (BYOD — Bring Your Own Device) 🏢

Если мобильное приложение использовалось на личном устройстве сотрудника, изъятие такого устройства может нарушать право на частную жизнь. В таких случаях предпочтительно извлечение данных путём создания копии приложения и его данных без изъятия всего телефона (т.н. «целевое извлечение»). Эксперт должен учитывать этот аспект и, при необходимости, делать оговорку в заключении о возможной неполноте данных. 📜⚖️

Глава 14. Типовые ошибки заказчиков при постановке задач и как их избежать ❌🛑

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

Ошибка 1. Постановка слишком общих (неконкретных) вопросов 🟡

Пример: «Определить, является ли мобильное приложение качественным?»

Проблема: понятие «качественный» субъективно. Эксперт не может дать однозначный ответ без привязки к конкретным критериям (договор, ТЗ, стандарты).

Как исправить: разбить на подвопросы: «Соответствует ли приложение функциональным требованиям, изложенным в п. 2.1–2.20 технического задания?», «Имеются ли в приложении дефекты, препятствующие его нормальной работе?», «Соответствует ли приложение требованиям, обычно предъявляемым к такого рода программным продуктам согласно ГОСТ Р ИСО/МЭК 25010-2015?».

Ошибка 2. Смешение юридических и технических аспектов 🟡

Пример: «Является ли ответчик виновным в некачественной разработке приложения?»

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

Как исправить: «Являются ли выявленные недостатки приложения следствием ошибок, допущенных разработчиком при написании программного кода?».

Ошибка 3. Отсутствие привязки к договору и ТЗ 🟡

Пример: «Оценить производительность приложения».

Проблема: без указания нормативных значений (из ТЗ, отраслевых стандартов) эксперт может дать оценку «в вакууме», которая не будет иметь юридической силы.

Как исправить: «Соответствует ли приложение требованиям к производительности, указанным в разделе 5 технического задания: время загрузки каталога не более 2 секунд, время отклика интерфейса не более 300 мс?».

Ошибка 4. Непредоставление необходимых материалов 🟡

Пример: Заказчик предоставляет только установочный APK-файл, но не предоставляет исходный код и техническое задание.

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

Как исправить: предоставить полный комплект: исходный код (если есть), техническую документацию, журналы ошибок, данные аналитики, тестовые устройства (или доступ к ним), описание проблем со стороны пользователей.

Ошибка 5. Запрос выводов о причинённом ущербе без экономического обоснования 🟡

Пример: «Определить убытки истца, вызванные недостатками приложения».

Проблема: эксперт не является оценщиком или бухгалтером, если у него нет соответствующей квалификации. Без предоставления финансовых документов (отчёты о прибылях и убытках, маркетинговые планы, данные аналитики) такой вывод невозможен.

Как исправить: привлечь к экспертизе второго эксперта (экономиста) либо поставить вопрос о предоставлении эксперту данных для расчёта, а не о самом расчёте. Либо использовать нашу комплексную экспертизу с привлечением специалистов по финансовому анализу.

Ошибка 6. Нереалистичные сроки ⏰

Пример: «Провести экспертизу за 3 дня».

Реальность: типовое исследование мобильного приложения средней сложности занимает 10–14 рабочих дней (установка окружения, тестирование, анализ, написание заключения). Срочные экспертизы (3–5 дней) возможны, но их стоимость увеличивается в 2–3 раза, а качество может снизиться из-за ограниченного времени на глубокий анализ.

Совет заказчикам: при планировании судебного разбирательства закладывайте минимум 3–4 недели на проведение экспертизы. Это позволит эксперту выполнить работу качественно, без спешки. Если дело срочное — свяжитесь с нами заранее, чтобы мы могли забронировать время специалистов. 📅🤝

Глава 15. Заключение: ценность независимого экспертного подхода и приглашение к сотрудничеству 🌟🤝

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

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

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

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

Союз «Федерация судебных экспертов» обладает многолетним опытом в данной области, аккредитованным оборудованием и программным обеспечением, а также штатом экспертов высшей квалификации (средний стаж — 12 лет). Мы выполнили более 200 экспертиз мобильных приложений, участвовали в десятках судебных процессов в арбитражных судах, судах общей юрисдикции, а также в уголовном судопроизводстве. Наши заключения признаются допустимыми и достоверными доказательствами, а эксперты — компетентными специалистами.

Если вы столкнулись с необходимостью судебного или досудебного исследования качества мобильного приложения, установления причин критических сбоев, оценки ущерба от ненадлежащей разработки — обращайтесь к нам. Мы проведём предварительную консультацию (до 1 часа) бесплатно, оценим перспективы дела, поможем сформулировать вопросы для эксперта и определим оптимальный объём исследований.

Посетите наш официальный сайт, где вы найдёте:

• Подробное описание услуг по экспертизе мобильных приложений.
• Примеры экспертных заключений (с удалением персональных и коммерческих данных).
• Реестр аттестованных экспертов с их специализациями.
• Бланки заявок и договоров.
• Рекомендации по подготовке материалов для экспертизы.
• Отзывы клиентов и судебные акты (в открытой части).

🌐 https://krimexpert.ru/ekspertiza-kachestva-razrabotki-mobilnyh-prilozhenij/

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

Доверьте качество своего приложения профессионалам — мы докажем правду в цифрах и коде. 📱⚖️💯