Believers in democracy all agree it depends on verifiable elections. We repudiate the sneering words of Nicaraguan dictator Anastasio Somoza "You won the election, but I won the count." [1977]. The question is how to verify elections. Recently, consensus is growing around the need for a tangible, re-countable voter verified paper ballot as a key ingredient. That would be required by the Voter Confidence Act (HR 2239, S 1980). But another mandate of this important legislation is less well publicized or understood - the requirement to disclose the source code to any citizen.
Paper ballots are only helpful if they are counted in a verifiable way. Previous practice has been to require that the source code for the software for voting systems be reviewed by a third-party organization. But recent history has demonstrated that these reviews have missed major flaws. In four major systems that had already been certified, independent reviews have shown that the software has multiple flaws. [Johns Hopkins, SAIC, Ohio Secretary of State's office, etc - see SecurityAnalyses]. The election industry is finally beginning to learn what other industries have known for a while now: writing secure software is really hard. And it is far harder when we also need to preserve the anonymity of the voter.
One instinctual notion is "Security through Obscurity". I.e. some people think the systems should be designed in secret, and hidden from as many people as possible. But decades of cryptography research has led to state-of-the-art systems in which the code can be public and only the keys need to be kept a secret. And experience shows that when enough people want to break into a system, trying to keep the code a secret doesn't stop them, as users well know. Openness is simply the best approach in this sort of situation.
For example, when the US government wanted a new Advanced Encryption Standard (AES), they didn't rely on the National Security Agency to design it with their enormous funding and expertise. They announced a public, open, worldwide competition. Algorithms were proposed and coded and disclosed and debated for years. The winning entry, from Belgium, was then presented to the world for free use.
The best model is electronic communications and commerce on the Internet. Despite fierce competition, more secure web sites rely on the "Open Source" software called Apache than anything else [2003].
A natural question is "But isn't it risky to allow absolutely anyone to look at your source code?". First we have to look at what risks we're worried about. Elections expert Douglas Jones writes "A trustworthy system of elections must rest on one central principle: Trust no-one". This is not out of paranoia, but simply because it's really important, and we don't have to trust anyone. The lack of security in the software that we currently use leaves elections vulnerable to manipulation by unscrupulous insiders, elections officials, and other savvy people. Full disclosure would induce the designers to be more careful, and provide them with assistance from the same enormous pool of talent that voluntarily contributed to AES and Apache.
A policy that limits code review to vendors and third-party reviewers means that the software will not benefit from the increased quality that comes from greater review, and thus remain vulnerable to manipulation by those who do have access to it.
There are different disclosure approaches. One option is to require that all the code be fully and publicly disclosed, but allow vendors to retain exclusive rights to sell it for use in elections. No one should have to sign any Non-Disclosure Agreements since that could suppress open discussion which is a primary goal.
It would also be possible to require that the software be provided under an Open Source license which would allow anyone to reuse it. Or we could require use of the GNU Public License (GPL). Such "Free Software" also requires that people who make and distribute changes "share and share alike". Note that many companies sell both Free Software and Open Source software, and it is easy for users to buy support contracts from their choice of vendors. We're talking about "free, as in freedom", not necessarily "free, as in zero cost".
I think the law should simply require full public disclosure of everything necessary to build a working system. This is more or less like universal practice of requiring blueprints from building contractors. HR2239 should be amended to make absolutely clear that Non-Disclosure Agreements (NDA) would not be necessary.
But I'd advise the people that acquire the systems and run the elections to recognize that using Free Software has big advantages. One is freedom from the risk that the vendor will go out of business.
Now you're thinking "Isn't this just pie in the sky? Who would really write and give away a free election system?" Well, one such system was used as early as 2001 in Australia. EVACS beat out proprietary rivals in a competition. It came from a company named Software Improvements. The software for online e-voting in the Netherlands has also been disclosed. Similar development projects are underway elsewhere, for example at the OSET Institute - Open Source Election Technology.
The accidental disclosure of Diebold source code has led to them fixing problems that had been called for by third-party reviewers years before. Mandatory full public disclosure would lead to better quality systems and enhanced voter confidence in our elections and our democracy.
See also