oh. my. dear. Ghu.

Does Diebold realize that anyone who knows enough to understand what antivirus software does, also knows enough to understand that the behavior they're claiming is not at all usual?

@1 - I consider myself fairly tech-savvy, but I didn't get your point. Then again, I don't think about anti-virus software that often, so it's probably me.

What I thought the point was is that any computer that deals with something as sensitive as votes would ideally be so insanely hardened against any kind of attack or tomfoolery that no commercial anti-virus software could run on it in the first place, whereas I get the impression runs off the shelf Windows servers or something. But I am probably wrong - for one thing, it doesn't quite fit xkcd's metaphor, hilarious as it is.

I'm with you, Jurie, I don't think I quite get it.

I thought from the XKCD that the system shouldn't need antivirus because it never should come in contact with anything except itself - the servers touch cards from the voting machines, and nothing else.

Anti-virus software? On voting machines?! Who the HELL thinks a voting machine should ever be connected to the Internet AT ALL, under any circumstances whatsodamnever?!!!

OK, my interpretation of what PJ Evans means:

Antivirus sofware doesn't run on whitelists. In other words, it doesn't say, "These things are good, and I will kill everything else." It can't, because there's lots of legit stuff it doesn't recognize.

Instead, it's a blacklist system, with an enormous list of stuff that it knows is bad. When your antivirus software updates signatures, what it's doing is adding more virus patterns to its blacklist of things to block.

So either Diebold was making vote recording systems* look like existing viruses, or the virus software was configured to treat vote recording systems as viruses, or they are talking through their collective arses.

I know which way I'm voting, and it's [removed by AV software].

-----
* Or the data? I can't see that - virus software should be testing executing code, not data such as the votes themselves.

I'm with xkcd. The problem here is that they're using a combination of hardware and software which requires anti-virus software for security in the first place.

There is also the interesting question of how a voting machine catches a virus in the first place. Does it send your votes out onto the internet? Does it exchange data via USB flash drive? If so, why is it autorunning anything in the first place?

A reasonably modern microprocessor will allow you define which portions of memory it will execute code from. It will also allow you to define which portions of memory are writable. If the loader which puts their voting software into memory also defines that memory as executable but not writable, that would take them some ways to being secure. The operating system should do this as a matter of course. However, the NX (No eXecute) bit came to x86 late in its evolution. On the other hand, it's been years since x86 chips that support the NX bit have been out on the market.

Actually, I suppose they could put their software into some flavor of read-only memory. That would be even better in terms of preventing code modification.

None of this is foolproof, of course. However, anti-virus software is a sign that your operating system needs to be more secure. It is not an encouraging sign that your system actually is secure.

I do have to wonder. It's not as if secure embedded operating systems don't exist. They might have been better off starting from there.

I am a programmer.

To put it as clearly as possible, from least to most epic fail:

1. Most states require the software on the voting machines to have been certified. Adding third-party, non-audited software to the system, the virus checker in this case, is probably a violation of that principle.

2. Basing the design of a voting machine around a desktop, virus-vulnerable operating system is lunatic. Trying to counter that threat with virus checking software is doubly so. Security must be designed from the ground up, not bolted on.

3. Using an open network and leaving the machine vulnerable to exterior network-based corruption to transmit the results is negligent. Developing a protocol that would be safe against viruses would have cost them a week of a competent engineer's time. He would turn off all incoming ports to the voting machine, save the one used to report the results, which would respond with only the list of counts, encrypted according to a pre-established one-time pad. Done. Although this part is the least worry to me, given item 4, which is well outside the scope of what voting machine manufacturers control, excepting perhaps through lobbying:

4. Trusting these voting machines to carry the formal record of the election can only make sense from the point of view of someone who is interested co-opting the results of the election. (Audit trail anyone? Without a physical artifact recording the vote? Reading the bits the machine recorded is not a re-count).

"The reason your quarterly financial statements were wrong is that you were running antivirus software while collecting the spreadsheets from your regional accounting managers."

Why would antivirus software interfere with loading data, or why would voting machine data uploads include executable code?

I don't think that the timing of turning off the antivirus software is particularly significant: clearly malware could be introduced at any point in the computer's operating history and set to lurk until the appointed moment, then spung into action.

The notion that this computer system is ever exposed to live, unfiltered interactions with the world at large (which is the only reason one would need antivirus software running on it) is truly frightening.

I would not be at all surprised to discover that the procurement rules required that all these systems run Commercial, Off The Shelf (COTS) software, or even that the requirements were such that some variant of MS Windows was required. Even given all that, though, there is no good reason why the central tabulator should ever have to process input from systems other than its satellites.

"Why would antivirus software interfere with loading data, or why would voting machine data uploads include executable code?"

If I had to make a guess without knowing the details: the antivirus software probably scans the entire filesystem when a new volume is attached to a peripheral bus looking for bit patterns contained in known malware, and the antivirus code is "buggy"— or maybe malevolent, let's not rule that out— so it "rewrites" things it finds on the volume in order to "neutralize" them before allowing the operating system to mount the filesystem, and sometime it erroneously rewrites things that aren't malware, e.g. the voting results that show not enough votes going to the Republican candidates for them to win the election. At least, that's what I'm presuming that Premiere claims is happening.

Shorter Premiere: it's MacAfee's bug, not ours.

XKCD is exactly right. If you need an antivirus package on your vote tabulator server, you're doing it wrong.

While I agree with the programmers in the audience (former programmer here) about the other epic fails, anti-virus software is well-known for interfering with a large class of applications (usually anything interacting with a network, since a lot of anti-virus software installs buggy network code).

The Cygwin project (a unix emulation layer on windows) has habitually run into problems when anti-virus software is installed.

See their Big List of Dodgy Apps and note how many are anti-virus.

A few, somewhat related, thoughts (and I note that I know just enough about this field to be dangerous and thus am noting that as a disclaimer):

XKCD, despite being funny, got the story a bit wrong. The anti-virus software was running on the servers that tabulated the votes, whereas XKCD stated that it was running on the voting machines themselves.

Now, to consider all the things that would be wrong, were the voting machines to be running an anti-virus program -- and, specifically, a commercial anti-virus program. First, if they're running a commercial anti-virus program, that virtually guarantees that they are running Windows. Windows is a poor choice of operating system for a secure application. The programmers do not have access to the source code for it, and thus cannot perform security audits on it. Furthermore, they cannot perform any sort of audit on it, even so basic a one as knowing what other programs will be running when their code executes, and whether any of those programs might have bugs that might cause data corruption. (And, worse, running an anti-virus program adds to the number of programs running around and mucking with the system while it's trying to do secure things.) Beyond this, the Windows security model is known to be fairly insecure.

(Consider, for example, the case where some researchers were able to bypass security on a Diebold voting machine with a USB stick that triggered Windows's "autorun" feature. There's a program in Windows that scans newly-loaded drives for certain files, and if the files exist, it automatically runs them. Maybe the Diebold engineers forgot that it was running. Or maybe they remembered, and turned it off, and somewhere there's a quasi-bug deep in some of Windows's update software that turns it back on, which nobody knew about. This is not a root problem; this is a symptom of the problem that the system is far too big and inscrutable for anyone at Diebold -- and probably at Microsoft -- to make any plausible claim that they completely understand how it all works in enough detail to make any sort of security statements about it.)

Second, running any multitasking operating system at all is a poor choice, for many of those reasons. A voting machine needs to do one thing at a time; it does not need to multitask. Running it on a system that does multitasking means that there will always be a number of unknown other things going on while the vote-tabulating code is running, which may muck with what's going on.

Third, the only way intrusions can happen is if the system intermingles program instructions with the data that it reads and writes from the memory cards. There exist computer architectures that will only execute instructions that come from a ROM chip (which can be reprogrammed, but only with a significant amount of physical access), and can guarantee that anything on the memory card will not get into the instruction stream.

The combination of processor types like that with a simple program that runs by itself without an operating system would produce a system that could actually be audited for security. It would be possible to examine the code and provide an actual proof that the results on the memory card corresponded to the votes cast. As it stands, however, the best that can be said is something like, "We think it will work, and we tested it a lot it laboratory conditions."

The fundamental problem, though, IMHO, is that we think that computers are like our desktop workstations, which are vastly complicated and unpredictable and do orders of magnitude more things at once than anyone can understand on more than an approximate level. And so, when we envision a computerized voting machine, we accept that this is a reasonable design for one, because it's trivial to make a desktop workstation tabulate votes. The right model for a voting machine is much closer to the computer in my dishwasher, which accepts no more than three dozen different inputs and does exactly predictable things with them in ways that one engineer understood completely.

And that is why a commerical anti-virus program on a voting machine is thirty-seven kinds of wrong. If the voting machine is capable of running the anti-virus program, it is not merely unnecessarily capable of getting into far more complicated states than we can understand and prevent from going wrong, it is actively doing it.

What Paul LaLonde @8 said.

It's in the running for the worst thing I've heard about Diebold yet (and that list is long) that the votes can be tabulated on J. Random Windows Machine conected to the Net. Any remotely sane, remotely competent design would include all relevant machines running a minimal system with nothing extraneous installed -- the less stuff you have running, the fewer opportunities you have for vulnerabilities.

My vague guess as to the sort of bug that happened, meanwhile, if it was an anti-virus program problem:

I hypothesize that this was a "real-time file check" part of the virus checker, which scans every file that gets loaded from disk, when it gets loaded.

How that works is by getting in the middle of the system between, in this case, the file with the votes stored on the memory card, and the program that's tabulating the votes. And it intercepts that data, checks it over, and passes it along to the vote-tabulator program.

If the antivirus program is bug-free and everything in the rest of the system works as intended, it will do this in a way that is completely transparent to the tabulator.

This is, of course, not a good hypothesis to rely on. Many things can go wrong. Maybe the antivirus program is busy at the wrong moment and take an extra few milliseconds to scan the file, and the tabulator program (or, more accurately, the parts of Windows that the tabulator program is using to load the file data) think that that delay means that the file doesn't exist, and so it doesn't get counted. Or maybe it's something else like that, where some complicated long chain of things builds out of a very tiny error.

Anything that gets in the middle of the process may perturb it. And anti-virus programs work by getting in the middle of every process on the computer that they can get in the middle of (and then checking it), pretty much.

A small note, counter to the comments about how the system should never be exposed to anything from the outside world: I should think it wise to harden the system against the possibility of a rogue memory card getting into the stream of tabulated results (especially in cases where the system is in storage or being tested, rather than when it's counting live votes), even if one is reasonably certain the stream is secure.

As can be concluded from my previous comments, I think any system design where anti-virus software is the right way to do that hardening is likely to be quite poorly designed, but I would not be surprised if the Diebold machines were designed that way.

And a quick note about "the virus checker did it": I've yet to see a case where that answer was true. It's an easy cop-out, but frankly, if the virus checker caused a short read on the file, the code reading it should have trapped the error. Many error conditions can occur in production systems and *if* (and it's a big if) the virus checker caused the problem, Diebold was still negligent for not writing code robust to simple I/O errors.

I suspect them of either the worst sort of cop-out, or of being voodoo computing practitioners instead of engineers. I don't know which is the most charitable.

Diebold was still negligent for not writing code robust to simple I/O errors

Ding!

Remember, these are the guys that used Access as their database and had sign bit overflow problems in their counter variables.

But all the original programmers have undoubtedly by now been replaced by outsourced labor in India. Doesn't that make you feel more secure?

Brooks Moses@14: I think that was my comment.

At some point in thinking about what might have happened I tentatively concluded that the satellite counting systems were uploading vote tallies over some kind of network link and probably running a complex OS ("...uploaded to shared servers."). That might be close enough for government work if the network were private (or virtually private), but not otherwise.

In general, I'd think that any software system which included a TCP/IP stack would be suboptimal w.r.t. efficient and accurate audits. Allowing random systems to throw traffic at such a system would take it from "suboptimal" to "fully pessimized."

As Paul says, even if the "anti-virus" story is correct, it's still Premiere's fault. If you're going to be moving data around (on smartcards or anything else) you need to use the proper techniques and safeguards against data corruption. Just doing a copy and hoping that everything works isn't acceptable for a high-reliability application.

(Unfortunately reliable copying is the classic example of the "end-to-end" principle and yet the one that hardly anybody gets right.)

I did a quick google. At least as of 2006, the Diebold AccuVote TS used Windows CE as its operating system. No, it's not the Windows that you run on your laptop. However, all of Brook Moses's arguments @11 still apply.

It's not a big surprise that Republican-owned Diebold's electioneering division had to suffer a name change to try to bleed off bad publicity associated with the D-word.

As for antivirus action on election software, I figure it's possible that some election software components could have been quarantined and disabled as suspected malware, such as integrated data tampering to throw close elections by a slim margin.

I won't believe any election software (regardless of who wrote it) is fair unless it survives rigorous third-party code examination (backed by the EFF, for example). Even so, last minute code injection in battleground states could slip past and ruin things anyway.

Ah, Access databases. This makes perfect sense now.

I use Codebase databases in an application - the open-source supported version of dBase from where Access databases come as well. They are Multiple-file databases. What happens is that the Real-time AV software sees a new file, or a change to a file, and goes in to make sure someone hasn't slipped them a fast one. Do that to a system that's writing to .dbf, then to .cdx, and one write works, but the other fails because AV is checking from the last write, and you have a corrupted database. Pretty easy to fix, but until you do so, you're hosed.

Having said that, the only access to the Real World that your voting machines, tabulation or end-user, should have is sneakernet via 3.5". If you need more data than you can put on a 3.5", You're Doing It Wrong. And if that's correct, AV software on the system is exactly equivalent to condoms on a poll worker.

Of course, Security Is Hard, and it's just easier to get it half-right and just hope Users Are Stupid doesn't bite you Today.

Earl Cooley III @ 20: It's even worse. I won't believe *any* electronic vote collection is accurate, no matter how audited and examined the machine is.

The argument for these machines is that they make tabulation faster and so can provide results in a more timely manner. Given that counting paper ballots scales very well with number of ballots I fail to see the need.

Paper voting is well understood, but frequently mis-applied. The basics are simple: count each ballot box, publicly, at the place of voting, immediately at the close of voting.

Making it practical works like this:

1. Limit the number of votes per ballot box to 500-1000 (depending on the complexity of the ballots) by distributing voters to many boxes at a polling station.

2. Let each person named on the ballot be allowed a representative present at the counting; if the party can't spare a counter for each ballot box they are unlikely to be elected, but their votes are still counted. Any representative can challenge a ballot and that ballot is put aside (sealed in an envelope) for later consideration.

This system has the advantage that any of the ballot-box counting committees has a strictly limited scope of fraudulent behavior: only the 500-1000 ballots per box is at risk for any set of corrupt counters. That means that even in tightly contested elections it's difficult to systematically drift the result: too many people have to be aware of the fraud to have a significant effect.

A typical error made in implementing ballot counting is the transporting ballot boxes, which not only allows substitutions to occur, but also typically centralizes the counting, which leads to fewer people needing to be corrupted to dramatically alter votes.

Really - there is nothing, except perhaps marking the ballot, that a machine can do better than humans in enforcing an accurate ballot count.

I am a programmer, but since this is back to school week, I've actually spent my xkcd energy trying to suppress the urge to ask the teachers if they always wear a condom while they're teaching.

Paul Lalonde #22: It's even worse. I won't believe *any* electronic vote collection is accurate, no matter how audited and examined the machine is.

Wow, whodathunk that I would turn out to be a moderate on this issue! heh.

"Diebold was still negligent for not writing code robust to simple I/O errors."

You mean, Diebold^H^H^H^H^H^H^HPremiere was at fault for not writing code that failed to perform a suitable integrity check on the payload data. I have a hard time ascribing that to negligence, or even reckless incompetence. I see mischief as the only reasonable explanation.

Earl @ 24: People forget that the requirement of a good election process is not just to count accurately, but also to count transparently. The appearance of vote fraud is as bad a result as actual vote fraud, weakening the validity of the result. The process should be understandable to every voter, not just those skilled enough in the technical arts to make a judgement on the validity of a software audit.

Jurie #2:

Yeah, you may be a little bit off with that assumption about voting machines. Check out the California Secretary of State's top-to-bottom review on election systems. FWIW, I know a lot of the folks involved in this very well, and they know what they're doing. The voting system manufacturers did not come out of that review looking even remotely competent. (Honestly, putting those experts up against the voting industry was like staging a fight between a grizzly bear and a chihuahua.)

The real question you have to ask is whether the voting technology and procedures work together to make the whole election outcome auditable in some meaningful way, and whether anyone pays attention to the results of those audits. It's relatively easy to do this (in a labor intensive way) with a pure paper election, or with hand-marked optical scan ballots plus a random percentage of precincts being randomly chosen for auditing recounts. Most of the discussions of clever software security mechanisms that could be used for voting machines kind-of miss this, and focus on how to be more sure that outsiders can't, say, slip some malware into the voting machines. That's worth going to some trouble to avoid, but even when you've done all that stuff, you still need to be able to audit the results.

It's more than likely that these machines actually run some form of Microsoft Windows. I don't even know what else to say at this point. This is like designing a bucket based on a modern tank. Sure you can pour water into it and probably also get it out again, but FOR THE LOVE OF GOD WHY DON'T YOU JUST MAKE A BUCKET?

There is, of course, this famous list of the top ten worst uses for Windows. I think this would top the list.

Honestly, aren't there engineers out there who'd say, voting machine? Cool, we'll design that from the ground up and actually get to build something cool from scratch! I guess there are... and I guess there are COMMITTEES somewhere who tell them not to.

Regardless of operating system, election computer systems would be high value targets for a variety of black hats.

I swear I saw a commercial in the last few days (but I can't find it online) where an elections official is massively worried about missing votes until the Maytag repairman steps into a booth (the kind with the curtain) and comes back out with the missing votes. Then the official is ecstatic.

I can think of plenty of hypothetical ways that anti-virus software could have caused some sort of problem, particularly if you allow for bad reportering.

- The software decided some directory should not be world-writable, and caused it to be unable to accept new files (or a file unable to accept updates)
- The software burned a lot of CPU or disk time while scanning, slowing down the vote software and uncovering a race condition[*]
- The software had a "block browser popups" or "block browser controls/plugins" mode, which prevented some part of the vote software from working[**]
- All the failure modes described at the bottom of that "Dodgy Apps" page that Richard Campbell @10 linked to.

[* Perhaps a human race condition, of the form "Leave the vote card in the slot for 30 seconds".]
[** Go ahead, reassure me that Diebold *wouldn't* implement vote tabulation using a mix of PHP and ActiveX controls.]

You can make up more. They all smack of some level of negligence -- but, really, the *point* of anti-virus software is to break other software. In ways that the other software cannot competely control. It's chemotherapy for computers -- you hope that it poisons your desired software *less*.

Now, back on the first hand, the line "Premier instructed users to disable the antivirus software on vote tabulation servers..." just smacks of boilerplate. I see such instructions on lots of software (usually installers), and I'm sure it's often tuchus-covering rather than a documented problem: if we can find a usage note that the user violated, it wasn't our fault.

Diebold has been trying to bypass the certification and contract obligations on voting machines for the last decade. (at least)

At one point they tried to claim that a code audit would be a breach of contract because of trade secret requirements. Nevermind that Nevada and other states that have legalized gambling are very careful about code audit, and change control, for their machines, and have, as far as i have heard, no problems with maintaining trade secret confidentiality.

Apparently, in each case where the machines have been decertified Diebold has still pressed to be paid in full.

Basing the operation on any sort of commercial OS is stupid.

Basing the operation on any kind of "shared server"is insane.

The entire operation should be physically separate, and with inbuilt printers for audit trail/verification, and the onluy way for vote counts to be moved from the voting machines to the eventual tabulation machines should be by physically moving *duplicated* data media to the "outside" world (such as burning a CD).

And any type of system for tabulating votes should have been constructed robustly enough, and tested enough, that someone running an AV package should not have been a surprise,

abi @ #5
virus software should be testing executing code, not data such as the votes themselves.

If it was anti-virus detection of a TCP stream, it'd be damned hard to say if it was executable code or data being streamed. Easier when it comes to a file on disk, as the excutable code normally has headers identifying it as such.

So, really, it would depend on how the vote data was moved from the individual voting statiosn to the central server.

For what it is worth, I prefer paper-based voting, without voter-identifying numbers on the ballot(s).

I'm with the folks who favour paper voting and lots-of-eyeballs as a fraud prevention mechanism.

Failing that? If you've got to have voting machines, then dedicated hardware is the way to go. Something simple. I'd suggest a Z80 running something derived from CP/M 2.2, burned into ROM, getting its election parameters (date, names of candidates) off a pluggable EPROM and saving the votes simultaneously on human-readable paper and on a PROM (not an EPROM, but a PROM -- burn it once and read it until the cows come home, but you can't overwrite it). Physically ship the PROM, under guard, to the tabulator machine, which maybe has a one-way RS-232 output to splat data at the election authority's line printer, whereupon a human being will double-check the totals given by the separate voting machines with a desktop calculator before announcing the count. Oh, and GPL the source code and operating system, and release the binaries publicly, and invite comp. sci. undergraduates to try and break it for course credits.

(Reason for picking CP/M 2.2: it's simple. The whole OS fits in about 30Kb of machine code, 200Kb of assembler source. It's not multi-tasking. It has no networking code. And it's small enough that many, many programmers have been able to understand it exhaustively. Sorry about the itallics, I feel these points are important.)
This is 1970s tech, but it's up to the job of handling ballots, and it's harder to corrupt than the sort of spatchcock GUI-assisted nightmares that Diebold appears to be foisting on the electorate.

Wearing my rather dusty software engineer hat: oh, for heaven's sake, MS-Windows can't be used for any secure system--military procurement or the intelligence community would just laugh this design off the table. That said, it must be admitted that the contracts for US voting systems were not written in any way that required security, reliability, or even adequate testing. I don't think we can honestly blame Diebold for that; it's the fault of our so-called representatives, elected by a so-called popular vote. It's also the fault of a populace that, in major part, does not take the responsibility of citizenship in a democracy seriously enough to fight to maintain democracy. I think we've failed bitterly in educating our citizenry.

First, if they're running a commercial anti-virus program, that virtually guarantees that they are running Windows.

Diebold voting machines run on a custom version of Windows CE.

34: I will out-Stross Stross by suggesting an even more robust system: pencil marks on bits of paper, counted by hand.

Yes, it'll take a little longer to count. So? Longer than the five weeks it took in 2000?

35: I wish you were right that military procurement would laugh off the idea of using Windows.

The British Royal Navy uses it for command-and-control systems in their *nuclear-powered Trafalgar-class submarines.

*I know they are nuclear-powered; they may also be nuclear-armed. They carry Tomohawk missles which can deliver nuclear weapons from US ships.

Must agree with Charlie's recommendation of a Z80. That's solid and very reliable.

It's also the fault of a populace that, in major part, does not take the responsibility of citizenship in a democracy seriously enough to fight to maintain democracy. I think we've failed bitterly in educating our citizenry.

There's a school of thought that you used to have a considerably better-educated citizenry, but that this otherwise admirable condition was thought likely to interfere with their duties as consumers, so steps were taken to change it.

Probably just conspiracy theories, though.

#31: They wouldn't use PHP + ActiveX.

Goodness no!

They'd use ASP + ActiveX.

Using a Z80 running CP/M wouldn't even invalidate the wish to have a sleek interface with touch screen buttons to push. You could write code to do the kind of limited GUI you'd want in an electronic voting booth for the Z80.

I'm all for it!

I find myself hard-pressed to find anything cynical enough to say to match just how bad the current election situation is. It's just way the heck too late to stop the bad guys from stealing the election again. Technical solutions are nice, but can't be brought in to play in time to save the election, even if there were enough lobbying money in place to cancel out the big money from the bad guys. We would have had to persuade a few progressive billionaires (are there any left?) to stop squandering donation money on saving the planet in general to instead save this focal point presidential election.

Hart Intercivic here in Austin uses the Precise real time operating system from ARC in its machines. It is a point in their favor but they also are in denial about the need for outside scrutiny of their source code. All other voting machines use either Windows CE or Windows.

I saw a presentation, four years ago, by a professor from Rice University who had analyzed the code for the Diebold system. Among other astonishing defects: the password was hard coded in the source code. Once you knew that password you could access any Diebold voting machine. There was no way for the user to change it!

He also described the handshaking between the card and the voting machine. It was simple minded beyond belief and easily circumvented. I asked him what grade he would give the programmer if the code had been handed in for a class assignment. F.

Sadly, I think incompetence is adequate to explain the poor design of voting machines. Much of the embedded code produced in this country is produced by EEs who are generally poor programmers. CS majors, on the other hand, frequently don't have enough hardware background to do good embedded work. The job really requires someone with both hardware and software chops and company management that values people with the necessary skill set.

If your software doesn't work with virus checking enabled, don't just put a note in the manual telling people about it. Use code to look for the presence of a checker (virus writers do it all the time), put up a dialog box before essential operations telling people to disable antivirus and how to do it, and then another one for them to certify that they've done so, blah blah blah.

But that would take good testing and quality programming. Instead, the folks at the company formerly known as Diebold (and much of the rest of the industry) appear to have put the bulk of their resources into wining and dining local officials.

If you'll excuse me getting political here...

DOes this describe some sort of market failure? I mean according to the dogma, there are these companies making voting machines, and local and regional gvts buying them, and somehow a reasonably secure machine cannot be made because of what?
Lack of decent programmers or hardware people? The whole game being captured by special interests?

(caveat- I am british with no knowledge of the USA beyond a few books, websites and 2 weeks in CA)

#44: The job really requires someone with both hardware and software chops and company management that values people with the necessary skill set.

A few years ago part of the Diebold source and internal developer correspondence was leaked to the net. That must be the same code the Rice professor was reviewing.

Most of those guys didn't know what they were doing; and as I remember there was at least one "I can't take this anymore" online resignation. As for testing: well, programmers are supposed to get it right the first time. That's what they're paid for!

BTW, they developed the system in Visual C++ using MFC.

Stuart: I would trust neither Joe EE or Joe CS to have adequate Security chops. Also note that EE includes Communication Theory, which is Not Hardware At All, and very useful in this sort of thinking. But the hardware guys take the minimum of that to get their degree, too (as, to be fair, I took exactly enough hardware credits to get my EE degree).

Thinking security, especially Black-hat security, just isn't part of a normal degree, except in "well, you have to watch for buffer overflows" sort of thing. There is a cross-discipline "department" at UWaterloo on Cryptography, from the Math Department (CS is in Math there) and E&CE. It's necessary for simple reasons (once you are told them).

I work for a company full of Very Smart Computer people, and our products are "Key to the Store"-level attack targets. And, simply because I have specifically done Crypto training, I see why we do X intuitively, and can make the "um, that's a really stupid idea, and here's why" comments more than most, who don't.

Mycroft: the problem is not computer/electronic/voting machine security, it is election security. Cryptographic integrity is orthogonal to the real problem, which is ensuring fair multi-partisan oversight and transparency from end to end of the entire process ... which is mediated by human beings.

You can audit the voting machines until the cows come home, but it doesn't mean a damned thing if the officers who supervise the count and announce the result have been bought, or if one party or the other is sending deceptive nastygrams to folks likely to vote for the other party in an attempt to confuse them and prevent them from voting.

Similarly, I'm willing to believe that Diebold's crap voting machines can probably be trusted, if they are loaded and supervised by non-corrupt officials in a transparent and auditable manner.

Focussing on the voting machines is a sign that something is very wrong with the electoral system as a whole.

#46: local and regional gvts buying them

Politician:
The votes for my election were counted by this system.
I won.
Therefore, there's nothing wrong with this system.

Sorry for the multiple post, didn't see this one the first run through.

Guthrie: it's sort of a market failure. The customer builds the specs, and in this case (it's the government) they don't have the security chops to say anything more than "it has to be secure"). So the specs are frequently built with the assistance of those who do know what they're doing - that would be the manufacturers. And they push the specs to what they can or have done, and away from things they can't, haven't, or don't want to do.

And, let's face it, the people that open up new markets are those who can't make money from the old ones; I'd be very happy if the people who made Nevada Slots built the voting machines, but there's no money in it for them. Diebold makes ATMs. There's a lot of money in those things - and that's clear to anybody, with or without a brain - so those things are more hardened and secure than the voting machines, which don't have access to money. Well, not directly, anyway. Plus with the ATMs, not only is the banking industry fairly heavily regulated as to "do you really do the transactions you claim to do?", the bankers don't take the risk - they buy insurance. The insurance people, who buy the risk, they care about security, and don't care about convenience or golf-course procurement deals, so the ATMs have to pass independent scrutiny.

The problem with voting machines is that there's no independent body with money in the game, except Us. And We Don't Count (like teaching to Academia, voters to Government are just a necessary evil that have to be dealt with so they can do what they're there for). The market doesn't actually care about whether it's accurate as long as its authoritative, really; it has to look accurate to the Users(*), though.

(*) Cue the old SysAdmin joke: Ever notice that there are only two professions that refer to their customers as Users? Computers and Drug Dealers.

#44: BTW, they developed the system in Visual C++ using MFC.

*sporks out eyes in dismay*

Of course it's a market failure. You have an enormously uninformed customer base, everybody and their sibling with monetary and other interests that align with all kinds of things other than the quality of elections, and not a heck of a lot of profit to be made even if the damn things work. No one would expect such a market to work properly.

(Of course, in propertarian terms that's not a market failure at all; the market is giving us, the public, exactly the kind of voting machines our elected representatives' deputies are willing to pay for.)

I'm a programmer too, and I'm damned if I know why the job of building a voting machine requires a programmer. As several people have already said, the machine should be designed as a special-purpose computer that can't do anything except tally votes. So there's no OS, no complex I/O software, absolutely no network connection, etc. The basic program is not much more complicated than a controller program in a toaster oven, and could certainly be written by the hardware engineer who designed the circuit board.

#54: But, don't you want to check your email or find out what your Facebook friends are doing at the same time that you are voting?

#51: "Diebold makes ATMs."

This is worth more illumination.

Diebold makes ATMs, and every time I walk up to one I think "Those scum-sucking bastards." Then I trust them with my bank account. Why? It's *not* because an ATM is a Z80 with every assembly instruction on the PROMS-not-EPROMS hand-inspected. (Probably some are, particularly old models, but I bet there's a lot of commodity hardware and software in ATMs these days.)

It *is* because the things aren't run on the open Internet. At least, not that I know of. The connection to the bank is a old-school 1200-baud modem -- occasionally I find an ATM whose modem is set speaker-on, and it's all DTMF and squeal. So the base argument of this thread, that an ATM should not have anti-virus software, is true.

But there are more important factors:

- an ATM runs all the time. An ATM with a bug is causing problems that day. (Whereas a voting machine is hauled out and used once every two or four years. Every use is special circumstances.)

- an ATM is audited by *both* parties. It sits between the bank and the customer, so it has to reassure both of them that it's honest. If it debits your account but doesn't spit out money, you complain to the bank and they have to fix it. If it spits out money but doesn't debit your account, the bank notices the next time it sanity-checks and fixes it. Either way, the bank talks to Diebold about it.

If a voting machine printed out a receipt and then the ballots were posted in public, we wouldn't be agonizing about secure hardware; everybody would audit and the results would be unquestionable. Unfortunately (from a nerd point of view), democracy requires secret balloting, so we have to come up with futzy procedures.

Note that the previous paragraph applies equally to electronic voting machines and to the pencil-and-paper kind.

I agree with Charlie that trust is not a problem to be solved by the application of a computer. The issue that gets the voting machines in the door is accessibility for disabled people. They should hand printed ballots to everyone who can use them and provide a machine for the disabled that will mark their ballot for them and give them feedback, in the form they need, that it has been done properly.

guthrie's question about market failure is on target. I worked for a company that built SCADA systems about 20 years ago. We sold to cities and counties and the amount of back scratching and fine dinners provided to help the officials make up their minds was unbelievable.

At the national level we see a Republican administration pass the Help America Vote Act to buy products from companies that are all owned by Republicans. All this to displace voting systems that were more reliable that the equipment that replaced them.

Here in Texas the Secretary of State certified the Hart Intercivic machines after a test that was nothing but a dog and pony show put on by the vendor's marketing people.

My wife worked at the polls and saw that the most common error was that people forgot to push the button to register their vote after they had set their choices. The poll worker was not allowed to press the button. They were required to clear the inputs so the next voter could use the machine.

My wife worked at the polls and saw that the most common error was that people forgot to push the button to register their vote after they had set their choices. The poll worker was not allowed to press the button. They were required to clear the inputs so the next voter could use the machine.

Training on the Hart-Intercivic machines that have been in use in Boulder County since 2004 (offered in addition to paper ballots, not instead of; they enable the blind to vote independently*) includes that we tell every voter, "You have not voted until you've pressed the 'Vote' button three times** and you've seen the American flag waving on the screen and/or heard/seen the words 'You Have Voted!'". And when we see them leave the machine, we ask them, "Did you see the flag and/or hear/see 'You Have Voted'?"

Our counting of the paper ballots is pretty much as Paul Lalonde describes.

*Headphones and text-to-speech. Also, there's a suck-and-puff attachment for use by those without use of their arms.

**You vote, and then you press VOTE. Then you review your selections on the screen, then you press VOTE. Then a paper version prints up behind the scroll-window to the left, and you review it. Then you press VOTE. Then the paper version scrolls out of sight and you get the American flag waving on the screen.

I was just listening to NPR this afternoon, and was appalled to be told that this year Ohio will stop sending the voting machines home with poll workers.

Yes, that's right, the machines with the terrible security spent 2-3 days in private homes, overseen by nothing more than the poll workers.

It's not that I think any great number of them are/were dishonest, but I am also not sure that none of them are, nor that they were, each and every, in complete control of the machines for the entire period.

Andrew @ 56: Yes, they make ATMs, but when the ATM malfunctions, the bank is on the hook, not you. And you know the machine has malfunctioned and can do something about it.

When a voting machine "malfunctions" the electorate gets shafted: the voter isn't aware, and no-one is on the hook.

Andrew Plotkin @ 56

It's *not* because an ATM is a Z80 with every assembly instruction on the PROMS-not-EPROMS hand-inspected.

The first generation of Diebold ATMs was based on a single board computer they bought from Intel, (lightly customized) with an 8088 running it, IIRC. The whole line of Intel boards had separate ROM and RAM memory blocks, plus 1 or 2 serial ports, I know this because I did the engineering evaluation on the board in a previous incarnation as a hardware engineer; the entire marketing and engineering team was 3 people, and we talked a lot about applications and customers.

The desire to build a voting machine with COTS hardware and software is purely a reflex cost-saving tactic that is meaningless for this application. Specialized hardware would not be any more expensive, because of the large reduction in software development costs (especially testing). Diebold's PHB's probably made the standard foolish decisions without really thinking the problem through. Of course, they may also have done a risk assessment after the fact to determine how their Republican buddies could use the vulnerabilities their bad design induced.

Charlie: "Computer" security isn't - at least not totally. The easiest thing to subvert has always been the process, and the easiest part of the process to subvert is the people. Computer security's hope is to make the secure process the easiest to perform, and to minimize the damage of people subverting the process.

Example in point: My professor came in to an MI5-equivalent building, and they had secure and insecure phone lines; the insecure lines were the only ones he could access. And it wasn't easy to tell which numbers were secure (for security reasons) - but since they labelled the ports of the insecure phone lines with the phone number, a blank phone jack with a dial tone was...And that was in a building dedicated to security.

And that is what I mean by "security chops" as opposed to hardware and software skills; the programmer may not have the hardware knowledge to know that the way he's going to implement something is inefficient/insecure because of the hardware; but he also may not know that the way he's implementing that thing leads to an insecure process.

Of course, the specs designers didn't have the security chops to force "auditing by independent auditors, including source code", or better yet, auditing by The Public, into the requirements docs over the objections of the bidders. And they don't have it because the legislators that appoint the specs designers have no idea that this is a special skill and needs more than just "programmer" skills. They don't know that because they aren't from Nevada or otherwise haven't been burned by this before.

As Schneier's Law states: anyone can design a security system too hard for her to break into. Security Is Hard; even to those people who make a career of it. Nobody in the HAVA path, at least the "customer" side of it, made a career of it; that much is clear.

Diebold Premier has now told the Ohio officials that it was a 'programming error' and not the antivirus software. (Also that it only lost a thousand votes temporarily.)

Why am I not reassured by this?

Bruce #54:

The touch screen/DRE machines you're talking about are more complicated than you're giving them credit (blame, perhaps) for. A lot of the alleged benefit of moving to DREs is that they can efficiently support audio ballots for blind voters, alternative language ballots, multiple different ballot styles[1][2], etc. They can support tracking of provisional ballots[3], and they normally have to deal with write-ins, and I'm sure a dozen other things I'm not thinking of.

Now, it would be nice if someone had carefully considered the security of these machines, and whether adding all that extra stuff made sense. But obviously, that's not what happened.

And at the risk of beating a dead horse, doing a competent job locking down the black box would have been a good thing to do, but it would never be enough. The only fix that works is to design mechanisms (including human-mediated procedures) which make it very likely that any significant fraud or error by the voting machine will get caught, and that attacks that prevent the detection of fraud require the participation of huge numbers of people.

[1] In some places, it's normal to have several different ballots that might be given to you at the same polling place, depending on your registration information. This has to do with overlapping boundaries of legislative districts, school districts, county boundaries, city boundaries, etc. And getting the machine to know which ballot to give you opens yet another vast storehouse of industrial-strength fail, involving electronic pollbooks and ballot activation cards.

[2] Note for non-USAian readers: You probably have no idea what US ballots look like. It's normal to have an election with 20-30 ballot questions, and not uncommon to have more. A couple years back, I heard reference to the ballot in the largest county of (I think) Arizona that was four pages long. This is one reason why we wind up dealing with machine counting of ballots, along with the slickness of the vendors' salesmen. (And I'll let you guess how well voters do at filling in every ballot question correctly according to their intentions on a four page optical scan ballot.)

[3] Provisional ballots are used where there is some question about your eligibility to vote in the election--say, you showed up at the wrong polling place, or your name isn't on the list but should be. For these ballots, it has to be possible to track them back to your name and other information, so that the election officials can later decide whether to count them. Handling these electronically adds yet more moving parts.

It turns out to be a plain old bug, not anti-virus software at all. PES (formerly Diebold) has issued a workaround. To judge from the reporting, it appears to be a day-one bug--a problem that has lurked unnoticed in the machines ever since they were shipped. Putting on my tester hat, I'd say we've just seen a powerful argument for white-box testing of any computer voting system. PEStiferous things.

albatross @ 64

Well, you're right, of course; I was thinking about an electronic replacement for the old mechanical voting machines, which wouldn't stand a chance of handling the kind of ballot I get: usually 1 ballot for state and federal, 1 for county, and 1 for city (and there is at least one super-county organization which is going to make us have yet another ballot if things go on as they have been).

I say, to Davy Jones with the lot of them!. We've been doing quite well in Oregon for the last few years voting by mail. That puts the problems of distributing the correct ballots in a totally different timeframe. And all the problems of ballot handling, counting, etc., can be geographically distributed in whatever way is convenient: you're no longer having to deal with everything at the polling place.

Bruce #66:

Yeah, there are big security issues with mail-in ballots, but they're different problems.

There might possibly be some advantages to setup for the electronic machines. We had a fluke this year in my precinct which led to having two primaries and two general elections (not counting November). It's possible that the electronic machines made this somewhat easier. That said, electronic voting machines are a clear example of PC Week Syndrome. They were bought to be cool-looking.

C Wingate:

Yeah, there are some advantages for electronic voting machines. Honestly, handling all the different ballot styles, audio ballots, and multiple languages is a good thing. But it definitely makes the system more complicated and opens more avenues of attack.

More broadly, my experience is that pretty much all election officials who've run many elections with paper have a few horror stories of ways in which the paper became a huge problem[1]. The DREs sold largely because they promised to make the election officials' lives much easier.

[1] One of my favorites was the city where they bought new ballot boxes, which turned out to be too narrow for the optical scan ballots. So the voters all folded the ballots lengthwise. The optical scanners really didn't appreciate these extra folds (registered as lines right down the middle of the ballot).

For more programming incompetence in the public realm, see this example of Boston's brand new multimillion dollar subway card reading system crashing with a sprintf() error, showing that the system is a Visual C++ app running on Windows.

This is the system that MIT kids revealed security flaws in. The latest news there is that the kids won't be prosecuted after all.

Sounds like The Evil Corporation Formerly Known As Diebold is trying the Hot Coffee defense.