Electronic Ballot Reader

Design Document

Rosa Arias, Chad Feller, Walter Smith

27 March 2004

TABLE OF CONTENTS

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 System Level Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 Class Diagrams And Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

4 Database Structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

5 Activity Charts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11

6 User Interface Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

7 Team Member Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

8 Glossary Of Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

9 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

1 Introduction

Throughout the years, traditional voting has been plagued with issues, scandals, and conspiracies. With the events of the 2000 presidential election being the most prominent in most people’s memories, people are calling for voting reform. As such, the push for touch screen voting systems has made its way into the forefront of the political scene everywhere. Most recently, on “Super Tuesday” a few weeks ago, touch screen voting machines were used in various places around the country. While they seem to provide an elegant solution to previous problems, they introduce their own set of problems. Most notably, “what do you do in the event of a recount”?

To date, there is no means to do recounts because of the nature of electronic voting. An electronic record was thought to be sufficient, and after all, what could go wrong with an electronic record?

In all actuality, electronic ballots suffer many of the same issues as traditional ballots. Furthermore, they introduce their own set of issues which are unique to them.

These issues can be generalized into four main items: Close elections, hardware failure, software failure, and audits. Under a close election such as Florida 2000, a recount would be needed. Not because of hanging chads and whatnot, but rather because of the voting official would want to verify that the votes which the machine reported were actually the votes which were placed.

If there was any type of software failure, hardware of software, it would have to be ensured that there was no data loss. Obviously there was a software failure, then the vote tally would be questioned. Similarly, in the event of a hardware failure the integrity of the data would again be questioned, and a recount would most likely be called for.

Certainly, the integrity of the machine would need to be certified – an audit. One of the ways to do this would be through a recount. The integrity of the voting software is already a hot button with U.S. congressional delegates. Since there is currently no way to verify that what the electronic voting machine reports is necessarily what was placed at the machine, congress is working on a bill to make paper trails in such machines mandatory.

With this impending legislation, several companies are already talking about adding paper registers to their machines. However, with all the talk, it is appears that Sequoia is the only company that is about to put such a voting machine on the market.

The introduction of voting machines with paper records would make it appear as though electronic voting machines no longer have any real issues. However, as we saw in Florida in 2000, a recount can be long and drawn out, as well as costly. This is because the manpower required not only is time consuming, but expensive.

The solution to this is to be able electronically verify the paper record. That is where our project comes in. Our electronic ballot reader would provide a quick, automated means of verifying votes cast during an election.

A voting official will effectively be able to enter in the offices, candidates, and propositions which were on the ballot, and the machine would do the rest. After the recount by the machine, the voting official might have to manually look at images of certain parts of the register tape which the system could not distinguish, these images would be anomalies. From there the voting official would be prompted to view each and every anomaly, assigning votes accordingly.

The purpose behind the voting official having to enter in the offices, candidates and, propositions is so that the machine will know what it is looking for. If it cannot match a candidate with an office, then there might be an error on the register tape, or it could possibly be a write in candidate. Non resolvable errors on the tape could be items ranging from smudges to poor print quality. In states that write in candidates are allowed, an anomaly would be created because the electronic ballot reader would obviously not be able to match the candidate with one listed.

The scan in is done with SANE scanning software, and the character extraction from the image will be done with OCR libraries. From there, the characters are written to file where the file is then matched with the data that the voting official entered.

The system will be written for Linux, and will be controlled through a web browser interface. The code will be written predominately in C/C++ and will feature our own http server and our own database.

Currently there are no other “known” similar products out there, so this will be effectively, the first of its kind. With the fact that congress is looking to make this type of system mandatory, future opportunities for this program are great. This project also has the potential of merging with another project in the field. The open voting consortium (openvotingconsortium.org) is looking to create free voting software to run on inexpensive PC’s. They have been told of our work and are interested in merging projects.

Overall, this project is effectively ahead of its time, and will be effective in addressing voting problems not yet seen. Because of its design, it is adaptable to a broad range of hardware, and will hopefully grow to be a very useful both today and tomorrow.

2 System Level Design

Figure 2 presents the entire system as a whole, and how each subsystem interacts with the others. The basic functionality is outlined in the class diagrams contained in section 3 – Class Diagrams. The state of the system is maintained in data files as delimited in section 4 – Database Structure. System activity is illustrated with a combination of state and activity charts in section 5 – Activity Charts. Finally, the user interface is previewed in section 6 – User Interface.

Figure 2 – System Overview

3 Class Diagrams And Tables

The basic model of the system is object oriented. There are 9 classes that provided the complete functionality. However, only 7 will be completed by the time of the first demonstration. The reaming two classes (inside the dotted box) deal with automation of the scanning process. Until these two classes are implemented scanning will be performed manually by first scanning each VVR to an image file, and then using OCR software converted to text files which will be read and tabulated.

Figure 3 – Class Diagrams

3.1 – Class Information
Name	BallotReader
Description	Handles all GET and POST browser requests by performing the desired action, to include updating the database, and then creating the appropriate HTML response.
Used By	Top Level Class
Inherits	HTTPServer
Class Methods
IsClientLocal	Determines if the browser is running on this machine.
GetHTMLAction	Determines which action to take for a HTTP request.
TabulateVotes	Reads the ballot text files and updates the vote count.
SendBadRequestResponse	Tells the browser that it made an invalid request.
SendForbiddenResponse	Tells the browser that it is doesn’t have permission to access the requested resource.
SendTextResponse	Sends a dynamically created HTML response.
SendFileResponse	Sends a static (file based) HTML response.
ProcessGetRequest	Handles all incoming GET requests.
ProcessPostRequest	Handles all incoming POST requests

3.2 – Class Information
Name	HTTPServer
Description	Handles the low level HTTP functions, and sets up the request environment for the top level BallotReader class.
Used By	BallotReader
Inherits	Servsock
Class Methods
GetRequestEntity	Gets a pointer to body of an HTTP request.
WriteHeaderLine	Writes a header line to the client browser.
WriteLogEntry	Writes a log entry to the logfile.
WriteResponseText	Writes a dynamically created HTTP response to the client.
WriteResponseFile	Writes a static HTTP response to the client.

3.3 – Class Information
Name	Servsock
Description	Handles all TCP/IP functions for the HTTPServer class.
Used By	HTTPServer; BallotReader
Inherits	None
Class Methods
Read	Reads data from a TCP socket.
Write	Writes data to a TCP socket.
GetClientName	Gets the URL of the client browser.
GetClientAddress	Gets the IP address of the client browser.
GetServerPID	Gets the PID of the parent server process.
GetClientPID	Gets the PID of the child process that was forked off to handle a single TCP/IP connection.

3.4 – Class Information
Name	OCRScan
Description	Turns an image file into a text file.
Used By	BallotReader
Inherits	None
Class Methods
OpenImage	Opens the image file for scanning.
Scan	Converts the image to text.
CloseImage	Closes the image file and finalizes the text file.

3.5 – Class Information
Name	ImageScan
Description	Turns the actual VVR into an image file.
Used By	OCRScan
Inherits	None
Class Methods
OpenScanner	Sets up the scanner.
Scan	Scans the VVR into an image file.
CloseScanner	Finishes the scan and closes the image file.

3.6 – Class Information
Name	DBManage
Description	Manages and acts as the central access point for all of the database files. The database contains the actual state of the system, and it is important that all transactions are atomic.
Used By	BallotReader
Inherits	None
Class Methods
CreateNewDB	Create a new office or proposition database.
AddNewRecord	Add a new candidate or response to the database.
UpdateCount	Adds one to the vote count for a candidate or response.
CorrectAnomaly	Assigns the anomaly to a database and updates the count.
CorrectError	Assigns an error to a database and updates the count.
SelectCountDB	Selects a ‘count’ database for iteration.
GetNextCount	Gets the next iteration record for the selected count database.
SelectAnomalyDB	Selects a ‘verify’ database for iteration.
GetNextAnomaly	Gets the next record for the selected verify database.
SelectErrorDB	Selects errors for iteration.
GetNextError	Gets the next error record.
GetAnomalyCount	Gets the total number of anomalies remaining.
GetErrorCount	Gets the total number of errors remaining.

3.7 – Class Information
Name	DBCount
Description	Maintains all the count databases.
Used By	DBManage
Inherits	None
Class Methods
CreateDB	Create a new office or proposition database.
AddRecord	Adds a new candidate or response.
UpdateRecord	Adds one to the total vote count for a candidate or response.
SelectDB	Selects the count database and begins an iteration.
GetNextRecord	Gets the next record for the selected database.

3.8 – Class Information
Name	DBVerify
Description	Maintains all of the anomaly databases.
Used By	DBManage
Inherits	None
Class Methods
CreateDB	Create a new office or proposition anomaly database.
AddRecord	Add a new anomaly to a database.
DeleteRecord	Sets the record as ‘assigned’ to a count database.
SelectDB	Selects an anomaly database, and begins an iteration.
GetNextRecord	Gets the next anomaly in the selected database.
CountRecords	Gets the total number of unverified anomalies.

3.9 – Class Information
Name	DBErrors
Description	Maintains a list of all errors encountered during tabulation.
Used By	DBManage
Inherits	None
Class Methods
AddRecord	Adds an error to the list.
DeleteRecord	Sets the record as assigned to a count database.
SelectDB	Starts an iteration of all unverified errors.
GetNextRecord	Gets the next error.
CountRecords	Gets the total number of unverified errors.

4 Database Structure

The following record structures are used within the system database. The database, and hence, the records maintain the current state of the system. Each record is defined outside of the class that manages it for ease of use by the programmer.

COUNTINFO – Count Database (class: DBCount)
Field	Description
Name	Name of candidate or response
Count	Number of votes received (initial value = 0)

VERIFYINFO – Verify Database (class: DBVerify)
Field	Description
Tag	Record ID
Name	Name of candidate or response
Image	Number of the image that contains this vote

ERRORSINFO – Errors Database (class: DBErrors)
Field	Description
Tag	Record ID
Type	Name of office or proposition
Name	Name of candidate or response
Image	Number of the image that contains this vote

5 Activity Charts

The following figures show the important logical decisions that are made within the system.

Figure 5.1 – Message Processing

Figure 5.2 – Tabulate Vote

Figure 5.3 – Enter New Office

Figure 5.4 – Enter New Proposition

Figure 5.5 – Verify Anomaly

Figure 5.6 – Verify Error

6 User Interface Design

The user interface is written entirely in HTML and are designed to be viewed from within a web browser in order to remain platform independent. These pages contain most of the data entry and state modification logic via the POST HTTP method and form variables. The screen shots shown in Figures 6.1 to 6.5 represent the configuration process and are straight forward, requiring no detailed explanation. The screen shots in Figures 6.6 to 6.12 represent the certification process, and each group of figures is followed by a brief description of their purpose.

Figure 6.1 – Federal Offices

Figure 6.2 – Federal OfficesContinued

Figure 6.3 – State/Local Offices

Figure 6.4 - Propositions

Figure 6.5 – Configuration Completed

Figure 6.6 – Initial Results

The screen shot in Figure 6.6 shows the results after all of the ballots have been scanned and read. The total amount of ballots read is specified along with the amount of votes obtained by each of the candidates in the appropriate category. Voting results of propositions are also displayed to the Voting Official. Towards the end of the page, the recount statistics are displayed as far as any anomalies or errors are concerned. If anomalies and/or errors exist, the Voting Official is granted the capability of correcting those ballots. The Correct Anomalies and Correct Errors buttons lead the Voting Official to different pages where he/she can make the necessary corrections to those ballots.

Figure 6.7 – State/Local Initial Results

Figure 6.8 - State/Local Initial Results Continued

Figure 6.9 - State/Local Initial Results Continued

The screen shots in shown in Figures 6.7 to 6.9 show the candidates for the state and local offices. Each of the candidates for those offices is accompanied by the total number of votes obtained. Also displayed is the combined number of votes for each office.

Figure 6.10 – Proposition Results

The screen shot in Figure 6.10 shows the number of votes that each of the answers for a proposition obtained. Also displayed is the combined number of votes for the proposition.

Figure 6.11 – Ballot Anomalies

The screen shot in Figure 6.11 shows the statistic obtained by the recount in regards to anomalous and erroneous ballots. Each of the provided buttons will take the Voting Official to the necessary pages in order to make the appropriate changes.

Figure 6.12 – Ballot Errors

The screen shot in Figure 6.12 provides the Voting Official with details on the erroneous ballots. It provides the number of the erroneous ballot as well as access to the ballot’s image and text files. Correction buttons are also provided in order to allow the Voting Official to make the necessary changes. However, the correction for a ballot cannot be made until the image file has been reviewed. The page also specifies how many votes are left to correct.

7 Team Member Contributions

General specification decisions such as selection of Use Cases, and which optional reports were implemented, where made in committee. Specific implementations were assigned as follows:

Rosa Arias: Activity Charts; Glossary; User interface screen shots

Chad Feller: Introduction; Database Structure; User interface screen shots.

Walter Smith: System Level Design; Class Diagrams; Publishing this document.

8 Glossary of Terms

Digital Recording Electronic (DRE) – A digital electronic device used to record a voter’s selection of candidates and proposition choices during an election. Is intended to replace the traditional paper ballot. When networked together with other DREs in the same voting place a accurate tally of votes can be tabulated.

Flatbed Scanner – Hardware device used to convert a paper based record into an image that scan be stored on a computer. Requires that each record be on a sheet of paper, as opposed to a sheet fed scanner which can scan a single sheet of paper or a entire roll of paper without intervention.

HTML – Stands for Hypertext Markup Language. Used by web developers to design webpages for use over the internet. The user interface will be designed using HTML to allow other voting officials to monitor the process counting and certifying the VVR.

HTTP – Stands for Hypertext Transport Protocol. Protocol used to distribute HTML documents between providers and users. Web servers and browsers use this protocol communicate. The software in this projected will be implemented as a HTTP server to provide the user interface.

Optical Character Recognition (OCR) Software – A collection of software utilities that can take an image file as input and output a text file. More advance versions can convert the text in an image to popular word processing formats. For this project only a simple text format is needed.

Voting Official – An official elected too, or appointed by elected officials, or monitor all election processes within a voting district. The voting official is the central actor of the process used by this project.

Voter Verification Record (VVR) – A printable record of each voter’s choices that is kept within a DRE to provide a paper trail for voting officials. This is the record that will be used in this project.

9 References

[1] A. Corrado and C. M. Firestone Editors, Elections in Cyberspace: Toward a New Era in American Politics, The Aspen Institute, 1996. Provides background on the subject of using computer technology to automate the voting process. Several scenarios are presented that outline the benefits and potential problems that may occur. (Domain Book)

[2] Thomas Powell and Dan Whitworth, HTML Programming Reference, McGraw Hill, New York 2001

[3] David Gourley and Brian Totty, HTTP The Definitive Guide, O’Reilly, Printed in the United States 2002

[4] Warren W. Gay, Linux Socket Programming, Que, Indianapolis, Indiana 2000

[5] J. Arlow and I. Neustadt, UML and the Unified Process, Addison-Wesley, 2002. Provides examples and detailed description on UML usage and the design process.