Software increasingly manages the world around us, in subtle ways that are often hard to see. Software helps fly our airplanes (in some cases, particularly military fighter aircraft, software is the only thing keeping them in the air). Software manages our cars (fuel/air mixture, among other things). Software manages our electrical grid. And, closer to home for me, software runs our voting machines and manages our elections.

Sunday's NY Times Magazine has an extended piece about faulty radiation delivery for cancer treatment. The article details two particular fault modes: procedural screwups and software bugs.

The procedural screwups (e.g., treating a patient with stomach cancer with a radiation plan intended for somebody else's breast cancer) are heartbreaking because they're something that could be completely eliminated through fairly simple mechanisms. How about putting barcodes on patient armbands that are read by the radiation machine? "Oops, you're patient #103 and this radiation plan is loaded for patent #319."

The software bugs are another matter entirely. Supposedly, medical device manufacturers, and software correctness people, have all been thoroughly indoctrinated in the history of Therac-25, a radiation machine from the mid-80's whose poor software engineering (and user interface design) directly led to several deaths. This article seems to indicate that those lessons were never properly absorbed.

What's perhaps even more disturbing is that nobody seems to have been deeply bothered when the radiation planning software crashed on them! Did it save their work? Maybe you should double check? Ultimately, the radiation machine just does what it's told, and the software than plans out the precise dosing pattern is responsible for getting it right. Well, if that software is unreliable (which the article clearly indicates), you shouldn't use it again until it's fixed!

What I'd like to know more about, and which the article didn't discuss at all, is what engineering processes, third-party review processes, and certification processes were used. If there's anything we've learned about voting systems, it's that the federal and state certification processes were not up to the task of identifying security vulnerabilities, and that the vendors had demonstrably never intended their software to resist the sorts of the attacks that you would expect on an election system. Instead, we're told that we can rely on poll workers following procedures correctly. Which, of course, is exactly what the article indicates is standard practice for these medical devices. We're relying on the device operators to do the right thing, even when the software is crashing on them, and that's clearly inappropriate.

Writing "correct" software, and further ensuring that it's usable, is a daunting problem. In the voting case, we can at least come up with procedures based on auditing paper ballots, or using various cryptographic techniques, that allow us to detect and correct flaws in the software (although getting such procedures adopted is a daunting problem in its own right, but that's a story for another day). In the aviation case, which I admit to not knowing much about, I do know they put in sanity-checking software, that will detect when the the more detailed algorithms are asking for something insane and will override it. For medical devices like radiation machines, we clearly need a similar combination of mechanisms, both to ensure that operators don't make avoidable mistakes, and to ensure that the software they're using is engineered properly.

As Ed pointed out in October, Sequoia Voting Systems, Inc. ("Sequoia") announced then that it intended to publish the source code of their voting system software, called "Frontier", currently under development. (Also see EKR's post: "Contrarianism on Sequoia's Disclosed Source Voting System".)

Yesterday, Sequoia made good on this promise and you can now pull the source code they've made available from their Subversion repository here:
http://sequoiadev.svn.beanstalkapp.com/projects/

Sequoia refers to this move in it's release as "the first public disclosure of source code from a voting systems manufacturer". Carefully parsed, that's probably correct: there have been unintentional disclosures of source code (e.g., Diebold in 2003) and I know of two other voting industry companies that have disclosed source code (VoteHere, now out of business, and Everyone Counts), but these were either not "voting systems manufacturers" or the disclosures were not available publicly. Of course, almost all of the research systems (like VoteBox and Helios) have been truly open source. Groups like OSDV and OVC have released or will soon release voting system source code under open source licenses.

I wrote a paper ages ago (2006) on the use of open and disclosed source code for voting systems and I'm surprised at how well that analysis and set of recommendations has held up (the original paper is here, an updated version is in pages 11–41 of my PhD thesis).

The purpose of my post here is to highlight one point of that paper in a bit of detail: disclosed source software licenses need to have a few specific features to be useful to potential voting system evaluators. I'll start by describing three examples of disclosed source software licenses and then talk about what I'd like to see, as a tinkerer, in these agreements.

It's Election Day in New Jersey. As usual, I visited several polling places in Princeton over the last few days, looking for unguarded voting machines. It's been well demonstrated that a bad actor who can get physical access to a New Jersey voting machine can modify its behavior to steal votes, so an unguarded voting machine is a vulnerable voting machine.

This time I visited six polling places. What did I find?

The good news -- and there was a little -- is that in one of the six polling places, the machines were properly secured. I'm not sure where the machines were, but I know that they were not visible anywhere in the accessible areas of the building. Maybe the machines were locked in a storage room, or maybe they hadn't been delivered yet, but anyway they were probably safe. This is the first time I have ever found a local polling place, the night before the election, with properly secured voting machines.

At the other five polling places, things weren't so good. At three places, the machines were unguarded in an area open to the public. I walked right up to them and had private time with them. In two other places, the machines were visible from outside the building and protected only by an outside door with an easily defeated lock. I didn't defeat the locks myself -- I wasn't going to cross that line -- but I'll bet you could have opened them quickly with tools you probably have in your car.

The final scorecard: ten machines totally unprotected, eight machines poorly protected, two machines well-protected. That's an improvement, but then again any protection at all would have been an improvement. We still have a long way to go.

Sequoia Voting Systems, one of the major e-voting companies, announced Tuesday that it will publish all of the source code for its forthcoming Frontier product. This is great news--an important step toward the kind of transparency that is necessary to make today's voting systems trustworthy.

To be clear, this will not be a fully open source system, because it won't give users the right to modify and redistribute the software. But it will be open in a very important sense, because everyone will be free to inspect, analyze, and discuss the code.

Significantly, the promise to publish code covers all of the systems involved in running the election and reporting results, "including precinct and central count digital optical scan tabulators, a robust election management and ballot preparation system, and tally, tabulation, and reporting applications". I'm sure the research community will be eager to study this code.

The trend toward publishing election system source code has been building over the last few years. Security experts have long argued that public scrutiny tends to increase security, and is one of the best ways to justify public trust in a system. Independent studies of major voting vendors' source code have found code quality to be disappointing at best, and vendors' all-out resistance to any disclosure has eroded confidence further. Add to this an increasing number of independent open-source voting systems, and secret voting technologies start to look less and less viable, as the public starts insisting that longstanding principles of election transparency be extended to election technology. In short, the time had come for this step.

Still, Sequoia deserves a lot of credit for being the first major vendor to open its technology. How long until the other major vendors follow suit?

The Supreme Administrative Court of Finland has ruled that three municipal elections, the first in Finland to use electronic voting, must be redone because of voting machine problems. (English summary; ruling in Finnish)

The troubles started with a usability problem, which caused 232 voters (about 2% of voters) to leave the voting booth without fully casting their ballots. Electronic Frontiers Finland explains what went wrong:

It seems that the system required the voter to insert a smart card to identify the voter, type in their selected candidate number, then press "ok", check the candidate details on the screen, and then press "ok" again. Some voters did not press "ok" for the second time, but instead removed their smart card from the voting terminal prematurely, causing their ballots not to be cast.

This usability issue was exacerbated by Ministry of Justice instructions, which specifically said that in order to cancel the voting process, the user should click on "cancel" and after that, remove the smart card. Thus, some voters did not realise that their vote had not been registered.

If you want to see what this looks like for a voter, check out the online demo of the voting process, from the Finnish Ministry of Justice (in English).

Well designed voting systems tend to have a prominent, clearly labeled control or action that the voter uses to officially cast his or her vote. This might be a big red "CAST VOTE" button. The Finnish system mistakenly used the same "OK" button used previously in the process, making voter mistakes more likely. Adding to the problem, the voter's smart card was protruding from the front of the machine, making it all too easy for a voter to grab the card and walk away.

No voting machine can stop a "fleeing voter" scenario, where a voter simply walks away during the voting process (we conventionally say "fleeing" even if the voter leaves by mistake), but some systems are much better than others in this respect. Diebold's touchscreen voting machines, for all their faults, got this design element right, pulling the voter's smart card all of the way into the machine and ejecting it only when the voter was supposed to leave -- thus turning the voter's desire to return the smart card into a countermeasure against premature voter departure, rather than a cause of it. (ATM machines often use this same trick of holding the card inside the machine to stop the user from grabbing the card and walking away at the wrong time.) Some older lever machines use an even simpler method against fleeing voters: the same big red handle that casts the ballot also opens the curtains so the voter can leave.

I'd be curious to know what the rules are about fleeing voters in Finland. I know that New Jersey procedures say that if a voter leaves without performing the final step of pushing the "Cast Vote" button, poll workers are supposed to push the button on the voter's behalf (without looking at the voter's choices). Crucially, the design of the New Jersey voting machine (for all its faults) makes it almost certain that such a non-cast ballot will be discovered promptly -- the machine makes a noise when the ballot is cast, and the machine will complain if the poll worker tries to enable the next voter's ballot before the previous voter's ballot has been cast.

It seems likely that the Finnish machine, in addition to its usability problems that led to fleeing voters, had other design/process problems that made a non-completed ballot less noticeable to poll workers. (I don't know this for sure; the answer isn't in any English-language document I have seen.)

Fortunately, the damage was not as bad as it might have been, because the e-voting system was used in only three municipalities, as a pilot program, rather than nationwide. Presumably, nationwide use of the flawed system is now unlikely.

Yesterday Diebold sold its e-voting division, known as Premier Election Systems, to ES&S, one of Premier's competitors. The price was low: about $5 million.

ES&S is reportedly the largest e-voting company, and Premier was the second-largest, so the deal represents a substantial consolidation in the market. The odds of one major e-voting company breaking from the pack and embracing up-to-date security engineering are now even slimmer than before. Premier had seemed like the company most likely to change its ways.

The sale represents the end of an embarrassing era for Diebold. The company must have had high hopes when it first bought a small e-voting company, but the new Diebold e-voting division never approached the parent companies standards for security and product quality. Over time the small e-voting division became an embarrassment, and the parent company distanced itself by renaming the division from Diebold to Premier and publicizing the division's independence. Now Diebold is finally rid of its e-voting division and can return to doing what it does relatively well.

Yesterday I chaired an interesting panel on Internet Voting at CFP. Participants included Amy Bjelland and Craig Stender (State of Arizona), Susan Dzieduszycka-Suinat (Overseas Vote Foundation) Avi Rubin (Johns Hopkins), and Alec Yasinsac (Univ. of South Alabama). Thanks to David Bruggeman and Cameron Wilson at USACM for setting up the panel.

Nobody advocated a full-on web voting system that would allow voting from any web browser. Instead, the emphasis was on more modest steps, aimed specifically at overseas voters. Overseas voters are a good target population, because there aren't too many of them -- making experimentation less risky -- and because vote-by-mail serves them poorly.

Discussion focused on two types of systems: voting kiosks, and Internet transmission of absentee ballots.

A voting kiosk is a computer-based system, running carefully configured software, that is set up in a securable location overseas. Voters come to this location, authenticate themselves, and vote just as they would in a polling place back home. A good kiosk system keeps an electronic record, which is transmitted securely across the Internet to voting officials in the voter's home jurisdiction. It also keeps a paper record, verifiable by the voter, which is sent back to voting officials after the elections, enabling a post-election audit. A kiosk can use optical-scan technology or it can be a touch-screen machine with a paper trail -- essentially it's a standard voting system with a paper trail, connected to home across the Internet. If the engineering is done right, if the home system that receives the electronic ballots is walled off from the central vote-tabulating system, and if appropriate post-election auditing is done, this system can be secure enough to use. All of the panelists agreed that this type of system is worth trying, at least as a pilot test.

The other approach is use ordinary absentee ballots, but to distribute them and allow voters to return them online. A voter goes to a web site and downloads a file containing an absentee ballot and a cover sheet. After printing out the file, the voter fills out the cover sheet (giving his name and other information) and the ballot. He scans the cover sheet and ballot, and uploads the scan to a web site. Election officials collect and print the resulting file, and treat the printout like an ordinary absentee ballot.

Kevin Poulsen and Eric Rescorla criticize the security of this system, and for good reason. Internet distribution of blank ballots can be secure enough, if done very carefully, but returning filled-out ballots from an ordinary computer and browser is risky. Eric summarizes the risks:

We have integrity issues here as well: as Poulsen suggests (and quotes Rubin as suggesting), there are a number of ways for things to go wrong here: an attacker could subvert your computer and have it modify the ballots before sending them; you could get phished and the phisher could modify your ballot appropriately before passing it on to the central site. Finally, the attacker could subvert the central server and modify the ballots before they are printed out.

Despite the risks, systems of this sort are moving forward in various places. Arizona has one, which Amy and Craig demonstrated for the panel's audience, and the Overseas Vote Foundation has one as well.

Why is this less-secure alternative getting more traction than kiosk-based systems? Partly it's due to the convenience of being able to vote from anywhere (with a Net connection) instead of having to visit a kiosk location. That's understandable. But another part of the reason seems to be that people don't realize what can go wrong, and how often things actually do go wrong, in online interactions.

In the end, there was a lot of agreement among the panelists -- a rare occurrence in public e-voting discussions -- but disagreement remained about how far we can go safely. For overseas voters at least, the gap between what is convenient and what can be made safe is smaller than it is elsewhere, but that gap does still exist.

I've previously summarized my own testimony and other plaintiffs' witnesses' testimony in the New Jersey voting machines trial, Gusciora v. Corzine.

The defendant is the State of New Jersey (Governor and Secretary of State). The defense case comprised the following witnesses:

Defense witness James Clayton, the Ocean County voting machine warehouse supervisor, is a well-intentioned official who tries to have good procedures to secure the Ocean County voting machines. Still, it became apparent in his testimony that there are security gaps regarding transport of the machines, keys to the machines, and security at polling places before and after election day.

Richard Woodbridge is a patent attorney who has chaired the NJ Voting Machine Examination Committee for more than 20 years. It's not clear why the defendants called him as a witness, because they conducted only a 15-minute direct examination in which he didn't say much. On cross-examination he confirmed that his committee does not conduct an independent analysis of software and does not consult with any computer security experts.

Robert Giles, Director of Elections of the State of New Jersey, testified about experimenting with different forms of seals and locks that New Jersey might apply to its AVC Advantage voting machines. On cross examination, it became clear that there is no rhyme or reason in how the State is choosing seals and other security measures; that they're not getting expert advice on these matters. Also he admitted that there are no statewide control or even supervision of the procedures that counties use to safeguard the voting machines, the results cartridges, keys, and so on. He confirmed that several counties use the cartridges as the official tally, in preference to paper printouts witnessed and signed (at the close of the polls) by election workers.

Edwin Smith testified as an expert witness for the State defendants. Mr. Smith is vice-president and part owner of Sequoia Voting Systems. He stands to gain financially depending on the verdict in this trial: NJ represents 20% of Sequoia's market, and his bonuses depend on sales. Mr. Smith testified to rebut my testimony about fake Z80 processors. (Wayne Wolf, who testified for plaintiffs about fake Z80s, testified after Mr. Smith, as a rebuttal witness.) Even though Mr. Smith repeatedly referred to replacement of Z80s as "science fiction", he then offered lengthy testimony about methods to try to detect fake Z80s. This gave credence to the fact that fraudulent CPUs are not only a possibility but a real threat.

Mr. Smith also confirmed that it is a security risk to connect WinEds computers (that prepare electronic ballot definitions and tabulate results) to the Internet, and that those counties in NJ that do so are making a mistake.

Paul Terwilliger testified as a witness for the defense. Mr. Terwilliger is a longtime employee and/or contractor for Sequoia, who has had primary responsibility over the development of the AVC Advantage for the last 15 years. Mr. Terwilliger admitted that in 2003 the WIPO found that he'd acted in bad faith by cybersquatting on the Diebold.com domain name at the request of Sequoia. Mr. Terwilliger testified that it is indeed possible to program an FPGA to make a "fake Z80" that cheats in elections. But, he said, there are some methods for detecting FPGAs installed on AVC Advantage voting machines instead of the legitimate (Some of these methods are impractical, others are ineffective, others are speculative; see Wayne Wolf's report.) This testimony had the effect of underscoring the seriousness of the fake-Z80 threat.

Originally the defendants were going to rely on Professor Michael Shamos of Carnegie Mellon University as their only expert witness. But the Court never recognized him as an expert witness. The Court ruled that he could not testify about the security and accuracy of the AVC Advantage, because he had not offered an opinion about security and accuracy in his expert report or his deposition.

The Court did permit him to testify in general terms. He said that in real life, we have no proof that a "hacked election" has ever occurred; and that in real life, such a hack would somehow come to light. He offered no studies that support this claim.

Professor Shamos attempted to cast doubt in the Court's mind about the need for software independence, and disparaging precinct-based optical scan voting (PCOS). But he offered no concrete examples and no studies regarding PCOS.

On many issues, Professor Shamos agreed with the plaintiffs' expert: it's straightforward to replace a ROM chip, plastic-strap seals provide only a veneer of protection, the transformed machine can cheat, and pre-election logic-and-accuracy testing would be ineffective in detecting the fraud. He does not dispute many of the bugs and user-interface design flaws that we found, and recommends that those should be fixed.

Professor Shamos admitted that he is alone among computer scientists in his support of paperless DREs. He tried to claim that other computer scientists such as Ted Selker, Douglas W. Jones, Joseph Lorenzo Hall also supported paperless DREs by saying they supported parallel testing--implying that those scientists would consider paperless DREs to be secure enough with parallel testing--but during cross-examination he backed off a bit from this claim. (In fact, as I testified in my rebuttal testimony, Drs. Jones and Hall both consider PCOS to have substantially stronger security, and to be substantially better overall, than DREs with parallel testing.)

Parallel testing is Professor Shamos's proposed method to detect fraudulent software in electronic voting machines. In order to catch software that cheats only on election day, Professor Shamos proposes to cordon off a machine and cast a known list of test votes on it all day. He said that no state has ever implemented a satisfactory parallel testing protocol, however.

Summary of the defendant's case

One of the plaintiffs' most important claims--which they demonstrated on video to the Court--is that one can replace the firmware of the AVC Advantage voting machine with fraudulent firmware that changes votes before the polls close. No defense witness contradicted this. To the extent that the defense put up a case, it hinged on proposed methods for detecting such fraudulent firmware, or on proposed methods for slowing down the attack by putting tamper-evident seals in the way. On both of these issues, defense witnesses contradicted each other, and plaintiffs presented rebuttal witnesses.

Short version: we now have gobs of voting system ITA reports, publicly available and hosted by the NSF ACCURATE e-voting center. As I explain below, ITA's were the Independent Testing Authority laboratories that tested voting systems for many years.

Long version: Before the Election Assistance Commission (EAC) took over the testing and certification of voting systems under the Help America Vote Act (HAVA), this critical function was performed by volunteers. The National Association of State Election Directors (NASED) recognized a need for voting system testing and partnered with the Federal Election Commission (FEC) to establish a qualification program that would test systems as having met or exceeded the requirements of the 1990 and 2002 Voting System Standards.^*

However, as I've lamented many, many times over the years, the input, output and intermediate work product of the NASED testing regime were completely secret, due to proprietary concerns on behalf of the manufacturers. Once a system completed testing, members of the public could see that an entry was made in a publicly-available spreadsheet listing the tested components and a NASED qualification number for the system. But the public was permitted no other insight into the NASED qualification regime.

Researchers were convinced from what evidence was available that the quality of the testing was highly inadequate and that the expertise didn't exist within either the testing laboratories to perform adequate testing or the NASED technical committee to competently review the ultimate test reports submitted by the laboratories (called Independent Testing Authorities (ITA)). Naturally, when reports of problems started to crop-up, like the various Hursti vulnerabilities with Diebold memory cards, the NASED system scrambled to figure out what went wrong.

I know have more moderate views with respect to the NASED regime: sure, it was pretty bad and a lot of serious vulnerabilities slipped through the cracks, but I'm not yet convinced that just having the right people or a different process in place would have resulted in fewer problems in the field. To have fixed the NASED system would have required improvements on all fronts: the technology, the testing paradigms, the people involved and the testing and certification process.

The EAC has since taken over testing and certification. Their process is notable in its much higher level of openness and accountability; the test plans are published (previously claimed as proprietary by the testing labs), the test reports are published (previously claimed as proprietary by the vendors) and the process is specified in detail with a program manual, a laboratory manual, notices of clarification, etc.

This is all great and it helps to increase the transparency of the EAC certification program. But, what about the past? What about the testing that NASED did? Well, we don't know much about it for a number of reasons, chief among them that we never saw any of the materials mentioned above that are now available in the new EAC system.

Through a fortunate FOIA request made of the EAC on behalf of election sleuth Susan Greenhalgh, we now have available a slew of ITA reports from one of the ITAs, Ciber.

The reports are available at the following location (hosted by our NSF ACCURATE e-voting center):

http://accurate-voting.org/docs/ita-reports/

These reports cover the Software ITA testing performed by the ITA Ciber for the following voting systems:

• Automark AIMS 1.0.9
• Diebold GEMS 1.18.19
• Diebold GEMS 1.18.22
• Diebold GEMS 1.18.24
• Diebold AccuVote-TSx Model D
• Diebold AccuVote-TSx Model D w/ AccuView Printer
• Diebold Assure 1.0
• Diebold Assure 1.1
• Diebold Election Media Processor 4.6.2
• Diebold Optical Scan Accumulator Adapter
• Hart System 4.0
• Hart System 4.1
• Hart System 6.0
• Hart System 6.2
• Hart System 6.2.1

I'll be looking at these in my leisure over coming weeks and pointing out interesting features of these reports and the associated correspondence included in the FOIA production.

^*The distinction between certification and qualification, although vague, appears to be that under the NASED system, states did the ultimate certification of a voting system for fitness in future elections.

Sometimes, working on voting seems like running on a treadmill. Old disagreements need to be argued again and again. As long as I've been speaking in public about voting, I've discussed the need for voting systems' source code to be published, as in a book, to create transparency into how the systems operate. Or, put another way, trade secrecy is anathema to election transparency. We, the people, have an expectation that our election policies and procedures are open to scrutiny, and that critical scrutiny is essential to the exercise of our Democracy. (Cue the waving flags.)

On Tuesday, the Election Technology Council (a trade association of four major American voting system manufacturers) put out a white paper on open-source and voting systems. It's nice to see them finally talking about the issue, but there's a distinctive cluelessness in this paper about what, exactly, open source is and what it means for a system to be secure. For example, in a sidebar titled "Disclosed vs. Open: Clarifying Misconceptions", the report states:

... taking a software product that was once proprietary and disclosing its full source code to the general public will result in a complete forfeiture of the software's security ... Although computer scientists chafe at the thought of "security through obscurity," there remains some underlying truths to the idea that software does maintain a level of security through the lack of available public knowledge of the inner workings of a software program.

Really? No. Disclosing the source code only results in a complete forfeiture of the software's security if there was never any security there in the first place. If the product is well-engineered, then disclosing the software will cause no additional security problems. If the product is poorly-engineered, then the lack of disclosure only serves the purpose of delaying the inevitable.

What we learned from the California Top-to-Bottom Review and the Ohio EVEREST study was that, indeed, these systems are unquestionably and unconscionably insecure. The authors of those reports (including yours truly) read the source code, which certainly made it easier to identify just how bad these systems were, but it's fallacious to assume that a prospective attacker, lacking the source code and even lacking our reports, is somehow any less able to identify and exploit the flaws. The wide diversity of security flaws exploited on a regular basis in Microsoft Windows completely undercuts the ETC paper's argument. The bad guys who build these attacks have no access to Windows's source code, but they don't need it. With common debugging tools (as well as customized attacking tools), they can tease apart the operation of the compiled, executable binary applications and engineer all sorts of malware.

Voting systems, in this regard, are just like Microsoft Windows. We have to assume, since voting machines are widely dispersed around the country, that attackers will have the opportunity to tear them apart and extract the machine code. Therefore, it's fair to argue that source disclosure, or the lack thereof, has no meaningful impact on the operational security of our electronic voting machines. They're broken. They need to be repaired.

The ETC paper also seems to confuse disclosed source (published, as in a book) with open source (e.g., under a GPL or BSD license). For years, I've been suggesting that the former would be a good thing, and I haven't taken a strong position on the latter. Even further, the ETC paper seems to assume that open source projects are necessarily driven by volunteer labor, rather than by companies. See, for example:

... if proprietary software is ripped open through legislative fiat, whatever security features exist are completely lost until such time that the process improvement model envisioned by the open source community has an opportunity to take place (Hall 2007).

There are plenty of open-source projects that are centrally maintained by commercial companies with standard, commercial development processes. There's no intrinsic reason that software source code disclosure or open licensing makes any requirements on the development model. And, just because software is suddenly open, there's indeed no guarantee that a community of developers will magically appear and start making improvements. Successful open source communities arise when distinct developers or organizations share a common need.

Before I go on, I'll note that the ETC report has cherry-picked citations to support its cause, and those citations are neither being used honestly nor completely. The above citation to Joe Hall's 2007 EVT paper distorts Hall's opinions. His actual paper, which surveys 55 contracts between voting system manufacturers and the jurisdictions that buy them, makes very specific recommendations, including that these contracts should allow for source code review in the pre-election, post-election, and litigation stages of the election cycle. Hall is arguing in favor of source code disclosure, yet the citation to his paper would seem to have him arguing against it!

So, how would open source (or disclosed source) work in the commercial voting machine industry? The ETC paper suggests that it might be difficult to get an open-source project off the ground with distributed development by volunteers. This is perfectly believable. Consequently, that's not how it would ever work. As I said above, I've always advocated for disclosure, but let's think through how a genuine open-source voting machine might succeed. A likely model is that a state, coalition of states, or even the Federal government would need to step in to fund the development of these systems. The development organization would most likely be a non-profit company, along the lines of the many Federally Funded Research and Development Centers (FFRDCs) already in existence. Our new voting FFRDC, presumably sponsored by the EAC, would develop the source code and get it certified. It would also standardize the hardware interface, allowing multiple vendors to build compatible hardware. Because the code would be open, these hardware vendors would be free to make enhancements or to write device drivers, which would then go back to the FFRDC for integration and testing. (The voting FFRDC wouldn't try to take the code to existing voting systems, so there's no worry about stealing their IP. It's easier to just start from scratch.) My hypothetical FFRDC model isn't too far away from how Linux is managed, or even how Microsoft manages Windows, so this isn't exactly science fiction.

The ETC paper asks who would develop new features as might be required by a customer and suggests that the "lack of a clear line of accountability for maintaining an open source project" would hinder this process. In my hypothetical FFRDC model, the customer could commission their own programmers to develop the enhancement and contribute this back to the FFRDC for integration. The customer could also directly commission the FFRDC or any other third-party to develop something that suits their needs. They could test it locally in mock elections, but ultimately their changes would need to pass muster with the FFRDC and the still-independent certification and testing authorities. (Or, the FFRDC could bring the testing/certification function in-house or NIST could be funded to do it. That's a topic for another day.) And, of course, other countries would be free to adopt our hardware and customize our software for their own needs.

Unfortunately, such a FFRDC structure seems unlikely to occur in the immediate future. Who's going to pay for it? Like it or not, we're going to be stuck with the present voting system manufacturers and their poorly engineered products for a while. The challenge is to keep clarity on what's necessary to improve their security engineering. By requiring source code disclosure, we improve election transparency, and we can keep pressure on the vendors to improve their systems. If the security flaws found two years ago in the California and Ohio studies haven't been properly fixed by one vendor while another is making progress, that progress will be visible and we can recommend that the slow vendor be dropped.

A secondary challenge is to counter the sort of mischaracterizations that are still, sadly, endemic from the voting system industry. Consider this quote:

If policymakers attempt to strip the intellectual property from voting system software, it raises two important areas of concern. The first is the issue of property takings without due process and compensation which is prohibited under the United States Constitution. The second area of concern is one of security. The potential for future gains with software security will be lost in the short-term until such time that an adequate product improvement model is incorporated. Without a process improvement model in place, any security features present in current software would be lost. At the same time, the market incentives for operating and supporting voting products would be eliminated.

For starters, requiring the disclosure of source code does not represent any sort of "taking" of the code. Vendors would still own copyrights to their code. Furthermore, they may still avail themselves of the patent system to protect their intellectual property. Their only loss would be of the trade secret privilege.

And again, we've got the bogus security argument combined with some weird process improvement model business. Nobody says that disclosing your source requires you to change your process. Instead, the undisputed fact that these vendors' systems are poorly engineered requires them to improve their processes (and what have they been doing for the past two years?), which would be necessary regardless of whether the source code is publicly disclosed.

Last but not least, it's important to refute one more argument:

Public oversight is arguably just as diminished in an open source environment since the layperson is unable to read and understand software source code adequately enough to ensure total access and comprehension. ... However, effective oversight does not need to be predicated on the removal of intellectual property protections. Providing global access to current proprietary software would undermine the principles of intellectual property and severely damage the viability of the current marketplace.

Nobody has ever suggested that election transparency requires the layperson to be able to understand the source code. Rather, it requires the layperson to be able to trust their newspaper, or political party, or Consumer Reports, or the League of Women Voters, to be able to retain their own experts and reach their own conclusions.

As to the "principles of intellectual property", the ETC paper conflates and confuses copyright, patent, and trade secrets. Any sober analysis must consider these distinctly. As to the "viability of the current marketplace", the market demands products that are meaningfully secure, usable, reliable, and affordable. So long as the present vendors fail on one or more of these counts, their markets will suffer.

Update: Gordon Haff chimes in at cnet, on how the ETC misconceptions about how open source development procedures work are far from atypical.