1 |
On Thu, 2019-09-05 at 22:42 +0000, Robin H. Johnson wrote: |
2 |
> If you consider various real world voting systems, they generally |
3 |
> require some form of electoral roll, on which voters are checked off, to |
4 |
> prevent voting multiple times (this can be enforced with other |
5 |
> mechanisms). |
6 |
|
7 |
Sure but I should point out that generally: |
8 |
|
9 |
1. The people who are checking you off generally try to cover other |
10 |
voters on the list. |
11 |
|
12 |
2. They don't have a real way of associating your vote with your check |
13 |
off. |
14 |
|
15 |
So I don't think examples of 'real life' voting systems are really |
16 |
relevant, unless they are 100% electronic and are subject to the same |
17 |
inherent weaknesses as we are. However, even then the scale might make |
18 |
sniffing votes impractical. |
19 |
|
20 |
> |
21 |
> > > 2. It introduces a big weakness in the system. My whole idea was to |
22 |
> > > make it practically impossible to sniff votes after the election is |
23 |
> > > prepared. With this solution, anyone with sufficient privileges |
24 |
> > > (election officials, infra) can trivially passively sniff votes. |
25 |
> > We need to know who cast votes, we don't need to know the content of the |
26 |
> > votes. I assume building such a system is possible (maybe it isn't?) |
27 |
> mgorny's system design is explicitly around building protections to |
28 |
> enable LESS trust being placed in infra & voting officials. |
29 |
> |
30 |
> Timing correlation in when a vote or stub appears in the system is a |
31 |
> concern in that environment. |
32 |
> |
33 |
> I agree that it should be possible to build this requirement into the |
34 |
> system, but at what cost in development. |
35 |
|
36 |
To be honest, I can't really think of a reasonable way to do that. We |
37 |
have simply too few votes spread over too much time. |
38 |
|
39 |
> > > I believe we should consider other options of determining activity. |
40 |
> > > Depending on whether we actually want to keep people actually interested |
41 |
> > > in GF, or just those caring enough to stay, I can think of a few |
42 |
> > > options. |
43 |
> I'd say those options should be in addition to, rather than instead of |
44 |
> voting. |
45 |
|
46 |
Why? What is the difference, say, between casting a vote and pushing |
47 |
a 'I am active' button once a year? If the latter's an option, there's |
48 |
really no point in leaking voting information just to have two |
49 |
alternatives. |
50 |
|
51 |
> |
52 |
> > > Another option (which some people aren't going to like) is to require |
53 |
> > > all Foundation members to be Gentoo devs (but not the other way around), |
54 |
> > > and then terminate GF membership along with developer status. Given |
55 |
> > > that there's only a few non-dev members, and most of them are retired |
56 |
> > > devs whose membership simply didn't terminate by existing rules yet, I |
57 |
> > > think there shouldn't really be a problem in making the few interested |
58 |
> > > members non-commit devs by existing rules. |
59 |
> > This doesn't really imply interested in the Foundation either though; |
60 |
> > because the developership and Foundation are separate. |
61 |
> If this includes making non-commit developership easier to |
62 |
> get AND maintain (the undertaker discussions about how to gauge |
63 |
> ongoing involvement of non-commit devs is very relevant to this), then I |
64 |
> have no conceptual problem with requiring all Foundation members to be |
65 |
> developers (It should still be possible to be a developer WITHOUT being |
66 |
> a Foundation member). |
67 |
|
68 |
That is the point. However, we need solid proposals for this. |
69 |
|
70 |
-- |
71 |
Best regards, |
72 |
Michał Górny |