[EM] Why We Shouldn't Count Votes with Machines

[Kristofer Munsterhjelm]

Dave Ketchum wrote:
>>      >> Or do we want the voter to be able to cancel the ballot and let
>>      >> the poll workers know that he needs a paper ballot instead that
>>      >> he can mark himself?
>>      >
>>      > I'm fine with the latter.  Actually that seems like a reasonable
>>      > thing to do.
>>
>>     I agree, but that is not happening on all of todays' voting systems.
>>     Election officials seem to be hopelessly slow to grasp the problem or
>>     the solution.
> 
> This is a possible place for some new, clear, thinking - the Election 
> officials likely couldn't fix this by themselves.
> 
> We are in trouble - failures have been proved too often, and there is 
> good reason to believe most failures do not even get proved.

Even if the voting machine would be perfect - have no flaws at all - 
having a backup paper balloting option would be a good idea, I think. To 
the extent that democracy is not only about who won, but also about the 
losers (and their voters) being confident that they lost in a fair 
manner, any voter who doesn't trust the machine can request a paper 
ballot instead; and candidates that distrust the machinery can tell 
their voters to use the paper ballot backup.

If the machine works correctly, and candidates and voters know that, the 
load on the backup system will be minimal. However, if the machines are 
untrusted or haven't earned the reputation for being fair, the backup 
will at least limit fraud somewhat.

A possible problem with the solution may occur if many more voters use 
"backup ballots" than was predicted, and the infrastructure (parties' 
counters, and so on) can't keep up with the load. This weakness is the 
consequence of that the load is going to be dynamic (depending on 
voters' trust in the machines), and in the worst case, the backup might 
be neglected completely.

> Even working correctly, Plurality voting is not adequate.  While there 
> are many competing methods, Condorcet is discussed here:
>      Ballot is ranked, as is IRV's.
>      Plurality voting is permitted, and can satisfy most voters most of 
> the time - letting them satisfy their desires with no extra pain while 
> getting their votes fully credited.
>      Approval voting is likewise accepted, satisfying a few extra voters.
>      Fully ranked voting is Condorcet's promise, giving full response to 
> those desiring such when desired.

 From a purely technical point of view, I agree. I think the "good" (at 
least cloneproof) Condorcet methods to focus on here would be either 
Ranked Pairs (easy to explain) or Schulze (seems to be gaining momentum 
for non-governmental purposes, e.g MTV and Debian), both wv as their 
definitions state. That shouldn't keep us from trying to find things 
like good burial-resistant Condorcet methods, though.

> Open source is ESSENTIAL:
>      While it encourages quality programming by those who do not want to 
> get caught doing otherwise, it also encourages thorough testing by the 
> community.
>      But, there is a temptation for copying such without paying:
>           Perhaps the law should provide a punishment for such.
>           Perhaps customers should pay for such code before it
> becomes open - and get refunds of such payments if the code, once open,
> proves to be unreasonably defective.
> 
> The community should be demanding of Congress such support as may help.
> 
> While "open source" could be thought of as just the voting program, 
> proper thinking includes the hardware, protecting the program against 
> whatever destructive forces may exist, and verifying what happens.
> 
> Secret ballot is essential.  While voter should be able to verify the 
> vote before submitting such, this is only to verify - goal above is 
> election programs that REALLY DO what they promise.

Let's look at this again. What does a voting machine do? It registers 
votes. Surely, that can't be a difficult task, so why use a computer? 
Why not (for Approval or Plurality) just have a simple chip connected to 
a PROM, with the chip in turn connected to a bunch of switches, one for 
each candidate, with a matrix display next to each switch, and a final 
switch to commit the ballot? Such a machine would be provably correct: 
as long as you have a PROM that hasn't been preprogrammed (this can be 
checked at the beginning), and the machine hasn't been compromised 
(rewired switches, backdoor chips), then it'll work as promised.

Reading off the PROMs would require more complex machinery, but it's 
really just an adder. In a Condorcet election, it's a two-loop adder 
(for each candidate, for each ranked below, increment vote_for[a][b]). 
That, too, is not too difficult a task and it should be possible to 
prove that it'll work in all cases.

One might also have to take TEMPEST sniffing and similar things into 
account, but the point is that both actually registering ballots and 
counting the votes is a simple task, and therefore one can inspect the 
device or program to see that it works properly, and more than that, 
that it'll always work properly within the constraints given (no rogue 
machines, or whatever).

The voters, approaching the machine like a black box, can't verify that 
the machine does what it says it does, but they can't do that with 
ordinary computers either. If that problem is one that damns 
computerized voting, then it damns it no matter what the black box is. 
If not, then since the computer program or device (in the case of a 
simple machine) can be known, at least by some, that there's no possible 
way it can go wrong unless it was sabotaged from the start or influenced 
by external effects (theft, PROM replacement, etc).

Similarly, cost also hits all forms of computerized voting. A 
purpose-built machine may even turn out to be cheaper in the end, since 
it doesn't need gigahertz CPUs, high resolution displays, or the likes.