Re: Reaffirm public voting
Thomas Goirand <zigo@debian.org> writes:
> When considering a voting system, there are a few important things to
> consider [1]:
> 1- vote-privacy: the fact that a particular voter voted in a particular
> way is not revealed to anyone.
> 2- Receipt-freeness: a voter does not gain any information (a receipt)
> which can be used to prove to a coercer that she voted in a certain way.
> 3- Coercion-resistance: a voter cannot cooperate with a coercer to prove
> to him that she voted in a certain way.
> 4- Individual verifiability: a voter can check that her own ballot is
> included in the election's bulletin board.
> 5- Universal verifiability: anyone can check that the election outcome
> corresponds to the ballots published on the bulletin board.
> 6- Eligibility verifiability: anyone can check that each vote in the
> election outcome was cast by a registered voter and there is at most one
> vote per voter.
> If I understand well the problem, we can't have all of the above. That's
> technically not possible, with the current state of knowledge on earth.
> I haven't read enough on the topic, but I believe that's the case. If
> anyone has read more and would like to explain, please do...
> The current proposal, if I understand well, is that we would like to
> enforce 1- and 3-. I'm somewhat ok with it, but I very much value 4-, 5-
> and 6- above 1-, 2- and 3-.
I believe the current system gives us 4, 5, and 6 only, and the proposed
initial implementation of using the same mechanism as DPL votes for all
GRs would give us 1 (partially), 4, 5, and 6. In other words, I think
it's additive with respect to your list because you do not lose 5 or 6
(all the rankings and all of the voters are published and you can do the
math yourself; you just don't have the association between rankings and
people). It's possible that we could gain more properties from Belenios
or some other voting system that makes better use of cryptographic
primitives. The security tradeoff (which is not captured by your list) is
to rely more heavily on trust in the Project Secretary because 4 remains
possible but becomes more complex (you have to check your hash rather than
just scrolling through the list and finding your name and your vote).
Both of our current voting mechanisms are somewhat vulnerable to injection
of votes by the Project Secretary or someone with administrative access to
the voting system supposedly from people listed as Debian Developers but
who are inactive and did not actually vote. The DPL election mechanism is
probably somewhat more so because people are less inclined to review the
list of voters when their votes aren't listed as well, but the difference
feels minor to me. This is a challenging thing to defend against in
general.
In DPL elections, we get 1 only partially since the Project Secretary
still can, in theory, determine which voters voted a specific way (as can
anyone else with privileged access to the machine that receives and
verifies the votes). This proposal would also only give us 1 partially.
I'm personally more interested in using something like Belenios than just
replicating the DPL election scheme mostly because I'm unsure that the DPL
election scheme has had sufficient security analysis and I'd prefer to see
us move onto the firmer footing of a voting system that's had a published
rigorous analysis of its properties and I'm not aware of one for our
current DPL election system. (I would love to be corrected if one does
exist.) But I think there's a bit of a chicken and egg problem with
experimenting with any other voting mechanism, and I'm not sure how we get
started. Sam's GR is one way to get started that seems reasonable to me,
but I can see why people may disagree.
> I am unsure about what Holger has in mind, but for me, yes, I do want to
> know about the full details of implementation to make sure we have 4-,
> 5- and 6-, which we currently have with a fully public voting system. Just
> voting on "I want my vote to be secret" without having any information
> about the other properties is IMO completely silly and looses the point.
Sam's GR intentionally leaves the details open to the Project Secretary to
determine. I understand why people might object to that and would prefer
to require a GR for any change to the process. I just wouldn't
characterize that as "rushed" (it's a deliberate choice, and hasn't been
made in a hurry so far as I can tell), so wasn't sure if that was the
objection here or if there was something else I was missing.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: