Наверх

В продолжении темы о "бомбах"

Архив
Время чтения: 3 минуты
11
В продолжении темы о

Какие еще угрозы несет "умный" документ

Прочитал вчера, как всегда занятную, запись от Сергея «Бомба формата doc» и первой мыслью было «Что ж теперь всем на plain text переходить?».

Результатом некоторых мысленных усилий стали следующие выводы (может не слишком стройно, но как уж есть).

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

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

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

Отсюда получаем:

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

●     Требования к программе просмотра.Программа просмотра должна однозначным образом визуализировать документ, основываясь только на его содержимом. Обязательным, но крайне трудно выполнимым условием здесь является проверка, соответствия программы некоему стандарту или эталону, т.е. что программа всегда формирует изображение в соответствии с требованиями формата документа. Если честно, я плохо представляю, на сколько это выполнимо (по-моему, вообще не выполнимо). Для примера можно привести ситуацию с RTF (который, в общем-то, открыт, но все редакторы, даже от одного производителя – Microsoft – показывают его по-разному). Или PDF (который, собственно, и задумывался для того, чтобы везде отображаться одинаково, но который все-таки зависит от просмотрщика, его отображающего, и даже если отказаться от использования встроенного JavaScript, остаются проблемы со шрифтами, если они не внедрены, с необязательным сглаживанием, с формами, и т.д.). Да что там – ведь даже простейший plain text этому требованию никак не удовлетворяет!!!

●     Требования к среде. Здесь - совсем плохо, т.к. по идее среда должна обеспечивать точное (попиксельно!) отображение документа. При этом, должны в пределах определенных допусков оставаться отклонения в цветопередаче, в искажении картинки при масштабировании и сглаживании, и т.д.

 

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

Хотя… может я просто сгущаю краски…

Чтобы прочитать эту статью до конца,
или зарегистрируйтесь

Комментарии 11

Хороший анализ indeed, Михаил! Согласен, что проблемы возникают вследствие оторванности содержания документа от его визуального представления. Плюс искажения, налагаемые средой.

Думаю, полностью застраховаться от всех «напастей» будет чрезвычайно сложно, но кое какие меры принять можно. С удовольствием прочитал вчера статью, предложенную Натальей, нашел для себя много нового. Так вот, автор статьи предлагает включать в тело документа шрифт, который используется для представления документа, и подписывать этот шрифт ЭЦП as well. Думаю, это можно использовать как альтернативу графического представления документа.

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

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

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

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

2Сергей Данилов.

Да, я думал над вариантом эталонной реализации. Но что он дает? Ведь перед пользователем встает дилемма: или пользоваться всегда только эталонной реализацией (или еще проще - всегда только одной программой). Или надеяться, что редактор, которым он пользуется в текущую минуту показывает документ правильно.

Вопрос будет: как определить в какой момент чем пользоваться?

Решение - сертифицировать приложение используемое пользователем.
Коллеги, хочу обратить Ваше внимание на стандарт ISO 19005-1:2005 "Document management — Electronic document file format for long-term preservation — Part 1: Use of PDF 1.4 (PDF/A-1)". Это описание формата PDF/A - вариант обычного PDF, в котором запрещены разного рода динамические элементы. Последние версии Adobe Acrobat позволяют создавать документы в этом формате (есть и ПО независимых поставщиков). Формат открытый.

Да, Наталья, спасибо за напоминание!

Скорее всего PDF/A один из возможных кандидатов на подобный стандарт, однако, на сколько мне известно, он не слишком популярен, по сравнению с обычным PDF.

Другой момент, что тот же Adobe Reader позволяет исполнять сценарии, зашитые не в тело документа, а лежащие на локальной машине. Понятно, что это уже вопрос доверия к вьюеру и среде его исполнения, но ведь все равно вопрос остается. Как вы считаете?

Согласна, PDF/A пока не очень популярен - он и появился совсем недавно; специалисты к нему пока присматривются. Но каких-то серьёзных альтернатив ему пока не видно.

Думаю, можно добиться доверия к этому формату. Что касается вьюера (или, если взять шире, к компьютеру пользователя со всем его софтом и железом) - то здесь всегда могут быть проблемы. Не случайно в случае споров документы всегда проверяют на эталонном "железе" и ПО. Есть ещё способ подстраховки - использовать собственную ЭЦП Acrobata - она защищает лучше т.к. "знает" особенности структуры документа.

Бороздя просторы Сети в поисках информации о PDF/A, нашел замечательный документик. С удовольствием делюсь ссылочкой.

2Сергей: Спасибо!

2Наталья: А Вы не рассматривали конкурентный формат от Microsoft - XPS? Потенциально, он тоже не содержит активного кода (по крайней мере смысла включать нет, ведь это еще и стандарт для работы новой подсистемы печати от Microsoft), а возможности по расширеню больше, чем у PDF/A (хотя до PDF не дотягивает, конечно).

2Михаил: XPS рекламируется как конкурент PDF. Понятно, что несложно обеспечить возможность изготовления чисто статических XPS-документов. Если XPS сумеет вытеснить PDF (что будет непросто, учитывая растущую в ряде ведущих стран в т.ч. в США микрософтофобию), - придется им пользоваться.

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