Да, но решать это будет сам пользователь, а не кто-то за него. У пользователя не будет выбор «доверять и голосовать» или «не доверять и не голосовать». У него будет выбор «доверять кому-то и голосовать». При этом кому доверять, он будет выбирать сам.
По нашим оценкам, возможность подделать результаты тайного голосования будут ничтожно малы. Их можно будет сорвать. С риском разоблачения тех, кто это сделал. Но и только.
Я уже писал, подкуп — это тоже вариант выбора пользователя. Его никто не принуждает к такому варианту. Он самостоятельно его выбрал. Так что это — вполне «законный» метод голосования.
При угрозе увольнения, если начальник не стоит за спиной когда вы голосуете (что должно быть юридически наказуемо), вы в любом случае можете придумать способ его обмануть. Будете-ли вы это делать — это тоже ваш осознанный выбор.
«решение о валидности «документа» принимается типа голосованием узлов»
Решение о валидности документа проверяется по ЭЦП этого документа и принадлежности этой ЭЦП валидному пользователю. Сделать это может любой участник системы.
«В коде, утрируя, на брэйнфаке лично я никогда не разберусь.»
Конечно. Есть множество людей, которые не разберутся в коде. Для этого у нас предусмотрен способ распространения установочных пакетов, подписанных персональными ключами экспертов, которые поручаются за то, что в данном экземпляре установщика нет закладок и он работает правильно. При этом у пользователя будет выбор из множества вариантов и он сам будет решать кому из экспертов доверять. В случае обнаружения проблем в подписанном коде, соответствующая рекция обратной связи мгновенно следует через систему взаимного доверия. И больше данной группе экспертов никто не будет доверять.
Ааа! Ну, это другое дело. В данном случае вы все верно написали. Тем не менее, я настаиваю на том что это неправильный способ работы с закрытыми ключами. И не имеет значения насколько он часто встречается на практике.
Ну, может я не так понял. В нашей системе реализуется распределенное доверие. Не доверие кому-то одному, кто может им злоупотребить, а доверие методике голосования, доверие экспертам, которые буду подписывать коды программ и т.д. Главное что у человека есть выбор в этой системе кому доверять, а кому нет. Мы не заставляем его верить 10-и людям в ЦИК или автору программы голосований.
Критерии свершившегося голосования будут вполне формальными. Которые сможет проверить любой.
А вот «при согласии» — вполне убедительно. Т.к. только сообщество в целом сможет решить открывать-ли пути прохождения ключей. Вполне нормальная защита от злоупотреблений. Никто не дает никаких гарантий, конечно. Однако, как я уже писал, подразумевается что участники системы заинтересованы в честных голосованиях и выявлении мошенников. Поэтому они будут содействовать попыткам очистить сеть от злоумышленников.
С какой стати? Ваш закрытый ключ нужен только на этапе формирования вами запроса на сертификат. Дальше вы отправляете запрос и УЦ подписывает его своим ключем. Ваш закрытый ключ при этом нигде в УЦ не фигурирует. Вы его ставите в настройках своего HTTP сервера вместе с сертификатом.
«Достоверное тайное голосование возможно, по-моему, только при полном доверии процессу голосования и подсчёта голосов.»
Вы немного не так сформулировали. Вероятно, вы хотело написать «при полном доверии к людям, осуществляющим процесс голосования и подсчета голосов». И в этом принципиальное отличие наших позиций. Мы не собираемся от кого-либо требовать к кому-то доверия. По крайне мере, мы стараемся максимально от этого уйти.
Однако, основная цель введения идентифицирующего хэша, все-таки не скрытие персональных данных, а создание «удобного» персонального идентификатора, который не будет входить в противоречение с законом о ПД.
«Имея базу ПДн можно заранее просчитать хэши и по приходу хэша идентифицировать субъекта.»
Разумное замечание. Пока мы не знаем как с этим бороться. К сожалению, введение в идентифицирующий хэш информации известной только владельцу не позволит независимо проверять его правильность. А создание специального центра для этого противоречит принципу отсутствия особых людей и серверов.
Как минимум тем, что все голоса передаются в систему в зашифрованном виде. До признания того, что голосование состоялось, никакие голоса не раскрываются.
Отслеживание-же источника голосов в случае признания что было существенное количество вбросов — по цепочкам распространения голосов при согласии на то владельцев узлов, через которые эти голоса шли в распределенной сети голосования. Т.е. владелец узла может сам проанализировать результаты голосования, сам понять что вбросов действительно много и предоставить информацию о прохождении пакетов, относящихся к данному голосованию.
Отмечу еще раз — при этом все голоса остаются зашифрованными.
Да ну? Я вот всегда ключи к такому сертификату сам генерирую. И никогда еще удостоверяющий центр у меня не требовал предоставить закрытый ключ для этой процедуры.
Да нет — меняем. Мы в своей системе стараемся сильно усложнить технически те способы мошенничества, на которые мы можем повлиять. На «давление» и «подкуп» мы повлиять в принципе не можем, т.к. эти действия происходят вне контекста IT системы. А «там, где ты не на что не способен, ты не должен ничего хотеть». Мы признаем эту проблему, но так-же признаем что на своем уровне мы не можем на нее повлиять.
Тем не менее, это не означает что ничего не надо делать. Мы стараемся решить те проблемы, которые, по нашему мнению, мы можем решить.
Неверно. Софт будет подписываться экспертами. Кому из экспертов доверять, будет выбирать сам пользователь.
При угрозе увольнения, если начальник не стоит за спиной когда вы голосуете (что должно быть юридически наказуемо), вы в любом случае можете придумать способ его обмануть. Будете-ли вы это делать — это тоже ваш осознанный выбор.
Решение о валидности документа проверяется по ЭЦП этого документа и принадлежности этой ЭЦП валидному пользователю. Сделать это может любой участник системы.
Конечно. Есть множество людей, которые не разберутся в коде. Для этого у нас предусмотрен способ распространения установочных пакетов, подписанных персональными ключами экспертов, которые поручаются за то, что в данном экземпляре установщика нет закладок и он работает правильно. При этом у пользователя будет выбор из множества вариантов и он сам будет решать кому из экспертов доверять. В случае обнаружения проблем в подписанном коде, соответствующая рекция обратной связи мгновенно следует через систему взаимного доверия. И больше данной группе экспертов никто не будет доверять.
А вот «при согласии» — вполне убедительно. Т.к. только сообщество в целом сможет решить открывать-ли пути прохождения ключей. Вполне нормальная защита от злоупотреблений. Никто не дает никаких гарантий, конечно. Однако, как я уже писал, подразумевается что участники системы заинтересованы в честных голосованиях и выявлении мошенников. Поэтому они будут содействовать попыткам очистить сеть от злоумышленников.
Вы немного не так сформулировали. Вероятно, вы хотело написать «при полном доверии к людям, осуществляющим процесс голосования и подсчета голосов». И в этом принципиальное отличие наших позиций. Мы не собираемся от кого-либо требовать к кому-то доверия. По крайне мере, мы стараемся максимально от этого уйти.
Разумное замечание. Пока мы не знаем как с этим бороться. К сожалению, введение в идентифицирующий хэш информации известной только владельцу не позволит независимо проверять его правильность. А создание специального центра для этого противоречит принципу отсутствия особых людей и серверов.
Отслеживание-же источника голосов в случае признания что было существенное количество вбросов — по цепочкам распространения голосов при согласии на то владельцев узлов, через которые эти голоса шли в распределенной сети голосования. Т.е. владелец узла может сам проанализировать результаты голосования, сам понять что вбросов действительно много и предоставить информацию о прохождении пакетов, относящихся к данному голосованию.
Отмечу еще раз — при этом все голоса остаются зашифрованными.
Тем не менее, это не означает что ничего не надо делать. Мы стараемся решить те проблемы, которые, по нашему мнению, мы можем решить.