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.
Quote:
——
My real choice, though, would be a machine using punched tapes, with a separate tape for each candidate, plus a tape for each race for “no candidate selected”. If 1,375 people cast ballots in a particular race, the tapes for that race should have a total of 1,375 holes. The machine could be constructed so as to allow voters to visually see the holes being punched in the tapes for their candidates, without allowing them to see how many holes had been punched previously.
——
You still have to present the races somehow, which leaves room for presentation attacks (e.g., removing candidates from the ballot; ballot reordering) and selection atacks (e.g., making it more difficult to select certain candidates). Also, such a tape system makes it easy for officials to determine who voted how. And you’d need to provide some means for cancelling errant selections, which then raises the possibility of the machine falsely cancelling votes on its own.
My intention would be for each candidate to have a separate tape, which would be advanced only when someone votes for that candidate. For technical reasons, it may be useful to construct the machine so the last hole punched for each candidate will always be visible, in which case the machine should be cycled to punch one hole on each type prior to the start of the election (interested parties would confirm before the start of the election that each tape has exactly one hole, and the holes would then be deducted from the totals) but the basic idea would be that (1) each voter would be able to see a mark placed on an indelible medium as a result of his vote, and (2) tapes could be protected against substitution via means that would be impractical with paper ballots.
IMHO, running from a ROM cartridge would be better than running from a CD-ROM, since a machine which is physically incapable of running from RAM can be relied upon to be running from the installed ROM cart, but such an assumption cannot be made about one running from RAM.
My personal preference, given a choice between detached paper ballots and an electronic system, would be to have an electronic system that would facilitate verification of code and ballot media by all interested parties. If all interested parties sign an agreement 10 minutes after the election that the system records 14,371 votes for candidate X and 13,194 for candidate Y, there is no way that somebody can alter the media later on and claim that it legitimately shows some other total. By contrast, paper ballots could be altered days or even weeks after an election, and the altered values recorded as legitimate.
My real choice, though, would be a machine using punched tapes, with a separate tape for each candidate, plus a tape for each race for “no candidate selected”. If 1,375 people cast ballots in a particular race, the tapes for that race should have a total of 1,375 holes. The machine could be constructed so as to allow voters to visually see the holes being punched in the tapes for their candidates, without allowing them to see how many holes had been punched previously. Such a machine should not be too expensive to construct, but should allow for excellent security.
Of course, unless election laws are changed so that fraud or malfeasance sufficient to swing an election will be considered sufficient basis for throwing out the results and holding a new election (and prosecuting the people responsible), all the security provisions in the world will be meaningless.
Quote:
——
IMHO, running from a ROM cartridge would be better than running from a CD-ROM, since a machine which is physically incapable of running from RAM can be relied upon to be running from the installed ROM cart, but such an assumption cannot be made about one running from RAM.
——
(1) You still need some kind of RAM for volatile state (e.g., totals, tap position);
(2) Just because the ROM cartridge says “100% certified super-secure ROM cartridge” doesn’t mean that that’s what’s inside. Indeed, just because a chip says, “Xyzzytel Zentium 5 Model 3” doesn’t mean that that’s what’s inside. A sufficiently-motivated and -funded attacker (e.g., a foreign government; a politically-motivated billionaire) can fake all of that stuff;
Quote:
——
My personal preference, given a choice between detached paper ballots and an electronic system, would be to have an electronic system that would facilitate verification of code and ballot media by all interested parties.
——
How about verifying the firmware (mainboard BIOS, video BIOS, SD card firmware, whatever)? How about verifying the hardware? A firmware- or hardware-based attack can dynamically modify the voting application, making it do anything the attacker pleases.
Quote:
——
If all interested parties sign an agreement 10 minutes after the election that the system records 14,371 votes for candidate X and 13,194 for candidate Y, there is no way that somebody can alter the media later on and claim that it legitimately shows some other total. By contrast, paper ballots could be altered days or even weeks after an election, and the altered values recorded as legitimate.
——
You can use the same approach with paper ballots, preferably at the precinct level. The weakness (as with most computerized systems) is with recounts.
Quote:
——
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.
——
This feature undermines the proposed system’s security. A device driver (or operating system component) can modify the voting application’s executable in any way it pleases (e.g., to cheat), and the modification is, of course, invisible to those reviewing the application’s source. Even firmware (e.g., BIOS; disk-controller firmware) can modify an application’s executable. You have to open-source everything — including the hardware — to gain significant security guarantees. Then, you have to solve the problem of transparently and securely verifying that the open-source (and reviewed) software/firmware/hardware is really used in every machine on election day.
Open sourcing does something for security, but not nearly as much as is commonly thought, especially not against determined attackers. You get much more security by limiting computers’ role in voting.
The solution is, I think, to think outside the “we gotta use computers” box. We don’t gotta, except for (1) tabulating hand-filled paper ballots where the ballots are sufficiently long or complex; and (2) assisting voters who cannot otherwise vote independently (e.g., who aren’t sufficiently helped by magnifying bars, extra lighting, Vote-PAD-like devices).
By limiting computers’ role to auditable areas (like tabulating hand-filled ballots, which can be cross-checked by hand), we limit the attacks they be used to wage.
Quote:
——
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.
——
True. But you’ve left out a critical category of potential attackers: vendors themselves.
-R
The government should simply commission a work for hire and shut up all those people screaming about IP once and for all.
At one point they cite Open Voting Consortium’s legislative efforts and say,
Based on the lack of currently viable open source developed voting technology, it is clear that advocacy groups are encouraging a disclosed software model rather than a true open source requirement.
They know that we’ve promoted software disclosure as a precursor to true open source. The software we’ve developed is all true open source — free software with a General Public License. Why would they lie about this?
There is a lot more in the ETC paper that needs to be addressed.
Earlier in this thread, you wrote, “I have no idea why they attribute that passage to my 2007 paper.” Okay, it wasn’t 2007, it was 2006. So what? What you wrote is bad, and was naturally picked up by our opponents.
In the response I gave back then (cited in my previous post, I wrote,
> 2) You say, “In the case of voting systems, disclosing information on known
> vulnerabilities arguably helps would-be attackers more than system
> defenders.” This is little more than pure speculation. You have not made
> the case for this. Most evidence suggests the opposite.
>
Then as now, you gave no explanation.
well, I thought I made the point that vulnerability mitigation on the part of local election officials is limited (they can’t patch, for example). I’m not here to respond to you point by point.
Joe,
“Well, I’m not ‘TimH’. I’ll respond accordingly.”
Oh, duh. Sorry. My bad.
“The are certainly not student papers. They were written by me as a student but held their own in a competitive venue that has been one of the most important venues for academic study of electronic voting systems.”
I gave my opinion. It’s understandable you might disagree.
I gave a detailed response to your 2006 paper back then.
http://gnosis.python-hosting.com/voting-project/July.2006/0073.html
Your response was,
“I agree with some of what you say and disagree with some of it. This is, of course, the first step in a line of related research and I had 16 pages in which to take this first step. Thanks for your feedback and I will work to strengthen the work as I go forward. -Joe”
You responded to none of the specific points I made. I thought the paper was weak in spots, and your response was a hand-wave. Some of the things you wrote were downright inaccurate. Maybe if instead of writing one long response, I had written about one thing at a time, I would have gotten a better response from you. Nonetheless, I did not like it.
I understand we come at this issue from a different perspective. I have a particular point-of-view: OVC system architecture good, others not so good; open source good for voting system, proprietary and/or secret code bad; OpenTest good, secret testing bad; OVC delivery model good, others not so good. I have been arguing those points more or less continually for over 8 years. You try to maintain a more impartial, objective point-of-view. Still, to me it seems that your work suffers from a certain amount of academic wishy-washiness.
Sometimes I wonder, “whose side is Joe on?” Also in 2006, there was a Senate Committee hearing on open source that was held at my behest. I was also consulted on panelists for the hearing — recommending ACCURATE among others. At one point, you warned Bowen that vendors would not like open source. I thought you guys were okay, but also have a lot of mixed messages.
David, what Schneier says is exactly correct. That’s why the OVC system is so great. The correctness every step along the way is readily apparent.
OVC is essentially a paper-ballot system. From your earlier post:
No information from the voter interaction with the machine gets stored electronically — paper only
Voter takes finished paper ballot (in a folder with bar code exposed) to pollworker standing at the ballot box and pollworker slides ballot face down into the ballot box.
Once the polls close, the ballot box is opened and the number of ballots counted
I assume the ballots are counted by computer. That’s not a good idea, but at least you do have human-readable ballots available should a human count be necessary. So we are in violent agreement that paper ballots are best.
As I pointed out elsewhere in this thread, open-sourcing the voting application does not prevent an attacker from using the device drivers, OS, firmware, or even hardware to cheat by modifying the application’s executable. Open-sourcing all of that is much more difficult than open-sourcing the voting application, plus you then need an auditable, secure way of verifying that every component was honestly produced from its open (and reviewed) source. Even then, you confront the problem that review isn’t very good at finding security flaws (e.g., http://gnosis.python-hosting.com/voting-project/May.2008/0000.html ).
We ought to limit computers’ role in voting to (1) tabulating hand-filled paper ballots (if length/complexity make this desireable or necessary); and (2) assisting voters who cannot otherwise vote independently. In my view, giving computers other roles substantially increases the number, virulence, and complexity of attacks without giving enough in return.
http://www.schneier.com/blog/archives/2006/11/voting_technolo.html
This is what you’re all failing to address:
“Voting is as much a perception issue as it is a technological issue. It’s not enough for the result to be mathematically accurate; every citizen must also be confident that it is correct. Around the world, people protest or riot after an election not when their candidate loses, but when they think their candidate lost unfairly. It is vital for a democracy that an election both accurately determine the winner and adequately convince the loser. In the U.S., we’re losing the perception battle.”
The Humboldt “open source solution” is an audit tool, not a voting system. The voting system was a Diebold opt scan system.
Generally, Dan is on the right track but a little behind the curve. ETC is blowing smoke, and their paper is barely worth dissection. Maybe some people in the political arena would benefit from hearing a good academic like Dan Wallach take the ETC arguments apart, so I don’t discount the value.
I like Joe Hall but I wouldn’t portray his papers as authoritative. These are student papers. There are some good ideas in there but nothing to get excited about.
Dan says,
“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.”
This is not going to happen, although something similar could happen with the Open Voting Consortium. I would be glad to give a more full explanation in case anyone is interested, but, for now, suffice it to say that the political will to do this is just not there for a top-down government-driven solution, and there is also a lack of technical competence. Decision-makers just don’t know what to do. The more experts they hear from, the more confused they get.
Another model that can be definitely ruled out is the return to a purely manual system as advocated by David Skoll and others in this thread (and elsewhere). Like eliminating computers in the voting system, you could also make a very powerful argument for eliminating automobiles in Los Angeles. Think about all the death, destruction, pollution, expense, and everything else from the automobile-based culture there. But short of nuclear war, automobiles are not going away anytime soon. Same with computers. Forget it.
Another thing that ain’t gonna happen: proprietary disclosed source. Dan seems a little unclear on this point, and OSDV (an advocate of proprietary disclose source) was mentioned by Joe Hall. OVC has, at various times, promoted software disclosure but we only see it as a possible path to true open source. For example, we sponsored AB 2097 in 2006 and AB 852 in 2007 (I did the initial draft of both bills) in the California State Legislature. These bills would have required source disclosure, but the real intent was to lead to open source. In my account of the April 2006 Assembly elections committee meeting, I point out that the members got that point, even though we weren’t advertising that (see what Villines said) http://www.openvotingconsortium.org/blog/2006-apr-26/no_opposition. I don’t have time to go into detail about why open source will win over proprietary disclosed source, but if anyone really wants to know you can read some posts from our discussion list from the last 6 years ( http://gnosis.python-hosting.com/voting-project/ ). Brian Behlendorf, founder of Apache and OVC participant, has made some of the most cogent statements about why voting system software must be true open source (most likely, GPL). Proprietary disclosed source might be okay for some applications, but not for the voting system.
Eight years ago, I proposed a voting system based on an open source electronic ballot printer. Los Angeles County Supervisors were interested. http://www.openvotingconsortium.org/ad/antonovich32201.pdf
They’re still interested. In general, we have moved the project forward step-by-step over the past 8+ years. Six years ago, I conceived the consortium model for how the open source technology could make its way into commercial use. OVC was born in 2003. Actually, the consortium idea goes back even further, starting with discussions I had with Henry Brady at UC Berkeley (http://www.openvotingconsortium.org/ad/src-proposal.pdf ). Eight years ago (almost to the day) I was sitting in Henry’s office and he asked about how people would make money with the system.
There is a lot of misinformation floating around about OVC. I am glad to report that we are much further along than most people realize. In this thread, Don Marti cited an article about our demo last summer at Linuxworld. The demo was very successful, and if you are not familiar with it, I recommend this YouTube video http://www.youtube.com/watch?v=q8CSKdMTARY
While the OVC system is not certified and not in official use anywhere, discussions with officials have escalated since Linuxworld and system development has continued. We are in more-or-less continual discussion with jurisdictions around California, around the U.S., and around the world. Linuxworld resulted in inquiries from Europe, Africa, South America, India, and Canada.
What will the OVC system look like? You can get a pretty good idea of the system by watching the YouTube video, and here are some requirements for the OVC pollsite system:
voter makes selections with computerized interface
voting machine uses standard PC architecture (probably custom enclosures) and free open source software. No harddrive for voting system — runs from read-only media (CD)
When finished with selections, finished ballot is printed on plain paper
Selections printed in English and another language, if necessary.
Selection also encoded in a 2-d barcode
No information from the voter interaction with the machine gets stored electronically — paper only
Voter takes finished paper ballot (in a folder with bar code exposed) to pollworker standing at the ballot box and pollworker slides ballot face down into the ballot box.
Once the polls close, the ballot box is opened and the number of ballots counted
Ballot count is reconciled against signatures on roster
Ballots are then tabulated at the pollsite one-by-one by scanning the bar code with the spreadsheet displayed on a screen for all to see (perhaps webcast as well) so the count is updated as each ballot is scanned.
When all the ballots have been scanned, the tally sheet is printed.
They will print as many tally sheets as people want. One will be posted at the pollsite. Electronic copy and paper copy will be delivered to HQ along with ballots.
HQ aggregates the vote by scanning the tally sheets (which have the precinct totals barcoded as in the current sample).
Anyone would be able to monitor the aggregation process at the HQ or remotely. For example, if a voter has a tally sheet in hand from a precinct, s/he would see all the contests and candidates laid out on the tally sheet zeroed out at the beginning of the aggregation process. When the tally sheet is read at HQ, the totals on the screen will be filled with the same numbers on the paper tally sheet in hand. The spreadsheet displaying the aggregate would be updated as each tally sheet is scanned.
Having looked at many ballots in Los Angeles, legal landscape should accommodate precinct data for any election. This way, no scrolling on the screen or shuffling multiple pieces of paper should ever be required to see the data for a precinct.
Here’s a mock up of a tally sheet for a Los Angeles precinct (data taken from 2002 general election)
http://www.openvotingconsortium.org/ad/sm.pdf The ballot from this precinct had 95 candidates for 36 contests. In addition, there were 9 ballot measures for a total of 45 contests. If you were to print out this tally sheet and scan the barcode, you would find that all the vote totals — 455 characters. Los Angeles is the largest and most complex jurisdiction in the U.S (4400 precincts). If we can show it working there, everywhere else will be easier. The entire election result will fit on a single 5-million cell spreadsheet — roughly 1,000 cells for each precinct and a single larger range of cells for the aggregated vote totals. Anyone will be able to download the spreadsheet for the entire election.
Our system depends heavily on the PDF417 bar code technology. Some argue against the bar code, but if you take up that side of the argument, you will lose. I have been over this many times over the last 8 years. I understand the cost, but the benefits far outweigh any perceived transparency hit.
The voter verification of the 2-d bar code is really not an issue. Going all the way back to our 2004 demo, we’ve always shown there would be a bar code scanner at the polite available. If the voter wants to verify the barcode, s/he can put on headphones and listed to the choices being read back.
Furthermore, since the barcode is printed on the ballot, it remains an item that can be audited at any time. This issue remains as pure esoterica. PDF417 bar code are ubiquitous. They’re on every FedEx package. You can print your airline boarding pass at home, which includes a PDF417 bar code. Election boards already use PDF417 barcodes extensively and they already have the scanners. In fact, the bar code on the ballot was suggested to me by an election official (Ryan Ronco, in 2001) and the bar code on the tally sheet was suggested (demanded, really) by Elaine Larson of Santa Clara County. We have found that it makes perfect sense to the public and they are quite comfortable with it.
The Election Management System (EMS) is all XML/EML. Data for the ballot definition file used in the voting machines is fed automatically from the EMS (for the linuxworld demo, the ballot definition file was created with a browser-based application… we working out the kinks for eliminating this step so it all comes for the EMS). There should be little or no customization per election. Every position on the spreadsheets as well as the voter interface will be programmatically determined.
You’ll hear more about all as we move closer to some solid backing. OVC is membership based. We can afford to give away the technology and still support it. Users of the technology and providers of the technology will all be OVC members. OVC has exactly the right technology and exactly the right consortium structure to deliver a great voting system. We have jumped through many hoops and taken many steps. There are still some steps and hoops ahead of us but we’re doing it.
Alan Dechert
“Another model that can be definitely ruled out is the return to a purely manual system as advocated by David Skoll and others in this thread (and elsewhere)”
Why? It works in Canada (population 34 million). It works in Germany (about 60 million.) It scales as O(log N) if done properly, so I see no reason it can’t work in the United States (population 300 million.)
“Like eliminating computers in the voting system, you could also make a very powerful argument for eliminating automobiles in Los Angeles.”
Eliminating automobiles in LA is infeasible; the disruption to daily life would be intolerable. Why, exactly, is eliminating electronic voting infeasible?
“But short of nuclear war, automobiles are not going away anytime soon. Same with computers. Forget it.”
That’s so silly. “Well, I can’t really think of a good reason why we SHOULD use e-voting… but we ARE using e-voting, so forget it!!!” (Is this why we still see distances in miles in the United States? 🙂 It’s the way we’ve always done it, so we won’t look at better ways.)
I concede that US elections are quite different from Canadian elections; we don’t have your 1001+ propositions that vary on a regional basis tacked on to our ballots. So the solution is to separate out the really high-stakes votes (an attacker would spend a lot of time and money influencing a presidential vote) from the lower-stake votes (should we ban cosmetic pesticides in county XYZ?) and use voting systems with appropriate levels of security. You also need national standards for national votes; the county-by-county mishmash is ridiculous.
I contend that for really high-stakes votes, no electronic system comes even close to the security of paper ballots, and no electronic system ever will for the forseeable future.
Alan: re: “I like Joe Hall but I wouldn’t portray his papers as authoritative. These are student papers. There are some good ideas in there but nothing to get excited about.”.
A little patronising don’t you think? Surely the more analysis, the better…
Hi,
you say, “I like Joe Hall but I wouldn’t portray his papers as authoritative. These are student papers. There are some good ideas in there but nothing to get excited about.”
I would say I found this a bit patronizing. That is, I don’t claim to be an authority but someone with a specific set of technical and policy expertise that I’ve built up over the course of my work and education.
The are certainly not student papers. They were written by me as a student but held their own in a competitive venue that has been one of the most important venues for academic study of electronic voting systems.
Frankly, I don’t do research based on if it will excite people. I like research on hard issues that I think will make a difference. I think each of those papers speak for themselves and I’m surprised at how well they and their conclusions have held up.
In Humboldt County California, they used an Open Source solution with scannable paper ballots: http://www.tevsystems.com and http://humtp.com/
If it is difficult to ethically and legally discover secrets about the software flaws, you will have few white hats able to contribute their analysis and suggestions; however, the bad guys won’t hesitate to expend that energy and money because of the potential payoff.
When bad guys discover secrets, they keep quiet. They reuse the secrets or wait for a great opportunity to exploit. If most secrets are being discovered by black hats, most secrets will stay hidden from public view and will be used to compromise election after election or at least important elections. When white hats find flaws, they make noise, the result being that security bloopers get rooted out much quicker.
When you have to code in the open, you can’t afford to take too many short-cuts or you will be embarrassed/lose business. Security through obscurity is a practical way (from the pov of the vendor) to save money which can be used to undercut competitors and drive their more secure products out of the market or to outspend them (with the same end results).
Finally, source code kept hidden “forever” from the public is a power to those that work within the organization and have the secrets. It is a power that is likely to be abused over time since there are few checks and balances. It is also power because it presents interop barriers and keeps customers ignorant of mistakes and weaknesses by the vendor. It’s just easier to do what you want and to win when you are in a position of trust and have less oversight. The ultimate oversight is opening up the code so that anyone can build the systems to verify for themselves.
That said, to safeguard e-votes goes beyond knowing and compiling the source code and then following ordinary procedures. The “source code” would likely also include instructions on putting the system together or place demand on auxiliary systems (eg, perhaps require interaction with a printer, demand certain security processes, and require that other protocols be followed as well.)
Joe’s papers:
http://www.josephhall.org/papers/jhall_evt07.pdf
(per this piece)
http://www.josephhall.org/papers/jhall_evt06.pdf
(oldie but goodie)
http://www.josephhall.org/papers/jhall_evt08.pdf
(wow, getting more!)
fixed the link.
I have no idea why they attribute that passage to my 2007 paper.
Dan, there is precedent for a finding of a 5th A takings when trade secrets have been disclosed (thus, destroying their protection). That’s in my 2006 paper.
Finally, I’m sorry that I haven’t been able to read let alone respond to the ETC paper… working on another paper but I hope to have some thoughts after Monday’s Politics Online Conference in DC (where I sit on a panel on open source in voting systems organized by the OSDV’s Greg Miller with Debra Bowen, Norm Ornstein and Aaron Burstein).
If the ETC paper was more explicit about the different forms of intellectual property, then it would be interesting to have a more focused discussion on nothing but the trade secrets issue, and where trade secrets are and are not appropriate in voting systems. Of course, that’s not the paper they wrote.
I suppose one of the interesting issues is the “value” of the trade secret. Coca-Cola places some serious premium on the secrecy of its formula, because they don’t want it cloned. Copyright wouldn’t help them in any meaningful way, and patents would have expired long ago. For voting machines, they have less to lose with the loss of their trade secrets because copyright is there to protect their code. The only real value I can imagine in voting vendors’ trade secrets is their presumably painstaking effort they’ve gone through to support all the quirky requirements of each and every state. If a competitor had all that available, in electronic form, then it would be easier to build competitive products that can be sold all those markets.
Electronic voting (whether open-source or not) will NEVER, EVER be secure. We are asking an industry that has never in its entire history made a secure product to do so now.
The only securable voting system is one that uses physical things like paper ballots. They are easy to understand and hard to subvert (it would require the cooperation of a great many people to materially subvert the results of a well-run physical-ballot vote.)
Much as I support open-source, I think the campaign for open-source e-voting is misguided. Instead, we should be campaigning against e-voting, period.
(Luckily for me, I live in Canada, where we still use physical ballots.)
Have a look at the work we’ve done on VoteBox. It’s entirely possible to build very secure electronic voting systems. Unfortunately, that’s not what anybody’s selling.
The ETC argues that there is some value to security by obscurity, despite the rejection of that notion by the computer security community. You point out that keeping the code secret does not add any security at all, and at most delays an attacker. To illustrate your point we need only recall Harri Hursti’s famous (white hat) hack of the Diebold AV-OS optical scan system in Leon County, Florida as recorded in the movie “Hacking Democracy”.
After discovering that there was interpreted byte-code software in an undocumented language (Diebold AccuBasic) stored on the memory cards of the machine, Hursti was able to examine the byte code of one of the scripts and reverse engineer it just enough to guess what the stack-pop operator was. After a little experimentation he figured out where to insert a couple of extra stack pop operators into the code of the “zero report” script, causing it to print a report saying that there were zero votes in every race stored in the machine when in fact a mixture of negative and positive votes were pre-recorded. That was the fundamental trick of the hack. He was able to do this without access to any Diebold proprietary information that one might naively assume would be necessary: not the AccuBasic language manual, not the AccuBasic compiler, not the AccuBasic byte code interpreter, and not even the AccuBasic “zero report” script source code from which the interpreted byte code script was produced. A small amount of reverse engineering and experimentation goes a very long way!
These arguments are all just plain stupid. Why? Because when you’re selling to a monopsony, you don’t get to write the rules unless you bribe someone. Reading this is like reading a screed from a cable company about how unfair it is that potentially profit-making channels have to be reserved for public access or local broadcasters. As if a state-issue license to make a profit were not enough.
So here’s my idea: instead of mandating disclosure or mandating support of open source by fiat, simply rewrite the rules for states and municipalities to say that no system will be certified unless its source code is disclosed, and no federal/state funding will be available for purchasing machines unless the sellers agree to send a (tax-deductible) part of the proceed to the open-source foundation building a next-generation version (rather like the universal service tax). See, no forced disclosure of anything.
I sometimes wonder whether the desperation of the fight against disclosure isn’t an attempt to ward off prevent litigation, because with code in hand the unfitness of most of these machines for their stated purpose is pretty clear.
Open source voting software already exists, and it works better than the proprietary machines that Alameda County, California tried.
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9111820
I am a Founding Member of the Open Voting Consortium, the organization that created the system you mention. Yes, it exists, but under current law it would cost something like a million dollars to get it certified. What we need is a change in the laws of the several states so that Open Source voting software can be accepted by being tested openly. Right now, secret proprietary is tested by secretive private testing companies, paid by the vendors, that routinely give the current radically broken systems a passing grade almost every time. Can you say “conflict of interest”?
There are a number of experts and organizations willing and able to conduct appropriate tests at no cost to the software provider or the public. We could have a standards organization develop a test suite that voting officials could run themselves, based on the best publicly available threat models, including for example vulnerability to any known type of virus software. Anybody would be able to run it, and to understand what the results say.
The argument about security of Open vs. Closed Source is a red herring. What we need is publicly available _evidence_ of how trustworthy and reliable our voting systems are. Right now the evidence all says that nothing we are using works.