Summary

  • UUID и хеш могут связать производную VCON с менее отредактированным предшественником, а JSON Pointer — назвать изменённое место. Но удаление элемента, изменение схемы или неразрешимый указатель разрывают смысл квитанции.
  • Подпись доказывает, кто закрепил данные производной версии и что байты не изменились. Она не доказывает полноту обнаружения, истинность замены или допустимость последующего действия.
  • Для высокорискового потребителя нужен отдельный проверяемый документ о преобразовании с правилом fail closed. Это операционный вывод данной статьи, а не уже стандартизированное требование draft-rosenberg-vcon-redaction-00.

Происхождение ломается не только при подделке хеша

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

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

draft-rosenberg-vcon-redaction-00, опубликованный 29 сентября 2026 года, позволяет увидеть более широкий класс таких разрывов. Это индивидуальный Internet-Draft с предполагаемым статусом Informational, материал для обсуждения сценариев и требований. Он не является RFC, не принят рабочей группой VCON, не выражает консенсус IETF и не подтверждает промышленное внедрение.

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

Что уже даёт VCON core

В редакции 04 VCON core объект redacted должен ссылаться по UUID на исходную или менее отредактированную версию. Он может содержать закрытый URL и хеш контента; при наличии URL хеш обязателен. Создателю производной версии следует подписать её. Если элемент массива удаляется целиком, рекомендуется оставить пустой заполнитель, чтобы последующие индексы не сдвигались.

Это хорошая основа. UUID задаёт родство версий. Хеш фиксирует внешние байты. Подпись указывает автора заявления. Заполнитель сохраняет позиционные ссылки.

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

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

Пять преобразований и пять разных потерь

Удаление целого dialog-объекта хорошо скрывает содержимое, но вместе с идентификатором может стереть жалобу клиента, роль реплики и связь со следующим решением. Без заполнителя индексы смещаются; с заполнителем остаётся сигнал о позиции.

Сохранение оболочки оставляет участника, начало, длительность и индекс. Хронология выживает, смысл смешанной реплики — нет. Если защищается свидетель, метаданные оболочки могут выдать его.

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

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

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

Квитанция должна переживать проверку адреса

Для действий с последствиями эта статья предлагает отдельную подписанную квитанцию преобразования. Это операционная конструкция Daniel Kade, а не установленный формат редакции 00. Квитанция фиксирует идентификаторы и обязательства исходной и производной VCON, версию и цель политики, точные машинные адреса и тип либо смысловой класс данных до изменения.

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

Критическое поле — результат разрешения каждого адреса. RFC 6901 определяет JSON Pointer, но оставляет приложению поведение при ошибке. Неразрешимый путь или несовпадающий тип должны закрывать использование, а не уменьшать счётчик предупреждений. RFC 7515 позволяет подписать заявление, RFC 8785 — повторяемо канонизировать JSON. Они не доказывают, что были найдены все чувствительные места.

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

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

Связанный проект о проверяемых разговорах агентов подчёркивает: подпись определяет подписанта, но не гарантирует правдивость. Runtime, регистратор, хранилище, проверяющий и принимающий решение образуют разные границы доверия. По модели reality layers Lu Heng источник, представление приватности, заявление преобразователя и последующее действие остаются разными реальностями. Связь не даёт им общей власти.

Источники и ограничения

Редакция 00 — ранний дискуссионный текст с открытыми вопросами. Здесь не оцениваются конкретные контакт-центры, поставщики моделей, продукты редактирования или реализации VCON. Статья не устанавливает юридическое соответствие метода в отдельной юрисдикции. Статья 5 GDPR и NIST SP 800-122 дают контекст для минимизации, точности и защиты, но не утверждают предложенную квитанцию.