Re: [gentoo-project] [pre-GLEP] Secrecy-respecting voting mechanism for Gentoo projects

[Alec Warner]

On Sat, Aug 28, 2021 at 3:30 AM Michał Górny <mgorny@g.o> wrote:
>
> Hi,
>
> Please review the following pre-GLEP.
>
> ---
> GLEP: 9999
> Title: Secrecy-respecting voting mechanism for Gentoo projects
> Author: Michał Górny <mgorny@g.o>
> Type: Standards Track
> Status: Draft
> Version: 1
> Created: 2021-08-27
> Last-Modified: 2021-08-27
> Post-History: 2021-08-27
> Content-Type: text/x-rst
> ---
>
> Abstract
> ========
>
> A new voting system is devised with the aim of providing a single voting
> system for all Gentoo elections and votes.  Automation is used to
> eliminate the human bottleneck in processing the elections.  Votes are
> submitted via random identifers, and the identifiers are sent to voters
> via encrypted e-mail to protect the vote secrecy.  E-mail is used to
> enable non-developer voters to participate.
>
>
> Motivation
> ==========
>
> The votify/countify tooling used to run Gentoo elections dates back
> to 2005.  While it still serves it purpose, it has grown antiquated
> and is facing a few problems that are discouraging the developers from
> using it.  These are:
>
> The problems with the current tooling include:
>
> 1. The elections require a lot of manual setup and attention.  This is
>    causing noticeable delays and can raise doubts about the validity
>    of elections.  For example, voters can still submit or modify votes
>    after the deadline until the infra official collects them.
>
> 2. The vote secrecy is not respected properly.  While the voting is
>    ongoing, the votes are stored in voters' home directories.  Any
>    person with superuser access to dev.gentoo.org is capable of reading
>    the votes.  Furthermore, there has been a case of votes being
>    accidentally disclosed to the mailing list by election officials.

Why do you want secret elections?

>
> 3. Including non-developers as voters is cumbersome and potentially
>    violates the vote secrecy.  In the past, it has been either done by
>    creating temporary accounts on dev.gentoo.org, or requiring the votes
>    to be sent openly via mail and therefore known to the election
>    officials.
>
> At this point, votify is  practically used only for the Council
> and Trustee elections.  The late attempts of using it for the Base
> System and Security project elections have resulted in a lot of
> frustration from the developers participating.  The vast majority of
> project elections are currently run using third-party services or plain
> mail votes.

I'm not sure disclosing "frustration" is sufficient. If there was
frustration (and FWIW I believe there was) it would be great to get
some detail on the list.

>
> The goal of this GLEP is to propose a new voting system that meets
> the expectations of developers better, and can be easily used to run
> elections and referenda by Gentoo developers and projects.
>
>
> Specification
> =============
>
> Requirements for the election system
> ------------------------------------
>
> The new election system should meet the following requirements:
>
> 1. Gentoo developers should be able to start a new election/referendum
>    without requesting manual attention of any other individuals.
>
> 2. The election system should cover the nomination phase if it is
>    applicable, providing the necessary automation to assemble the final
>    candidate list.
>
> 3. All deadlines should be enforced automatically, and results should
>    be published automatically as well.  In particular, it must not be
>    possible to modify votes after the final deadline.
>
> 4. The secrecy of the votes must be protected to the best of ability.
>    This includes both associating a particular vote with a voter,
>    as well as determining whether a voter in question has cast a vote.
>
> 5. The system should make it easy for non-developers to cast a vote
>    on the same terms as developers.

This seems like a fairly generic problem; are we not sure that a
solution already exists?

>
>
> The election process
> --------------------
>
> Each election/referendum consists of the following steps:
>
> 1. A developer creates a new election/referendum.  During this step,
>    the developer specifies whether the boundary dates for each election
>    phase, the voter list and the (potential) candidates.
>
> 2. If the nomination phase is applicable, the system accepts nominations
>    from the voters.  Each nominated candidate is mailed about
>    the nomination, and given the explicit choice of accepting
>    or declining it.  If the nomination is accepted, the candidate may
>    also upload a manifesto.
>
> 3. When the voting phase beings, the system creates random identifiers
>    for all voters.  Each identifier is encrypted using voter's PGP key
>    and sent via email to the voter.  The voter-identifier mapping is
>    discarded immediately to reduce the risk of it leaking.
>
>    If the nomination phase was enabled, the system also creates
>    the final candidate list from nominees who accepted their nomination.
>
> 4. Voters submit their votes using their random identifiers.
>
> 5. When the voting phase ends, the system publishes the results
>    and the master ballot.
>
>
> Rationale
> =========
>
> In the proposed system, the whole election process is automated from
> the point of creating the election, through nominations and voting
> phases, to publishing the results.  Any developer can easily start
> an election without hitting a manpower bottleneck.  This should make it
> possible to use the new election system both for major elections such
> as the Council elections, and small in-project elections and votes.
>
> The elections/votes can be either based on predefined candidate/option
> list, or run a semi-automated nomination phase, to account for various
> kinds of elections.
>
> The system is largely based on mail, making it possible to easily
> include voters who are not developers.  The most important mails are
> PGP-encrypted to provide the necessary authentication for voters
> and protect their secrecy.
>
> This GLEP does not enforce a specific UI to the voting system.
> An example solution would be to provide a simple web-based UI to handle
> nominations and cast votes, using URLs with random identifiers sent via
> mail.  Such a system would make it easy for non-developers
> to participate.  Creating and managing elections could be done locally
> using scripts on dev.gentoo.org.
>
> As long as the underlying tooling is not tampered with, the system
> protects the vote secrecy through use of random identifiers.
> The association between a random identifiers and a voter name is
> preserved only for the short time needed to encrypt the identifier
> and send it via mail.  Afterwards, the association is discarded.
>
> After the election concludes, the master ballot is published
> and the voters can both verify the election results, and confirm that
> their vote has been included in it.
>
> The system does not provide the ability to establish whether
> a particular voter has cast a vote or not by design.  This makes it
> unsuitable for Trustee elections.
>
>
> Backwards Compatibility
> =======================
>
> The new system can replace the use of votify script, with the exception
> of Trustee elections that require the ability to determine who have
> voted.  However, there is no reason not to deploy it alongside the old
> one.

I'm currently a trustee; and I do not necessarily desire a secret
election for board members; so I'm fine with not using this proposal
for that.

>
>
> Reference Implementation
> ========================
>
> Not complete.
>
>
> Copyright
> =========
> This work is licensed under the Creative Commons Attribution-ShareAlike
> 3.0
> Unported License. To view a copy of this license, visit
> https://creativecommons.org/licenses/by-sa/3.0/.
>
>
> --
> Best regards,
> Michał Górny
>
>
>