Продолжаем говорить о деятельности ДИТ Москвы (смотрите наши предыдущие посты), но одновременно и переходим к следующей теме, внезапно ставшей актуальной и набравшей обороты — теме электронного голосования.
Если в прошлом году дистанционное голосование граждан рассматривалось скорее как курьёз или эксперимент, выводы из которого будут сделаны когда-то потом, то в 2020-м мы все внезапно обнаружили, что это — реальность, с которой нам предстоит столкнуться скоро и в полном объёме. В значительной степени к этому подтолкнули карантинные ограничения — проведение выборов оказалось под вопросом, а жизнь политических партий встала на паузу.
В общем, спрос встретился с предложением — и повалили законопроекты. Партиям разрешили проводить праймериз через Госуслуги/ЕСИА, регионы один за другим рапортуют о стремлении организовать ДЭГ (дистанционное электронное голосование) уже в сентябре на местных выборах.
К счастью или к сожалению, одного только законотворчества мало — нужна ещё и техническая реализация, с которой не всё так однозначно. Кто-то верит, что всё уже было сделано в Москве в прошлом году (там даже был блокчейн!), кто-то — что ДЭГ вообще невозможно реализовать на уровне, не допускающем массовых фальсификаций, а потому от ДЭГ необходимо отказаться в принципе.
Поэтому мы решили посвятить разбору этих вопросов небольшой цикл статей и встреч:
Первую статью начинаем прямо сейчас, а вторую и анонс круглого стола повесим завтра (и добавим сюда ссылки).
Строго говоря, это не статья, а слегка литературно отредактированный текст одноимённого выступления Алексея Щербакова (alexeishch) на нашей конференции 5 марта этого года.
Алексей — приглашенный эксперт команды Романа Юнемана по подготовке доклада «Электронное голосование. Риски и уязвимости», ведущий backend-разработчик компании FoodPlex.
В докладе рассказывается о том, как именно было технически устроено дистанционное электронное голосование на выборах в МГД 2019 года, какие были достоинства и недостатки как в технических решениях, так и в работе с экспертными группами.
Помимо этого текста, можно прочитать также ещё две статьи, уже публиковавшиеся на Хабре:
Если вы предпочитаете видео или аудио, полную запись доклада можно посмотреть на YouTube.
Здравствуйте, меня зовут Алексей Щербаков, я был экспертом приглашённой команды Романа Юнемана на Московском голосовании. Ну вообще прежде чем рассказывать о самом голосовании, стоит сказать как это вообще происходило.
Всё это началось в марте 2019 года, когда было объявлено об эксперименте, потом уже в мае принят закон о голосовании, а само голосование происходило 8 сентября в трёх округах Москвы. Голосование проходило через интернет в течение 12 часов.
Сама система была построена на базе блокчейна Ethereum фирмы Parity. Там же была использована схема Эль-Гамаля для шифрования. Система логирования использовалась Graylog и для передачи данных между сообщениями использовался какая-то реализация AMQP, мы предполагаем, что скорее всего это был RabbitMQ, просто как корпоративный стандарт. Сама система выглядела вот таким образом:
Большая часть системы находилась вне Департамента информационных технологий (ДИТ) Москвы [это очень важный момент, так как с внешними экспертами общался только ДИТ Москвы — прим. ред.], но блокчейн находился у них. Они работали совместно с порталом Госуслуг. Описание, как эта система создавалась, ДИТ Москвы публиковал на Хабре. И они там же уже говорили в частности о том, что у них проблемы были, в основном, только один час, порядка 400 человек были этим затронуты.
Мы произвели анализ данных на основе выгрузки из блокчейна, которая была представлена Медузой. И отдельно ещё рассматривали свидетельские показания, которые были собраны уже непосредственно наблюдателями на участках. Это был электронный участок, там фотографировались показания на экранах, я подробнее дальше расскажу.
Прежде чем сказать по поводу анализа, который был сделан, расскажу, как мы подходили к задаче. Если бы я сам проектировал эту систему, то я бы использовал определенные стандарты для проектирования системы высокой доступности. В частности, использовались бы метрики для наблюдения непосредственно за здоровьем системы. Для того, чтобы понимать, что начинаются какие-то проблемы — и на них быстро реагировать. И помимо команды, которая должна всё это делать, это должны видеть сами наблюдатели — то есть, наблюдатели должны каким-то образом понимать, что что-то идёт не так. И участковая-избирательная комиссия, которая находилась на этом участке, тоже должна была понимать, что происходило не так, если вдруг что-то идёт не так.
В нашем случае метрика по времени вычисления блоков блокчейна выглядела вот таким вот образом. На ней видно отдельно несколько проблем, первые проблемы связаны с остановкой блокчейна, это первые три зоны. И ещё одна зона — это неизвестная нам проблема, которую мы конкретно на этой метрике не видим. И ещё в конце мы видим плавную деградацию, которая происходила до самого конца голосования.
Если мы рассмотрим вторую метрику — число транзакций на блок — то по ним мы видим проблему уже подробнее. Мы, во-первых, видим, что в зонах отключения, никаких транзакций не записывалось. В нашей подозрительной зоне мы видим крайне мало транзакций, а потом мы видим интересный момент, когда у нас меняется характер записи данных блокчейна. С чем это связано? Изначально, когда данные писались, они писались с определённым интервалом, это сделано для того, чтобы нельзя было по времени голосования точно определить, какой человек голосовал. Данные накапливались и сбрасывались в блокчейн. Однако потом после какой-то реконфигурации блокчейна данные стали записываться уже хаотично. То есть была произведена какая-то операция, но мы не можем точно сказать на основе этой метрики что конкретно ДИТ сделал. Но мы можем сказать, что в данном случае ДИТ каким-то образом вмешался в работу системы.
На основании этих метрик мы можем посчитать время, на которое блокчейн был остановлен. В зонах устойчивой работы время блока было порядка 4 секунд. Соответственно, мы можем посчитать в зонах остановки, сколько уместилось блоков по 4 секунды и сколько оставшееся время блокчейн был остановлен. И на основании этого мы получаем нижнюю оценку для времени остановки, равную 2 часам. Это то время, когда блокчейн полностью не работал.
Помимо этого, у нас ещё есть ещё одна зона, в которой данные не доходили до блокчейна. Суммарно все эти зоны неисправности занимают 4 часа. Зона деградации занимает порядка 6 часов, она началась после обеда и шла до конца голосования. Из-за того, что никак не мониторили блокчейн, они даже не подозревали о том, что были какие-то проблемы. Более того, люди, которые присутствовали на самом участке, часть избирательной комиссии, говорили, что всё, что они могли сделать — это сидеть на диванчике и смотреть, что происходит на экране. То есть они не понимали, что происходит, и узнавали о каких-то проблемах исключительно из СМИ. У них не было вообще никаких инструментов для того, чтобы наблюдать за проблемой.
Помимо этого был интересный момент: у наблюдателей должен был быть доступ к самому блокчейну. То есть, им обещали, что у них будет специальная нода наблюдения и они смогут уже непосредственно обращаться к блокчейну, выполнять на нём операции и смотреть, что происходит. Но эту возможность у них отобрали! Почему? Непонятно. И на экран просто вывели статистику.
Вот так выглядели экраны, там просто четыре позиции: классическая «воронка продаж», когда у нас есть количество людей, которые перешли на страницу голосования, авторизовались, получили бюллетень и проголосовали, и оно с каждым шагом уменьшается.
Здесь есть очень важный момент — время жизни бюллетеня. Если избиратель не успевал за 15 минут заполнить бюллетень, то он считался аннулированным. И сама статистика также шла интервалами по 15 минут. То есть, если у нас избиратель не проходил какой-то участок воронки за 15 минут, то мы можем уверенно сказать, что на следующем этапе статистики он не учитывался. И на каждом этапе у нас получалось меньшее количество. Именно благодаря этому удалось отсл��дить интересные аномалии статистики.
Здесь приведена эта воронка, цветами отмечены времена неисправности блокчейна. Здесь есть интересные аномалии, например, когда красная линия переходит над жёлтой — это количество выданных бюллетеней стало больше, чем количество людей, которые авторизовались, введя код из SMS. Это физически невозможно просто, для того, чтобы получить бюллетень, нужно ввести код. И это произошло в районе двух часов.
Это сравнение статистики, которая получена по данным наблюдателей, и статистики, которая получена из выгрузки из блокчейна. Как видно, они практически совпадают, но есть небольшое отличие, когда, видимо, были небольшие проблемы в статистике на фронтенде. Это нам дает возможность говорить, что статистика, которую получали независимые наблюдатели, и статистика, полученная из блокчейна на основе выгрузки — это практически одно и то же, за исключением этапа, когда у нас были какие-то проблемы.
Помимо статистики, у нас есть интересная аудиозапись — время около 17 часов, проголосовало около 2000 человек, один из представителей ДИТ Москвы рассказывает, какие вмешательства они проводили на работающей системе. В частности он рассказывает, что порядка 900 человек повторно получали SMS для авторизации.
Нам это говорит, во-первых, о том, что благодаря системе логирования, которую они использовали, ДИТ Москвы мог нарушать тайну голосования. Они могли сопоставить время голосования, статус бюллетеня и номер телефона, что очень важно! Они идентифицировали людей, у которых были проблемы, определили их номера телефонов и разослали повторные SMS. Количество этих людей — порядка 40 % от всех проголосовавших на этом участке. Разница между двумя кандидатами, первым и вторым, составила всего 84 человека, в то время как для 900 человек мы даже не можем сказать, какой у них был результат. Потому что над ними производились какие-то действия. Мы не можем сказать, что эти голоса подтасовывали, но мы можем сказать, что у 900 человек были проблемы, мы не можем сказать, за кого они проголосовали и проголосовали ли они вообще. То есть число людей, которые столкнулись с проблемами, в десять раз больше, чем число людей, которые отделяли одного кандидата от победы.
Репозиторий с данными и код, который используется для анализа, можно найти по этой ссылке.
Также мы проивели анализ кода, который использовался для самого голосования. Мы ожидали, что большинство операций будет происходить непосредственно в самом блокчейне и что код должен быть опубликован. Мы получили смарт-контракты, код формы и код, ответственный за отправку сообщения. Но там были части, которые остались неизвестными, потому что они выполнялись на стороне уже другого Департамента — уже портала mos.ru.
Что было интересно найдено в коде? Оказалось, что он не ограничивал возможность одного человека проголосовать в разных округах. Это интересный момент, это было на откуп отдано бэкенду, который находился где-то в другом месте и исходный код которого мы не смогли посмотреть. Непонятно, зачем в системе использовали блокчейн — так как он всё равно не контролировал всё, его можно было заменить на обычную базу данных. Ну и в код формы буквально за день до голосования добавили вот такой волшебный код, который позволял с помощью одной переменной на стороне бэкенда включать дополнительный скрипт в форму, что очень интересно! Зачем они это сделали? По сути, это возможность выполнения произвольного кода в момент голосования на устройстве пользователя.
По криптографии также был интересный момент. Изначально они выбрали 256-бит шифрование, хотя ещё в 1999 году для этой схемы предлагалось использовать 768 бит, а 10 лет назад предлагалось уже 1024 бита. А если сейчас открыть рекомендации Евросоюза, то там будет требование «не менее 1024 бит», если же требуется защита до 2030-го года, то рекомендуется использовать 3072 бита. Есть также интересный момент в том, как они вычисляют энтропию. Понятно, что люди не до конца разобрались, зачем им это всё нужно.
Что я могу сказать об этой системе?
Во-первых, ДИТ Москвы не смог обеспечить хотя бы 90% работоспособности. Вообще считается, что система высокой доступности, она должна иметь не менее 90% времени работы. То есть мы не можем даже сказать, что она была рабочая.
Во-вторых, на продакшн-системе производились операции, которые никто никак не контролировал, ни��то вообще не мог понять, что происходило. Если посмотреть заседание суда [по обжалованию итогов выборов — прим. ред.], окажется, что ни люди, ни наблюдатели, ни сама комиссия не понимали, что происходит. Всё-таки надо было их как-то подготовить к самой процедуре, которая происходила.
Мы не хотим сказать, что электронные выборы — это обязательно бардак, постоянные проблемы, странные технические решения и непонимание, что вообще происходит в данный момент.
Тем не менее, как мы видим по этому материалу, вопрос доверия к результатам голосования по сути своей являлся вопросом доверия к его организаторам — взаимодействие с которыми оказалось весьма неоднозначным. Это, как нам кажется, отвечает и на весьма актуальный вопрос о том, имеет ли ДИТ Москвы достаточно опыта для его масштабирования на всю Москву, а тем более — всю страну, и на вопрос о том, можно ли просто взять какую-нибудь «голосовалку с блокчейном», запустить её на сервере и начать проводить выборы.
О том же, можно ли вообще построить цифровую голосовательную систему, доверие к которой обеспечивается самой её архитектурой, а не честностью её авторов — мы поговорим в следующей статье.
Если в прошлом году дистанционное голосование граждан рассматривалось скорее как курьёз или эксперимент, выводы из которого будут сделаны когда-то потом, то в 2020-м мы все внезапно обнаружили, что это — реальность, с которой нам предстоит столкнуться скоро и в полном объёме. В значительной степени к этому подтолкнули карантинные ограничения — проведение выборов оказалось под вопросом, а жизнь политических партий встала на паузу.
В общем, спрос встретился с предложением — и повалили законопроекты. Партиям разрешили проводить праймериз через Госуслуги/ЕСИА, регионы один за другим рапортуют о стремлении организовать ДЭГ (дистанционное электронное голосование) уже в сентябре на местных выборах.
К счастью или к сожалению, одного только законотворчества мало — нужна ещё и техническая реализация, с которой не всё так однозначно. Кто-то верит, что всё уже было сделано в Москве в прошлом году (там даже был блокчейн!), кто-то — что ДЭГ вообще невозможно реализовать на уровне, не допускающем массовых фальсификаций, а потому от ДЭГ необходимо отказаться в принципе.
Поэтому мы решили посвятить разбору этих вопросов небольшой цикл статей и встреч:
- Алексей Щербаков — «Уроки электронного голосования в Московскую Городскую Думу 2019 года»
- Олег Артамонов — «Дистанционные электронные голосования: архитектура доверенной электоральной системы»
- Круглый стол «Нажми на кнопку: теория и практика электронных голосований»
Первую статью начинаем прямо сейчас, а вторую и анонс круглого стола повесим завтра (и добавим сюда ссылки).
Строго говоря, это не статья, а слегка литературно отредактированный текст одноимённого выступления Алексея Щербакова (alexeishch) на нашей конференции 5 марта этого года.
Алексей — приглашенный эксперт команды Романа Юнемана по подготовке доклада «Электронное голосование. Риски и уязвимости», ведущий backend-разработчик компании FoodPlex.
В докладе рассказывается о том, как именно было технически устроено дистанционное электронное голосование на выборах в МГД 2019 года, какие были достоинства и недостатки как в технических решениях, так и в работе с экспертными группами.
Помимо этого текста, можно прочитать также ещё две статьи, уже публиковавшиеся на Хабре:
- Анализ данных блокчейн-голосования 2019 года в Московскую Городскую Думу, также авторства alexeishch
- Параллельный аудит в ходе Электронного голосования авторства Оксаны CryptoTyan
Если вы предпочитаете видео или аудио, полную запись доклада можно посмотреть на YouTube.
***
Здравствуйте, меня зовут Алексей Щербаков, я был экспертом приглашённой команды Романа Юнемана на Московском голосовании. Ну вообще прежде чем рассказывать о самом голосовании, стоит сказать как это вообще происходило.
Всё это началось в марте 2019 года, когда было объявлено об эксперименте, потом уже в мае принят закон о голосовании, а само голосование происходило 8 сентября в трёх округах Москвы. Голосование проходило через интернет в течение 12 часов.
Сама система была построена на базе блокчейна Ethereum фирмы Parity. Там же была использована схема Эль-Гамаля для шифрования. Система логирования использовалась Graylog и для передачи данных между сообщениями использовался какая-то реализация AMQP, мы предполагаем, что скорее всего это был RabbitMQ, просто как корпоративный стандарт. Сама система выглядела вот таким образом:
Большая часть системы находилась вне Департамента информационных технологий (ДИТ) Москвы [это очень важный момент, так как с внешними экспертами общался только ДИТ Москвы — прим. ред.], но блокчейн находился у них. Они работали совместно с порталом Госуслуг. Описание, как эта система создавалась, ДИТ Москвы публиковал на Хабре. И они там же уже говорили в частности о том, что у них проблемы были, в основном, только один час, порядка 400 человек были этим затронуты.
Мы произвели анализ данных на основе выгрузки из блокчейна, которая была представлена Медузой. И отдельно ещё рассматривали свидетельские показания, которые были собраны уже непосредственно наблюдателями на участках. Это был электронный участок, там фотографировались показания на экранах, я подробнее дальше расскажу.
Прежде чем сказать по поводу анализа, который был сделан, расскажу, как мы подходили к задаче. Если бы я сам проектировал эту систему, то я бы использовал определенные стандарты для проектирования системы высокой доступности. В частности, использовались бы метрики для наблюдения непосредственно за здоровьем системы. Для того, чтобы понимать, что начинаются какие-то проблемы — и на них быстро реагировать. И помимо команды, которая должна всё это делать, это должны видеть сами наблюдатели — то есть, наблюдатели должны каким-то образом понимать, что что-то идёт не так. И участковая-избирательная комиссия, которая находилась на этом участке, тоже должна была понимать, что происходило не так, если вдруг что-то идёт не так.
В нашем случае метрика по времени вычисления блоков блокчейна выглядела вот таким вот образом. На ней видно отдельно несколько проблем, первые проблемы связаны с остановкой блокчейна, это первые три зоны. И ещё одна зона — это неизвестная нам проблема, которую мы конкретно на этой метрике не видим. И ещё в конце мы видим плавную деградацию, которая происходила до самого конца голосования.
Если мы рассмотрим вторую метрику — число транзакций на блок — то по ним мы видим проблему уже подробнее. Мы, во-первых, видим, что в зонах отключения, никаких транзакций не записывалось. В нашей подозрительной зоне мы видим крайне мало транзакций, а потом мы видим интересный момент, когда у нас меняется характер записи данных блокчейна. С чем это связано? Изначально, когда данные писались, они писались с определённым интервалом, это сделано для того, чтобы нельзя было по времени голосования точно определить, какой человек голосовал. Данные накапливались и сбрасывались в блокчейн. Однако потом после какой-то реконфигурации блокчейна данные стали записываться уже хаотично. То есть была произведена какая-то операция, но мы не можем точно сказать на основе этой метрики что конкретно ДИТ сделал. Но мы можем сказать, что в данном случае ДИТ каким-то образом вмешался в работу системы.
На основании этих метрик мы можем посчитать время, на которое блокчейн был остановлен. В зонах устойчивой работы время блока было порядка 4 секунд. Соответственно, мы можем посчитать в зонах остановки, сколько уместилось блоков по 4 секунды и сколько оставшееся время блокчейн был остановлен. И на основании этого мы получаем нижнюю оценку для времени остановки, равную 2 часам. Это то время, когда блокчейн полностью не работал.
Помимо этого, у нас ещё есть ещё одна зона, в которой данные не доходили до блокчейна. Суммарно все эти зоны неисправности занимают 4 часа. Зона деградации занимает порядка 6 часов, она началась после обеда и шла до конца голосования. Из-за того, что никак не мониторили блокчейн, они даже не подозревали о том, что были какие-то проблемы. Более того, люди, которые присутствовали на самом участке, часть избирательной комиссии, говорили, что всё, что они могли сделать — это сидеть на диванчике и смотреть, что происходит на экране. То есть они не понимали, что происходит, и узнавали о каких-то проблемах исключительно из СМИ. У них не было вообще никаких инструментов для того, чтобы наблюдать за проблемой.
Помимо этого был интересный момент: у наблюдателей должен был быть доступ к самому блокчейну. То есть, им обещали, что у них будет специальная нода наблюдения и они смогут уже непосредственно обращаться к блокчейну, выполнять на нём операции и смотреть, что происходит. Но эту возможность у них отобрали! Почему? Непонятно. И на экран просто вывели статистику.
Вот так выглядели экраны, там просто четыре позиции: классическая «воронка продаж», когда у нас есть количество людей, которые перешли на страницу голосования, авторизовались, получили бюллетень и проголосовали, и оно с каждым шагом уменьшается.
Здесь есть очень важный момент — время жизни бюллетеня. Если избиратель не успевал за 15 минут заполнить бюллетень, то он считался аннулированным. И сама статистика также шла интервалами по 15 минут. То есть, если у нас избиратель не проходил какой-то участок воронки за 15 минут, то мы можем уверенно сказать, что на следующем этапе статистики он не учитывался. И на каждом этапе у нас получалось меньшее количество. Именно благодаря этому удалось отсл��дить интересные аномалии статистики.
Здесь приведена эта воронка, цветами отмечены времена неисправности блокчейна. Здесь есть интересные аномалии, например, когда красная линия переходит над жёлтой — это количество выданных бюллетеней стало больше, чем количество людей, которые авторизовались, введя код из SMS. Это физически невозможно просто, для того, чтобы получить бюллетень, нужно ввести код. И это произошло в районе двух часов.
Это сравнение статистики, которая получена по данным наблюдателей, и статистики, которая получена из выгрузки из блокчейна. Как видно, они практически совпадают, но есть небольшое отличие, когда, видимо, были небольшие проблемы в статистике на фронтенде. Это нам дает возможность говорить, что статистика, которую получали независимые наблюдатели, и статистика, полученная из блокчейна на основе выгрузки — это практически одно и то же, за исключением этапа, когда у нас были какие-то проблемы.
Помимо статистики, у нас есть интересная аудиозапись — время около 17 часов, проголосовало около 2000 человек, один из представителей ДИТ Москвы рассказывает, какие вмешательства они проводили на работающей системе. В частности он рассказывает, что порядка 900 человек повторно получали SMS для авторизации.
Нам это говорит, во-первых, о том, что благодаря системе логирования, которую они использовали, ДИТ Москвы мог нарушать тайну голосования. Они могли сопоставить время голосования, статус бюллетеня и номер телефона, что очень важно! Они идентифицировали людей, у которых были проблемы, определили их номера телефонов и разослали повторные SMS. Количество этих людей — порядка 40 % от всех проголосовавших на этом участке. Разница между двумя кандидатами, первым и вторым, составила всего 84 человека, в то время как для 900 человек мы даже не можем сказать, какой у них был результат. Потому что над ними производились какие-то действия. Мы не можем сказать, что эти голоса подтасовывали, но мы можем сказать, что у 900 человек были проблемы, мы не можем сказать, за кого они проголосовали и проголосовали ли они вообще. То есть число людей, которые столкнулись с проблемами, в десять раз больше, чем число людей, которые отделяли одного кандидата от победы.
Репозиторий с данными и код, который используется для анализа, можно найти по этой ссылке.
Также мы проивели анализ кода, который использовался для самого голосования. Мы ожидали, что большинство операций будет происходить непосредственно в самом блокчейне и что код должен быть опубликован. Мы получили смарт-контракты, код формы и код, ответственный за отправку сообщения. Но там были части, которые остались неизвестными, потому что они выполнялись на стороне уже другого Департамента — уже портала mos.ru.
Что было интересно найдено в коде? Оказалось, что он не ограничивал возможность одного человека проголосовать в разных округах. Это интересный момент, это было на откуп отдано бэкенду, который находился где-то в другом месте и исходный код которого мы не смогли посмотреть. Непонятно, зачем в системе использовали блокчейн — так как он всё равно не контролировал всё, его можно было заменить на обычную базу данных. Ну и в код формы буквально за день до голосования добавили вот такой волшебный код, который позволял с помощью одной переменной на стороне бэкенда включать дополнительный скрипт в форму, что очень интересно! Зачем они это сделали? По сути, это возможность выполнения произвольного кода в момент голосования на устройстве пользователя.
По криптографии также был интересный момент. Изначально они выбрали 256-бит шифрование, хотя ещё в 1999 году для этой схемы предлагалось использовать 768 бит, а 10 лет назад предлагалось уже 1024 бита. А если сейчас открыть рекомендации Евросоюза, то там будет требование «не менее 1024 бит», если же требуется защита до 2030-го года, то рекомендуется использовать 3072 бита. Есть также интересный момент в том, как они вычисляют энтропию. Понятно, что люди не до конца разобрались, зачем им это всё нужно.
Что я могу сказать об этой системе?
Во-первых, ДИТ Москвы не смог обеспечить хотя бы 90% работоспособности. Вообще считается, что система высокой доступности, она должна иметь не менее 90% времени работы. То есть мы не можем даже сказать, что она была рабочая.
Во-вторых, на продакшн-системе производились операции, которые никто никак не контролировал, ни��то вообще не мог понять, что происходило. Если посмотреть заседание суда [по обжалованию итогов выборов — прим. ред.], окажется, что ни люди, ни наблюдатели, ни сама комиссия не понимали, что происходит. Всё-таки надо было их как-то подготовить к самой процедуре, которая происходила.
Вместо заключения
Мы не хотим сказать, что электронные выборы — это обязательно бардак, постоянные проблемы, странные технические решения и непонимание, что вообще происходит в данный момент.
Тем не менее, как мы видим по этому материалу, вопрос доверия к результатам голосования по сути своей являлся вопросом доверия к его организаторам — взаимодействие с которыми оказалось весьма неоднозначным. Это, как нам кажется, отвечает и на весьма актуальный вопрос о том, имеет ли ДИТ Москвы достаточно опыта для его масштабирования на всю Москву, а тем более — всю страну, и на вопрос о том, можно ли просто взять какую-нибудь «голосовалку с блокчейном», запустить её на сервере и начать проводить выборы.
О том же, можно ли вообще построить цифровую голосовательную систему, доверие к которой обеспечивается самой её архитектурой, а не честностью её авторов — мы поговорим в следующей статье.
