The trouble with computerized voting
March 14, 2020 at 7:47 AM - Views: 6 #286347eridaniParticipant
- Total Posts: 9,978
When I first heard about electronic voting, I thought “Good Grief!” I wrote a trivial little VB program showing how the screen can display one thing while something different is stored. There were two candidates and no matter how many times you voted for Howard, George always won. It seemed so obvious to me. How could anyone not understand?
Then I got involved with VerifiedVoting.org and attended to lobbying for HR2239. I remember listening to the computer experts talk about the security problems and feeling vaguely dissatisfied with what they were saying – as if they were missing something. But they were the experts, so I just continued pushing for HR2239. Everyone was calling for VV AT (Voter Verified Audit Trail) – oops, VVPB (Voter Verified Paper Ballot), and I called out, too. As long as it was accompanied with open source code and random recounts, then VVPB would be a satisfactory solution—not perfect, but still a lot better.
Super Tuesday brought me back to the reality I had known when I said “Good Grief!” But now I have learned that it’s so much worse than I thought back then. VVPB WILL NOT SAVE THE DAY. It will not save our election system. I’ve been involved in software development for 22 years. I’ve seen how it works. I know stuff from experience. I’ve worked with highly competent, thoroughly honest software developers who have found old calculation bugs that remained undetected through several released versions.
I’ve seen bug lists mount into the hundreds, so the manager has to select the worst 50 to fix and let the other ones crawl around in the released version of the product. I’ve seen Microsoft send out upgrades (bug-fixes) on a weekly basis – and so have you. Consider these points—
Point 1: RELEASED SOFTWARE HAS LOTS AND LOTS OF BUGS.
Many are undetected, some are known, and none are reported to the customer.
Point 2: THERE’S NO SUCH THING AS A COMPUTER GLITCH.
It’s a malfunction. When votes are tallied wrong, it’s a malfunction. “Glitch” is such a soft little word, implying a little bitty “oops.” Like losing 12,000 votes. But if the software did it once, it WILL DO IT AGAIN. That’s the nature of software. If it does the same thing 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 (they always say that), there are three possibilities.
a. The” glitch” was fixed by correcting a configuration that was incorrect before.
b. The “glitch” was fixed by installing an uncertified software patch.
c. The “glitch” wasn’t fixed at all.
And, BTW, fixing a bug is a huge risk. Often the “fix” introduces a new bug—or gives an old, undetected one new life. That’s why software companies test and test and test again after bugs have been fixed. “Patch” is such a nice word, innocuous like” glitch”. But a patch means that the code has been changed, always a risky venture. Software is sooooo precarious. Developers know that. The general public probably doesn’t.
Point 3: ELECTIONS ARE BETA TESTS OF THE VOTING SOFTWARE.
For those of you who know what a beta test is, you will see what I mean immediately. For those of you who don’t, 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. So any reputable company does beta testing before releasing a product. Send it out to users, have them work with it for a while and report the disasters they encounter. Fix the disasters, and then—only then—is the product worth the purchase price. Only then can you be reasonably certain it won’t make a mess of your computer.
Elections are the field tests for Diebold, ES&S, Sequoia, Hart, and the others. You can’t find an appropriate user base to do an adequate field test unless you hold an election. Simple as that.
So we see people pushing the magnification button and the ballot disappears. Yup, exactly the sort of thing that would show up in a beta test. The wrong screen appears when the thing 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 tested, beta tested, and is now robust, accounts for 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 make a 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 their goofs. (Thus the blessed “Undo” command.) So when an election is chaos because of user error—either poll workers or voters or both—the fault lies with the developer. ALWAYS.
Point 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 a pop, it is 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)?
Point 5: THE CERTIFICATION PROCESS IS A JOKE.
As Bev Harris so marvelously pointed out, when federally-qualified machines fail miserably, what is the solution? Make the repairs and send them back to the same people to test them again. Think about it. Hundreds of election disasters have occurred in the last two years. ALL OF THEM have occurred with federally-qualified, state-certified equipment (except perhaps in Mississippi). Why do we care if something has a NASED number? It means nothing. Look at the evidence.
Point 6: ELECTRONIC ELECTIONS AREN’T TRANSPARENT, EVEN WITH A 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.
Point 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.
Point 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 very computer savvy. They may be trying really hard, 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. But I’d be surprised if even 1% of them have any idea how far over their heads they are.
Many of them get offended when we talk about insiders doing malicious programming. They think we’re talking about them. 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. They are completely befuddled by computers. Most people are, except for computer professors, computer professionals, and teen-agers. Other than that, everyone is befuddled by computers. Electronic elections are being run by people who are befuddled by electronics.
Point 9: THE PEOPLE WHO MADE THE CRAPPY 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 they take 40 minutes to boot up – what is that? 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?
If you think VVPB (even with open source code and random recounts) will save the day, you are wrong. It cannot safeguard against:
• Bugs—inadvertent or advertent—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.
• Pieces of crap disguised as voting machines.
The only 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.
Jesus: Hey, Dad? God: Yes, Son? Jesus: Western civilization followed me home. Can I keep it? God: Certainly not! And put it down this minute--you don't know where it's been! Tom Robbins in Another Roadside Attraction
- You must be logged in to reply to this topic.