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

[Kristofer Munsterhjelm]

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.

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.)

>> 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.

>> 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.

>> 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).

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.

> 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.)
>      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.

>>>      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.