Судебная экспертиза исходного кода на JavaScript

Спор с подрядчиком об интернет-магазине, личном кабинете или портале часто сводится к соответствию результата техническому заданию: что заказали, что передали и можно ли это принять. В проектах на JavaScript один язык может использоваться в двух средах — в браузере посетителя и на сервере под управлением Node.js. Браузер получает доступные ему файлы приложения, поэтому их копию можно сохранить до обращения в суд; исходные тексты при этом могут остаться у разработчика. Серверная часть доступна лишь тому, у кого есть законные полномочия и технический доступ. Экспертиза исходного кода на JavaScript — специализированное направление экспертизы процесса разработки программного обеспечения. Форма результата зависит от процедуры: судебный эксперт готовит заключение по назначению уполномоченного органа, а при внесудебном исследовании заказчик получает документ специалиста, который можно представить суду.

Если спор уже начался, сохраните то, что исчезает первым. Браузерную часть зафиксируйте как можно скорее: она меняется при обновлении сайта, а прежние сборки могут не сохраниться. Как снять копию и оценить её доказательственное значение — ниже, в разделе «Что сохранить прямо сейчас». Не переписывайте историю зафиксированных изменений в репозитории, не удаляйте ветки и метки и не переустанавливайте пакеты на спорной площадке до её фиксации.

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

Какие споры разбираем

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

Чаще всего это такие ситуации:

• подрядчик сдал интернет-магазин, личный кабинет или портал на React, Vue или Angular, а вы считаете, что предусмотренное техническим заданием не выполнено;
• стороны спорят, какие требования реализованы, какие выполнены иначе, а какие не работают в описанных условиях;
• интерфейс ломается в конкретном браузере или на мобильном устройстве, и это приводится как довод о несоответствии;
• в корзине, счёте или отчёте расходятся суммы — копейки на позицию, заметные деньги на обороте;
• серверная часть на Node.js падает под нагрузкой или теряет данные при обмене с платёжной, учётной или партнёрской системой;
• фоновые задачи не отработали: письма не ушли, заказы не выгрузились, статусы разошлись;
• подрядчик ушёл, а из переданного комплекта нельзя собрать приложение либо комплект неполон;
• нужно проверить, не использован ли чужой код и на каких условиях подключены пакеты из открытых хранилищ.

Если ваш вопрос звучит иначе, точнее начать с соседнего исследования: о качестве кода — экспертиза качества исходного кода, о заимствовании — сравнение исходного кода, о деньгах и объёме — экспертиза объёма и стоимости выполненных работ. Если спорная система написана на другом языке, смотрите экспертизу кода на Java или на Python.

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

Чем это отличается от экспертизы сайта

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

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

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

Две среды исполнения — и два разных объекта

Это и есть главное отличие. Браузерная и серверная части живут по разным правилам, и материалы для них собирают по-разному.

Разница проявляется в трёх вещах:

• Доступность кода. Сайт отдаёт браузеру клиентские файлы: их можно сохранить вместе с адресом, датой и контрольной суммой. Серверную часть на Node.js исследуют только при законном основании и предоставленном доступе.
• Воспроизводимость. Серверное приложение проверяют на контролируемом стенде с зафиксированным окружением. Поведение в браузере зависит от устройства, версии браузера, расширений и настроек посетителя, поэтому сообщение «не работает» проверяют в названных условиях и фиксируют их.
• Следы. Серверные журналы существуют лишь при настроенном протоколировании и могут быть неполными. В браузере остаются текущие данные консоли и сети, а исторические сведения доступны, если заранее была подключена служба сбора ошибок вроде Sentry. Поэтому выводы о клиентской части сопоставляют с кодом, воспроизведением и сохранившимися записями.

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

Сборка, минификация и карты исходного кода

В рабочей версии браузер обычно получает не те файлы, которые редактировал разработчик. Исходные тексты проходят через Webpack, Vite, esbuild или другой инструмент: он собирает модули, преобразует код, а при включённой минификации сокращает имена и удаляет лишние пробелы. Результат называют бандлом. Он должен сохранять предусмотренное поведение программы, но ошибки и различия настроек сборки могут его изменить.

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

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

Ссылку на карту ищут рядом со сборкой, в служебной пометке самого файла и в HTTP-заголовке ответа. Представленную карту не принимают на веру: её сопоставляют со сборкой по отображению позиций и объявленным именам файлов, а для обоих объектов фиксируют адрес, дату получения и контрольные суммы. Минификация делает файл компактнее; карта не обращает это преобразование, а связывает полученный код с указанными исходниками. Обфускация намеренно затрудняет чтение: строки могут кодироваться, поток управления — усложняться, а имена — заменяться. Степень такого преобразования фиксируют как обстоятельство, влияющее на определённость выводов. Если карты нет, исследуют сам бандл: в зависимости от способа сборки в нём можно выявить модули, признаки библиотек и исполняемую логику, но нельзя автоматически восстановить авторское оформление и имена. Наличие, вид и происхождение карты указывают отдельно.

Что может установить эксперт

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

При достаточных материалах вы получите ответ о следующем:

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

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

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

Как проверяют соответствие техническому заданию

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

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

• Не реализовано — в полном исследованном контуре не выявлен механизм, который обеспечивает выполнение требования в коде, настройках, зависимостях или связанных компонентах, а проверка не подтверждает требуемого поведения. Такой вывод делают только после оценки полноты объекта; одной браузерной копии для этого недостаточно. Приложение может подгружать части по мере надобности, а у каркасов вроде Next.js и Nuxt часть логики исполняется на сервере. Пока эти части системы не проверены, результат относят к четвёртому исходу.
• Реализовано иначе — механизм есть, но работает не так: другой сценарий, другой состав полей, другое поведение при ошибке.
• Реализовано, но не работает в описанных условиях — для браузерной части это один из распространённых исходов: функция работает в одном браузере и отказывает в другом, на телефоне или при медленной сети; значение имеет то, были ли эти условия заданы.
• Проверить на представленных объектах невозможно — критерий есть, а объекта нет: не передана серверная часть, не сохранена сборка спорного периода, утрачены журналы за нужные даты. Это самостоятельный исход, а не разновидность первого: отсутствие материала не равно отсутствию кода, и эксперт называет, чего именно не хватило для ответа.

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

Если передан только собранный бандл

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

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

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

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

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

Какие объекты исследуются

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

Код, сборка и опубликованное приложение

Эти материалы собирают вместе: по отдельности они отвечают на меньшее число вопросов, а сопоставление исходных текстов с тем, что отдаётся посетителю, и есть основная проверка.

В группу входят:

• зеркальная копия каждого репозитория со всеми доступными ветками, метками и достижимой историей изменений, а при споре о переписывании истории — дополнительные серверные журналы или согласованный снимок хранилища;
• исходные тексты на JavaScript или TypeScript, файлы сборщика и настройки компиляции;
• описание зависимостей package.json и файл блокировки — package-lock.json, yarn.lock или pnpm-lock.yaml, — описывающий разрешённое дерево пакетов; фактически установленный состав проверяют отдельно;
• сохранённая браузерная сборка спорного периода вместе с картами исходного кода, если они публиковались;
• версия Node.js, образы контейнеров, установочные комплекты и их контрольные суммы.

Настройки, данные и следы работы

Вторая группа помогает установить, почему одна и та же версия ведёт себя по-разному и что происходило с данными.

В неё входят:

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

Отчёты и измерения другой стороны рассматривают как объекты с проверяемым происхождением. Текущие показатели по возможности получают повторно на переданной копии и описывают условия измерения; результаты нового опыта не подменяют исторические данные о спорном периоде.

Что сохранить прямо сейчас

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

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

Порядок такой:

• на согласованной копии пройдите спорные сценарии — каталог, корзину, шаги оформления заказа до подтверждения, свой личный кабинет. На рабочей системе ограничьтесь разрешёнными действиями и учитывайте, что даже корзина или вход могут создать серверные записи. Настоящий заказ не оформляйте;
• сохраните страницы, сетевой журнал с ответами и заголовками, снимки экрана, загруженные файлы сборки и карты исходного кода; способ фиксации и состав полученных объектов опишите;
• для каждого файла запишите адрес, дату и время с часовым поясом и посчитайте контрольную сумму — строку, по которой позднее проверяют соответствие файла записанному значению. Сама по себе она не удостоверяет дату и источник получения. В Windows используют команду Get-FileHash в PowerShell, на macOS и Linux — shasum -a 256 в терминале; результат сохраните рядом с файлом;
• сложите всё в один архив, сохраните его без изменений, а для просмотра используйте рабочую копию.

Самостоятельно снятая копия требует проверки происхождения: вторая сторона может оспорить способ и время получения или заявить об изменении файлов. Это не делает копию бесполезной, но снижает определённость выводов. Если спорная сборка — ключевой объект, фиксацию поручают специалисту, который описывает порядок, время и условия получения, — это фиксация содержимого интернет-страниц. Возможность нотариального обеспечения доказательств зависит от обстоятельств и процедуры; после возбуждения дела доступно также обеспечение доказательств судом. Браузерную часть мы можем зафиксировать по вашему поручению до назначения судебной экспертизы; после назначения объекты предоставляют через назначивший орган.

Остальное требует доступа и полномочий, а часть действий сама меняет спорную систему:

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

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

Как передать материалы и не раскрыть лишнего

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

К передаче подготовьте:

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

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

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

Как проводится исследование

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

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

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

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

Примеры вопросов на экспертизу

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

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

1. Каковы состав и структура представленного приложения: модули, использованные каркасы и библиотеки с версиями, точки обмена с другими системами?
2. Выполнено ли в представленной версии приложения требование, описанное в указанном пункте технического задания, и в каком объёме?
3. Достаточен ли переданный комплект исходных текстов, настроек и документации для самостоятельной сборки и запуска приложения, и чего в нём не хватает?
4. Соответствует ли представленная браузерная сборка, снятая по указанному адресу и в указанную дату, представленным исходным текстам, и какие расхождения обнаруживаются?
5. Имеются ли в представленных материалах карты исходного кода, соответствуют ли они представленной сборке и в каком объёме позволяют восстановить её исходные тексты?
6. Каков результат обработки указанных исходных данных представленной версией приложения и соответствует ли он результату, зафиксированному в указанном документе?
7. Воспроизводится ли описанная ошибка в представленной версии приложения при указанном сценарии, в указанном браузере и на указанном устройстве?
8. Какие технические причины отказа серверной части в указанный период подтверждаются представленными журналами и записями об ошибках?
9. Отражено ли в представленных источниках прохождение указанных заказов между системами и, если обработка прекратилась, на каком этапе это произошло?
10. Имеются ли в исходных текстах двух представленных приложений совпадающие фрагменты, каковы их объём и характер с отдельным учётом сторонних пакетов, сгенерированного кода и обязательных конструкций каркаса?

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

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

Форматы работы и результат

В документе по коду на JavaScript одного названия репозитория недостаточно. Указывают адрес, дату и время получения каждой браузерной сборки, её контрольную сумму, наличие и вид карт исходного кода, версии сборщика и Node.js, а для ошибки интерфейса — браузер, устройство и сценарий проверки. Затем описывают методы, выполненные действия, полученные данные, проверенные версии причин, ограничения и ответы на вопросы. Таблицы сравнения и снимки экранов приводят так, чтобы другой специалист мог повторить проверку. Заранее установленной силы у документа нет: суд оценивает его вместе с другими доказательствами.

Формат выбирают по стадии спора:

• Консультация или справка — письменный ответ специалиста по существу вопроса. В отличие от предварительного разбора, это платная работа. В ответе указывают, что можно установить по имеющимся материалам, каких источников не хватает и насколько определённым может быть вывод.
• Внесудебное исследование проводится по договору со стороной по согласованным техническим вопросам.
• Судебная экспертиза выполняется по определению суда либо постановлению следователя, дознавателя или иного уполномоченного законом лица.
• Рецензия проверяет уже готовое заключение — объекты, методы, ограничения и связь результатов с выводами; подробнее на странице рецензирования экспертизы разработки ПО.

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

От чего зависят стоимость и срок

Стоимость и срок зависят прежде всего от трёх обстоятельств. Первое — сколько сред исполнения входит в спор: исследование только браузерной части отличается от исследования связки «браузер плюс Node.js», где сопоставляют данные клиентской и серверной частей. Второе — в каком виде сохранился код: бандл без карт требует отдельного разбора, а обфускация увеличивает объём работы. Третье — сколько условий нужно воспроизвести: каждый указанный браузер, устройство и сценарий проверяют отдельно, поэтому десять сочетаний требуют больше времени, чем одно. Учитываются также зафиксированные версии пакетов, сохранность журналов, число вопросов и необходимость смежных специалистов. Ориентировочная стоимость судебной экспертизы — от 100 000 ₽, срок — от 10 рабочих дней; точные условия определяются после просмотра материалов.

При первом обращении опишите спор, наметьте вопросы и перечислите, что у вас есть. Небольшие доступные копии можно приложить сразу, если вы вправе передать их через форму. Позвоните по номеру 8 (800) 333-24-09 или оставьте заявку — мы проверим, относится ли задача к нашей компетенции, предложим безопасный порядок передачи материалов и скажем, каких данных не хватает для расчёта.