Democrats & Liberals Archives

The case against computer-based voting systems

Following the 2000 presidential election, the nation paused to reflect upon how poorly a modern-day election could go so wrong, so quickly. Instead of the nation focusing their efforts on the hard questions surrounding the all-important human angle, Americans focused on the technology associated with managing elections. That little deviation set us on a potentially devastating disaster for democracy.

Instead of identifying the obvious human element that created the fiasco in Florida, 2000 and later in Ohio 2004, the media pushed forth its opinion that technology was the culprit. For days, months and years that followed the elections, those paper ballots or more specifically, those butterfly, paper ballots became the root of all that was wrong in the election process. And the solution came in the form of electronic or computer-based voting. As if to say, the guy with the shaved head, soul-patch and loose pants that created your website is more credible than the simple elegance of a stylus poking through a perforated ballot.

The human element, we forget, whether it's the person counting the ballots, punching the ballots or tallying the ballots, is always the chink in the chain, not the technology.

Since technology solutions are put forth as the panacea for the savior of our election process, let's break down that actual way that such a transformation would take place. We all know, by know, how computerized systems function. Computerized systems function by a complex relationship between independent platforms working together to produce a desired result. Whether the result is a spreadsheet tallying your expenses or a greeting card for your niece's birthday, all systems behave in a standard systematic way.
Software is installed onto a medium that the hardware system acts upon to produce and deliver the final result. If we break down a greeting card: software is installed onto the computer's hardware, usually a fixed disk or hard-drive that is recognized by both the hardware operating system (CMOS) and the operating system of the particular environment (for example: Window XP). A person uses the installed application through a user interface to create the greeting card. Once the person has accepted the result and the results meets their needs; they print the greeting card for distribution. In order to print the card, the application uses the operating system to talk to a subsystem managing peripherals, such as printers, for the actual printing. The result is: the digital version of the greeting card is electronically sent from the operating system subsystem to the printer and the printer acts on the data that the particular peripheral (printer) receives and prints the card.

Sounds simple; right?

Now let's examine the greeting card application if we apply a couple of standards, say accuracy and secrecy to how the application must behave.

That would complicate and already complicated process. You would have to verify that the greeting card was exactly as the person created. That there was absolutely no difference between what was developed, on screen, to that was printed via the printer. The font size, color and camber would be exactly the same. The content, both in placement of text and graphics would be an exact match as bit by bit comparison. Then after you were clear of the accuracy, you would need to see that the privacy standard had been met. And that there were absolutely no copies of the data existing after the printed result. Making sure that all cache, whether in active RAM or video RAM or serial cache or printer cache or anything that related to the spooler files that the printer subsystem uses to manage the transportation of the material, is completely gone. Anyone that knows anything about fixed disk drives, know that one can always retrieve data from a storage medium such as a fixed drive.

And that's just with a greeting card application. How about your right to vote?

A computer-based voting system that manages the process of recording, tabulating and disclosing the results of the tabulated votes cannot succeed. Here's why:

First we have to breakdown the system in the very same fashion we broke down the greeting card application.

One would have to make the assumption that standardized hardware platforms will be used in the gathering or recording of votes. For, it would be much too cost prohibitive to develop an entirely new hardware platform that uses proprietary CPUs, memory and storage devices, as well as video display devices. Not only is there significant research and development costs to develop such a hardware platform, but the support requirements would be cost prohibitive as well, requiring a specialized hardware support group for this system. It's for that reason that I believe any voting system developed would be done so on standardized hardware platforms such as motherboards, CPU, memory, video display controllers, fixed-disk controllers and a host of other readily available hardware platforms.

Since it's now plausible to believe that the election system applications would be developed on these standardized hardware platforms, we must believe that these hardware platforms are not secure by any possible measurement. For these standardized platforms (video cards, fixed-disk storage and associated hardware, CPU, RAM, etc…) have evolved over the years through a community and standards-based process. Volumes of recorded documentation pertaining to the schematics of both the specific hardware platforms and the architecture are available for anyone smart enough to understand them. These volumes are not secret, they are just complicated. And inherent complication is not a method to protect the secrecy of a voter's ballot.

So let's for the sake of discussion assume that the extra smart people developing these systems have devised a method to protect these hardware platforms so much that when data is stored onto the storage device, no unsuspecting individual can hack the hardware platform and retrieve and manipulate its results. Let's say they got past this hurdle.

Software is developed through various levels of abstraction away from the hardware. Gone are the days that computer scientists develop machine language to crunch numbers. No, applications are developed now in a way that gives a tremendous amount of control over to the environment to which it is developing. To be clear, the applications will have to be developed to a standardized operating system for the very same reason that standardized hardware platforms will be used; cost and resource availability.

So it's perfectly okay to assume that the applications will be developed in common operating systems currently commercially available. In fact, if you add a little bit of capitalism to the mix, you'll see some active competition for this market. Microsoft and desktop Linux will battle for the business ensuring that a common operating system will be used.

Pick one: Microsoft or Linux on Intel. It really doesn't matter the same reasons will abuse will still apply. Each environment, more so on Microsoft than Linux, have robust development environment ripe and ready for the application to be built upon.

If the governing body picks Microsoft, the application will live within Microsoft's popular Windows development environment. They will reuse years and years of readily available code for everything from form processing to database connections to on-screen display. This repository of reusable code libraries called Microsoft Foundation Classes has evolved over the course of many, many years with volumes of documentation. In fact, Microsoft was sued a few years back by competing software development companies complaining that Microsoft wasn't releasing enough application libraries that exploit the full capabilities of the Windows operation system, thereby creating an unfair competitive advantage. Microsoft was forced by the court to release all application programming interfaces (API) for the Windows operating system. The release of these internal APIs opened up the guts of the operating system including many key areas locked from third-party developers before.

So now Windows developers gained access to everything that Microsoft Windows operating system had to offer. Gaining access to underlying code to communicate to the various peripheral devices, display controls and the guts of how Windows deals with data and its cache.

Now let's look at the raw data. How and where would the data be stored, if it in fact were stored onto the computer? It's obvious that a fixed drive will be used to store the voting data. This storage mechanism will be standard; that's absolutely for sure. And one thing that's also for sure, the data stored onto the computer can be retrieved no matter how much you think you deleted the data.

But let's say that the application use a database. Normally applications are built in a tiered architecture, each functional layer abstracted from one another. Usually the user interface is separate from the business logic which, in turn, is separate from a data access layer. If we dissect where the data would be stored we will find, for all of the same reasons about proprietary designs, that a standardized platform for the storage of the data will be used. As in many databases, whether they are multi-user relational databases, like Oracle or single-user desktop solutions like Microsoft Access, all have significant problems with regards to the safety and security of the data stored within its system. All rely on standard networking protocols and integrate system services for authentication. This would mean that if you can break into the security subsystem for the platform, it's easy to break into the security subsystem for the database management system. Additionally, all common relational database management systems (RDBMS) use a common way to access their database system and provide APIs for developers for such access. If a person wants to hack into the database, there's plenty of ways to do so; just do a Google search on the subject. This is simple because all RDBMS are to adhere to a level of government security known as C2 level security. C2 level security is the watermark for which they are to match for protecting the data contained within the machine and the database. But the problem is that C2 was developed in 1985 and hasn't been updated since. Sound's secure, no? The point is that any database that the voting application uses will most likely be a common platform with plenty of supported documentation. In other words, it's open because it's designed that way.

But that's just what the problem with casting the vote electronically. We have to tally and report that vote, don't we?

When tallying and recording the results of the election, we must make certain that the ballots that we are counting are, in fact, the ballots that are actually cast. With paper ballots, we have that level of expectation. For once the ballot goes into the ballot box; the ballot is sealed until it is tallied. And when the ballot is tallied, it is done so under the eyes of the election officials. In a computerized solution, it's assumed that the tallying portion of the process would be done from the system itself, removing a necessary check and balance. By streamlining the process you relinquish ever important checks for accuracy.

So let's say we have tallied the results, now what? As part of the process we have to record and publish the results. How do you publish the results of the election?

Is the publishing going to take place to an electronic audience, say a larger computer for further computation? It's safe to say that the system would transfer the results electronically in a digital format. I'm sure that most people would feel it a futile exercise to record the tallied results of an election and create a report and present the report to be entered into another computer system. No. That's just plain dumb.

Because it's safe to say that the counties that receive the precinct results would like the process streamlined as well. They would like to have the election officials merely validate the results and distribute the results electronically. That's what is commonly referred to as an 'integration point'. This integration point is the county's computer system receiving the digital precinct data and feeding into a larger county election system.

Since larger county-wide computerized election systems already exist (they take the paper ballots and count them) the new system would have to be developed to integrate the two. It would be implausible to believe that anyone would go to the extent of computerizing the precincts and not integrate the results with a larger computerized system.

So how would this happen? Would this happen the same way that most computers talk to each other, through Internet technologies? It makes sense. The infrastructure is large. There's a large install base and all the available hardware for this communication is readily available at any office superstore. But that produces a significant security risk. Using the public network to transfer these results would be down right insane. There's the initial Internet service provider that would be needed to provide the hookup. And with all of the same competition, companies like AOL, Earthlink and NetZero would be salivating for this business. But would they be ready for this type of traffic? Could say, Earthlink, provide this service without caching any data as it passes through their computer systems? That's improbable. The Internet Service Providers would have to cache everything and therefore would retain a copy of everything that passes through its servers. Let me reiterate that point. Once a precinct uses an Internet connection to upload its data to the main computer, a copy of that data will be retained onto hardware and software platforms of the Internet Service Provider. The servers and routers are designed to handle this for this event, because of the security risk they have for every customer that passes through their computer systems, not just the precinct.

So if they can't use the Internet, how about another method to transfer the data. How about if they use the little, USB jump drives to transfer the data and just hand it off to the county when the precinct arrives? That sounds slick, but would it work. Well, not really. Those devices, although inexpensive are known to fail. Published failure-rates for these jump drives vary from 5% to 30%. So I can't imagine disenfranchising a host of voters, 50,000 to 300,000 per million, because the technology method chosen happen to fail. The point being that any method for the transmission of the election result data must be secure and safe and when you're dealing with technology, nothing is 100%.

We must ensure that every vote has had the opportunity to be cast, counted and published. Real-time financial systems have this level of fault-tolerance, but they used a hard-wired network to communicate and transmit their results. This gives them the ability to distribute the load of the request and have automatic failover systems in advent of a error. But even if your transaction doesn't go through, the person will not be adversely affected because they have a way of tracking the transaction and remedying the situation. In the financial transaction world there are audit trails; plenty of audit trails. Something that the electronic election system cannot, by design, have. For one of the fundamental principles of our voting process is the secrecy of the cast ballot. Audit trails, whether paper or electronic, must not exist to ensure the privacy of each vote and the voter who cast it.

Companies that design the electronic voting systems would have to verify, through computer forensic verification, that the votes cast are wiped clean after the ballot is cast. The companies would have to verify that there is no connection between the voter's identity and the cast ballot.

Ensuring that each company upholds the trust of every American voter is a daunting task. Given the allegations about companies like Diebold donating significant amounts of money to political campaigns, additional safeguards would need to be put in place to guarantee that the companies in charge of developing the applications have no political ties.
It's time we take the hard look at the human element of the election process and shy away from replacing existing voting methods. It is the human element that will always fail regardless of the implementation. No method, whether paper, mechanical or electronic ballot will protect against a person or a group of persons bent on affecting the outcome of an election.

It's time to look for a solution to the problem; not the symptom.

Posted by john trevisani at November 18, 2005 8:00 AM