Кратко

  • Индивидуальный проект от 27 октября предлагает опечатывать каждую редакцию условий и политик сервиса записью с названием документа, номером версии, URL и SHA-256 обычного текста. Старый файл должен оставаться доступным по этому адресу.
  • Ключи компаний и агентов привязываются к домену, история ключей сохраняется, а наблюдатели независимо хранят подписанные контрольные точки дерева Меркла. Так можно проверить автора и время заявления. Его истинность проверяется другими средствами.

Новая ссылка не отвечает за старую сделку

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

Проект Фуркана Янтери от 27 октября 2026 года в разделе 4.2 формулирует конкретное требование к предлагаемой системе заявлений. Каждая редакция условий и политик сервиса получает печать с названием документа, идентификатором версии, отдельным URL и SHA-256 текста без оформления. Все опечатанные редакции должны оставаться доступны по своим адресам. Компания вправе написать новую редакцию, но подмена прежнего файла по тому же адресу обнаружится при сравнении хеша.

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

Карточка IETF Datatracker указывает, что это действующий индивидуальный Internet-Draft со статусом I-D Exists. В данном наборе первичных документов нет ни принятого стандарта рабочей группы, ни проверенного дела о конкретном споре клиентов с сервисом. Интересен предлагаемый способ сохранить предмет спора, прежде чем стороны начнут толковать его по-разному.

Подпись не назначает директора

Чтобы две стороны проверяли одну и ту же запись, раздел 3.1 использует ограниченный канонический JSON на основе RFC 8785. Ключи сортируются рекурсивно, лишние пробелы исключаются, типы значений ограничены. Раздел 3.2 подписывает каноническую полезную нагрузку ключом Ed25519; описание алгоритма дано в RFC 8032. Подпись отвечает на вопрос, какие байты подписаны данным ключом. Она не исправляет ложное утверждение внутри сообщения.

Публичный ключ сам по себе не говорит, за какую организацию он выступает. Проект связывает ключ компании или агента с доменом через DNS TXT-запись _humancollab. Для первоначальной связи допускается файл HTTPS. Замена уже привязанного ключа требует подтверждения через DNS. Прежний ключ нельзя повторно назначить другому домену; в открытой истории сохраняются ключи и номер первой записи, подписанной каждым из них. Если контроль домена переходит к другому лицу, читатель получает временную границу вместо вечного значка «проверено».

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

Архив, который никто не вынес из офиса

Раздел 4.3 строит журнал на дереве Меркла с правилами хеширования, согласованными с RFC 9162. Журнал выдаёт доказательства включения и последовательности, подписывает контрольные точки и закрепляет опубликованные корни во времени через OpenTimestamps. Наблюдатели сравнивают каждую новую точку с ранее полученной и хранят собственные копии. Оператору предлагается запустить наблюдателя вне инфраструктуры сервиса; любой другой участник также может его вести.

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

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

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

Источники