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

[Dave Ketchum]

On Sun, 17 Aug 2008 11:14:34 +0200 Kristofer Munsterhjelm wrote:
> Dave Ketchum wrote:
> 
>>> 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.
> 
> 
> Each does a fragment of the task, yes; that's the point of modular 
> design, so that you can treat the local units differently from the 
> central units and don't have to prove everything everywhere.

You claim that many fragments can be done by specialized machines. 
AGREED, though I do not agree that they can do it any better than a 
normal computer - which has equivalent capability.

However, the whole task involves connecting the fragments:
      One way is via computer capability.
      You seem to be doing without such, so What do you have other 
than humans HOPEFULLY correctly following a HOPEFULLY correct and 
complete script?
> 
> Consider a general computer. Even for general computers, it makes little 
> sense to have the district joining software - that counts the results 
> from various districts and sum them up in the case of a summable method 
> - on the individual units. As such, the general-purpose computers are 
> already specialized, only in software instead of hardware.

???
> 
>>> 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.
> 
> 
> By extension, they can be cheaper by, in concert, doing just enough and 
> no more. One doesn't need Turing-completeness to count an election. 
> (Perhaps unless it's Kemeny.)

Se my above note.
> 
>>> 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.
> 
> 
> The way I would set up the system, there would be different counting 
> units. The group of units would need a person to "unlock" them each time 
> a new voter wants to vote; that could be included in the design so that 
> you don't need a system administrator for it. Then, once the election 
> day is over, gather the read-only media (CD or programmable ROM), and 
> either send them or the summable result (given by a second machine) to 
> the central. Count and announce as you get higher up in the hierarchy.
> 
> If the components are constructed correctly, and proved to be so (which 
> can be done because of the units' relative simplicity), then there won't 
> be any bluescreens and little need for maintenance - except for cases 
> where the machines simply break.
> 
> In this manner, the setup is more like paper balloting than it is to 
> ordinary computer systems. The read-only media take the place of the 
> ballot box, and the aggregating machines the place of the election count 
> workers.
> 
>> Computers get cheaper and cheaper - think of what is hidden inside a 
>> cell phone.
> 
> 
> That's true. Maybe a compromise could be using cheap computer hardware 
> with read-only software, standardized components, and have the software 
> not be a full OS, but instead just enough to get the job done and be 
> provable. You'd have to rely on that there are no hardware backdoors, 
> but the existence of such would be very unlikely, and the entire thing 
> would have to be put inside some sort of tamper-resistant enclosure so 
> hackers can't attach keyloggers or do similar things.

Hardware backdoors can be hard to find.  Still, if and when one is 
found, can there not be an appropriate punishment to discourage such 
crimes in the future?

Agreed defense against such as keyloggers is essential.

I still say OPEN SOURCE!
> 
>>> 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?
> 
> 
> A chip with just enough transistors to do this task. I'm not a hardware 
> expert, but I think it could be done by the use of a HDL like Verilog.

The chip needs to be able to find its data.
> 
>>> 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?
> 
> 
> Central could have a computer or another kind of machine.
> 
>>> 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.
> 
> 
> Open source software can still have unintended bugs that could be 
> exploited by a hacker. Open source is at an advantage because "many eyes 
> make bugs shallow", but that advantage is still finite, more so because 
> the coders aren't going to use voting machines on a regular basis 
> (unlike, say, Linux).

No matter what you do, errors can happen.  Proper target is to 
minimize them, which I claim can best be via using computers for what 
computers can do well.
> 
> I'll grant the point, though, regarding malicious machines. If the 
> entire standard is public, and the machines can be rigorously tested to 
> be sure no tricks are being done by the manufacturers, then deliberately 
> malicious holes should not exist. I still hold that one should engineer 
> defensively and as simple as possible, so that the system is transparent 
> to as many people as possible, and so that bugs either are fixed very 
> quickly or (preferrably) don't have the room to exist at all.

Looks like what I am trying for.

Simple is a good word, as is defensively.
> 
>> 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.
> 
> (Just a note: if the programs are simple enough, one can *know* they are 
> correct. With provisions for unexpected OS bugs unless the OS itself is 
> equally simple, and so on.)

When you mention OS, remember my insistence on open source.
> 
>>      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.
> 
> Granted, if the machine isn't hacked due to an unexpected bug. 
> Printout-based machines could be useful even if we have provably correct 
> machines (strongest sense of security) if the voters are very 
> distrustful. Counting only based on the printout ensures the voter that 
> nothing fishy is going on - because nothing fishy *can* be going on.

Our sorry history justifies distrust.

I DO NOT like printout-based machines.  To start some thinking, how about:
      All machines have identical valid code,
      Some have video cameras recording the ballot as the voter 
submits it.
      Voters choose which machines to vote on.
      Audit that tapes prove 100% correctness of those machines taped 
- BETTER be.
> 
>>>>      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.
> 
> 
> Yes, that's why channels that can link voters to their votes (destroying 
> secrecy) should be either obscured or removed.
> 
> Obviously, it's possible to make voting machines with even more channels 
> than I mentioned here, like something that produces name-labeled 
> receipts. I wouldn't want that, either, but the channels I gave are less 
> obvious and shows that one has to be careful when making records; things 
> that seem to give no link between voters and ballots may turn out to do 
> so under certain conditions anyway.
> 
>>> 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.
> 
> 
> Use a LED with a photoresistor on the other (logging machine) end. No 
> data can move from the voting machine to the logging machine, and so 
> would reduce complexity significantly. Or have two in different colors, 
> one of which is always on to detect broken cables.
> 
> There'd still be some code to verify, though: make sure that the voting 
> machine don't leak ballot data to the logging machine, for instance.
-- 
  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.