Re: [Demexp-dev] Re: Request for ideas on delegation
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
Re: [Demexp-dev] Re: Request for ideas on delegation
Hi David, On 5/1/07, David MENTRE [EMAIL PROTECTED] wrote: Hello, My own answers, after some coding and thoughts about it. 2007/4/27, David MENTRE [EMAIL PROTECTED]: Internally, I use the participant identifier to identify to whom one wants to delegate a question. Now the question is: what should be the external API for this identifier? I've decided to use a cryptographic token, i.e. a short string, to identify each participant that wants to be a delegate. When one wants to be a delegate for other people, he creates such a delegation token and give it to other people or publish it on his web site. This delegation token is used by a participant when he want to delegate. I have a comment here. We are dealing with the threat of stealing the delegation: Someone can be pretending to be someone else in order to attract delegation. Of course you always have the possibility to check his votes but after a while you become confident and you don't check them anymore and problems arise. Lets call this problem Delegation phishing. I see two strategies to avoid the problem: -First startegy: the delegation phishing prroblem is managed within demexp. You trust the demexp software to garantee that token XYZ corresponds to Alice.Bob.TRUC. In this wcase we need a mechanism that garantees it. -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. Should all participants publish their participant id? Should we use a random identifier associated to a participant id and generated only if a participant wants to be a delegator? In that case, what should be the lifetime of this identifier? Up to 1024 tokens can be simultaneously active for a participant. A participant can create or delete a delegation token at will. They are valid as long as the participant does not remove them. A comment is attached to each token (for example the real user name and email address of the participant). 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. 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. Félix ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
[Demexp-dev] Re: Request for ideas on delegation
Hello, My own answers, after some coding and thoughts about it. 2007/4/27, David MENTRE [EMAIL PROTECTED]: Internally, I use the participant identifier to identify to whom one wants to delegate a question. Now the question is: what should be the external API for this identifier? I've decided to use a cryptographic token, i.e. a short string, to identify each participant that wants to be a delegate. When one wants to be a delegate for other people, he creates such a delegation token and give it to other people or publish it on his web site. This delegation token is used by a participant when he want to delegate. Should all participants publish their participant id? Should we use a random identifier associated to a participant id and generated only if a participant wants to be a delegator? In that case, what should be the lifetime of this identifier? Up to 1024 tokens can be simultaneously active for a participant. A participant can create or delete a delegation token at will. They are valid as long as the participant does not remove them. A comment is attached to each token (for example the real user name and email address of the participant). Another question: should it be possible to delegate to somebody that has never voted on a question (right now, this is impossible)? Right now, this is not possible. That could be an issue in case of massive delegation. Feel free to comment. Best wishes, d. ___ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
