I have attached two documents prepared by Citizens For Accurate Mail Ballot Results (CAMBER) concerning problems with the November, 2001, mail-in election in Boulder County. The Word document contains both CAMBER's list of election irregularities and responses from the Boulder County Clerk. As many other Colorado counties conducted a mail-in ballot election, these comments have broad applicability for the state.

When establishing standards in the past I have found it quite useful to look at real world problems. While many of the problems presented in the attachments may already be covered by standards, e.g., recertification requirements, they are not making it down to the election officials, or are not being followed if they are.

I think it is also useful to look at where current voting machines are failing, or lack features essential to an honest and accurate election. The General Election Systems (GES) Accu-Vote system is widely used, and misused in Colorado and in a number of other states. The GES VoteRemote system for scanning mail-in ballots was first used here in the November, 2001, election with problems occurring both in Boulder and El Paso Counties.

One of the major problems I see with computer voting is the "black box" approach. In the process poll watchers, such as Mr. Kolwicz are either excluded or ignored and election judges and officials have no technical background so what comes out is treated as gospel. GIGO in reverse, i.e., Garbage In, Gospel Out. And though I have only attempted to deal with GES they are, to say the least, uncooperative.

From the conference calls it seems apparent that the IEEE group does not favor mail-in elections, and Mr. Kolwicz's report will likely reinforce that prejudice. However, legislation was introduced, and defeated, last year to encourage such elections, and many Colorado counties went ahead with mail-in elections anyway. It is also likely legislation will be introduced again this year enabling mail-in elections. Given the vastly increased opportunities for election fraud with mail-in ballots, particularly combined with computer vote counting, it would seem wise to look at standards for such elections. Absentee and military ballots will continue to be cast by mail in any event and the handling of the military ballots in the November, 2000, election was of national concern.

* A fundamental problem is an accurate and up-to-date voter registration database. In the November, 2001, election some 10-12% of the ballots were returned by the US Post Office as non-deliverable. More alarming was the number of residences that received multiple ballots, e.g., I received two, and I've heard of some who received five. Of course, some registered voters did not receive a ballot. I realize this is an immense problem but any ballot-by-mail plans must address and solve the problems in advance. In the past election the approach was damn the torpedoes, full speed ahead. Hence, Mr. Kolwicz's extensive comments.

* The interface between legislated mandates and IEEE and Federal Election Commission (FEC) standards needs to be addressed. For example, from comments by the Boulder County Clerk it is clear the deceased should be allowed to vote ballots mailed to their last address unless the County Clerk has received an "official notification" of their passing. Whether a seance would suffice for the deceased to vote or to provide the clerk with official notification, or other procedures are required, is unclear. The point, however, is that the voter registration roles, i.e., voter database, must be consistent with both the law and with technical standards. How do we approach that?

* From the Boulder County Clerk's response it is clear that having the ballot number match the number on the envelope cannot be relied upon due, in part, to equipment used to stuff the envelopes. Also, where multiple ballots go to the same address the clerk attributes the mismatch to human error. Of course this multiplies the potential for fraud.

* Ballots were mailed to voters in the wrong counties by the printer(?) in at least two cases. That held up the election results for three weeks for those counties. On a finer scale, there is little assurance that ballots for the right slate of candidates and issues will be mailed only to those voters eligible to vote for those candidates and on those issues. Or, conversely, that voters eligible to vote for a candidate or issue will be given a ballot with those on it. Again, this is a voter registration database issue. If such database issues can't be resolved then standards for voting machines are nearly superfluous.

Remarks here address problems with GES Accu-Vote and VoteRemote equipment used in the November, 2001, election in Colorado. Equipment manufactured by other companies probably has many of the same, as well as some different problems. These remarks are not intended as a diatribe against GES but GES public relations could definitely use a vast improvement.

* Colorado has not recertified its Accu-Vote equipment since 1995-96 when it was operating on a UNIX OS. Accu-Vote machines used in the 2001 election have all been ported to a PC running NT OS. The VoteRemote equipment used in the 2001 election has never been certified as best I can find out. The Boulder County Clerk indicates there is no requirement to do so. Both standards and legislation require such certification and recertification but nothing happens when it isn't done. I think the entire IEEE group is aware of the hazards of that neglect.

* Security is a major concern to all of us. But in practice it ranges from nonexistent to pretty poor. In Teller County the voting computer simply stands in a corner of the IT department. El Paso County has a special secure room with keypad access for the voting computers but for the mail-in election they moved the computers to a insecure auditorium. Accu-Vote uses modems to connect to optical scanner tabulators taken to the precincts. Phone line security is a matter of luck. The tabulator is accessible via modem or cell phone and an IR link. Software is obviously being modified or replaced during the course of an election and, according to the Boulder County Clerk there is no requirement to even log such problems, simply let the tech rep make it work. Nor is there an audit of such changes or, apparently, what effect such changes have on election results. Mr. Kolwicz is also severely critical of the VoteRemote software, so the odd "bug", either accidental or deliberate is a given. Protection against equipment intrusion either physically or remotely is generally primitive to non-existent. Few clerks seem to take precautions against viruses, worms, trojan horses, or have firewalls installed.

* Equipment accuracy is fundamental but there don't seem to be quantitative measures applied. The problem is compounded by human error and Mr. Kolwicz details many such. As one of the state legislators I deal with won his election in 2000 by about 100 votes, and the presidential race was decided on the basis of a few hundred votes, I am appalled when I see disagreements where 375 more ballots are counted than cast in a single county. A month after the election was certified the clerk has that down to a difference of only 62 from the original 75,569 cast and 75,944 counted. Counting errors are one justification for moving to computer voting but most hand counts come out better than this. Interoperability problems between machines seems to play a major role in the vote counting discrepancies. There is also the unmentioned problem of tracking write-in candidates.

* A major advantage of a system like Accu-Vote and its GEMS software is that it aids greatly in producing ballots for the multitude of candidates, special districts, and issues that arise even within small counties or townships. However, as is quite evident in Mr. Kolwicz's report, tracking and accounting for the ballots is in very rough shape. Whether the problem is mechanical, with a ballot with one number being stuffed into an envelope with a different number, or an optical one with scanners and associated signature-recognition software, or human error of what ballots get put in and pulled out of what tray, there is a long way to go. Toss in functional problems of working with the post office for delivery and security and we have a ways to go. There is also the problem that the ballot is produced as a PostScript file, and anyone who gets ahold of that file can edit it to suit themselves, or print their own ballots.

* Clearly there is no version or upgrade control for hardware or software, nor are versions and upgrades frozen during an election. And since the software and hardware are not fixed, any pre-election testing becomes invalid when the change is made. Nor is testing done to determine what effect such changes might have on the election. As noted above, there isn't even an audit trail of such changes.

* Legacy system migration is a problem probably everyone in the IEEE group has faced but I don't find any mention of it with regard to elections. And we are dealing with county clerks with only the most rudimentary computer skills and even if they have an IT department it usually isn't much. Migrating legacy data is a time when Murphy has a lot of fun. Don't know if this is part of the standards but it is certainly part of the process.

* Outside of the report by Mr. Kolwicz, made at substantial effort, I have not seen any attempt to integrate poll watchers with computer voting. And he appears to have encountered great resistance. The role of election judges seems to be being reduced to rubber stamping computer results. I don't find that acceptable.

* Recounts done by the same computer system and method seem meaningless. Standards should specify another method, preferably including a hand count option. That is in line with Brit William's requirement to record an image of the ballot cast.

Charles E. Corry, Ph.D., F.G.S.A.
455 Bear Creek Road
Colorado Springs, CO 80906-5820
Telephone: (719) 520-1089
Facsimile:        (509) 472-5275
Instant Messenger:        drcecorry
Home page: http://www.pcisys.net/~ccorry
Curriculum Vitae: http://www.pcisys.net/~ccorry/CorryBook-82.htm