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.
----
Election-Methods mailing list - see http://electorama.com/em for list info
