1 |
On Fri, 2019-08-09 at 05:49 +0000, Robin H. Johnson wrote: |
2 |
> On Sat, Jul 27, 2019 at 11:40:12AM +0100, Roy Bamford wrote: |
3 |
> > On 2019.07.27 07:21, Michał Górny wrote: |
4 |
> > > Hi, |
5 |
> > > |
6 |
> > > (CC-ing all parties interested in technicals, plus main consumers) |
7 |
> > > |
8 |
> > > I'd like to work on providing new web-based frontend for voting |
9 |
> > > in Gentoo elections. It would replace votify in the pipeline but |
10 |
> > > generate countify-compatible data, so the votes would still be counted |
11 |
> > > using old tooling. |
12 |
> > > |
13 |
> > > |
14 |
> > > Goals |
15 |
> > > ===== |
16 |
> > > The goals for the new system would be to: |
17 |
> > > |
18 |
> > > 1. Improve privacy of votes by removing connection between voters |
19 |
> > > and their confirmation IDs ASAP (not storing them unencrypted |
20 |
> > > on permanent storage at all). |
21 |
> > > |
22 |
> > > 2. Unifying voting mechanism for developers and non-developers. |
23 |
> > > The latter currently vote by mail and get their votes manually hacked |
24 |
> > > into the system. |
25 |
> > > |
26 |
> > > 3. Removing dependency on dev.gentoo.org shell access for voting. |
27 |
> > > This |
28 |
> > > is implied by 2. but should also support any future efforts of |
29 |
> > > reducing |
30 |
> > > reliance on the single system in Infra. |
31 |
> > > |
32 |
> > > 4. Make it possible to use the system for unofficial elections (e.g. |
33 |
> > > team lead votes). Currently setting a vote up requires root |
34 |
> > > privileges |
35 |
> > > on dev.g.o which is not really feasible. |
36 |
> > > |
37 |
> > |
38 |
> > 5. Election Officials shall have a means to determine the voter turmout |
39 |
> > from time to time while the election is in progress. |
40 |
> |
41 |
> 6. The voting system must produce a list of voters who cast a valid |
42 |
> ballot. This is required to see which voters did not cast a ballot in |
43 |
> the Foundation elections, and could thus be struck off the member list |
44 |
> for failure to participate. |
45 |
> |
46 |
> This might be implemented via two separate identifiers from the secret |
47 |
> per your ideas. |
48 |
|
49 |
Do I understand correctly that you want: |
50 |
|
51 |
1. one derived identifier to be used to cast the vote and stored without |
52 |
association to developer, |
53 |
|
54 |
2. another derived identifier to be used to confirm the vote, and stored |
55 |
with association to developer? |
56 |
|
57 |
I suppose this could work. However, it would weaken the privacy |
58 |
protection much. Any active watcher (say, Infra or election official) |
59 |
would be able to notice simultaneous appearance of the vote |
60 |
and the voter entry. Sure, they could also break the system by hacking |
61 |
the scripts over or adding voters manually rather via the script |
62 |
but the whole point is to limit privacy exposure to the minimum. |
63 |
|
64 |
Furthermore, I believe the fact whether one has voted or not is also |
65 |
a matter of privacy. Expecting people to explicitly indicate this is |
66 |
violating it, so it doesn't seem the correct solution to the problem |
67 |
at hand. |
68 |
|
69 |
Maybe Trustees should consider finding a better way of determining when |
70 |
to retire inactive members? The simplest solution that comes to my head |
71 |
is finally requiring all Foundation members to be active developers, or |
72 |
at least setting same rules for both groups (i.e. retiring Foundation |
73 |
members when they stop making new contributions to Gentoo). Given that |
74 |
there are only a few Foundation members who are not devs, either way |
75 |
shouldn't be a real issue. |
76 |
|
77 |
-- |
78 |
Best regards, |
79 |
Michał Górny |