[Licom-l] SecurePoll tally procedure

[Robert Rohde]

Okay, I've managed to update one of my private wikis and install the
SecurePoll extension.

After poking for a while I think I now understand the tally procedure.
 (For future elections we may want to have a discussion about a
simpler process, but for now I think we can make this work.)

So, to answer some of the technical questions I myself posed earlier:

Yes, the software automatically handles overvotes from the same
account on a specific wiki, so that only the most recent vote counts.
However, if the same user votes from multiple different starting wikis
these will need to be struck by hand.  My browsing suggests that 1-2%
of all votes are cross-wiki overvotes.

The vote "dump" creates a list of encrypted votes excluding the votes
that have struck (and the same wiki overvotes).  So, as long as we
completely finish our sockpuppet hunt before creating the dump, the
bad votes will be automatically discarded without being opened (i.e.
reducing the risk of mishandling).

The dumped votes are just votes, no demographic data attaches.  This
is good for user privacy, but also means that all one gets is a single
tally (i.e. no ability to differentiate by user communities).


So, what needs to happen would appear to be the following:

Andrew, Huib and I need to go through the ~18500 ballots to pick out
cross-wiki overvotes (sort by username and look for repeats with
similar IP / browser info) and sockpuppet attempts (e.g. sort by IP
and find repeats with the same browser string).  This will take a
while.  I may write some tool to try and find duplicates more quickly.

Once we are totally and completely satisfied, we generate an official
encrypted vote dump.

Then, and only then, we ask Michael at SPI for the encryption key so
we can open the votes and generate a tally.  The dump plus encryption
key plus Mediawiki plus properly set up SecurePoll extension allows
the votes to be tallied.  I've set up the software on my private wiki
so I can do the tallying, but if anyone else wants to also set it up
for verification purposes, you are more than welcome to do so.

It should be fast to tally once we are ready.  We probably should also
have a plan in place for who, when, and where gets informed about the
results.  The current plan calls for the Board to be informed before
the public, but leaves open issues such as how far before, when the
WMF office is informed, and what channels are used to communicate to
the public.

Any thoughts on this would be appreciated.

-Robert Rohde


On Fri, May 1, 2009 at 6:42 PM, Tim Starling <tstarling at wikimedia.org> wrote:
> SecurePoll tallying procedure, copied to licom-l and Michael Schultheiss.
>
> The best way to do a tally at the moment is to set up a local instance
> of MediaWiki, on your desktop computer. In outline:
>
> * Install MediaWiki from subversion trunk, create the wiki
> * Install SecurePoll from subversion trunk, enable it in LocalSettings.php
> * Create the tables, mysql < SecurePoll.sql
> * Create the vote configuration, using the SQL file which should be
> attached to this message. It's the same as the file I sent to Michael to
> set up the vote at SPI. Michael can confirm that the option IDs in that
> file match the ones in the SPI wiki: 3=yes, 4=no, 5=abstain.
> * Insert the private key. From the mysql command line:
>
> INSERT INTO securepoll_properties (pr_entity, pr_key, pr_value) VALUES
> (1, 'gpg-decrypt-key', '
> ... key goes here...
> ');
>
> * Get the election record, from [[Special:SecurePoll/dump/1]] on the SPI
> wiki.
> * Go to [[Special:SecurePoll/tally/1]] on the local wiki. Upload the
> election record that you got from SPI
> * Results displayed.
>
> I can help with the details when I'm online, grab me on IRC.
>
> That's the best way. The easy way, which is slightly less secure, is to
> insert the private key into the SPI wiki itself, which allows the SPI
> wiki to do its own tallies. Then any election administrator would be
> able to view the tally results via [[Special:SecurePoll/tally/1]].
>
> The security problem with the easy way comes from the fact that a
> compromise of the SPI server in this state would lead to a compromise of
> voter secrecy. There's also a slightly greater potential for a leak of
> an early tally, and a greater potential for abuse of the strike feature
> to influence the results.
>
> -- Tim Starling
>
> _______________________________________________
> Licom-l mailing list
> Licom-l at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/licom-l
>
>