Проект "Свободные голосования"

Согласен что может помочь. Но алгоритм очень сложный может получиться.

_________________
89DC B598 306B 26C8 B9AA 5C0C CFB6 7184 B2B2 FF17

На самом деле, Сергей дело пишет. В идеале у нас должна быть распределенная сеть голосований. А в такой никакого центрального ключа просто не может быть.

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

Вообще, тогда надо предусмотреть процедуры подписания ключей. Например, что-нибудь типа такого...

1. Проверяющий (любой пользователь) отправляет проверяемому подписанный своей подписью запрос с предложением о проверке и подписании ключа.
2. Проверяемый обязан в течении 14 дней отправить подписанный своей подписью ответ с согласием.
3. Если проверяющий не получает в течении 14 дней согласие, то он должен как-то зарегистрировать это событие в системе. При этом уровень доверия проверяемого ключа снижается.
4. Если проверка прошла неудачно, по окончанию 14-дневного срока производиться еще одна попытка связаться с проверяемым. Если и она в течении следующих 14 дней не увенчается успехом - ключ считается поддельным, блокируется и инициируется проверка всех, кто подписал данный ключ.
5. Если процедура завершилась удачно, об этом будет свидетельствовать подпись проверяющего на ключе проверяемого до истечения срока проверки.

Вообще, всю эту процедуру хорошо-бы вести через какой-то отдельный сервер, на котором будет регистрироваться каждый ее шаг. И при этом сам сервер будет дублировать предупреждения проверямым, что-бы не было мухлежа - когда проверяющий инициировал процедуру проверки, а сообщить о ней проверяемому "забыл". Ну и кроме того, на сервере надо-бы отслеживать все сроки данной процедуры.

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

Согласен процедура нужна, но она должна носить не обязательный, а рекомендательный характер.

Да, хорошо, но думаю надо ограничить количество запросов по времени, например не больше 3 запросов в сутки, иначе возможны случаи когда кто то начнет просто спамить запросами.

Думаю, что он должен снижаться катастрофически и система должна сообщить проверяемому об этом.

Согласен и всех кто подписан данным ключом тоже надо проверить.

И соответственно рейтинг проверяемого повышается.

Да хорошо было бы так сделать.

_________________
89DC B598 306B 26C8 B9AA 5C0C CFB6 7184 B2B2 FF17

Сергей, проблема в нашем случае в том, что другой пользователь может лишь подписать ключ, а не может указать что ключ поддельный. Т.е. тут наблюдается некоторая асимметрия, которую нам придется устранять сторонними средствами.

Естественно, что процедура подписания будет добровольной со стороны проверяющего. Со стороны проверяемого она должна быть обязательной. Иначе виртуалы расплодятся.

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

Согласен. Тем более, если это будет централизовано, это можно организовать.


Да - я это и имею ввиду. Уровень будет снижаться до того, который не позволяет принимать участие в голосованиях.




Ну, тут, в общем-то принцип дискретный - ключ либо не допускается к голосованию либо допускается. Отсутствие проблем с проверкой ключа и нужное количество подписей у него подразумевает что ключ допущен.



Хотя, это плохо с точки зрения децентрализации системы. Но пока других вариантов я не вижу.

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

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

Т.е. эта процедура не исключает обычный процесс подписания - без регистрации на этом специальном сервере.

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

Тогда мы не сможем проверять ботов - они будут проверять сами себя ^_^.
Да еще и нас запросами на проверку замучают.
Сервер для таких проверок - еще одно уязвимое место.

Чем проще система - тем устойчивее она.

Давайте будем действовать итерациями. На данный момент предлагаю сделать проверку по количеству подписей и ограничится этим пока не будут другие идеи.

Юрий, этого недостаточно. Вот представьте... Сделал я сеть виртуалов из 100 ключей. Вы обратились к одному из виртуалов что-бы проверить и подписать его ключ. Я от имени этого виртуала отвечаю что не могу и придумываю причину почему не могу. Так-же я отвечаю на любые другие попытки проверки любого из этих виртуалов. Если все оставить как есть, так эта сеть и просуществует и будет голосовать.

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

Кстати, такие сервера, на которых будет проводится процедура подписания ключей, можно сделать и распределенными. Технически, это вроде как не очень сложно сделать. Даже без Freenet, а чисто на уровне приложения.

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

Если сделать ограничения на частоту проверок, то мои виртуалы будут постоянно проверять друг друга, так чтоб другие пользователи не могли их проверить (из-за лимита).

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

Для этого необходимо, чтобы выполнялось следующее условие: активным ключ должен становиться только после подписания n другими "рассредоточиными" ключами. Под словом "рассредоточиные" я подразумеваю ключи расстояние между которыми максимально. Собственно я в работе...

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