Hello Félix, 2007/5/9, Félix <[EMAIL PROTECTED]>:
We are dealing with the threat of "stealing" the delegation: Someone can be pretending to be someone else in order to attract delegation.
I did not thought about this issue. It would be nice to add such threat scheme on the wiki on the pages related to delegation, security or the faq.
-Second strategy: it's up to every participant to avoid delegation phishing and get the token by a trustful source (read: the person itself, not his website, or another trustful source) I assume that you are taking the second approach, and I support that, in the name of coding simplicity.
In fact, up to now I would favor this second approach, in the name of simplicity. And because there is currently no user interface to use delegation so this part needs more coding. ;-) But nothing would prevent us to implement a "delegation checking" scheme. It remains to see how to do that. Providing a yes-no answer to the question "is this token related to This.NAME?" would break token weak anonymity. Notice that a comment string, entered by the token's owner, is attached to each token and can be changed at will. We can imagine to put there an authentication scheme, like offering an infrastructure to sign the token.
Here we deel with what I call "Weak Delegation Anonymity". This means that you don't want to give your name to everyone because then everyone can delegate to you temporarily in order to know your vote (I know, delegate vote is different to personnal vote, but frankly, who is going to vote differently?). So you only give a token to a person you trust and you hope that this person is not going to "publish" the token and your name together (this is why I call it Weak Delegation Anonymity). Of course the person can do it but it stil provides some protection.
Your analysis is subtle and correct. I pondered the fragility of token anonymity by the ability to create or delete many tokens, with any comment string. And deleting a token does not break the delegation scheme: once a delegation is made, it is no longer attached to the token used to make it but to the internal participant id on the demexp server.
> > Another question: should it be possible to delegate to somebody that > > has never voted on a question (right now, this is impossible)? That's fine with me.
That could be an issue in case of massive delegation, once we will link delegation and classification. A point to analyse and solve in the future. Many thanks for your comments and analysis, Best wishes, d. _______________________________________________ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
