[steering-discuss] About elections

Hi Tom,
[...]

Hi :slight_smile:
Agreed. But the founders have shown good strategic planning and good planning
for the future as shown by the way things have played out in the last few
weeks. I think it would take time for newly elected people to have such
commitment to the long-term vision.

Thanks for the flowers as we also say in French :slight_smile:

I have to point out that i am not a founder and not even a regular member. I've
had disagreements and arguments with founders but have always had good reason
to respect even the ones i disagree with.

Even if no more a member of the SC, I will still consider me as a founder. But it's not what is important to my eyes. The importance for me reside in the fact that even if I'm not a SC member, I'll still have a say because I'm a member of the Foundation, and though can express my feeling and my wills for the present or the future of the foundation and it's community.
And I'm sure that the new formed SC will take them into account, we're not new and have always shared our knowledge and experience.

Kind regards
Sophie

Hi :slight_smile:
True. Weirdly i hadn't thought of that point lol :slight_smile:

I think the important issue to vote on is the Apache issue. I was wondering if
it might be possible to collaborate with them to put a wiki-page together on the
TDF wiki so that the different lists can vote on the issue and discuss on the
lists. The vote probably couldn't be taken as definite decision but might be
helpful to gauge general feeling.

Regards from
Tom :slight_smile:

+1

From: sophie <gautier.sophie@gmail.com>
To: steering-discuss@documentfoundation.org
Sent: Mon, 6 June, 2011 12:35:04
Subject: Re: [steering-discuss] About elections

Hi Tom,
[...]
>
> Hi  :)
> Agreed.  But the founders have shown good strategic planning and  good
planning
> for the future as shown by the way things have played out  in the last few
> weeks.  I think it would take time for newly  elected people to have such
> commitment to the long-term  vision.
Thanks for the flowers as we also say in French :slight_smile:
>
> I  have to point out that i am not a founder and not even a regular member.
I've
> had disagreements and arguments with founders but  have always  had good
reason
> to respect even the ones i disagree with.
Even if no  more a member of the SC, I will still consider me as a founder. But
it's not  what is important to my eyes. The importance for me reside in the fact
that even  if I'm not a SC member, I'll still have a say because I'm a member of
the  Foundation, and though can express my feeling and my wills for the present
or  the future of the foundation and it's community.
And I'm sure that the new  formed SC will take them into account, we're not new
and have always shared our  knowledge and experience.

Kind regards
Sophie

Hi :slight_smile:
True.  Weirdly i hadn't thought of that point lol :slight_smile:

I think the important issue to vote on is the Apache issue.

Vote on what exactly ?

I was wondering if
it might be possible to collaborate with them to put a wiki-page together on the
TDF wiki so that the different lists can vote

I don't think we have a say and even less a vote on what Apache
Foundation is going to do.

First we have to see what they decide and if they are indeed going
forward with their plan to fork, (granted there is not much suspense
there)
Then we have to see _how_ they're going to do it
Then we have to see _when_/_if_ the poddle graduate
Then we have to see _what_ they end-up doing.
Until then it is pretty much vaporware and there is not much to do,
even less to vote about.

Norbert

100% agreed. I'm eager to vote in support of / on our SC - since it
seems some criticise them for being un-elected :slight_smile: Nice to knock down
all the objections one by one of course.

  ATB,

    Michael.

+1

+1

Hi,

FYI: We asked the Membership Committee to follow-up with some information on membership status and elections soon, so stay tuned. :slight_smile:

Florian

Practical question:

Shouldn't the MC start collecting ssh public-key ?
People having commit access to git or login to any infra box already
have one available... but some member may not have one already on file
and collecting them with some level of chain of trust may not be
completely trivial, and more importantly, may induce some significant
delay.

I suppose the the election won't be conducted in-person, but
presumably on-line... some level of temper-proof seems necessary, if
for no other reason than to avoid FUD and smear campaign about the
legitimacy of our process (there have been enough of that already in
the blog of a notorious Big Blue employee)

Norbert

Completely orthogonal to all the OOo and Apache stuff going on... the
ASF has an online voting tool that you guys may be interested in.
There is both a command line version (for ssh users), and a web-based
version (if you guys also have web-based authentication for your
Members). That tool may be useful for you guys. It provides for secure
and private/secret voting. Just select a few people to do the vote
counting, and away you go.

It is located in a private repository, but I see no reason that it
couldn't be public (simply a historic accident, I believe). If you're
interested, I can snap a copy of the command line stuff. For the
web-based version, please ask on infrastructure@apache.org.

Cheers,
-g

Hi,

I remember that, some time ago, Michael Meeks suggested OpenSTV as a
tool (http://www.openstv.org/).

Hi Norbert,

Hi,

FYI: We asked the Membership Committee to follow-up with some information on
membership status and elections soon, so stay tuned. :slight_smile:

Practical question:

Shouldn't the MC start collecting ssh public-key ?
People having commit access to git or login to any infra box already
have one available... but some member may not have one already on file
and collecting them with some level of chain of trust may not be
completely trivial, and more importantly, may induce some significant
delay.

I suppose the the election won't be conducted in-person, but
presumably on-line... some level of temper-proof seems necessary, if
for no other reason than to avoid FUD and smear campaign about the
legitimacy of our process (there have been enough of that already in
the blog of a notorious Big Blue employee)

We were used to LimeSurvey, from what I remember it can be used on invitation only and password protected generated by the survey admin. For me it has several advantages, among them a simple UI that you can customize and localize. UX could you use it also for their surveys.
But I'm open to other tools of course, this is just because I'm pretty used to this one and we have already use it for voting campaigns

Kind regards
Sophie

Oh, then it's all good.... I was just wondering about the logistic...
looks like the MC has things under control... very good :slight_smile: carry on
:smiley:

Norbert

Hi Greg,

Completely orthogonal to all the OOo and Apache stuff going on... the
ASF has an online voting tool that you guys may be interested in.
There is both a command line version (for ssh users), and a web-based
version (if you guys also have web-based authentication for your
Members). That tool may be useful for you guys. It provides for secure
and private/secret voting. Just select a few people to do the vote
counting, and away you go.

It is located in a private repository, but I see no reason that it
couldn't be public (simply a historic accident, I believe). If you're
interested, I can snap a copy of the command line stuff. For the
web-based version, please ask oninfrastructure@apache.org.

thanks a lot for the offer, much appreciated! I'd like to give this task to the MC. If they need support from the infrastructure side, I am happy to help out, of course, and will ping you about the tool. :slight_smile:

Thanks for sharing!

Florian

Right. STV (Meek) is a key part of the election and bylaws since it
produces a 'fair' result; it requires ranking the candidates.

  I strongly suggest we simply copy the GNOME process here; this
generates a unique random key per person which is mailed out, and used
instead of a name when voting; thus the voting record can be published,
and independently analysed while keeping it anonymous (outside of the MC
that is).

  The PHP etc. code for the GNOME voting website is here:

http://git.gnome.org/browse/foundation-web/tree/foundation.gnome.org/vote

  With the (per year) voting template mail, and to generate and mail the
tokens the code is here:

  http://git.gnome.org/browse/foundation-web/tree/bin

  To analyse the results, OpenSTV is used I think, and the results
published:

  http://foundation.gnome.org/vote/results.php?election_id=14

  along with the complete voter record:

  http://foundation.gnome.org/vote/votes.php?election_id=14

  It is possible that Maemo re-used the code and made it more generic;
not sure - Dave might know (?).

  I hope that helps,

  ATB,

    Michael.

Hi,

Michael Meeks wrote:

  It is possible that Maemo re-used the code and made it more generic;
not sure - Dave might know (?).

When I got it, the code had the anonymous token/voter token system for
anonymising votes already, but used the old "pick N, and we aggregate
all the choices to get the result" GNOME system. I wanted STV with
fractional transfer, so I modified step 2 and 3 to use (not working on
IE 6 or 7) Javascript to generate the candidate list on the fly, allow
the voter to order them, and then submit the ordered ballot. I also
modified the database structure to handle the ordering, and added a page
to download all ballots in the OpenSTV .blt file format.

I did all that for Maemo, and then GNOME copied the code back :slight_smile: I don't
think any major changes beyond making it fit with stylesheets was done
to the code when GNOME reused it.

So the balloting code's in use by at least 2 communities at this point.

One thing we don't do, which I believe other former Sun projects do, is
venerate the results on the fly using OpenSTV. Someone needs to download
the ballots, generate the result, and store it. Shouldn't be too hard to
accomplish, but currently a gap.

Cheers,
Dave.

I strongly suggest we simply copy the GNOME process here; this
generates a unique random key per person which is mailed out, and used
instead of a name when voting; thus the voting record can be published,
and independently analysed while keeping it anonymous (outside of the MC
that is).

Just to make sure I understand it correctly:
it is 'anonymous' but each voter know _his_ anonymous token and
therefore can verify that his vote has been recorded accurately, by
cross-checking the published details-values right?
and that is the basis of the temper proof mechanism.
It is incumbent on each member to make sure that he received his token
and that is vote is correctly counted. (that his make sure that his
email didn't get intercepted somehow, or that the MC did not received
a spoofed email).
I think that pgp/gpg-signing these email would remove some possibility
to interfere with the process.
(note that if you add encryption of the vote-email then you can even
achieve end-to-end anonymous(1) voting as long as the group that
verify the signatures is not the group that decode the encrypted vote)

To analyse the results, OpenSTV is used I think, and the results
published:

OpenSTV is GPL, but only available for download for a fee.
It would be nice to find a way for anyone, or at the very least for
Members, to be able to use the raw result and re-calculate the result
for themselves...
( to temper proof the last step )

Norbert

PS: Not that I am overly concerned about election tempering... but as
the saying goes: Trust but Verify :slight_smile: and I'd like to avoid, as much
as possible, any room for controversy on that topic.

(1) Although we want to be open and transparent, open voting on issue
is good, but when we vote on 'person, candidate', it is indeed
probably better, to avoid 'poison', to keep that anonymous... but the
worse is a partial anonymous, where things are anonymous except for
the ones 'in the know'. And again this is not a concern about any
individual.. processes we put in place should be design to to provide
lasting stability, not relying on _everybody_ involved doing the right
things at all time..

Hi,

Norbert Thiebaud wrote:

       I strongly suggest we simply copy the GNOME process here; this
generates a unique random key per person which is mailed out, and used
instead of a name when voting; thus the voting record can be published,
and independently analysed while keeping it anonymous (outside of the MC
that is).

Just to make sure I understand it correctly:
it is 'anonymous' but each voter know _his_ anonymous token and
therefore can verify that his vote has been recorded accurately, by
cross-checking the published details-values right?

I can explain the mechanism.

Before the election, a unique token is generated for every voter, and
stored with their email address. This token is mailed out to the voter.
Obviously, since these are stored together, there is no anonymity at
this point.

When I vote, I use my email address and this token to authenticate. Then
I'm brought to a page where I can order the candidates in order of
preference.

On successfully voting, a unique anonymous token is created, and stored
in an anonymous token table. This token is used (along with a
preference) to identify which candidates I voted for, and in what order.
The temporary token associated with the email address is at this point
deleted, leaving no way to connect the email address to the anon token.
Then we communicate the anonymous token to the voter, and tell him to
write it down somewhere so that he can check his vote later.

At the end of the election, this does leave us some standard election
type stuff you can do:
* we can tell whether someone has voted or not (but not how they voted)
by checking the temporary auth tokens still left in the database.
* We can publish the ballots, identified by the anon token, so anyone
can check the results, and check their own ballot, but not how others voted.

and that is the basis of the temper proof mechanism.

Yes, basically.

There are of course security weak-points here. The first and weakest is
the voter's email client: if I gain access to the voter mail, I can vote
in the place of someone using their email & token. The second is the
database itself: if I can get access to the authentication tokens and
the electorate, I can vote for anyone at all.

In principle, we can address the first with gpg, but not everyone
uploads a pgp key. The latter implies trusting the administrators of the
system to be honest. There are ways to encrypt the entire chain with
private key cryptography, but for us that would have complicated the
voting process for a substantial number of people, and been overkill.

It is incumbent on each member to make sure that he received his token
and that is vote is correctly counted.

Yes - we can of course resend tokens, and we announce the tokens have
been sent publicly. Until someone votes, we can get & resend the
temporary token easily.

(that his make sure that his
email didn't get intercepted somehow, or that the MC did not received
a spoofed email).

Yes, this is the weak point, as I said. pgp signed proves providence,
but doesn't prevent interception. pgp encryption would do the latter,
but not the former.

I think that pgp/gpg-signing these email would remove some possibility
to interfere with the process.

You would also need to pgp encrypt the temporary token with the voter's
public key to ensure that the election administrator can't vote on
behalf of people.

OpenSTV is GPL, but only available for download for a fee.

Really? News to me! It wasn't up until OpenSTV 1.6. I'd be happy to
share my copy with anyone who needs it.

Ooh: I just saw this on the openstv blog: http://www.openstv.org/node/133

If you have <=10 candidates and <=1000 voters, you can do the voting
online, with hosted OpenSTV.

It would be nice to find a way for anyone, or at the very least for
Members, to be able to use the raw result and re-calculate the result
for themselves...

Why not buy one copy of the source code and share it among OOo members
who don't want to pay $5 to Jeff?

PS: Not that I am overly concerned about election tempering... but as

Funny - I *just* realised that you meant "tamper" - I honestly thoughht
you wanted to "temper" (ie harden) the process. Sorry - that just amused
me - not picking on your grammar or anything.

Cheers,
Dave.

Hi,

Thanks for the explanations...
[...]

Then we communicate the anonymous token to the voter, and tell him to
write it down somewhere so that he can check his vote later.

how does one figure out what information is in the token ?
iow. given my token, or any token for that matter can I independently
verify what voe is encoded in it ?

[snip]

Funny - I *just* realised that you meant "tamper" - I honestly thoughht
you wanted to "temper" (ie harden) the process. Sorry - that just amused
me - not picking on your grammar or anything.

:smiley:

I'm painfully aware of my weak spelling/grammar, even in my native
language I do a lot of these :slight_smile:
It is not helped by my fingers inability to keep up with my
thoughts... and my notorious laziness in proof-reading :slight_smile:

Norbert

Hi,

Norbert Thiebaud wrote:

Then we communicate the anonymous token to the voter, and tell him to
write it down somewhere so that he can check his vote later.

how does one figure out what information is in the token ?
iow. given my token, or any token for that matter can I independently
verify what voe is encoded in it ?

There is no information in the token. You can see the code that
generates it here:
http://vcs.maemo.org/svn/maemo2midgard/maemo-elections/vote/include/step4-commit.php

We store the token in one table (election_anon_tokens) with the
election_id (after a uniqueness check), then store the votes of the
person in the election_votes table, with the highest preference in
($election_id, $token, $cand1, 1), second preference ($election_id,
$token, $cand2, 2), etc.

I guess we could encode the person's vote in the token also, if there
were a good reaso,... but that's not what we do now.

Cheers,
Dave.