Re: Yes to Publicity! Not to Anonimity! Was: Re: GNOME Foundation Annual Elections - proposal



On Tue, 2003-09-16 at 18:18, George wrote:
> On Tue, Sep 16, 2003 at 05:28:59PM -0600, Andreas J. Guelzow wrote:
> > > Best course of action would be for the voting software to re-send the ballot
> > > with a new unique key (same counter).  But that's getting quite anal.
> > 
> > So if I want to find out whether my subordinate indeed voted for me, I
> > send a request from the employee's account for a new key. That yields
> > the employee's serial number (first 3 digits) that suffice to look up
> > the vote.
> 
> So if the key is re-made on requests (which is what I suggested) then you
> don't.  

Read you own previous reply. You said `same counter'. So I can look up
the vote. THe first 3 digits were supposedly unique.

If you assign a different counter, then it can't be verified whether in
fact only as many valid keys as members were issued. 

> You request it and get a new key.  The employee will try to vote with
> the old key (which you don't know) and will be refused.
> 
> If you can get into your emplyees email then you can get the key in the first
> place.  Obviously though if you want to be independent from your employer you
> vote from home using a personal account (or use encryption).

We will be able to use encryption? That wasn't mentioned before and it
would bve nice to see how you are going to set up that each member will
receive an individually encrypted message. (Of course if you do that,
you may not even need any keys.)

> 
> So I as a voter can take the precaution (using a personal email account to
> vote).
> 
> Can you come up with an example which is not easily refuted? 

Simply you stating that you refuted an issue, does not make it so. You
seem to be changing both the purpose of the change and the proposed
method on the fly without even acknowledging your changes.

>  As in a REAL
> problem?  So far the examples are either incredibly vague (e.g. "secrecy
> makes fraud possible"), not different in old/new scheme and thus irrelevant,
> or obvious and easily preventable by the voter that does care about anonymity
> (e.g. above).

You suggested encryption above. Can you explain this in a working setup?

Can you clarify whether the replacement key will have the same counter
digits (as you said in the previous message) or a new counter as you
imply in this one? 

And perhaps you can come up with an scheme we can stick with at least
for discussing it.

Andreas

Attachment: signature.asc
Description: This is a digitally signed message part



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]