Yesterday I argued that computerized voting was dangerous because it makes the voting process more centralized and less transparent. Today I’ll argue that open source voting is clearly better than proprietary computerized voting, but that paper ballots is preferable to either.
Open source voting software doesn’t do a whole lot to address the centralization issue. True, the development of the software would be decentralized, but the process of manufacturing the machines and loading the software onto them would still likely be handled by a commercial company that would constitute a single point of failure. If someone at the manufacturing facility is unscrupulous, or if someone finds a vulnerability in the software or hardware, he’s going to be just as able to compromise a large number of open source machines as he would with closed-source ones.
As for transparency, open source voting machines clearly enhance transparency in the sense that more people are able to study and criticize the design of the voting software. And that would certainly enhance security. It’s widely accepted among security professionals that openness and peer review is the best way to ensure a system’s security. If Diebold made the source code to its voting machines publicly available, it’s certain that security experts would have long since pointed out those the flaws Felten discovered and Diebold (I hope) would have fixed them.
But I see two flaws with this. First, it creates a kind of high priesthood, in which the integrity of our voting system can only be verified by a small sliver of the electorate. Anybody can understand the security mechanisms that prevent fraud with paper ballots. But understanding the security measures in an open source voting machine requires highly technical training. That strikes me as inherently problematic, because it requires the other 99 percent of the population to take the integrity of our election system on faith. And one only has to look at the global warming or intelligent design debates to see that it’s quite common for both sides in a scientific debate to enlist the support of supposed scientists who accuse the other side of lying.
Secondly, although the process of developing the software is transparent, the rest of the process remains totally opaque. There’s no way for an ordinary poll worker to verify that the correct software is installed on a machine–malicious software can be programmed to mimick the behavior of the correct software, making any diagnostic tests unreliable.
It’s important to keep in mind that computer security is never purely a technical issue. There’s no such thing as a device that’s secure against tampering by someone who has unfettered access to it. This is particularly true because, for practical reasons, the machines are going to have to be designed to allow software upgrades. Although techniques like cryptographic signing of software updates can certainly make it more difficult to introduce malicious software onto a machine, those techniques can only accomplish so much. The encryption key would itself become a single point of failure, and you’ll never be able to stop someone with a screwdriver and a soldering iron.
But it’s actually worse than that. Luis points out, quite correctly, that fraud is all too common in jurisdictions with paper ballots. He’s right, but what I think he’s missing is that open source voting would be just as prone to most of the problems experienced with paper ballots. Much of the fraud that occurs is the result of manipulating who is able to vote–creating fraudulent voter roles, understaffing polling locations where the other guy is more popular, falsely labeling the other guy’s likely voters as felons, etc. There’s absolutely nothing a voting machine–open source or otherwise–can do to detect these types of fraud. It simply counts the number of votes fed into it. If a candidate’s voters are allowed to vote twice, or if his opponents’ voters are prevented from voting at all, there’s nothing the machine can do about it.
And it gets even worse. The above is a highly optimistic scenario from a public policy standpoint. Luis and I may have a good understanding of the arguments for open source voting, but the average voter or politician do not. On first impression, people tend to think that open source software would be less secure, because the bad guys would have an easier time finding and exploiting flaws. I think they’re wrong, but the reasons aren’t easily reduced to 30-second soundbites. Open source voting is likely to be an even more difficult cause to sell than the abolition computerized voting.
Moreover, a campaign for open source voting would be far easier for Diebold to subvert than a campaign against computerized voting. Everyone knows what a computer is. A ban on computerized voting machines would be straightforward to write and hard to evade. In contrast, hardly anyone outside of geek circles have any clear understanding of what open source is. Therefore, even if we were to create a public groundswell for open source voting machines, Diebold could probably respond by adopting Microsoft-style “open source,” where bits source code was released to a select group of friendly experts. There would be endless arguments about what counts as open source, and although we’d have reason on our side, they’d have most of the money and lobbying clout.
Even if the political battle could be won, I suspect that the result would be a less than harmonious development process. The open source process works best when they grow organically in a low-pressure environment, driven by the curiosity of their contributors. I’m sure Luis knows better than I do that there’s often friction between for-profit companies–which have deadlines and feature checklists to meet–and open source projects that often don’t move as fast or in the direction the company would like. We can’t put our elections on hold while we wait for volunteers to write voting software, so in practice, any open source voting project would have to be driven to a large extent by commercial vendors. The vendors would ultimately control which patches get included in the final product and which don’t, and that seems likely to create schisms and disillusioned volunteers.
So if we’re going to have computerized voting, I do think that we should push for as much openness and transparency in the software development process as possible. But in my view this merely mitigates the harms of a fundamentally misguided technology decision. It would be far better to abandon the notion of computerized voting machines entirely.
The Technology Liberation Front is the tech policy blog dedicated to keeping politicians' hands off the 'net and everything else related to technology.