Гримасы компьютеризации II

В "Гримасах компьютеризации" Геннадия Кузнецова (#13 [291], 1999) - письме, написанном по поводу статьи Андрея Акопянца "Кодексы и код" (#10 [288], 1999), была приведена История, показывающая, как "несмотря на официальный нормативный документ, на самом деле реально действующим "законом" является некоторая программа". Напомню, что основной тезис статьи Акопянца, вызвавшей к жизни эту полемику, заключался в том, что роль правовых механизмов для ряда приложений при виртуализации отношений будет постепенно перемещаться к алгоритмическим, программным сущностям.
Максим Отставнов

   НЕТ - программизму!
   Прежде всего, этими историями я хотел проиллюстрировать прямо противоположный тезис о "программизме": нет ничего хуже ситуации, когда нормотворчеством начинают заниматься программисты, тем паче настоящие программисты. Под "настоящим программизмом", имеющим, естественно, отрицательную оценку, будут пониматься настоящие конечность (в смысле: ограниченность), детерминированность и настоящий автоматизм. Все это в сочетании с ощущением всемогущества, ибо кто из нас на вопрос "А можно ли сделать в программе <...>?" не слышал всегда уверенного ответа: "Ну, в принципе, можно". Как говорят преподаватели госуниверситета: "Приходите к нам на мехмат, и мы сделаем из вас человека. Ну, на худой конец, программиста".

   Послесловие к истории первой
   Обстоятельства с тех пор претерпели некоторую трансформацию. ГНС состряпала письмо ї ВП-6-30/95, существенно изменившее состав реквизитов, но интересное не этим. Следующим этапом в отношениях Госналогслужбы с юридических лицами, желавшими или обязанными подавать данные на дискете, стало то, что за программу некоего ЗАО "Налогоплательщик" (уже интересно!) надо было обязательно платить (10 долларов). Действующий документ детально описывал все обязательные строки файла, но программа добавляла всего одну неописанную: с регистрационным номером, который вы получали только при покупке программы "Налогоплательщик 1.1". И не описанная в документе, а следовательно, необязательная и даже незаконная строка становилась самой обязательной: без нее налоговая инспекция просто не принимала сведений. Реквизит перекочевал и в ныне действующий документ и даже приобрел статус обязательного. Однако с передачей функций создания и распространения программ это потеряло всякий смысл.

   История вторая
   Похожая ситуация сложилась, когда второй по значимости сборщик податей - Пенсионный фонд РФ - начал сбор анкет для внедрения системы персонифицированного учета. Сведения он собирал на основании Постановления ПФ РФ 44 от 03.07.97 "О формах документов индивидуального (персонифицированного) учета в системе государственного пенсионного страхования и инструкции по их заполнению", в котором не забыто даже то, что "концы скрепляющей нити выводятся с тыльной стороны пачки, связываются и заклеиваются листом бумаги, на который ставится печать работодателя".

   А вот о том, как же готовить информацию на магнитных носителях всем предприятиям и организациям, имеющим хоть один компьютер, ничего не говорится, кроме скупой фразы: "Пачка входящих документов может сопровождаться машинным носителем (дискетой), содержащим информацию всех документов пачки в формате, утвержденном ПФР".

   Утвержденным форматом на деле была опять-таки какая-то простая, без изысков, программа на незабвенном Клиппере. Детали файлового представления, какого-то варианта CSV [1] ("значений, разделенных запятыми"), никто сообщить не мог. Поскольку это был лишь первичный сбор сведений, для многих оказалось проще опять-таки настукать их в предложенной программе, нежели конвертировать из своих данных. Так что этот этап прошел сравнительно гладко, однако я с большой опаской жду светлого момента окончательного внедрения персонифицированного учета. Ведь сведения придется подавать по текущим начислениям, а каким образом трансформируются требования к структуре информации на магнитных носителях или программам, их реализующим, неизвестно.

   Выводы
   Я еще раз обрисую новизну возникшей ситуации.

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

Несмотря на официальные нормативные документы, на самом деле реально действующим "законом" в обеих историях была некая программа, иногда - непонятно, кем, когда и где написанная. Излишне говорить, что в тексте документа нет слов "программа sved.exe" или "сведения должны подготавливаться программой person.exe". О программе ПФ РФ трудно сказать, что она не соответствует, потому что описывающего ее документа нет вообще. У меня нет, собственно, возражений против того, чтобы программы тоже являлись источниками права. Но это должно быть закреплено не только де-факто, но и де-юре. Это хотя бы увеличит ответственность авторов программ, ликвидирует их анонимность и избавит нас от неконтролируемого диктата "программизма".

Еще один прагматический аспект автоматизации деятельности этих ведомств - степень соответствия предъявляемых ими требований друг другу. Мне совершенно безразлична компьютеризация какой-то отрасли. Это проблемы отрасли, и они меня не касаются. А вот компьютеризация сборщиков податей - ГНС и ПФ РФ существенно бьет меня по карману и увеличивает мои косвенные издержки. На сегодняшний день сходство этих требований довольно отдаленное. Те, кто пытался конвертировать адресные данные, подготовленные для Пенсионного фонда, в сведения для налоговой инспекции, быстро осознали, что это дело бесперспективное и реально лишь преобразование паспортных данных. Когда-то мне пришлось полностью переформировать структуру реестра акционеров для совместимости с прежней программой ГНС. А для того, чтобы бесконфликтно предоставлять сведения в обе структуры, налогоплательщик должен хранить (и поддерживать!) сведения в обоих форматах, помимо своего собственного. А ведь есть еще фонд медицинского страхования, который в один прекрасный день тоже может ввести персонифицированный учет. Таким образом, эта автоматизация налогосборщиков на деле лишь намного усложняет налогоплательщикам подготовку сведений, а навязывание устаревших форматов данных может даже служить тормозом для их собственной автоматизации.

Хотя событиям этим уже полтора-два года, они для меня не стали историей минувших дней. Только что пришлось заплатить 735 рублей за очередную программу подготовки сведений о подоходном налоге в новом формате, чтобы подать информацию на пять человек. ГНС решает свои проблемы компьютеризации, а я несу самые прямые издержки: плачу за программу сначала самой ГНИ, а теперь уже совсем посторонней в этих отношениях фирме "ГипроНИИгаз". Во всей мировой практике принято, что за услуги платит заказчик. А сейчас мы оказываем услуги по подготовке информации для ГНС, и мы же сами за них платим!

   От редакции
   Опубликовав 30 марта фрагменты переписки Геннадия Кузнецова и Андрея Акопянца, мы, как выяснилось, немного поторопились (чего не бывает в первоапрельском номере). "Волею судеб и компьютерных технологий мое письмо попало в номер в таком виде помимо моего желания. Я бы хотел расставить акценты и внести некоторые дополнения", - написал Кузнецов и прислал продолжение Первой истории и Историю вторую с Выводами, которые мы с удовольствием и публикуем.

   Акопянц же ограничился следующей припиской:
   "Ремарки я комментировать не буду, кроме одной: программисты - не сахар, но юристы в среднем не лучше. При этом, в отличие от программистов (у которых плохо с прагматикой), у них зачастую еще просто плохо с логикой, и почти всегда - с дисциплиной мышления.
   Так, счастливой жизни под игом программно реализованного права нам, конечно, не будет, но хуже, чем сейчас, не будет тоже".

   Что здесь можно добавить? Я могу добавить только свой личный аналитический взгляд на класс ситуаций, которые приведены в примерах Кузнецова.
   1) Первый и наиболее очевидный слой ситуации - банальное воровство.
   Потери жертвы "программизма" не исчерпываются десятью долларами: к программе, состряпанной в среде настольной СУБД, нужен, наверное, runtime-модуль, который придется искать, а запускать все это придется в определенной ОС и/или оболочке, которая, в свою очередь, требует вполне определенного "железа".
   Если хард и платформа отличаются от обычно используемых конкретным юридическим лицом в основной и офисной деятельности, их придется покупать и осваивать (или арендовать), и расходы возрастут если не на два порядка, то на порядок точно.
   Причем основная масса затрат уйдет не конкретному ГУП или ЗАО, которое "отстегивает" от своих продаж чиновнику того или иного ведомства, подписывающего очередное письмо! Нет, она уйдет или третьим лицам, или просто псу под хвост (стоимость рабочего времени сотрудников, устанавливающих и эксплуатирующих такое, с позволения сказать, ПО). Специфическая модель чиновничьего воровства - "потрава": свинья в огороде съест на рубль, а разроет и вытопчет на сто.

   2) Второй слой ситуации - это относительная атомизированность жертв "(анти) правового программизма" при относительной консолидированности его инициаторов. Понятно, что конкретному чиновнику сговориться с конкретным "программистом" (пардон) гораздо проще, чем четверти "подвластных" им юридических лиц объединиться с тем, чтобы нанять юриста, который первых "затопчет", даже при том, что последнее гораздо дешевле, чем тратиться по n (а то и по m) долларов на выполнение каждого письма или постановления первых.

   3) Но я, собственно, хочу заметить, что у ситуации есть и третий слой.

   Первая из историй, рассказанных Кузнецовым, до абсурда явно связана с воровством, хотя бы потому, что очевидно
   а) наличие и б) относительная дешевизна неворовского решения соответствующей задачи (исчерпывающая формулировка требований к формату/структуре данных и заблаговременное их раскрытие). Вторая - поскольку о принудительной покупке программы-тире-закона, как я понимаю, речь не идет, - скорее пример дури, когда ущерб наносится, а выгоды, даже воровской, не имеет никто.

   Однако существует класс задач, которые приходится решать нормативно-правовым способом, но решения которых, тем не менее, гораздо проще (=дешевле для всех) описать алгоритмически (кодом), чем спецификацией форматов.

   Наверное, скорее к этому третьему слою я бы отнес и замечание Кузнецова о том, что "нет, собственно, возражений против того, чтобы программы тоже являлись источниками права", и приписку Акопянца.

   Возможно, в том, чтобы найти ту грань формализации, которая допустима без существенных потерь для хозяйственно-правовой системы в целом, и есть Высокое Искусство Права (в отличие от "юризма")?

   Я рискну привести один (пока теоретический) пример того, как компьютеризация (автоматизация) юридических действий может влечь за собой необходимость весьма изощренной компьютеризации (автоматизации) юридических процедур, - см. врезку).

1 (обратно к тексту) - CSV - comma separated values, aka comma delimited values - простейший формат для импорта-экспорта данных из электронных таблиц и баз данных в "плоские" текстовые файлы.

   Судья-оракул

   Одна из сложностей, возникающих при "заочном" заключении контрактов, - это так называемая проблема одновременной подписи. Для многих типов сделок (кроме подписания открытой оферты, то есть публичного предложения заключить сделку) существенно наличие подписей обеих сторон.
   При заочном (не обязательно цифровом) заключении контрактов добиться этого не так-то просто. Одна сторона может, получив контракт с подписью контрагента, воздержаться от его возврата последнему со своей подписью, получив выбор: при благоприятных обстоятельствах позднее предъявить контракт, подписанный обеими сторонами, либо оспорить сам факт заключения сделки, заявив, что его не было.
   Понятно, что такой риск сильно ограничивает область заочного заключения контрактов между не доверяющими друг другу сторонами.
   Один из известных протоколов, решающих эту проблему, - это введение посредника-"нотариуса", обеспечивающего "квазиодновременность" подписи (две копии контракта с подписями двух сторон передаются через "нотариуса", который отправляет их дальше не ранее, чем получит обе). Введение третьего лица в сделку может быть невозможным (не находится "нотариуса", которому доверяют обе стороны), нежелательным (сделка конфиденциальна, и ее содержание может разглашаться только в случае возникновения конфликта) или просто слишком дорогим.
   Оказывается, в среде электронных коммуникаций можно поступить иначе. Заочные контрагенты не присутствуют одновременно в одном месте, зато они могут моментально и дешево обмениваться данными. Представьте себе, что вместо того, чтобы поставить свою подпись за один раз, вы рисуете лишь один из ее штрихов и передаете документ контрагенту. Он делает то же самое. Видя его "продвижение в деле подписи", вы делаете то же самое. С каждым шагом оба контрагента "увязают" в контракте все глубже и глубже, и в конце концов он оказывается подписанным как бы одновременно.
   Для цифровой подписи (как функционального эквивалента подписи собственноручной) придуман ряд продвинутых протоколов, позволяющих это осуществлять.
   Конкретные детали математики этих протоколов нам здесь не важны [2]. Важно другое: оказывается, что этот протокол работает только в случае вероятностной (недетерминированной) модели судьи (арбитра), к которому стороны потенциально обращаются при возникновении конфликта.
   Каковы бы ни были детали, выполняя каждый шаг, одна из сторон, по сути, заявляет, что признает себя связанной контрактом с определенной вероятностью, причем большей, чем на предыдущем шаге. "Правильный" арбитр случайно выберет число между нулем и единицей, а потом посмотрит на указанную вероятность и, если она больше этого числа, признает контракт действительным и сделку - состоявшейся [3]. (Понятно, что бросающий монету или кости судья в мантии выглядит странно, поэтому на месте арбитра естественно было бы видеть все-таки автомат.)
   Как только (законом или прецедентом) устанавливается определенная мера принятой стороной вероятности (50%, 75% или любая другая), за которой следует действительность сделки, протокол разрушается: передача "критической" частичной подписи становится равносильна просто подписи, и мы оказываемся в самом начале, перед все той же "проблемой одновременной подписи" [4].
   Таким образом, парадоксально, Фемида должна быть слепа.
   Можно ли обойтись без недетерминированного арбитра и квазиодновременно подписать "обычный" цифровой контракт? Такие протоколы существуют, но работают лишь при очень сильном допущении симметричности ресурсов (вычислительной мощности) сторон [5].

2 (обратно к тексту) - Интересующихся отсылаем к C. P. Pfleeger, Security in Computing - Englewood Cliffs: 1989; M. Ben-Or, O. Goldreich, S. Micali & S. L. Rivest, A Fair Protocol for Signing Contracts // IEEE Trans. On Information Theory, v. 36, No.1 (Jan 1990); S. Even, O. Goldreich & A. Lemplel, A Randomizing Protocol for Signing Contracts // Comm. of the ACM, v. 28, No.6 (Jun 1985).
3 (обратно к тексту) - См. B. Schneier, Applied Cryptography, N.Y.: 1996, pp. 119-20.
4 (обратно к тексту) - Ibid.
5 (обратно к тексту) - Ibid., p. 121.