После «блокчейн-голосования» к ДИТ уже невозможно серьёзно относиться и несколько месяцев назад уже было понятно что там сидят некомпетентные люди.
Мне лично непонятны вообще эти «потуги» с пропусками.
1. Граждане понимают что ситуация опасная и сами сидят дома.
2. «Одноразовый» пропуск можно получить одному человеку много раз, имея несколько симок и несколько карт Тройка.
3. Даже если гражданин получает такой пропуск честно, он может за пару часов не активироваться на турникетах (за окном 21 век, а операции у них очень неспешно идут)
4. Информация никак не проверяется
Отсюда возникает вопрос — зачем вообще пропускная система нужна?
Если болезнь опасная — то человек быть изолирован под наблюдением в стационаре и никакое мобильное приложение тут не нужно.
Не важно долго или не долго. Если используется Kubernates — то в каждом сервисе должны быть подняты оконечные точки для liveness & rediness. И до каждого разработчика должно быть донесено, что его сервис не будет запущен на production среде если этого не будет сделано.
В случае если нет HealthCheck с тегом ready, rediness будет всегда выдавать ок. В дальнейшем как только вам понадобится этот функционал у вас появится HostedService который будет соответствующий чекер устанавливать.
Весь каркас занимает дай бог 20 строчек кода.
Асинхронный код для двух вещей:
1. Высокая нагрузка, как следствие много запросов и потоки не должны ждать на Network/IO и прочих операциях и продолжать заниматься полезным делом
2. WPF и графический интерфейс — для удобства
Его не надо пихать везде
Асинхронный код в инициализации не нужен Выстраданный правильный способ инициализации долго запускающегося сервиса:
1. Определить liveness healthcheck /healthz — отвечать ok всегда когда поднят web-сервер
2. Определить rediness healthcheck /healthz/ready — отвечать ok когда все зарегистрированные HealthCheck с тегом ready отвечают что всё в порядке
3. Вынести инициализацию в HostedServic'ы, которые по завершению инициализации выставляет флаги готовности, которые уже считывают HealthCheck.
4. Однажды введенный в строй сервис выводить из балансировки только по факту завершения
5. Настроить liveness probe на /healthz, а rediness probe на /healthz/ready
Мне достаточно того что:
1. Наблюдатели на местах ознакомлены с правилами проведения голосования на участке.
2. Итоговые результаты можно найти на сайте и сравнить с теми что представляют наблюдатели
Т.е. система представляет собой черный ящик в котором можно сверить данные на входе и данными на выходе.
В случае электронного голосования наблюдателям прям перед выборами отказывают в возможности вести наблюдение за блокчейном без каких-либо обоснований. Более того, всё что они видят это кортеж из 4 чисел каждые 15 минут.
P.S. Вы так упорно защищаете этих людей, что кажетесь ангажированным )
Зеленый, красный и синий графики не растут, а растет только желтый. Это подгонка статистики, т.к. до этого число выданных бюллетеней превысило число людей которые правильно ввели СМС
Разработка информационных систем никак не решает кризис человеческих отношений. В случае с электронной системой голосования необходимо, чтобы:
1. Голосующие имели хотя бы базовое представление как это работает
2. Наблюдатели имели понимание системы в такой степени, чтобы понимать когда что-то идет не так.
Для пункта 2 важно, чтобы им дали соответствующие инструменты. Пока я не визуализировал данные было решительно непонятно что происходило. Оператор системы всегда имеет больше всего знаний о системе и всегда имеет способы в той или иной мере на неё повлиять. Если у дежурных программистов нет доступа к проду и нет агрессивного логгирования, то вам требуется на порядок больше ресурсов для проработки и запиливания фич. Любая система голосования в России будет в той или иной форме контролироваться властью. В этом случае для электронной системы способов махинаций в разы больше и они технически легче.
На эту тему есть прекрасный эпиграф в книге «Designing Data-Intensive Applications»:
Technology is a powerful force in our society. Data, software, and communication can be used for bad: to entrench unfair power structures, to undermine human rights, and to protect vested interests. But they can also be used for good: to make underrepresented people's voices heard, to create opportunities for everyone, and to avert disasters.
Проблемой у нас являются не технологии, а тот факт, что российская политическая элита по своему социальному поведению является средневековой. И она будет следовать первому пути, а не второму
Наблюдатели с трудом понимали что там происходило. Например, они знали о факте сбоев, но не могли оперативно оценить масштабы, т.к. их намеренно лишили инструментов мониторинга.
Всё еще смешнее (и одновременно при этом страшнее). Представителей ДИТ суд вообще не привлек в роли заинтересованной стороны. Т.е. они как бы ни причем :-)
Заканчивал ИБ в 2009 году. У нас было довольно много девушек, и отношение некоторых преподавателей на первых курсах к ним было не ахти. Но уже к старшим курсам отношение к тем девушкам, которые сами сдавали экзамены, поменялось. Холодное отношение в самом начале — так принято у людей связанных с криптографией. Мне вот на первом курсе в 2003 году, когда я завалил самую первую свою контрольную Алексей Евгеньевич Жуков сказал что-то вроде «если вам не дано — то стоило выбрать другую кафедру». Это был первый семинар по профильному предмету, который оказался для нашей группы еще и одним из первых семинаров в университете в принципе, и я тогда еще не отошел от шока после школы. Этот факт я вспоминаю всегда с юмором, и это стало неким уроком, если слишком сильно волнуешься — то думать сложнее. Don't worry — be happy, хорошее настроение сохраняет ясный ум. Что касается преподавателей, у них тоже есть свой опыт, у нас на потоке криптографию нормально тянуло дай бог 10% человек, поэтому они совершенно справедливо изначально относятся ко всем холодно.
В течение всего дня система электронного голосования работала стабильно, за исключением одного часа, но мы смогли оперативно устранить неполадку.
Скажите пожалуйста, на чём основывается утверждение что время неполадки составило всего один час?
Мы сделали расчёт, и получили как минимум в 4 раза больше — habr.com/ru/post/480332
Блокчейн тут использовался исключительно в роли места для хранения голосов. У нас в докладе есть еще анализ смартконтрактов — откуда видно, что то всё что касается регистрации голосов в блокчейне выполненно скажем так, немного неаккуратно. Например, смартконтракты позволяют на уровне блокчейна проголосовать пользователю в каждом из трех округов). Т.е. вместо блокчейна можно было использовать обычную БД (У наблюдателей всё равно отобрали возможность подключения к блокчейну незадолго до начала голосования) и это никак бы не ухудшило безопасность системы.
Что касается зарубежного опыта в применении систем электронного голосования, то я его смотрел по этой научной статье
В Эстонии очень большая часть населения живет вне пределов страны, поэтому для их страны это жизненно необходимо. Однако там не достигается полной анонимности.
В Вашингтоне пробовали по почте, но отказались из-за проблем с безопасностью
В Норвегии отказались из-за возможных проблем с тайной голосования и опять же безопасностью
В Австралии работает — www.elections.nsw.gov.au/Voters/Other-voting-options/iVote-online-and-telephone-voting
Мне лично непонятны вообще эти «потуги» с пропусками.
1. Граждане понимают что ситуация опасная и сами сидят дома.
2. «Одноразовый» пропуск можно получить одному человеку много раз, имея несколько симок и несколько карт Тройка.
3. Даже если гражданин получает такой пропуск честно, он может за пару часов не активироваться на турникетах (за окном 21 век, а операции у них очень неспешно идут)
4. Информация никак не проверяется
Отсюда возникает вопрос — зачем вообще пропускная система нужна?
Если болезнь опасная — то человек быть изолирован под наблюдением в стационаре и никакое мобильное приложение тут не нужно.
В случае если нет HealthCheck с тегом ready, rediness будет всегда выдавать ок. В дальнейшем как только вам понадобится этот функционал у вас появится HostedService который будет соответствующий чекер устанавливать.
Весь каркас занимает дай бог 20 строчек кода.
Асинхронный код для двух вещей:
1. Высокая нагрузка, как следствие много запросов и потоки не должны ждать на Network/IO и прочих операциях и продолжать заниматься полезным делом
2. WPF и графический интерфейс — для удобства
Его не надо пихать везде
Выстраданныйправильный способ инициализации долго запускающегося сервиса:1. Определить liveness healthcheck /healthz — отвечать ok всегда когда поднят web-сервер
2. Определить rediness healthcheck /healthz/ready — отвечать ok когда все зарегистрированные HealthCheck с тегом ready отвечают что всё в порядке
3. Вынести инициализацию в HostedServic'ы, которые по завершению инициализации выставляет флаги готовности, которые уже считывают HealthCheck.
4. Однажды введенный в строй сервис выводить из балансировки только по факту завершения
5. Настроить liveness probe на /healthz, а rediness probe на /healthz/ready
Это стандартный функционал вроде как:
docs.microsoft.com/en-US/aspnet/core/host-and-deploy/health-checks
1. Наблюдатели на местах ознакомлены с правилами проведения голосования на участке.
2. Итоговые результаты можно найти на сайте и сравнить с теми что представляют наблюдатели
Т.е. система представляет собой черный ящик в котором можно сверить данные на входе и данными на выходе.
В случае электронного голосования наблюдателям прям перед выборами отказывают в возможности вести наблюдение за блокчейном без каких-либо обоснований. Более того, всё что они видят это кортеж из 4 чисел каждые 15 минут.
P.S. Вы так упорно защищаете этих людей, что кажетесь ангажированным )
1. Голосующие имели хотя бы базовое представление как это работает
2. Наблюдатели имели понимание системы в такой степени, чтобы понимать когда что-то идет не так.
Для пункта 2 важно, чтобы им дали соответствующие инструменты. Пока я не визуализировал данные было решительно непонятно что происходило. Оператор системы всегда имеет больше всего знаний о системе и всегда имеет способы в той или иной мере на неё повлиять. Если у дежурных программистов нет доступа к проду и нет агрессивного логгирования, то вам требуется на порядок больше ресурсов для проработки и запиливания фич. Любая система голосования в России будет в той или иной форме контролироваться властью. В этом случае для электронной системы способов махинаций в разы больше и они технически легче.
На эту тему есть прекрасный эпиграф в книге «Designing Data-Intensive Applications»:
Technology is a powerful force in our society. Data, software, and communication can be used for bad: to entrench unfair power structures, to undermine human rights, and to protect vested interests. But they can also be used for good: to make underrepresented people's voices heard, to create opportunities for everyone, and to avert disasters.
Проблемой у нас являются не технологии, а тот факт, что российская политическая элита по своему социальному поведению является средневековой. И она будет следовать первому пути, а не второму
Скажите пожалуйста, на чём основывается утверждение что время неполадки составило всего один час?
Мы сделали расчёт, и получили как минимум в 4 раза больше — habr.com/ru/post/480332
Что касается зарубежного опыта в применении систем электронного голосования, то я его смотрел по этой научной статье
В Эстонии очень большая часть населения живет вне пределов страны, поэтому для их страны это жизненно необходимо. Однако там не достигается полной анонимности.
В Вашингтоне пробовали по почте, но отказались из-за проблем с безопасностью
В Норвегии отказались из-за возможных проблем с тайной голосования и опять же безопасностью
В Австралии работает — www.elections.nsw.gov.au/Voters/Other-voting-options/iVote-online-and-telephone-voting