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

[Dave Ketchum]

On Fri, 15 Aug 2008 16:01:10 +0200 Kristofer Munsterhjelm wrote:
> 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.

As I say above, we are in trouble.  Until we both fix the machines and 
demonstrate success of the repairs, such use of paper backups makes sense.

Complicating all this, paper ballots have their own problems.
> 
> 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.

I will use "zillion", a stretchable value, below:

A zillion precincts each set up for a few of the zillion races voted 
on in the US.

A zillion personnel who must do all the manual labor and guidance of 
voters.  This is a sideline, thus hard to justify learning complex 
skills, rather than a full-time career for these.

A zillion voters, who BETTER be provided a simple interface for voting.

At end of election the counts for the zillion races better get 
attended to.

I really see it easier to do well effectively if you take advantage of 
what computers can do (and have them do better than the failures we 
have experienced).
> 
> 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.

For Condorcet you must recognize, for A vs B, how many ranked A>B and 
how many B>A.  Must do this for every pair of candidates.  If 
write-ins are permitted (better be), they are more candidates to 
attend to.
> 
> 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).

We know that failing is possible with defective computer systems.

I claim that those willing should be allowed to demonstrate, and 
deliver if they demonstrate ability, good computer systems.

Agreed the average voter cannot demonstrate quality of systems, though 
a few have failed so miserably that even they should notice.
> 
> 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.

Big expense for proper computerized voting is the programming but, 
supply a reasonable part of the zillion precincts and this becomes 
trivia for each one.

Big equipment item would be cost of preventing various destructive 
acts at each of the zillion machines.

Some talk of printing copies of the ballot:
      Certainly voter should have aid in verifying the ballot.
      But I do not see need for printing such.
      I am for a record on disk of each ballot, but done in a maner to 
not destroy secrecy.  Disk records should also report what, of a 
suspicious nature, may have been done to the system.
-- 
  davek at clarityconnect.com    people.clarityconnect.com/webpages3/davek
  Dave Ketchum   108 Halstead Ave, Owego, NY  13827-1708   607-687-5026
            Do to no one what you would not want done to you.
                  If you want peace, work for justice.