Облачная демократия - технические аспектыВ мае 2011 года в интернете была опубликована книга Леонида Волкова и Федора Крашенинникова “Облачная демократия” (
http://www.cdem.ru/). Идеи, высказываемые в книге мне показались очень полезными и вполне своевременными.
Что предлагается, если коротко?
Предлагается электронная система голосования по вопросом любого уровня и любой специализации. Для этого предусматривается использование прямого голосования в сочетании с системой делегирования голосов, работающей в непрерывном режиме (без “моментальных” выборов).
В связи с этим хотелось-бы остановиться на технических аспектах возможной реализации такой системы.
Подсистема идентификации пользователейПо своей сути в системе обязательно должны быть модули авторизации и аутентификации пользователей. Модуль авторизации должен отвечать за технические аспекты взаимодействия пользователя с системой и предоставлять средства идентификации пользователя. Модуль аутентификации должен отвечать за то, что конкретный пользователь соответствует определенному реальному человеку.
Проблему авторизации решить не особенно сложно с использованием сертификатов шифрования, электронной подписи и открытых ключей. Однако, модуль аутентификации представляет собой уже более существенную проблему. Если на государственном уровне у нас, как, например, в одном из прибалтийских государств, введут персональную карточку с помощью которой можно будет формировать электронную подпись, тогда и проблема аутентификации превратиться в чисто техническую. Пока-же этого нет, можно попробовать использовать процедуру взаимного подписывания, распространенную, например, в сообществе GnuPG.
Подсистема регистрации субъектов голосованияТ.к. голосования будут проводиться не абстрактно, а все-таки будут иметь какой-то уровень (например, территориальный), не имеет смысла выставлять голосование по вопросам конкретного ТСЖ на всероссийский уровень. Для такого распределения голосований и делегирования по уровням необходима, как я ее назвал, “подсистема регистрации субъектов голосования”. Это может быть конкретный дом по определенному адресу для проведения голосования жильцами этого дома. Или это может быть “городская дума” для голосований по вопросам какого-то города. Ну или “Российская Дума” для голосований по вопросам российского законодательства.
Технически “субъект голосования” будет представлять собой следующее:
- наименование субъекта, для того что-бы пользователи, относящиеся к нему, могли его идентифицировать;
- критерий фильтрации пользователей. Наиболее очевидный - по территориальному признаку. Например, “пользователи проживающие в доме N8 города Н-ска, такой-то области”.
- ссылка на ресурс в интернет, на котором проводится обсуждения и общение в контексте данного субъекта.
Подсистема матричного делегирования голосаДля делегирования своего голоса у пользователя должна быть возможность сделать это отдельно для каждого субъекта голосования. У него должна быть возможность на уровне ТСЖ отдать свой голос одному, а на уровне Гос. Думы - другому.
Кроме того, учитывая наличие матрицы специализаций в системе, необходима возможность так-же разделять делегирование для разных специализаций. Например, по экономическим вопросам я могу доверять одному человеку, по вопросам спорта - другому, а по вопросам, касающимся сферы IT хочу принимать решение сам.
Поэтому система делегирования, как минимум, должна быть двухуровневой. На первом уровне - субъекты голосования, на втором - матрица специализаций для каждого субъекта голосования.
Подсистема матричного рейтинга пользователейТ.к. подразумевается (или пока только обдумывается) система при которой никто не будет знать реального количества делегированных кому-то голосов, необходимо обеспечить какую-то обратную связь между делегировавшими свой голос пользователями и делегатами. Для этого можно использовать "матричный рейтинг пользователя" ("Честность", "Активность", "Соответствие ожиданиям" и т.д.). Во многих системах типа социальных сетей или блогов сейчас используется такое понятие как "карма", которое отражает что-то вроде "авторитета" пользователя.
Рейтинги будут меняться пользователями у своих делегатов после определенных событий. Например, после голосований делегатом по каким-то вопросам. Или, например, перед тем как забрать свой голос у делегата пользователь может оценить работу делегата. Не всегда такой "отбор" голоса будет сопровождаться отрицательными оценками.
Кроме того, рейтинги смогут меняться и в автоматическом режиме. Например, для пользователей, по субъектам которых проходили какие-то голосования, а пользователи и не делегировали свой голос и не голосовали, будет понижаться рейтинг "Активность".
Подсистема голосований с учетом делегирования и прямого голосованияЭта подсистема, в общем-то, сердцевина всего комплекса - то, ради чего и будут работать и все остальные подсистемы. Здесь будет производится регистрация вопросов для голосования с привязкой их к субъекту голосования и с указанием того, к каким сферам относится данный вопрос. Последнее, вероятно будет представлено как набор “весов” в матрице специализации данного голосования. Вопрос по поводу того, откуда будут браться данные “веса” пока оставим “за кадром”.
В процессе работы данной подсистемы необходимо предусмотреть многие механизмы. Во-первых, обязательной должна быть возможность проверки собственного голоса по каждому голосованию. Независимо от того, делегирован он был или нет. Во-вторых, у вас должна быть возможность проверить какие из пользователей, относящихся к данному субъекту голосования, участвовали в голосовании. Вопрос об открытости или закрытости голосования пока так-же отложим, т.к. он не совсем очевиден.
ВзаимодействиеВозможно вы обратили внимание, что когда я описывал “субъекты голосования”, последним пунктом в его свойствах стоит “ссылка на ресурс в интернет, на котором проводится обсуждения и общение в контексте данного субъекта”. Мне кажется, что описанные мною подсистемы должны представлять собой, по большей части, программные или сетевые интерфейсы для работы с ними, а пользователи будут работать в конечном итоге с различными ресурсами, создаваемыми кем угодно и использующими взаимодействие с данными подсистемами прозрачно для пользователя.
РезюмеКонечно, я не рассмотрел очень многих вопросов, касающихся безопасности системы, не привел конкретных вариантов реализации механизмов взаимного подписывания для аутентификации пользователей, не описал некоторые нюансы самой идеи облачной демократии. Но в качестве затравки для обсуждения этой идеи и возможных способов её реализации, думаю, статью можно рассматривать.
Вход
FAQ
Поиск
