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.
Again, this doesn’t address attacks on how the ballot is presented or attacks on how the voter makes selections. Also, it doesn’t address denial-of-service attacks (e.g., the machine locks up when “too many” voters select the “wrong” candidate).
If many voters obtain (e.g. download from the official election site) a picture of what the machine is supposed to look like and what order the different color tapes are supposed to be installed, how is a presentation attack supposed to succeed without someone realizing that things aren’t set up right? If the official election guide says the tapes are supposed to be in the order red, green, yellow, purple, but a voter sees that they’re in some other sequence, that should be easy to spot, and the voter’s complaint should be easily verifiable.
As for denial-of-service attacks, if most of the mechanism is visible to voters except for the supply and takeup reels, and if the supply and takeup reels are inspected by all interested parties before polls open, by what means would unexpected lockups occur?
While it’s possible that almost anything theoretically can go wrong with any type of mechanical voting system, problems in a system like I described would be immediately detectable and reportable. What to do about such problems may not be so clear, but having a system that ensures that problems will be detected makes it easier to determine which claims of irregularities have merit.
Those are some significant “ifs”. I am assuming that you present the ballot electronically. If so, an attacker can program it to drop candidates from the ballot, reorder it, mess with the headings, make some names a little greyer than others or in smaller fonts, etc. Simple attacks like these can easily tilt elections; in Sarasota in 2006, a U.S. House race was very likely flipped by a 15% undervote, which officials attributed to a poorly-designed race heading.
On DoS attacks, they can affect any portion of the system. If, for example, the presentation and selection modules are electronic, they can monitor the vote stream and selectively “fail” if too many voters select the “wrong” candidate.
I am not completely clear on what you’re proposing. If your system is purely mechanical, and simple enough (e.g., like the old-style Chicago lever machines), then I would agree that it’s probably pretty resistant to most global (centrally-orchestrated) attacks, which are my primary worry. If, on the other hand, the proposed system has any electronic components, it’s going to be susceptible to one or more of the attacks I’ve discussed.
Also, on voting procedures, it’s really easy to confuse voters (and pollworkers). If there is some miscorrespondence between some official website and what the machines are doing, the pollworkers are very likely to go with what the machines are doing.
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.
There need not be any firmware of any sort other than what’s in the ROM cartridge. While one would have to ensure that someone doesn’t replace the Z80 (or whatever microprocessor is used) with something else that has hidden code features, allowing interested parties to select some machines for x-ray examination should minimize the likelihood of undetectable mischief.
As for using the ‘agreement’ approach with paper ballots, the problem is that if a later examination of paper ballots yields a different tally, there’s no way to know whether the later one is more or less accurate than the earlier one. By contrast, if two parties both agree that a write-protected non-volatile memory cartridge holds certain data, and the cartridge is then found to hold something else, that’s a pretty strong indication that something has been altered.
It is exceedingly difficult and expensive to determine the contents of any highly-integrated electronic device during forensic examination. Also, the examination has to apply to every piece of software, firmware, or hardware that has any role in the machine’s operation, not just the equipment that records the voter’s selections. And, even if examinations occur frequently enough, sample enough machines randomly enough, and are performed by sufficiently-competent and -honest officials, their results will not be available until long after the concerned elections are certified. Thus, such examinations would, at best, deter some future frauds, while leaving past fraudulent elections intact. Finally, only a tiny sliver of voters have any idea of how to supervise the forensic examinations; we simply have to trust that the experts do them correctly and honestly. A republic that relies on that degree of trust easily can become a republic in name only.
On the “agreement approach”, there is no real difference between its efficacy with ROM cartridges and its efficacy with paper ballots. Just as one can claim that some paper ballots were replaced or corrupted, one can claim that a ROM cartridge was replaced or corrupted.
If at 8:12pm on election night, representatives from both major parties and maybe a couple minor ones read out the electronic ballot cartridge, and all such representatives agree as to the precise contents of that cartridge, that agreed-upon content is what was in the cartridge at 8:12pm on election night, period. There is no plausible scenario by which the contents could have been misread at 8:12pm and yet could be meaningfully read at some future date.
By contrast, even if representatives of all parties agree that a stack of paper ballots contains 1954 votes for X, 473 votes for Y, and 23 votes for Z, that does not imply that those representatives are correct in their perception of ballot contents.
With regard to substitution issues, secret ballot requirements mandate that blank paper ballots be identical and indistinguishable. There is no practical way to protect against the creation of fraudulent ballots; the best one can do is try to keep them out of the ballot stream. By contrast, a representative of each interested party may supply its own serialized tamper-evident seals to protect ballot media cartridges from substitution. The ability to serialize the seals makes a world of difference in the degree of protection.
Even if all parties agree on the contents of the cartridge on election night, it doesn’t mean that the contents are correct. The cartridge got those particular contents via a series of interactions with a series of voters (or, in the case of DoS attacks, series of non-interactions with non-voters), any or all of which could have been falsified. It’s true that the totals are precise digital quantities, but that doesn’t mean that they accurately represent the selections that voters made, or that they meant to make.
On substitution, all the parties could digitally sign the cartridge, making substitution detectable. They could also do that with raw scans of the paper ballots.
But, again, the basic problems with this approach are that the software/firmware/hardware can cheat at any point in the process, from making the machine available (or unavailable), to presenting the ballot to the voter, to accepting her selections, to recording the tallies. Securely agreeing upon the final tallies is the least of the problems with this approach.
I should qualify and expand upon what I said about digital signatures. Designing a digital signature protocol that is resistant to attack is more complex that it seems. In particular, you need to guard against not only cartridge substitution, but also against one or more signatories attempting to repudiate their signatures, either by denying a valid signature or by providing an invalid signature. You also have to guard against the signature-generating and -handling software doing these things. And you have to guard against social-engineering attacks on the signature protocol, which could invalidate its guarantees.
As for paper ballots, you aren’t confined to signing a scan of each ballot. You could also digitally sign each original ballot, for example by hashing together its contents (as scanned) with a ballot serial number and a signatory’s key. You could then stamp the signature on the ballot, in visible and/or magnetic ink. Of course, this process, like the cartridge-signing process, can also be attacked.
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.
I just don’t see it.
For the sake of argument, consider one of the great features of the Diebold TS: If you insert a PC card that has a file with a special secret name and turn the machine on, the software in the machine will be replaced with whatever is in the file (Diebold said they wanted to make it easy to update the software).
Scenario #1
—————–
Suppose officials made sure that everyone around knew of this — they even had a picture of the card on the wall with instructions about how to insert the card and what the file name needed to be.
Scenario #2
————————
Suppose officials took care to keep this information secret.
Question: under which scenario would an attacker have the best chance to succeed?
I think an attack under Scenario #2 would be much easier. The file name and what it does might be a secret, but someone knows about it. A motivated, devious, clever, skilled attacker could probably get this information from somewhere (or somebody). With malware disk in hand, the attacker might get access to the machine “for testing” and no one would suspect that the software on the machine could be replaced so easily.
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.
“I contend that for really high-stakes votes, no electronic system comes even close to the security of paper ballots….”
Wrong. The country had paper ballots long before any automated system. Maybe you should read up on that. The system was extremely hackable and corrupt.
Actually, a secure manual system is possible, but with complex ballots the cost is prohibitive (you can’t depend on volunteers for the huge labor requirement … do the math, and you find it’s just way too expensive to recruit, screen, train, manage and supervisor the workforce needed).
You haven’t done your homework and I’m not going to do it for you. Generally, if you have one or just a few things on the ballot, paper ballots manually counted can work okay. Most of the world has one or just a few things on the ballot. Even then, the trend is away from manual systems.
Have a look at the tally sheet I posted for Los Angeles. Ninety-five candidates in 36 contests … another 9 ballot measures.
“Wrong. The country had paper ballots long before any automated system. Maybe you should read up on that. The system was extremely hackable and corrupt.”
Then it was poorly designed. As far as I know (I could be wrong, but I don’t think so) there has never been any question about the legitimacy of a Canadian election result since 1867. I don’t think that’s true of the United States.
“Actually, a secure manual system is possible, but with complex ballots the cost is prohibitive (you can’t depend on volunteers for the huge labor requirement … do the math, and you find it’s just way too expensive to recruit, screen, train, manage and supervisor the workforce needed).”
Elections are expensive; Elections Canada has a large budget to run federal elections. But it positively pales in comparison to the amount of money spent on an election campaign. I suspect the same would hold true in the United States.
“Have a look at the tally sheet I posted for Los Angeles. Ninety-five candidates in 36 contests … another 9 ballot measures.”
So? You scale it as O(log N). At each polling place, officials have to count maybe a few hundred ballots. Tedious, to be sure, but eminently parallelizable. They then sign the results, the scrutineers sign off on them, and they move up a level, to a district maybe. These are totalled and sent up to the city level. Repeat until you get the final count.
To hack the result, you either have to bribe a whole lot of low-level people, or somehow get at the higher-level ones, who are naturally more senior civil servants with deeper background checks and a lot more to lose if they’re found to be corrupt.
Point is, anyone can UNDERSTAND the system. A system most people can’t understand is simply undemocratic, no matter how secure it is in theory.
David Skoll and Alan Dechert appear to be, as they say, in violent agreement. ^_^
Both argue that the paper ballot is essential to secure voting. One of the questions that remain is whether the paper should be marked manually, with something like a 1% rejection rate using the best scanners, or by machine, with a much lower rejection rate due to complete absence of overvoting and extraneous markings, and a few other such types of error.
The other big issue is whether either system is vulnerable to ballot-box stuffing, mysterious disappearances, or forgery. If these are not problems in Canada, congratulations. For the US, I will simply cite the cases of Huey Long, the elder Mayor Daley of Chicago, and “Landslide” Lyndon Johnson. The OVC system has a number of cross-checks for preventing such shenanigans, by assuring that they will be discovered, and in many cases enabling election officials or courts conducting audits to recover the correct totals from the partial data. It is the same concept as error-correcting memory, but for larger data sets.
We all agree about the numerous documented failures of all-electronic voting systems. But that is not what Dechert and Skoll are discussing here.
“Both argue that the paper ballot is essential to secure voting. One of the questions that remain is whether the paper should be marked manually, with something like a 1% rejection rate using the best scanners, or by machine, with a much lower rejection rate due to complete absence of overvoting and extraneous markings, and a few other such types of error.”
No! Ballots are marked manually and interpreted by human beings, not scanners. A bunch of human beings including representatives from various parties look at each ballot. If they can’t agree on what the vote is and can’t agree that it should be rejected, it could eventually be decided by a court. But the decision is not left to a machine.
“The other big issue is whether either system is vulnerable to ballot-box stuffing, mysterious disappearances, or forgery. If these are not problems in Canada, congratulations. For the US, I will simply cite the cases of Huey Long, the elder Mayor Daley of Chicago, and “Landslide” Lyndon Johnson.”
As I wrote in another post, this hasn’t been a problem in Canada. It could be that we have national standards for national elections rather than leaving it up to each district to run the election, or it could be that running for Prime Minister of Canada is lower-stakes than President of the United States. 🙂
Fraud is not my biggest beef with e-voting. My biggest problem with it is that it’s impossible to explain to the average layperson, and this alone should completely disqualify it. People who don’t understand the system are disenfranchised and democracy becomes a farce.
A couple comments, responding to David Skoll in part and Alan Dechert in part.
Hand-counted paper ballots have nice security properties, but they have several important caveats that cannot be dismissed.
– A typical U.S. ballot may well have 30 or more issues on it. In most other countries, you’re voting for your MP and that’s it. This radically complicates the process of human tallying. Don’t think that hand-counting will scale easily. It would be a nightmare.
– Human beings make errors. We’re not perfect. In a hand-counted ballot situation, even if you have an elaborate system of checks and balances, you will still have errors.
– Computers and statistics can augment humans in important ways, while still preserving the security of hand-counted paper. Computers are generally very good at counting things. The trick is that they’re also very easy to modify. However, what if ballots were individually numbered after they leave the voters’ hands? Have the scanner stamp a number in the corner. At that point, you can mechanically scan them and make those scans public. Anybody can tally them with any software they’d like. The trick is that people will want to sample the actual paper, by serial number, to compare it with the electronic scans. If you randomly sample a small percentage and they come out okay, that gives you some confidence that the rest are okay as well.
– Sophisticated cryptography can go much farther than hand-counted paper, notably allowing a voter to leave the polls with some sort of record of their vote (in VoteBox, a copy of the full ciphertext), which they can later find on the public bulletin board. Anybody can download the full bulletin board, compute the encrypted tally, and verify that it matches the public tally. There’s simply nothing equivalent available in the world of hand-counted paper.
Finally, one response to Dechert:
Disclosed source is already happening. That’s what the California TTBR and Ohio EVEREST work were all about. They’re not disclosed to everybody (not yet), but these are examples where disclosure has had valuable outcomes. This model is almost certainly more feasible, from a political perspective, then the adoption of a full-blown open source model.
I fully acknowledge that my FFRDC idea is a pie in the sky, particularly given the stress of Federal and State budgets these days. The point of raising it is to note that open source projects need not necessarily be volunteer community projects, which was one of the assumptions in the ETC paper that I felt needed to be refuted.
“Don’t think that hand-counting will scale easily. It would be a nightmare.”
Has anyone tried it? Why not get a group of a few people and simulate a worst-case counting scenario, counting all the ballots from a polling place in the LA district, for example.
Does it matter if it takes a few hours longer to get a vote result?
Dan’s comment is about scalability. Getting a few people to count all the ballots from a single poll site doesn’t have much to do with scalability. Furthermore, there is already plenty of data to know how many people it will take and how long for a single poll site.
In another forum earlier this year, Sheila Parks, Ed.D., Founder & Director, Center for Hand-Counted Paper Ballots, DEMOCRACY IN OUR HANDS, http://www.handcountedpaperballots.org/ showed up. She said 20 counters could do it.
http://www.change.org/ideas/view_idea/move_the_country_towards_transparent_election_systems?page=2
The number of poll sites claimed in Los Angeles varies anywhere from 4400 to 5000. So, if we’re concerned about scalability, we want to know how you hire 88,000 to 100,000 to do the counting.
Yes, it does matter if it takes a few hours longer. The longer it takes, the longer you have to have security holes plugged. If some preliminary results leak out (think network of interested counters all over the county text messaging), then gamers may learn how many ballots they need to swap in order to take an election. If counting takes a long time, you are giving cheaters more time to their thing. People get tired. Want better access to the ballots at 1:00 am? Tip over a table spilling ballots everywhere and then announce it’s going to take another 3 hours to re-do this work. Most people would probably go home at that point.
Hand counting works in small jurisdictions with simple ballots. Even then, they prefer automation. Examples in other countries are irrelevant. It has to work with the system we have here in the U.S.
“Yes, it does matter if it takes a few hours longer. The longer it takes, the longer you have to have security holes plugged.”
That’s absurd. If you want to hack an e-voting system, you have weeks to years to prepare (you get the hardware, study it, poke at the software, etc.) You’re saying a few hours of hand-counting is a security risk??
“The number of poll sites claimed in Los Angeles varies anywhere from 4400 to 5000. So, if we’re concerned about scalability, we want to know how you hire 88,000 to 100,000 to do the counting.”
First of all, I think 20 counters is far too high. You need to hire about 2 or 3 counters per polling place. Secondly, if scrutineers from various political parties want to oversee the counting, that’s fine — they don’t get paid. So you’re looking at hiring about 15,000 people for about 4 hours at maybe $15/hour. That’s $900K to run the election in LA, which sounds about right to me. You’d probably be looking at about $300M for the entire US.
“If some preliminary results leak out (think network of interested counters all over the county text messaging),”
You put the counters in a room. You take away cell phones, etc. Since there are representatives from different parties, there’s a strong incentive to keep each other honest.
“Want better access to the ballots at 1:00 am? Tip over a table spilling ballots everywhere and then announce it’s going to take another 3 hours to re-do this work. Most people would probably go home at that point.”
Again, you have people from competing parties keeping each other honest. And you’d have to do this on a massive scale to really affect an election. Hacking an e-voting system can be done in seconds, remotely and untraceably.
“Examples in other countries are irrelevant. It has to work with the system we have here in the U.S.”
That’s plain silly. The US has a complex voting system, but it’s not that complex. And saying examples in other countries are “irrelevant” is simply closed-minded.
Look. We all know that e-voting is insecure and unsecurable. No-one has ever, in the history of computing, made a secure network operating system, let alone a secure software suite from OS all the way up to applications. You are objecting to paper ballots with hand-counting without offering real evidence that it won’t work.
Your description of disclosed source is in no way shape or form what I mean by “disclosed source.” To clarify, I will tell you a story that Arnie Urken told me around 6 years ago.
Arnie went through the process with NASED to become an authorized test lab (“ITA”). I believe it was some sort of partnership — at least 10 years ago — with Stevens Tech. Anyway, his first customer, ES&S, presented a system for him to test. Arnie said, “where’s the source code?” ES&S said, “you don’t need it.” Arnie protested to NASED (maybe the FEC too). They supported the ES&S position. Arnie shut down the test lab since he concluded the whole system was a sham.
That was really before disclosed source. Since then, that kind of closed source has been banned. The disclosed source you are talking about only expands the body of authorized reviewers. I’ve always considered disclosed source to mean full public disclosure. The licensing restrictions that apply mean we don’t consider this type of disclosed source as “open source.”
The assertion you made that, “This model is almost certainly more feasible, from a political perspective, then the adoption of a full-blown open source model” is unsupported. I don’t see much of a political barrier here. The real barrier is financial. It used to be we said we need 100s of thousands to get a system finished and certified. It now appears the bar has been raised to “millions of dollars.”
So, you admit your “FFRDC idea is a pie in the sky.” When you said, “A likely model is…” it should really read, “An unlikely model is ….” No problem. Yes, officials are confused, too.
You end with, “The point of raising it is to note that open source projects need not necessarily be volunteer community projects, which was one of the assumptions in the ETC paper that I felt needed to be refuted.” I don’t quite agree with that, because that’s not exactly a good characterization of what the ETC paper says on this point. They point out that the project model that produced some successful open source software wouldn’t be adequate for the voting system since there are these regulatory and legal hurdles (that also happen to be expensive). They are right about that. They don’t really say a different open source model could not emerge. A consortium structure (like OVC) could address this issue. The ETC asks if an open source system was certified and in use, who would be responsible if changes were needed. My answer is that if it was the OVC system, then the OVC would take care of that. Obviously, we need to build up membership to support the software. The OVC structure would involve a lot of volunteers but also some paid staff to make it all work.
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…
That was a test, Joe. You passed.
Well, I’m not “TimH”. I’ll respond accordingly.
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.
The loss of Trade Secrets, may just be a cost of selling machines to a government. Happens all the time. It would be up to each company to evaluate the risk/reward. If California were to mandate a single system and require disclosure, the vendors would have a hard time resisting. If it was a single rural county in Wyoming, I think they would pass.
Intellectual property rights that voting machine vendors harp about really reflect an abuse of the concept. IP protections were conceived to advance human knowledge by providing an incentive to inventors.
This is spelled out in the US Constitution (Article I, Sec. 8) “To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries;”
Vendors have learned to use IP protection to rig the market while not coming up with an idea of any real value. In other words, the value of voting machine vendors’ inventions, in terms of advancement of human knowledge, is exactly zero.
This type of IP abuse is very common in many industries, unfortunately.
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.
I’m sorry, Dan, but IMO, your research is well-intentioned but misguided. Take a couple of sentences from the opening paragraph of your page:
“It is designed to be a platform for broad e-voting research, particularly in the areas of security and usability. The code is written in Java, and runs on computers with Windows, Macintosh, and Linux operating systems. ”
Right there, you’ve lost 75% of the electorate. If people can’t understand how a voting system works, why it’s secure (or not) and what sort of attacks can be leveled against it, they won’t trust it, and that will erode democracy.
I can explain the paper-ballot voting system in Canada in terms an 8-year-old can understand. I can explain its resistance to tampering in terms that a bright 10-year-old could understand. I can explain the types of attacks that could be leveled against it to that same 10-year-old.
To understand VoteBox, you’d need more background in computer science than 90% of the population. That’s bad.
Apparently somewhere between the ages of 8 and 10, a child learns how stickers with their name on them can seal a cardboard box shut.
But what that 10y/o couldn’t do, is sit in a gym for 12 hours watching that box. Or count 5000 county ballots without making a mistake, possibly naming Batman president.
The 10-year-old couldn’t sit in a gym watching the box or counting ballots accurately. However, the 10-year-old could easily understand how adults could do those things. He or she could understand that ballot-counting involving one election official plus one scrutineer from each political party is likely to be pretty accurate. He or she could also understand that automatic recounts in the event of a close race improve accuracy even more.
I don’t think there are many 10-year-olds who could understand VoteBox.
My issue with e-voting is not that i don’t understand enough Java to trust the code (i do, i’m a programmer), it’s that it is VERY difficult to verify and trust that the code i just read is actually the code installed on the voting machine. Oh sure you can run a checksum, but checksumming software can be corrupt just as easily as voting software. Ultimately it is just a difficult problem. Lot’s of people have access to the machine, and don’t some of them even have dial-in or tcp/ip access? software can be written to self-modify: you can pass the checksum with clean code, somehow get dirty code on there, and the dirty code can clean itself up after the election so a post-run checksum will pass too. It’s a thorny problem.
Furthermore, if the program is a few 100,000 lines of code, or even more, it is very hard to be sure you’ve checked it all thoroughly for maliciousness. Are you *sure* that there isn’t some code in all those source files that cheats in some way? The project i work on at work is over a million lines of code, and nobody in our office knows it all. People know certain areas, and we hope that across the whole team we have coverage of any detail, but it is a lot of code. I don’t think a voting machine would need a million lines, but if you wanted to bloat it up to hide malicious code in it easier? could get there. Sure that’s dangerous, but are you *sure* no one would risk it? to win the presidency? Code can be written in a way that makes it hard to tell what it’s doing, exactly, too.
I’m a coder, but i certainly wouldn’t waste my time reading the source to voting software before an election, i’d trust an agency or organization to do it. But it is not an easy thing to read strange code for a big program, and ultimately, because of the problems with code verification on the machine, i would strongly prefer that we use mechanical, paper ballots. A simpler, easier to verify, harder to tamper with, more transparent, recountable, hard-copy-creating mechanism is strongly preferable, in my mind, to the needlessly complex and problem-ridden computerized alternative.
Seems I have to address this every time I talk about VoteBox.
In order to trust VoteBox, I’m not asking you to trust my code. You don’t have to read it. I’m asking you to trust the cryptography inside VoteBox. I’m asking you to trust some equations and a few hardness assumptions on modular arithmetic — and if those turn out to be false, we’ll all have bigger problems to worry about.
VoteBox is an example of an end-to-end cryptographic voting system. What that means is that the cryptography forces the machine to either output the correct, encrypted representation of your vote, or risk getting caught with what amounts to a signed confession of its malfeasance. If you think that any particular VoteBox is suspicious, or if you’re just in an auditing kind of mood, you’d be able to go into the polls, declare to the poll workers that you’re there to do some auditing, and then they’d let you have at it. (They would probably lock down the “cast vote” button, so you couldn’t accidentally cast an actual vote, but the machine wouldn’t know that.)
Go ahead and read the papers. They’re intended to be readable.
Now, there is a side issue, which is that a malicious VoteBox, while it cannot change your vote, it could still save it on the side or it could dork around with the random numbers used in the encryption as a way of leaking how you voted to an observant third party. We’ve got a solution to that as well, but that’s research work in progress.
“I’m asking you to trust the cryptography inside VoteBox.”
You’ve just lost.
Every single cryptographic system based on reliable cryptography that has been cracked, has been cracked because of implementation deficiencies. You can have rock-solid cryptography and mathematics, but in the real world, that’s not good enough.
Furthermore, nothing you have said has addressed the “understandable by the general public” issue, which in my opinion is more of a strike against e-voting than theoretical security issues.
Every cryptosystem has been cracked? That’s unclear at best. Has SSL/TLS been cracked? Certainly, subtle bugs have been found in earlier versions and those have been fixed. Weaknesses in MD5 led to a recent attack based on certificates that Verisign now doesn’t issue any more. Likewise, earlier cipher suites, like 40-bit RC4, were dumb to begin with and are no longer used. Good cryptography is a process. It grows and evolves. SSL, today, is an evolving thing, and it’s pretty good. Calling SSL inherently broken is taking an extreme position that’s not supported by the evidence. Crypto in a voting machine would be no different.
As to the comprehensibility issue, you might have a look at systems like Scantegrity where this was an explicit design goal of the system. Current voting systems, of all stripes, have issues with comprehensibility. How many people do you think could understand how gerrymandering works? How many people understand how the caucus and primary system really works? In short, they tend to trust others to pay attention and vouch for the process. With a cryptographic voting scheme like VoteBox, a voter doesn’t need to understand the crypto at all. They only need to understand the auditing process, and how a third-party organization that they do trust can build a web server that they can reach from their iPhone, and how that will let them challenge a voting machine.
Put another way, consider investment pariah Bernie Madoff. His clients never really understood what he was doing, but really they didn’t care because they assumed that other smart people were paying attention, and they were getting great consistent returns. Madoff’s clients were satisfied with the results. Of course, they weren’t quite so happy when it turned out to be a sham. Now, if a cryptographic voting system can deliver good results, and if a handful of smart people can pay attention and assure themselves that the system is working properly, that could well be good enough. The only way to definitively answer questions of what people will or will not accept is to do surveys or controlled experiments. Neither you nor I can make categorical statements about what the public will or will not accept.
So long as you’re ragging on me for two particular issues, I should point out all the other issues you’re leaving out that are every bit as important.
– Usability is essential to the error rate of a modern election. Usability issues were one key issue in the whole butterfly ballot craziness in 2000. You also have to worry about poll worker usability issues. In a voting center with potentially thousands of different ballot styles, you need to make sure that every voter sees the proper ballot style.
– Related to usability, voter satisfaction matters. The political scientists have shown that if people like voting, that they’ll come back and vote again. If not, they won’t. While voters aren’t any more accurate with electronic voting machines, they have a statistically significant preference for them. Voter satisfaction is also tied in to other things, like how long they have to wait, whether poll workers are friendly and helpful, and even whether there’s adequate parking. You ignore these issues at your peril.
– You’re understating the importance of administrative efficiency. Election administrators have zero interest in trying to manage hoards of people counting ballots by hand, and they also generally have very tight budgets. If you don’t have the election administrators on board, your proposal goes nowhere.
“Every cryptosystem has been cracked?”
No. That’s not what I wrote. Here it is again: “Every single cryptographic system based on reliable cryptography that has been cracked, has been cracked because of implementation deficiencies.” So when you say we don’t need to trust your implementation, you’re saying something ludicrous.
“How many people do you think could understand how gerrymandering works?”
Well, the Wikipedia article is very clear. It requires basic reading skills and common sense. not a background in computer science.
“How many people understand how the caucus and primary system really works?”
I confess I do not, since our system is far simpler. But again, I assume that a reasonably bright person with no background in computer science could figure it out.
“With a cryptographic voting scheme like VoteBox, a voter doesn’t need to understand the crypto at all.”
Again: You’ve lost. Put yourself in the position of a voter: “Some computer scientist is saying to me, Don’t worry! You don’t need to understand this stuff.”
Umm… no.
“They only need to understand the auditing process, and how a third-party organization that they do trust can build a web server that they can reach from their iPhone, and how that will let them challenge a voting machine.”
But that is utterly incomprehensible. I don’t know if my bank can build a secure web server. I do online banking not because I’m convinced the bank’s server is bullet-proof, but because of limits on my liability if my card is fraudulently used. As a test, please try to explain your system to non-technical people and see how they react.
“Put another way, consider investment pariah Bernie Madoff. His clients never really understood what he was doing, but really they didn’t care because they assumed that other smart people were paying attention, and they were getting great consistent returns.”
That’s an argument against e-voting. What we have is an expert (you) saying “Don’t worry your pretty little heads about the crypto; it’s all fine.” Well, no. I don’t accept that, and neither should most voters.
“Usability is essential to the error rate of a modern election.”
Yes! And the absolutely most usable system is a paper ballot where you fill in a circle next to the person or thing you’re voting for. Alternatively, you have different ballots and you pick the one(s) you want. I’ve watched my parents interact with computers; trust me, no computer interface will be easier than paper ballots.
For the tiny fraction of people too disabled to fill in a ballot or pick one, well, sorry; they’ll need to get assistants to do it for them.
“While voters aren’t any more accurate with electronic voting machines, they have a statistically significant preference for them.”
Do you have evidence to back that up?
If filling in a paper ballot is too onerous for some people, do we want those people voting? Except in countries where voting is mandatory, there’s something to be said for ignoring those people who are too lazy to vote.
“You’re understating the importance of administrative efficiency.”
No, you are overstating it. Unfortunately, North Americans have become used to instant gratification, and the news networks would probably go berzerk if they had to wait a day for election results. So they sacrifice democracy on the altar of instant gratification.
“Election administrators have zero interest in trying to manage hoards of people counting ballots by hand, and they also generally have very tight budgets. If you don’t have the election administrators on board, your proposal goes nowhere.”
A country that’s willing to spend more than a trillion dollars bailing out greedy and corrupt financial institutions and fat and lazy auto manufacturers can surely spend money on one of the foundations of its democratic system. If it’s unwilling to do that, I guess it’s clear where its priorities lie.
The United States desperately needs a national election commission to run national elections. Uniform rules across the country would do far more to ensure fairness than any high-tech e-voting system.
Do you have evidence to back that up?
Actually, yes.
Sarah P. Everett, Kristen K. Greene, Michael D. Byrne, Dan S. Wallach, Kyle Derr, Daniel R. Sandler, and Ted Torous. Electronic voting machines versus traditional methods: Improved preference, similar performance. Human Factors in Computing Systems: Proceedings of CHI 2008.
You might find it helpful to read the literature before you make claims about usability or satisfaction of different voting systems.
“I’ve watched my parents interact with computers; trust me, no computer interface will be easier than paper ballots.”
First of all, your parents have a large array of user interface metaphors that they feel comfortable with. Other people will have other metaphors, especially as the video gaming generation gets to be a larger percentage of the population. I honestly am starting to have a little trouble writing with a pencil…marking an X on a piece of paper is obviously still within my grasp but if you’ve never used a pencil in your life for writing, what’s the use of forcing us to use one here? Again; there may be a public benefit to doing so, but make no mistake, the use of a pencil as interface is not an absolute, timeless, perfect UI design; it is a learned skill, and one that is only important insofar as other tasks require it, tasks which are being automated out of existence left and right.
Second, saying “no computer interface will be easier than paper ballots” is, I would consider, a huge challenge to the future perhaps. Voting for me includes walking often dozens of blocks so that I can wander around in a school or church, verify my identity with some old ladies or something, prodeed to hide myself where I can put a black mark on a piece of paper. Voting could be putting the special blue headband around my head, and concentrating on the candidate I want, never leaving my chair. Or it could be done while I’m out in the prairie somewhere, just wandering around, in the same way. We’re not *that* far from that kind of technology, give it 75-1,000 years.
The rest of your post, though, I’m probably in complete agreement with.
I don’t personally know Mr. Skoll, but I’d strongly urge Dan, and the others here to re-read what he’s trying to get across to you here very carefully.
I understand that much of this, the response from computer scientists and security experts to perceived election “problems”, is akin to tasking Western physicians to find a cure for cancer (they’re likely only going to look at cut/poison/burn types of solutions), so if you ask computer scientists and security experts for a “solution” to our election “problem” (which we’ve self-created), you’re very likely going to get computerized “solutions”.
As a one time programmer myself, it took me a while before I understood that programming was not the solution.
But, at some point, and it may take at least as long as it’s taken the private vendors to begin seeing the darkness at the end of their tunnel, I’d suggest those looking for a computerized “solution” are eventually going to come to terms with the reality that there isn’t and/or needn’t be one.
Again, I’d urge you to pay close attention to what Mr. Skoll is trying to tell you here — in each of his important comments — but if “Oy vey” is the only general response you’re able to muster for the moment, I’d suggest the answers still remain a long, long way from your grasp. That’s disappointing to see among several folks here who I admire a great deal.
Pigeon-hole and/or marginalize Mr. Skoll’s school of thought any way you like, if you must, for the moment, but the fact is, he’s 100% right in each of the points he’s made here. Thankfully, he made those points here, so I didn’t have to, so I can press on in other areas and leave this one to him for the moment. But please consider this a vote of association with Mr. Skoll’s lessons he’s trying to impart here.
I have not read the paper you cite, but I have read papers on VHTi and other “E2E” systems. VHTi, for example, is vulnerable to (at least):
1. Social-engineering attacks. “E2E” systems’ security guarantees obtain only if the voter correctly executes an unfamiliar protocol with the voting machine. An attacker (e.g., the vendor) can program the machine to guide the voter to execute the protocol incorrectly, thus voiding the security guarantees. Since the protocol is unfamiliar, the vast majority of voters (but excluding cryptographers) will have no idea that something has gone wrong.
2. Selective denial of service (e.g., the machine monitors the vote stream, and selectively “fails” or slows down voting when too many voters are selecting the “wrong” candidate);
3. Presentation attacks (e.g., omitting candidates from the ballot, reordering the ballot, playing with the race headers to de-emphasize certain races). Don’t discount these attacks’ possible effects; in 2006, CD-13 (Sarasota FL) experienced a 15% undervote (which very arguably flipped the outcome) in a congressional race — which officials attributed to an badly-designed race heading;
4. Selection attacks (e.g., selectively enlarging or shrinking candidates’ selection areas, or modulating their sensitivity). An amusing video on this theme is at http://www.youtube.com/watch?v=V3jHENhdi0w . It’s over the top, but it cogently illustrates some problems that can arise when we leave the voter alone with a programmable vote-casting device.
Unless your “E2E” solution is quite different from VHTi, it will share these vulnerabilities.
See Is E-Voting a solution? To which problem?.
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.