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

[Dave Ketchum]

To clarify:
    >   Kristofer
    >>  Me
    >>> Kristofer

On Sat, 16 Aug 2008 09:54:28 +0200 Kristofer Munsterhjelm wrote:
>> 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.
> 
> 
> Hopefully the paper ballot problems won't be the same as the machine 
> problems, so that fraud is complicated rather than made easier.
> 
>>> 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).
> 
> 
> So you're saying that computers are better than specialized machines? 
> I'm not sure that's what you say (rather than that machines are better 
> than paper ballots), but I'll assume that.

Your specialized machines can each do a fragment of the task. 
However, dependably composing a capable whole from them requires big 
efforts from humans.
      Composing the same capability whole from a computer and adequate
programming can be easier.
> 
> Because the specialized machines are simpler than computers, once mass 
> production gets into action, they should be cheaper. The best here would 
> probably be to have some sort of independent organization or open-source 
> analog draw up the plans, and then have various companies produce the 
> components to spec.

They can be cheaper by not doing the complete task - make the task an 
election system and the cost goes up and dependability becomes expensive.
> 
> The simplicity of voting could also count against general-purpose 
> computers as far as manual labor is concerned. If the machine has been 
> proved to work, you don't need to know what Access (yes, Diebold used 
> Access) is to count the votes, and you don't need a sysadmin present in 
> case the system goes to a blue screen.

You need equivalent of a sysadmin to sort out getting a whole composed 
of your specialized machines.

Computers get cheaper and cheaper - think of what is hidden inside a 
cell phone.
> 
> You could also do these kind of proofs on general purpose computers, but 
> then you'd have to design the complete software system from the bottom 
> up, which includes what one'd traditionally consider the OS; and if it's 
> general purpose, you also have to ensure that the vendors don't patch 
> the systems after they've been deployed.
> Having the kind of programmable ROM infrastructure with a limiter on 
> per-voter might be good in the general-purpose computer case as well, in 
> which case the computer just act as a GUI. Then it can't mass vote - the 
> worst (which is pretty bad) it can do is alter the ballot as the voter 
> votes.

I do say "general purpose computers", with no funny stuff buried inside.
      And all the contents open source.
      And recording - CD-R sounds right.
> 
>> 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.
> 
> 
> That's true, but it's still fairly simple. Assume the ranked ballot is 
> in the form of rank[candidate] = position, so that if candidate X was 
> ranked first, rank[X] = 0. (Or 1 for that matter, I just count from zero 
> because I know programming)
> 
> Then the simple nested loop goes like this:
> 
> for (outer = 0; outer < num_candidates; ++outer) {
>  for (inner = 0; inner < num_candidates; ++inner) {
>   if (rank[outer] < rank[inner]) {      // if outer has higher rank
>    condorcet_matrix[outer][inner] += 1; // increment
>   }
>  }
> }
> 
What ran this loop outside a computer?

> It's less than instead of greater than because lower rank number means 
> the rank is closer to the top.
> 
> Write-ins could be a problem with the scheme I mentioned, and with 
> transmitting Condorcet matrices. One possible option would be to prepend 
> the transmission with a lookup list, something similar to:
> 
> Candidate 0 is Bush
> Candidate 1 is Gore
> Candidate 2 is Nader
> Candidate 3 is Joe Write-In
> Candidate 4 is Robert Write-In, etc
> 
> and if the central gets two condorcet matrices that have the same 
> candidates in different order (or share some candidates), it flips the 
> rows and columns to make the numbers the same before adding up.

Do you concede central having a computer - or offer more magic?
> 
> "Writing in" with the switches-and-display GUI would still be very 
> difficult, however; I recognize that problem.
> 
>> 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.
> 
> 
> I don't really like computerized voting, since I think it solves a 
> problem that isn't there while complicating things a lot. But if voters 
> insist upon computerized/machine voting, then we might as well do the 
> best of it, and in my opinion, it would be better to prove positively 
> (that everything it's supposed to do, it'll do correctly no matter what 
> happens) than negatively (that it won't err), because there's so much 
> more potential for something to fall between the cracks in the latter 
> case than in the former.

I don't insist on computerized voting, but believe that if we are 
willing to accept valid systems, they can be produced economically.
> 
> The specialized conclusion follows from this, because in the general 
> purpose computer case (without your own OS or something with a security 
> microkernel or similar to ensure the validity of the proofs) you have to 
> prove that the display driver doesn't mess with memory it shouldn't, 
> that the keyboard driver doesn't, and that basically the entire OS works 
> as specified.

Remember I specified, and insist on, open source.
> 
>> 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.
> 
> 
> One idea that came to mind when considering this and Kathy Dopp's 
> statement that voters don't check their ballots, is this: have the 
> machine print the ballot (underneath glass) on a transparency. The 
> system is set up so that the screen is monochrome in one color and the 
> printer is monochrome in another. Then overlay, very precisely, the 
> printed ballot on top of the monitor. If there are any discrepancies, 
> then those will stand out because there'll be a color mismatch. The 
> printed ballot is what counts - no in-memory count is kept.

I want:
      Display completed ballot, for voters to review and redo any 
problems.
      Record ballot on CD-R.
      Open source, so the programs SHOULD be 100% correct.
      Care in system design.
      See no value in above printout.
> 
> It would require very precise alignment and wouldn't do anything for 
> colorblind voters, and the GUI would have to look (if not act) just like 
> the paper ballot so that the confirmation isn't on a separate screen 
> (which would defeat the purpose). Those requirements may be too strict 
> for the method to work, but I mention it anyway in case it isn't.
> 
> The point of using the printed ballots as what counts is that as long as 
> the voter checks the result, there's no way for the computer to "keep 
> two books" - to tell the voter the ballot registered was for X while 
> secretly registering one for Y instead.

AGAIN, OPEN source.
> 
>>      I am for a record on disk of each ballot, but done in a maner to 
>> not destroy secrecy.
> 
> 
> You have to be very careful when doing so, because there are many 
> channels to secure. A vote-buyer might tell you to vote exactly at noon 
> so that the disk record timestamp identifies you, or he might, in the 
> case of Approval and ranked ballots, tell you to vote for not just his 
> preferred candidate, but both the low-support communist and the 
> low-support right extremist as well, so that he can tell which ballot 
> was yours and that you voted correctly.

More important is to preserve secrecy for voters who desire exactly that.
> 
> Perhaps one could have a compromise by repeatedly record the Condorcet 
> matrix so far (or Approval counts, in the case of Approval) once they've 
> changed sufficiently. That idea may have more subtle flaws, but those 
> may also be fixable; I don't know if either is the case.
> 
> Finally, the disk record won't help if the machine is compromised. If 
> pre-election polls show the incumbent at 47% and the challenger at 53%, 
> and the machine changes challenger ballots to incumbent ballots at a 
> rate of 7%, prior to those ballots being written to disk, nobody will be 
> any wiser. Even an individual ballot record would just show that 7% of 
> those that in reality voted for the challenger, voted for the incumbent 
> instead, as if having changed their minds just before the election.

AGAIN, OPEN source!
> 
> (If you go further in this vein, trying to fix that attack, you 
> eventually end up at cryptographic zero-knowledge proofs, which aren't 
> really "disk records", but more than that.)
> 
>> Disk records should also report what, of a suspicious nature, may have 
>> been done to the system.
> 
> 
> That's a good idea, but it should probably be network based instead of 
> disk based so that the virus (if one is introduced) can't just wipe its 
> tracks afterwards. Or use some non-erasable medium like aforementioned 
> PROMs (or a CD-R for that matter).

I get nervous about network connections while polls are open - more 
code to validate.
-- 
  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.