Ellen Theisen
VotersUnite!
www.votersunite.org
www.wheresthepaper.org/VVPBnotEnough.htm
May 12, 2004
Many computer experts are hoping that voter-verified paper ballots (VVPB), accompanied by open source programming code and random recounts, will allow computers to be used in elections in a satisfactory way.
The primary elections of Super Tuesday shed new light on this issue, however, and revealed problems that warn us that electronic DRE voting may never be reliable.
Here are the problems I see with electronic elections:
1. RELEASED SOFTWARE HAS LOTS AND LOTS OF BUGS. Many are undetected, some are known, and none are reported to the customer.
I've been involved in software development for 22 years. I've worked with highly competent, honest software developers who have found errors that remained undetected through several released versions of software. I've seen lists of errors in software climb into the hundreds, so the manager has to select the worst 50 to fix and let the other ones stay in the released version of the product. My workplaces were the norm -- we've all seen Microsoft send out upgrades (bug-fixes) often — sometimes weekly.
2. THERE'S NO SUCH THING AS A COMPUTER GLITCH. It's a malfunction. When votes are tallied wrong, it's a malfunction. "Glitch" implies something not very serious, but "glitches" have been known to lose 12,000 votes. And if the software did it once, it WILL DO IT AGAIN. That's the nature of software. If it does the same process twice, it will do it exactly the same both times.
This means that when the newspaper reports that an election disaster was due to a software glitch, but the technicians fixed it and the election outcome wasn't affected (which they always say), there are three possibilities:
1) The "glitch" was fixed by correcting a
configuration that was incorrect before.
2) The "glitch" was fixed by installing an uncertified software
patch.
3) The "glitch" wasn't fixed at all.
An additional problem — fixing a bug is a huge risk. Often the "fix" introduces a new bug, or gives an old, undetected bug new life. That's why software companies test and test and test again after bugs have been fixed. "Patch" is an innocuous word, like "glitch". But a patch means that the code has been changed, always a risky venture.
Software is so very, very precarious. Developers know that. The general public doesn't.
3. ELECTIONS ARE BETA TESTS OF THE VOTING SOFTWARE. A beta test is a field test of the software. It is well-known in software development circles that in-house testing only catches some of the bugs. Reputable companies do beta testing before releasing a product. They send the software product out to target users, have them work with it for a while and report the disasters they encounter. The company fixes the disasters, and then – only then – is the product worth the purchase price. Only then can customers be reasonably certain it will operate fairly accurately without causing problems on their computers.
Elections are the field tests for Diebold, ES&S, Sequoia, Hart, and the other voting machine manufacturers. It isn't possible to find an appropriate user base to do an adequate field test, except by holding an election. It's as simple as that.
In recent elections, voters have pushed the magnification button and the ballot disappeared. That's exactly the sort of thing that would show up in a beta test. The wrong screen appears when the PCM is booted up with low batteries. Definitely beta test material. USER ERROR IS JUST NOT A GOOD ENOUGH EXCUSE. A good software program, one that has been thoroughly beta tested, is made to handle user error. This is why when you delete a folder with files in it, the program says, "Are you sure you want to do that?" just in case you clicked the Delete button by mistake.
In the software development world, engineers spend a great deal of time, energy, and money to ensure that users can make errors without destroying their data or wasting their precious time recovering from errors (thus the blessed "Undo" command). So when an election is chaos because of user error – either poll workers or voters or both – the fault ALWAYS lies with the developer.
4. THE LONG CERTIFICATION PROCESS IS A HINDRANCE TO GOOD SOFTWARE. When you find a bug – a common occurrence – it must be fixed. But with the NASED qualification process followed by the state certification process, all according to law and costing $10,000 or more for each application, it's much, much, much easier to leave the bugs unfixed or sneak a fix in behind the backs of the authorities. And who knows what gets snuck in with it – inadvertently or not.
The nature of software development is that it operates on a short time-line. Find a bug, fix the bug, send out a notice so customers can download the patch. All in a matter of days. What if Norton had to get every virus definition file certified in a six-month process? What if Microsoft had to wait six-months between updates (bug-fixes)?
5. THE CERTIFICATION PROCESS IS A JOKE. As Bev Harris has pointed out, when federally-qualified machines fail miserably, the manufacturers make the repairs and send them back to the same agencies to test them again. Hundreds of election disasters have occurred in the last two years. Virtually all of them have occurred with federally-qualified, state-certified equipment. So, there appears to be very little value in having a NASED number. It means almost nothing. Look at the evidence.
6. ELECTRONIC ELECTIONS AREN'T TRANSPARENT, EVEN WITH VOTER-VERIFIED PAPER BALLOTS (VVPB). You cannot watch the ones and zeros moving around, recording votes, counting votes, tabulating the results. Election officials can have all their procedures in place perfectly, but the processes that do the most important work of an election are not visible to them, and they are not in control of them at all.
7. VENDORS CONTROL OUR ELECTIONS. With electronic voting, ballots are recorded and tabulated by software processes, which are:
- developed by anonymous software engineers, who are hired
by vendors.
- federally qualified by anonymous testers, who are hired by vendors.
- installed and maintained by technicians, who are hired by vendors.
- trade secrets of the vendors and therefore not open to public scrutiny.
And if we get VVPB printers, the printers and the software that drives them will be developed, tested, qualified, installed, and maintained by the vendors.
8. ELECTRONIC ELECTION PROCEDURES ARE IN THEIR INFANCY. Election officials all over the US are attempting to run electronic elections using procedures adapted from the procedures for paper ballots. Most of the officials aren't computer savvy. They may be trying their best, but they aren't qualified to do what they are being asked to do. Partly they realize they are over their heads, and so they attempt to maintain a good relationship with vendors whose help they rely on. Since virtually none of them are computer professionals, it is unlikely that even 1% of them have any idea how far over their heads they are.
We hear of election officials becoming offended when they hear talk about insiders doing malicious programming. They think they are being attacked. They think they are programming when they configure the ballot designs. They don't even know what programming is.
As a software technical writer, I have dealt with novice users for 22 years — intelligent and competent people, but novices. They are completely befuddled by computers. Most people are. Other than computer professors, computer professionals, and teen-agers, everyone is befuddled by computers. Electronic elections are being run by people who are befuddled by electronics.
9. THE PEOPLE WHO MADE THE MALFUNCTIONING HARDWARE MADE THE SOFTWARE. How many times has your computer overheated and broken down? Never? Well, voting machines have. The hardware isn't even adequate. Sometimes DREs take 40 minutes to boot up. They just quit working correctly, right in the middle of an election. Touch screens are misaligned. Sensors don't sense correctly. The people who brought us these worthless hardware devices also designed and developed the software that runs on them. What does that tell us?
10. VOTING SOFTWARE IS A HORSE OF A DIFFERENT COLOR. Virtually all software applications are designed to give feedback to the user. That's their purpose. The user enters input, the computer does something to it, and hands back the results to the user. This is true in a spreadsheet, a word-processor, a computer game, an aviation program. Part of the alpha testing process is to ensure that the results are correct. Beta testers, too, are constantly receiving feedback and validating the results.
As users work with the software on a daily basis, they notice things that don't mesh, and often they report it to the manufacturer. We are so used to working with software that gives feedback, and gives it correctly, that we are now taking it for granted. When I save a file and then open it again tomorrow, I see the same data I had in the file yesterday. I don't even think about that it was software that accomplished both the saving and retrieving tasks correctly. It's just so natural, it seems like "of course."
Wrong. Not "of course". Software developers have spent an enormous amount of time, effort, and money to make sure that the feedback their applications give to users constantly, daily, minute-by-minute, is accurate. Because that's the only way they can make money.
Voting machine software is the only software I can think of that is specifically designed NOT to give feedback to the user. (Screen feedback at the time of the voting doesn't count.) Once the data is saved, the user never gets to look at it again. The only people who ever see the results are those who have no idea what the input was. THIS IS A HUGE BLIND SPOT IN THE PROCESS. The law does not allow this blind spot to filled since votes must be anonymous.
So any comparisons to cash registers (which give constant checkable feedback, even though they aren't software), ATMs, or any other software at all are bogus.
CONCLUSION. It is simply wrong to assert that VVPB (even with open source code and random recounts) will save the day. It cannot safeguard against:
- Bugs – inadvertent or not – in the software.
- Inadequate testing.
- Laughable certification process.
- Legal restraints on fixing software bugs in a timely manner.
- Legal restraints on fixing software bugs before an election.
- Intimate involvement of vendors in the electoral process.
- Computer novices running electronic elections.
- Security procedures developed by officials who are befuddled by computers.
- Malfunctioning hardware.
- Nonexistent input/feedback process.
The only way to get a fair election is to have a transparent election. Electronic elections, by definition, are NOT transparent. And that's on top of all the other problems.
Votes should never be recorded electronically. Period.
# # #