Редакция 3 от 14.10.2026. Номер редакции печатается в разделе 1 каждого протокола, выданного после этой даты. Здесь описано только то, что система делает сейчас; изменения практик выходят новой редакцией с датой.
Документ по пункту 5 статьи 78 ГПК РК: снимок и исходный код интернет-страницы (письма, переписки, публикации) на момент фиксации, сведения о способе фиксации и технические подтверждения неизменности. Оценку доказательства даёт суд; eFix удостоверяет только неизменность файла и способ его получения.
Часы сервера сверяются с эталонным сервером точного времени (NTP) перед фиксацией; смещение печатается в протоколе. Без сверки протокол не называет сервер времени.
На итоговый файл протокола запрашивается квитанция RFC 3161 государственной службы меток времени НУЦ РК (tsp.pki.gov.kz); при её недоступности — квитанция стороннего TSA, и протокол называет, чья она.
Квитанция OpenTimestamps (блокчейн Bitcoin) запрашивается на тот же файл.
С 10.10.2026 квитанция НУЦ РК вкладывается и в саму электронную подпись.
SHA-256, SHA-512, MD5 и SHA3-256 итогового PDF; SHA-256 каждого файла архива — в реестре файлов протокола и в manifest.json. Все суммы печатаются целиком.
Подпись ГОСТ (СТ РК ГОСТ Р 34.10-2015) ключом НУЦ РК через KalkanCrypt: внутри PDF (PAdES), отдельным файлом protocol.pdf.cms и присоединённой protocol.cms (для ezsigner.kz и SIGEX).
Если служба меток времени не ответила, подпись не ставится, и протокол выдаётся с прямым указанием «не подписан» — подписать без квитанции молча система не может.
С 11.10.2026 те же итоговые байты протокола дополнительно подписываются постквантовым алгоритмом ML-DSA-65 (FIPS 204): файл protocol.pdf.mldsa.p7s и сертификат eFix efix-mldsa65.pem. Это техническая страховка неизменности файла, а не замена ЭЦП; сертификаты ключа публикуются на ленте прозрачности и не удаляются после смены ключа; проверка — OpenSSL 3.5 и новее.
Хеш каждого готового протокола попадает в хеш-цепочку; не реже раза в сутки корень цепочки публикуется на ленте прозрачности с квитанциями НУЦ РК и OpenTimestamps.
Над реестром выпускаются архивные метки (ETSI TS 119 511): первая — после первого заверённого корня, далее раз в квартал и досрочно при смене ключа подписанта или за год до истечения сертификатов. Evidence record каждого протокола и внешний монитор ленты доступны любой третьей стороне; проверка — без участия eFix (tools/verify_ledger.py, tools/verify_evidence_record.py, tools/monitor_transparency.py).
Постквантовых квитанций времени службы пока не выпускают; когда появится служба меток с подписью ML-DSA или другим алгоритмом FIPS 204/205, очередная архивная метка будет выпущена ею досрочно и накроет всю прежнюю цепочку, прежние квитанции сохраняются.
Код сервера выкладывается только из коммита git; реестр выпуска (SHA-256 каждого файла) заверяется подписью, меткой НУЦ РК и OpenTimestamps и хранится в журнале выпусков.
При каждой фиксации сервер сверяет свой код с реестром и печатает итог в разделе 1 протокола; расхождение печатается открыто. Код расширения браузера присылает отпечаток своих файлов, он сверяется с опубликованной сборкой.
Архив протокола хранится 5 лет с момента создания (срок печатается на странице проверки); продление — по тарифу. Дело под удержанием (legal hold) по сроку хранения не очищается.
Доступ к протоколу — только владелец аккаунта и администратор; вход администратора защищён вторым фактором; смена пароля обрывает все сеансы и ключи API.
Cookies заявителя, переданные для авторизованной съёмки, используются только для этой фиксации и в архив не попадают.
Выданный протокол не изменяется: корректировка — новый протокол, прежний отзывается с указанием действующей редакции; служебные материалы (evidence record, досье, выписки) хранятся вне папки протокола.
Резервные копии: отдельный сервис резервного копирования на той же площадке.
Протокол называет способ, которым ФАКТИЧЕСКИ получен снимок: серверный браузер eFix по адресу; серверный браузер с сеансом (cookies) заявителя, переданным расширением с его согласия; браузер заявителя через отладочный протокол (Chrome DevTools Protocol); браузер заявителя снимками видимой области окна с прокруткой и склейкой на сервере. Заявление расширения сервер сверяет с тем, что реально прислано.
Если политика управляемого браузера организации заявителя запрещает расширению отладочный доступ или снимки экрана (Chrome 155 и новее), расширение переходит на путь, который политика не запрещает, и протокол называет причину. Правила защиты от утечек (DLP) eFix не обходит: на защищённой ими странице фиксация не выполняется. Памятка для ИТ-отделов — efix.kz/it-admin.
Снимок проверяется заслоном качества (заполненность, высота, признаки стены логина); брак не выдаётся как протокол. Длительность фиксации и доля успеха измеряются по базе и видны администратору (p50/p90).
Материалы, сформированные языковой моделью (досье, фильтр оповещений мониторинга), помечаются «создано ИИ», снабжаются паспортом (модель, география инференса, хеши промпта и ответа) и не являются частью протокола; персональные данные перед отправкой модели заменяются токенами; каждое утверждение досье сопровождается дословной цитатой из зафиксированного материала.
Контакт для сообщений об уязвимостях — /.well-known/security.txt (RFC 9116).
Как проверить протокол без eFix — отдельная страница; лента прозрачности — здесь.