Let's pretend they're not using Access for a second -- let's pretend they're using a full-featured real relational database like Oracle, henceforth an RDBMS.

Here's why you'd want to use one of those.

1. Reliability. Any decent RDBMS provides you with transactional integrity. You want to know, absolutely and without question, whether or not a vote has been recorded. You never want to be uncertain of the integrity of your database. An RDBMS gives you that certainty.

This is not a feature restricted to relational databases per se, but it's a high end feature that you won't happen to find elsewhere.

2. You can't have it both ways. One of the huge problems with the Diebolds is the lack of audit trail. If you don't store anything but +1 to Smith, you've completely lost any hope of an audit trail. If I can stroll over to the machine after hours, and add a bunch of votes without the time of the vote being recorded, we've got even worse problems than the ones that exist right now.

3. Big financial institutions use RDBMS all the time, and oddly, they do not run into problems with the rollback scenario Erik proposes. He's kind of blurring the issues (sorry, Erik).

I agree that using an RDBMS, *per se*, is not
evidence of any evil intent.

It's a general tool used for a specific purpose.
That's the history of computing. The software
is already running on a general-purpose computing
device, under a general-purpose operating system --
because that's a commodity platform which is
cheap, well-known, and well-supported. (I'll save
the Microsoft cracks for another forum.)

The only point worth noting is that an audit of the
device must include inspection of the RDBMS structure
and programming, in addition to the interface
software and operating system.

I just responded to this -- in the other thread of course (the response took a while). My take in brief:

1. I bascially agree with Eric -- I prefer paper mark/sense systems over touchscreen for both auditablility and general reliability. And they are cheaper as well.

2. Eric has confused relational with relationships -- a common misunderstanding.

3. Real production grade RDBMS's such as Oracle, DB2 (sigh), SQL Server, and PostGRES have a varitey of features that enhance auditablility that Access does not (and probably should not) have. But you don't want to load those on a touchscreen.

There are very good reasons to use RDBMS's for the collation and reporting of voting results that can enhance the reliability of results. Using Access on a touchscreen to capture the vote itself does not. Paper works. Stick with paper for this.

Even if Diebold were storing voting records in a tab-delimited text file, we would still have a problem.

I am not familiar with the communications protocols, etc, used by the voting machines, but my guess is it works something like this:

Each machine has a serial number. Each voter gets a ticket number (when I voted using an e-vote machine, I was given a slip with a number to punch into my machine as a sort of password). The machine accumulates all the vote data internally, perhaps along with time-stamps, and at the end of the day uploads it to the mothership.

Also: when I vote, I have to present ID (obviously) and sign in. I'm not sure if they record my ticket number next to my name--I'll have to check next time--but if they do, that's the end of secret ballots.

Even without that, they can come close to associating specific votes to specific voters. And again, it doesn't matter whether the data is primarily stored in a RDBMS or not, since it could always be imported to one after the fact.

Let me take my comment (on the thread below) and Adam's a bit further with this bit of information:

After the election, it is possible to obtain how people of various parties voted in each precinct. Therefore, if there is one Democrat in a very small absentee precinct, you can then match up the voter to how they voted by looking at your lists of registered voters. In fact, I've done it, mainly for amusement value. Granted, it doesn't work in areas with very large populations, but I suppose if you were very determined, you could at least make some educated guesses by watching polling places, particularly when you have divided your volunteers according to precincts so they get to know individual voters.

All this is perfectly legal. There are also illegal, unethical methods of obtaining information, which might involve an inside job of some sort, but there are protections against such things. However, one can (and does, one when is campaign staff) legally obtain quite enough personal information (name, age, phone number, address, stated political party, precinct number, I've even seen lists with social security numbers) and voting information about various voters that it would make probably a good portion of the population nervous if they were aware of it. Think about campaigning somewhere like Brentwood--ever wonder where those star maps people get their information?

At least in California, you can decline to state your political party and phone numbers are optional, but then you are potentially hampering the campaign efforts of a candidate you'd like to see elected by limiting staff's ability to gather information; information they use to target staff and volunteer time to vulnerable precincts and money to areas that require more intensive media buys.

For "recounts," of course; that's why to have a database. Of course a recount of what is in the database presupposes that it was validly recorded to begin with.

I, too, am a professional in the database arena. Before we can analyze what kind of data storage system is needed for an application, we should look at the requirements. Bev Harris's description of the Diebold System from the NZ mirror here

http://www.scoop.co.nz/mason/stories/HL0307/S00065.htm

is shown below. To summarize, this system appears to require 1) a reliable store for the vote total at the precinct. This is a single number, and can be stored in various simple ways. 2) A store at the city, county, or state level where vote aggregation is being done. From the Harris description, aggregation reports must enable "...Election summary (totals, county wide) or a detail report (totals for each precinct)."

Eric is therefore correct that a single relation, containing (geographic-area, precinct, vote-total) should be sufficient for aggregating the vote of an entire state.

Others have stated that the qualities of a relational database are needed here. This is incorrect. Relational databases have complex mechanisms to ensure that database changes applied to multiple relationships but representing a single application-level change are either all applied to the permanent store or none are applied. This protects against a failure of part of the computer hardware or software during the multiple updates such an application change entails. A partially completed update would leave some storage areas updated and others not, an inconsistent or corrupted state that is difficult to recover from.

The vote counting application, in contrast, can use a much simpler mechanism than the complexity of a relational database system and associated reporting functionality. All that is needed for the core application, the part whose software needs to be transparent to public inspection, is a program to accept (from the precinct) and store one number together with the precinct identifier for every precinct duly participating in the election. The resulting relation is very simple and could if necessary be checked manually. Subsequent to the collection of this simple relation, any proprietary software a vendor can talk a county into buying could input the relation and make pretty reports. But the data itself could be available for all to examine and process for themselves.

Here is Harris's description.

"Diebold Elections Systems AccuVote systems use software called "GEMS," and this system is used in 37 states. The voting system works like this:

"Voters vote at the precinct, running their ballot through an optical scan, or entering their vote on a touch screen.

"After the polls close, poll workers transmit the votes that have been accumulated to the county office. They do this by modem.

"At the county office, there is a "host computer" with a program on it called GEMS. GEMS receives the incoming votes and stores them in a vote ledger. But in the files we examined, which were created by Diebold employees and/or county officials, we learned that the Diebold program used another set of books with a copy of what is in vote ledger 1. And at the same time, it made yet a third vote ledger with another copy.

"Apparently, the Elections Supervisor never sees these three sets of books. All she sees is the reports she can run: Election summary (totals, county wide) or a detail report (totals for each precinct). She has no way of knowing that her GEMS program is using multiple sets of books, because the GEMS interface draws its data from an Access database, which is hidden. And here is what is quite odd: On the programs we tested, the Election summary (totals, county wide) come from the vote ledger 2 instead of vote ledger 1, and ledger 2 can be altered so it may or may not match ledger 1.

"Now, think of it like this: You want the report to add up only the actual votes. But, unbeknownst to the election supervisor, votes can be added and subtracted from vote ledger 2. Official reports come from vote ledger 2, which has been disengaged from vote ledger 1. If one asks for a detailed report for some precincts, though, the report comes from vote ledger 1. Therefore, if you keep the correct votes in vote ledger 1, a spot check of detailed precincts (even if you compare voter-verified paper ballots) will always be correct.

"And what is vote ledger 3 for? For now, we are calling it the 'Lord Only Knows' vote ledger."

Possibly-naive question: does building on top of a DBMS make it easier to add improvements such as preferential voting (aka instant runoff)? Or is this an orthogonal issue?

Perhaps Diebold is using a relational database because their programmers have joined the sinister death cult.

Remember the poll that showed Dewey beating Truman? Remember why that poll failed? Remember the poll that showed Wilkie beating Roosevelt? Remember why that poll failed?

Okay.

It's all very well and good to have all blogdom in a rage. What's needed is to get the word, in simple-to-understand form, out in ink-on-paper magazines and newspapers. So, let's all bell that cat. I'm writing a letter to the Union Leader.

How 'bout the rest of you?

Extra toy here: Vote Fraud Simulator

In my post above, I should have said "for aggregating the vote on a single ballot item for an entire state.

Implementing instant runoff could be accomodated by adding another column to the relation: "preference order". This would multiply the number of rows in the relation by the number of preferences voters were allowed to reflect. I have read that San Francisco is considering a system that allows 5 preferences to be indicated. Conceptually any number could be accomodated. Of course, the complexity of the voting machine increases as well.

The software that actually tallies the votes also grows more complex, but is still quite amenable to inspection. Again, fancy reporting can be done with any ancillary software that can input the basic file.

Slashdot has been all over this story.

Latest (Tuesday 10/21): a group of Swarthmore students are defying a court order by posting Diebold confidential memos online.

The answer to "Why an RDBMS?" is "Why NOT an RDBMS?" It's almost always easier, more portable, and more flexible to write software that stores its data in a DBMS than in a flat-file.

But, man, Access.

Correction: I said above "they can come close". I should probably revise that to say "they could come close if they really had their shit together."

On the one hand, their incompetence increases the odds that my vote will be mis/uncounted. On the other, at least I don't have to worry about visits from the goon squad for my unwise voting.

"because their programmers have joined the sinister death cult."

I find it ironic that an email likening rdbms people to a sinister death cult advocates the use of LISP

"The answer to "Why an RDBMS?" is "Why NOT an RDBMS?" It's almost always easier, more portable, and more flexible to write software that stores its data in a DBMS than in a flat-file."

by that reasoning they should have an xml format for storing voting results.

The answer to "Why an RDBMS?" is "Why NOT an RDBMS?" It's almost always easier, more portable, and more flexible to write software that stores its data in a DBMS than in a flat-file.

As my former BOFH-mentor would say "Bzzt. Thank you for playing."

How is it, Erik Asked Quite Pointedly, that ease of programming, or far worse, flexibility, are virtues in this role?

It doesn't need to be easier to program this. Counting votes is easy. You find the candidate voted for, you increment his vote counter by one. In a seperate action you increment a total vote counter. Repeat for each voter.

At the end of voting, you output the counters.

That's it. That's the *entire* voting procedure. If there's more data than that to process, you are doing this wrong.

STV is a little harder, but code to do so has existed for at least 15 years. Compared to, say, Solitare on Windows, it's trivial code.

This doesn't require an RDBMS. You could implement this on a PIC microcontroller.

As to flexibility. Let me make this as clear as I can. THERE SHOULD BE NOTHING FLEXIBLE ABOUT A VOTE COUNTER, OTHER THAN THE NUMBER OF CANDIDATES. PERIOD.

And it should be a royal bitch to change that. You should not be able to change *one* *damn* *thing* at the polling place. Period.

And what data are you storing? Let's say your stuck counting in a standard American form -- he who has the most votes, wins. How many bytes do you need to store this data?

Well, a 32-bit unsigned integer can count to 4 294 967 296. That's a little low for many states. So, we use a double. A double on a 32 bit machine can hold about 18,446,744,100,000,000,000 votes per counter. When you candidates start getting a quadrillion votes, you can start thinking about adding a third byte to each counter, but, I think for my lifetime, it's enough.

You don't need floating point -- there is no such thing as a non-integer vote. You don't need a sign bit -- at no time should the machine *remove* a cast vote, and at no time should a candidate ever have a negative vote total.

So. 2*num_candidates+2(total votes) = total bytes required. For your typical presidental election, this is, oh, somewhere around 12-20 bytes. For the recent California nastiness, you don't even need a kilobyte.

So. We have, basically, a trival data storage and a trivial process to implement. And I'm supposed to slap an RDMBS on it so I can go "One, Two, Three?"

Wrong Answer, for dozens of reasons. If you must do voting electronically, don't add any capability to the machine that isn't directly and immediatly needed. Given the simplicity of the problem -- programmatically, even an STV vote with three dozen candidates is a peice of cake -- using an RDBMS just makes things easier to abuse and screw up.

I don't want this programmed by a VB programmer running an ODBC interface to the Database Of Your Choice. If the programmer can't do the core functionality in less than 100 lines of C, that programmer is unfit to do the job. All that needed to be added to that is the UI and the data transmission routines -- both of which A) are much harder to do right and B) are not helped by a database.

The number of things that don't need a is legion. The number of things that have been programmed into a DB that didn't need to be there, at a huge cost of complexity, stability and money, is legion.

Hell, the Navigator 4 email client is a legendary example of why you *shouldn't* use a database.

I wonder if there isn't a tendency for programmers to look at the vote-recording, conveying, tabulating, and reporting as the "problem." If that's the "problem," of course a relational database manager is going to look like a comfortable "solution."

The thing is, that's not the problem. The actual problem--the actual task at hand--is maintaining an open and accountable democracy which provides as few opportunities to cheat as possible.

Erik seems to be describing (sans fancy video UI and electronics) the old New York State voting machines I and my parents and grandparents used all our lives.

Erik, you're being ridiculously reductionist. Why flexible? Because every voting machine in every district needs to have different positions and different candidates (and, oh, if it's in California, you're legally bound to list them in a particular order that certainly isn't the one you hard-coded in).

And you need to group the candidates and specify how many in each group you can vote for (i.e., only one President, but three district judges), and you probably need to show their party affiliation, and allow a straight party ticket (in some precincts; in others it may be illegal to show that option) (and hey, there's another relationship: party to candidate, so you know who to tick off if the user votes a straight party-line).

You're ignoring all the details and complications that make software actually complex to develop, and pretending that all you're implementing is a pair of counters.

Patrick: The data-collection and transmission problem is a subset of the broader problem you describe. Yes, you need to get all that data secured, audited, and so forth, but ALSO you need to present the ballot to the voters in a non-confusing way, collect the votes reliably, and so forth.

If you can't give the voters a UI (whether it be touch-screen, ATM-style, punch-card, Scantron or otherwise) that they can easily understand and use, and if you can't accurately store their votes, you sure as heck can't do much toward reaching that broader goal.

I think I know why they used Access: It was easy and fast to implement.

I'd also point out that the votes of a single voter--that is, that voter's ballot--have to be of a piece. If the vote is successfully challenged, you need a mechanism to revoke all the votes.

You don't need an RDBMS to do that, but you do need more than a counter. Somewhere you've got a key--voter ID--and a bunch of records--the individual votes--and an RDBMS will do that.

A better way would be a single record for each ballot--tab-delimited text, BerkeleyDB, Perl hash, whatever--with the voter ID as the key, and the votes recorded in race-choice pairs.

That looks funny, though, because it's not 3NF, so someone reflexively rejected that solution. It also wasn't as easy and fast as sticking into an RDBMS.

(The microcontroller solution bugs me because--and correct me if I'm wrong, because it's outside my area of expertise--it'd need different firmware at every precinct, and firmware is not transparent.)

Uh, excuse me? For what possible reason would one want to record a "voter ID" ??

If you use a relational DBMS, you get all sorts of things for free that you don't get with a plain text file or BerkeleyDB. Transactions, so that if something breaks while your vote's being recorded, your whole vote can be rolled back and you can try again safely.

I'm not saying that a RDBMS was definitely the best thing here, because I don't know enough about their requirements to even begin to speculate (neither does anyone here who hasn't developed this type of software), but I'm saying that on the face of it, it's not a dumb decision.

ACCESS, though... hoo boy. Access. Wow.

Mike:

That's why the physical audit trail is the true safeguard. I really like the idea of a touchscreen which prints out a physical ballot to be optically scanned. That provides lots of benefits:

1) Setup is much easier than for printing physical ballots or adjusting mechanical voting machines.
2) The voter can look over the ballot and make sure the votes are cast correctly.
3) The ballots are then dropped into the box, which randomizes their order (something an audit tape inside a voting machine could only do with some difficulty).
4) Optical scanning is fast and accurate.
5) And it can be hand-verified.

Jon:

It's common practice. The way it works in Arkansas is that every ballot is numbered, both on the ballot proper and on the stub. Your ballot number is recorded in the book when you get your ballot.

Why would this be done? Well, if you can't verify the one voter-one ballot relationship, how can you spot the the ballots that were stuffed? The truly secret ballot is, in a sense, highly insecure.

The secrecy of your ballot depends on the integrity of the people who physically manage the system, and on the checks and balances placed on them by the political system.

Security problems are ultimately human problems. There aren't any technical fixes for that.

Well, I hope that the Arkansas voting officials don't record the names along with the IDs.

Adamsj,

I like your "system." For one thing, if someone is going to cheat, it is a lot harder to get rid of thousands of physical ballots than to make virutal ones disappear. And having the dual system (electronic recording based on physical recording, not the other way around) provides even more protection.

Additionally, personally knowing some of the management at Diebold and what unbelievably self-righouteous, gloated assholes they are, I would never trust them with anything that is supposed to serve the public good. I would expect the worst from them and want the utmost protection from any possible attempt they might make to favor the politicians who protect their corporate interests.

Take the California example again. When one is assigned an absentee ballot, you bet your rear end they record who that ballot was issued to, when and what ballot number was on it. When you submit the absentee, you retain a ballot stub, which also has the serial number. If you were so inclined, you could then call the clerk-recorder and be sure that your ballot had been received and your vote recorded.

They do the same with voter registration forms, which is why when you register yourself as someone able to collect voter registrations, they write down what serial numbers they give you so if a bunch of fradulent requests come in with those numbers, they know who to arrest. Not so consequently, when you register with someone other than the clerk-recorder (tables in front of supermarkets and post offices come to mind), those forms are photocopied by the person taking the registration. The same is done with absentee ballot requests.

Yet more reasons why your vote is not as secret as you think.

Jon:

The ballots are held in one place, the ballot book in another. It takes a court order to put them together. Compartmentalization is a wonderful thing, in the right context.

I'm sure it's been misused, gamed, and cheated, as was the system it replaced, and (most likely) as will any system which replaces it; the goal is to make it as good as possible.

It's not a controversy-free choice.

It's been debated, with the black-helicopter people (possibly an unfair characterization) and their left-wing analogues being the primary opponents.

There's such a thing as being so skeptical as to be gullible. If we're ever in Arkansaw at the same time, I'll introduce you to some people on both sides of all stripes who prove it beyond a doubt.

My current precinct does keep the ballot stub, and the scantron style ballots are fed into a machine that stores them until collected. I'm not sure if they are connected to me or not. One little surveilance camera and it wouldn't be too hard to figure that out though.

The problem with any of the electronic methods is that there's no practical way to verify that there hasn't been any tampering to the system short of being able to independently count the votes by second seperate trusted system.

The best solution I can see is:

Electronic voting to create an official scantronable ballot and a reciept that contains a short cryptographic checksum that can be given to the voter.

The electronics are for fast reporting. A scannable ballot allows for recounts and checking manually if necessary, especially in cases where the outcome is not within some percentage of what is expected by polling. And the checksum can be done in a way that it should be possible to check to see that your vote was recorded properly without revealing any of the contents of your vote.

Erik: you're still completely ignoring the need for an audit trail.

And yes; you do need one above and beyond the paper ballots, because you damned well want to be able to catch the people who screwed with things. "Um, we know someone added 500,000 votes to Smith, but we can't ever figure out who."

Are there privacy implications? Of course. Which is an argument for not having electronic voting at all. I'm beginning to think it's not possible to both have auditable electronic voting and adequate privacy.

But a flatfile scheme exacerbates the problem.

Erik: you're still completely ignoring the need for an audit trail.

Damn right I am. Because you cannot make a secure audit trail within the electronic voting machine. If you can lie about the initial vote, you can lie to the audit trail. Fundamentally, all computer do is set bits and clear bits.

IF the voting machine is generating human readable paper, then we have a useful audit trail. But if the voter cannot compare the audit trail vote to the counted vote, then there is no true audit trail.

Mike--
Your criticism of Erik's point (on the coding requirements) is really addressing a separate issue. Erik was talking about tabulation; you're talking about presentation and validation. Assuming the voting machine won't let you vote wrong, the tabulator can be dead simple.

This discussion makes me think that a dual-counting system--paper and electronic--would be ideal. Have each voting machine spit out a paper tape. Tabulate the votes electronically as a first pass, but use paper tapes for the real count. Major discrepancies would indicate a problem. Will we see it? Not anytime soon.

So far I haven't seen what I consider the probable real reason for using Access: It's all the consultants and/or programmers involved knew how to use, and so their "survey" of suitable programs automatically settled upon Access because everything else is "too hard to work with." They had the hammer, they decided everything needed to be nailed.

I don't deny the possibility of malice, you understand... but there's still a chance we could attribute the initial choice to stupidity.

I have worked in the King Co., Washington, Board of Elections checking absentee ballots. In theory, one could record who an absentee voter voted for. in practice, not. When an absentee ballot is issued, it has a number, which is recorded as being issued to a specific voter. When it's returned by the voter, it's returned in a special envelope whcih also bears that number, and a space for the voter's signature. The returned ballot is checked against a signature card to make sure the actual voter has signed it. Then it's opened and the ballot inside is put in a basket along with other votes for that precinct. The actual ballot had a number on it, but that is supposed to be removed by the voter (not everyonne does this, so sometimes the election worker has to remove it). Then the actual votes are tabulated by a card reader. Now, let's assume you were dishonorable, say, for example, in the state of Florida. I suppose you could preselect the absentee ballots of Democratic voters and either destroy them or fold, spindle or other wise mutilate them so that they would be declared "spoiled ballots" and invalid. But you'd have to take them out of the envelope (and they save the envelopes), or else destroy the whole envelope. Not so easy. Nevertheless, I've always thought the easiest way to manipulate the votes is at the final counting stage. Who knows what the algorithm is to count them? And unless there's a full re-count, how can we know that a thousand here or there weren't disappeared?

Back to first principles ...

Q: What is the purpose of a secret ballot?

A: To ensure that the voters are not interfered with.

This could be positive interference -- "vote for Big Machine Al and we'll buy you a shot of whiskey" -- or negative interference -- "vote for Saddam or we shoot your dog". But the point is, the secrecy is of secondary importance to the requirement that voters not be interfered with.

Given the history of electoral fraud, it's not hard to see why secrecy has become something of a holy grail -- both types of interference above have been used dismayingly often, and only keeping the relationship between the voter's identity and the votes they cast secret seems to work reliably.

But I submit that if we start using electronic voting techniques, secrecy becomes a liability because the nature of electoral fraud changes in line with the technology: we have to add a new requirement (voter authentication) because authenticating votes at the software level authenticates nothing but the existence of a bloody database file, with no guarantee that it hasn't been tampered with.

You can take this as a strong argument against computerized voting. Or you can take this as an argument for re-thinking the entire framework of the debate: as Patrick pointed out, it's about how is democracy to be implemented, without external interference, and this is a much broader question than whether or not RDBMSs are evil.

(Got more to say on the subject but don't want to get distracted.)

IF the voting machine is generating human readable paper, then we have a useful audit trail. But if the voter cannot compare the audit trail vote to the counted vote, then there is no true audit trail.

Um, that's exactly my point. If the counted vote is a simple +/- counter, you can't compare it to the paper trail.

Ah. We're crossing points. I was arguing that, if you build an electronic machine, an RDBMS is the wrong tool to do so, because of the nature of the problem set, which is trivial.

I happen to completely agree with you that a vote machine that doesn't generate paper for each vote is fundamentally crooked.

But, I realize after I hit the send button, if you are doing this properly (namely, printing a ballot), then the *only* thing you want in the machine is counters. Collecting any other data -- time of vote, etc. -- is contrary to the principal of your vote being made secretly.

Those that think Diebold could fix this by using better tools or design need to think about this:

No programmers at that company will question any management decisions about design, security, or anything else, because they will be fired; and, in this economy, that means they are out of IT altogether. In fact, the people that worked on the original implementation are likely long gone and their jobs outsourced to India.

Call me a Luddite if you will, but I find it curious that everyone seems to be accepting as a forgone conclusion that electronic voting is the way to go.

My county uses an optical scanner, which means that when you go into vote, you are handed a pencil and a paper ballot, and vote in a little curtained booth. No problems writing in a candidate, no problems with power outages, or equipment malfunctions, and no hanging chads.

I don't understand why there is a push to move from this system, which is reliable and easy.

Yes, we can switch to an electronic voting system, but I have yet to come across an argument that convinced me as to why we should. (And that doesn't even go into the cost of implementing a new system, which I don't see how municipalities with already strained budgets, can afford.)

(And if it explains things a bit, my day job is software support)

Hi, Michelle,

You've back-handedly put your finger on why I'm not arguing against electronic voting per se: I don't want to be perceived as a Luddite. I think that's a good way to be marginalized and ignored.

Not all the companies out there which want a piece of the voting machine action are run by right-wing ideologues. I'm sure there are some who just want to rake in the bucks making the machines, and would be just as happy to make honest machines as dishonest machines. There might even still be a company or two (privately-held, I suppose) that would prefer to do an honest job of it.

Those companies and their congressional buddies have the artillery to win this fight, if we can get them into it. Those of us who are simply concerned--that is, nervous--citizens don't.

The Democratic Party isn't taking up the issue. The Greens are taking it up, sort of, and will be perceived (fairly accurately, I think) as Luddites when they do. It's not a favorable situation.

Hi adamsj,

What is interesting about the debate about electronic voting is that the only voices I have heard arguing against it and being taken seriously are computer people, who I suppose can't be labelled as Luddites, seeing as how they are already in the technology.

My problem is that I seem electronic voting machines as a ridiculous expense that will cause problems where none currently exist. I work with computers every day, and know quite well how unreliable they are, and how easily systems can be manipulated.

I also worry about the effects the machines will have on the poll workers. The poll workers I have ever seen in my county seem to be about 70 years old. I'm not saying they can't learn the technology, I'm saying that they can't lift the technology, (someone has to set everything up after all), and that they won't know what to do if something goes wrong.

After all, right now even a massive powerfailure that takes down all the electricity to the area for days at a time will have little effect upon voting as long as ballots have already been printed, I just can not believe that electronic voting can say the same thing. (I'm 33, but grew up with power fluccuations and outages occurring on a regular basis. I have never believed that our power system is stable.)

I just cannot believe that electronic voting can't be hacked, and the fact that those likely to do the hacking may possibly be further to the left than I still doesn't reassure me.

And nobody it talking about these issues at all.

Hi, Michelle,

What you're saying is very reasonable, even where I disagree, but I don't think it's politically tenable. This is too important an issue to lose politically while winning technologically.

It amounts to telling people the technology they use everyday--gas pumps, ATMs, checkout counters--is too untrustworthy to use for elections, and that's just not a winning argument.

We can win this argument by showing how the disputed voting systems differ from the technologies people use. Every one of the devices I mention above has a physical audit trail.

When we argue against the expense of electronic voting machines, the argument can be thrown back on us: "We're already spending on these nice shiny machines--the physical audit trail is too costly!"

It's better, I think, to argue thus:

"Each person's vote is at least as important as the seven gallons of gas they bought at the pump; as the twenty dollars they got from the ATM; as the groceries they purchased at W*l-M*rt.

"We will spend what it takes to run our elections as well and as honestly as we run our businesses."

That's an argument not calculated to win over the hearts of the left. (So? Maybe the left should grow up or give up.) It's designed for moderates and conservatives, from whom we need support.

I agree that it's hard to call tech folks Luddites, but it's not hard to call them loonies.

I'm thinking right now of three notable figures in technology, one I like a lot, one I dislike strongly, and one I don't know at all, each of whom has loudly-expressed political opinions which are just plain nuts. Those are the sort of people who will be used to form public opinion against us. We have to pre-empt that by being incredibly reasonable and mainstream.

Electronic voting machines are not likely to be that much heavier than mechanical machines. Component by component, they may be lighter. The heaviest item is likely to be a UPS system, and that doesn't have to be lifted, just wheeled in. Setup for mechanical systems is done now by official personnel. That can be done for electronic systems, too.

There are real advantages to electronic systems, particularly touchscreen systems. They're easy to set up for complex ballots. They're easy to make multilingual. They allow the voter to review the ballot before casting it. They can allow the voter to review the vote against a pre-generated sample ballot with the desired votes marked--again, a boon for a complex ballot with many questions.

The final safeguard in any system is the physical audit trail. Any system can be hacked. There are ways of rigging mechanical systems. Every year, there are illegal voter suppression campaigns which can seldom be traced back to Republicans but are targeted at heavily Democratic precincts. Physical intimidation is not unheard of, and I'm not just talking about the riots in Florida.

The key is to have a good enough system for producing physically secure verifiable ballots.

When push comes to shove, you can put the physical counting and re-counting of those ballots into the public eye. Most partisans of every party will not sign off on actual, honest-to-god cheating. At worst, they turn a blind eye to it. Put it in their faces and they will back down. The Republicans went as far as they could with the riot in Florida, and it's hurt them somewhat.

Again, what you're saying is very reasonable, but in politics, reason is seldom enough.

Re: "why use electronic voting at all?" -- I believe a lot of the impetus for electronic voting is coming from voter rights laws mandating increased accessibility. adamsj touched on this above, but there's more to this than convenience and multilinguality -- in particular, if you're blind, you just can't use a paper ballot. But you can use the Diebold machines we have here in Berkeley; they have little hookups for headphones so you can do everything via audio.

Letting blind people enjoy the same rights to a secret and convenient polling process is something I think we as a society should support, and I doubt I'll find anyone here to disagree. I'm not sure how this could be done without this kind of software support. (Maybe braille ballots? how would those work?) I also wouldn't be surprised if, all else aside, it were cheaper to run elections on machines -- no need to print up millions of ballots, with thousands of different variations, etc.; all that can be handled by the machines. We need to be sensitive to benefits like this; if I'm an election official who thinks electronic voting is great because of reasons A, B and C, and all the people screaming at me about the dangers appear entirely unaware of reasons A, B and C... well, I'm much more likely to dismiss them as people who don't understand the issues involved, and ignore them entirely.

But surely a paper trail isn't too much to ask for. I'm fairly certain that the United States has a larger budget than my local coffee shop; I'd like to think that Americans cared about free and fair elections at least as much as my coffee shop cares about how many macchiatos I ordered last week.

I saw an article somewhere, an interview with an elections official from (I think) Argentina, who saw the lack of a paper trail as a desirable feature -- because this made it impossible for the poll workers (who are in a position to see the human-readable audit trail printout) to intimidate or bribe the voters into voting their way. This was considered a much more serious problem than the potential for meddling with the machines.

Careful arrangement of the voting stations ought to eliminate this problem, however. For instance, instead of having one ballot box for an entire polling place, one could put a box in each voting station (they're just fiberglass suitcases with slots in the side, can't be that expensive compared to the cost of a small computer) so the voters can check their printouts and then squirrel them away, before ever leaving the curtained station.

It also seems to me that thoughtful design of computerized voting machines might produce a system that was harder to tamper with than the alternative. For instance, suppose that all the voting machines are programmed to communicate with each other, in peer-to-peer fashion, and they all maintain running totals for the entire election. And when you go to shut the polls, each machine prints out its idea of the grand total. That should thoroughly scupper any after-the-fact tampering.

Hi adamsj & Nathaniel,

I apologize if I skip any points which you find important.

As far as accessability, my county has no excuse absentee voting. Starting (I think) two weeks before election day, you can go to one place downtown and vote absentee. You don't have to have a doctor's excuse or plane tickets or anything else to prove you won't be able to vote on election day, you just go in and vote. And in our county this is the electronic voting system.

If anything, it is more convient to be able to go to one location at any point several weeks before the election, so if those who have difficulty with "regular" ballots have access to electronic voting assistance, then must such voting be implemented across the board?

Right now, to be honest, my biggest problem is the expense of having areas with accurate voting systems take on the expense of switcing to electronic voting. If a switch has to be made (such as in Florida and areas of California) where punch card machines are being used, then it makes sense to swtich, and to swtich to the latest technology. But it also seems to me that there is a faction who insist upon switch to the latest and greatest technology, even when there are no problems with the current system.
Local budgets--some of which are cutting funding for public schools because of state budget crises--have to finance these changes, for equipment that is used only a couple of times a year. It seems to me that voting technology should not just be accurate and tamperproof, but should also be as inexpensive as possible.

One method of creating a paper trail I have heard, so to have to voting machine print out a paper ballot which the voter can then view before it is placed in the ballot box (I'm not sure why multiple ballot boxes are needed--at least where I vote, before you leave the voting station, you place your ballot in a hard plastic sheath and the ballot is dumped from the sheath into the ballot box. No one can see how you voted.) So if we create a paper ballot for each voter we are essentially just computerizing the way a ballot is filled out. The end result is the same, except that instead of filling out the ballot with a pencil, you use a computer.

Isn't that an awfuly expensive way to acheive the exact same result?

The other issue I have is write-in candidates. last year when I had the opportunity to use an electronic voting machine, I did not see any easy way to write-in a candataite. Perhaps it was just that system, or perhaps there was a way that wasn't obvious, for I wasn't writing in a canidate at that time, but that bothered me in retrospect.) Is there an easy way to write in canidates with electronic voting technology? Is there a way to make the system more accountable other than printing out every single ballot? I don't know, and I wish I did.

Of course I live in an area where we don't have many non-English speakers (unless you consider the mangling of the language by the under-educated) so that may have a great deal of influence upon my opinion. But mostly I just can not move past the cost of switching to a new system unnecessarily. Too much of a local focus I suppose.

Learn Electoral Engineering at Home!

(Headline from fake ad for a correspondence course in National Lampoon a few years back)

Channeling various cybersecurity gurus here:

What's your threat model?

That is, before you can argue "mechanism X is best for us", you have to decide what threats you take seriously, and how important they are. These are some threats off the top of my head:

1. Changing of vote counts by insiders
2. Changing of vote counts by outsiders (break-ins, hacking, etc.)
3. Changing (or discarding) of votes themselves (again, by insiders, or by outsiders)
4. Coercion of voters (by threats of punishment, or promises of reward) to vote to specification (or not to vote at all) - this may or may not require some way for the coercers to determine whether their instructions were followed or not; this is why keeping a verifiable copy of your vote is a bad idea
5. Voting by unauthorized voters (not citizens, wrong precinct, etc.)
6. Repeated voting by qualified voters
7. Changing qualifications of voters (to allow #5, or to prevent qualified voters from voting)

Can anyone think of any other threats against elections?

Unfortunately, I don't know which of these are most likely to happen, though I coercion is fairly low on the list.

I suspect that most probably attacks will either be carried out by relatively few people in secret, or be border-line legitimate so that most of the perpetrators can convince themselves that they didn't do anything wrong. How many of the Florida rioters think they subverted democracy? The "discourage blacks from voting" folks will say that they don't actually stop any legitimate voters from voting, they're just trying to make sure that illegal voters don't slip through the cracks.

The trouble is, unlike bank fraud, for example, the perpetrators of election fraud, at least at the national level, may gain control over any after-the-fact investigation of their fraud. So you have to not just make fraud detectable (long) after the fact; you have to make it OBVIOUS as its happening.

The good news is, the (potential) defenders way outnumber the attackers, if you can make the defenders aware of what to look out for.