1 |
Hi, |
2 |
|
3 |
(CC-ing all parties interested in technicals, plus main consumers) |
4 |
|
5 |
I'd like to work on providing new web-based frontend for voting |
6 |
in Gentoo elections. It would replace votify in the pipeline but |
7 |
generate countify-compatible data, so the votes would still be counted |
8 |
using old tooling. |
9 |
|
10 |
|
11 |
Goals |
12 |
===== |
13 |
The goals for the new system would be to: |
14 |
|
15 |
1. Improve privacy of votes by removing connection between voters |
16 |
and their confirmation IDs ASAP (not storing them unencrypted |
17 |
on permanent storage at all). |
18 |
|
19 |
2. Unifying voting mechanism for developers and non-developers. |
20 |
The latter currently vote by mail and get their votes manually hacked |
21 |
into the system. |
22 |
|
23 |
3. Removing dependency on dev.gentoo.org shell access for voting. This |
24 |
is implied by 2. but should also support any future efforts of reducing |
25 |
reliance on the single system in Infra. |
26 |
|
27 |
4. Make it possible to use the system for unofficial elections (e.g. |
28 |
team lead votes). Currently setting a vote up requires root privileges |
29 |
on dev.g.o which is not really feasible. |
30 |
|
31 |
|
32 |
Voter UX |
33 |
======== |
34 |
The idea is based on using two tokens: |
35 |
|
36 |
1. *Secret token* which is known only to the voter, and is used to |
37 |
authenticate in order to cast/modify the vote. |
38 |
|
39 |
2. *Voter ID* (formerly: confirmation ID) which is used to |
40 |
pseudonymously identify the vote. While IDs themselves are public, |
41 |
their association with a particular voter is known only to the voter. |
42 |
|
43 |
Ideally, voter_id = KDF(secret_token), so the voter needs only to use |
44 |
one of them while voting and the other will be implicit. |
45 |
|
46 |
|
47 |
Before the election starts, election officials prepare a list of voters |
48 |
containing their e-mail addresses and OpenPGP key fingerprints. They |
49 |
run a script which creates tokens for all voters, encrypts them, then |
50 |
mails them to voters. The flat list of voter IDs (without association |
51 |
to voters) is then stored on the server. |
52 |
|
53 |
During the voting period, voters visit a trivial web-form. They enter |
54 |
their secret token in order to authenticate, and are presented with |
55 |
a simple box to edit their vote. Once the vote is submitted, is it |
56 |
saved using voter ID. The site also lets voter download a copy |
57 |
of the vote for post-election verification. |
58 |
|
59 |
I will also provide a trivial CLI app to preserve the old 'use my |
60 |
favorite editor' voting experience. |
61 |
|
62 |
Once the voting period is over, election official runs another script |
63 |
that collects results and generates countify-compatible data. Then |
64 |
votes can be counted on any system, using the old tooling and results |
65 |
announced as usual. |
66 |
|
67 |
|
68 |
Technical details |
69 |
================= |
70 |
I've been wondering what would be the best implementation. I had two |
71 |
ideas in mind: either absolutely minimal scripting with SSH-based access |
72 |
for election officials, or full-fledged webapp. It's important to avoid |
73 |
low bus factor and follow KISS principle. Our experience shows that |
74 |
maintenance of most of the custom webapps for Infra has become |
75 |
a nightmare, so I think the former is a better option. |
76 |
|
77 |
This means that webapp would be limited to the actual voting. It will |
78 |
be written either in simple Python (without frameworks) or even bash. |
79 |
Votes will be stored in plain text files. |
80 |
|
81 |
Election officials will access the server via SSH. They will be |
82 |
provided with a few scripts to do common things such as setting up |
83 |
the election, generating tokens, mailing voters, collecting results. |
84 |
For anything less common, they will have to edit files directly. |
85 |
|
86 |
We will also provide SSH access to other devs who wish to set up |
87 |
unofficial elections. Access to individual election will be controlled |
88 |
by ownership/permissions, so regular devs won't be able to fiddle with |
89 |
Council or Trustee elections. |
90 |
|
91 |
|
92 |
Your comments |
93 |
============= |
94 |
What are your thoughts? |
95 |
|
96 |
-- |
97 |
Best regards, |
98 |
Michał Górny |