Am I alone in having serious doubts of the ability to have an open source implementation of a voting machine?
The problem is that to have any benefit from having an open source solution, all of the code in the system needs to be open source, including all of the drivers etc. As drivers need to be adapted to the specific hardware that they run on, it is normally only the manufacturer of the equipment that can write them. Think video drivers in Linux, as an example. Hardware manufacturers probably see little commercial advantage in providing their source code, and even if they do, there is no guarantee that what they give out as source code is really what they have loaded into the voting machine.
It's not about them seeing the "commercial advantage" in free market terms; it's about mandating a particular approach (in this case, open hardware and software from top to bottom) because it's the only way to insure that the basic infrastructure used in elections works. This is not a case where the whims of the market should decide the approach taken.
If no one gets rich on the design and implementation of electronic voting systems, that's fine. I'd rather see it run by well-intentioned, poorly-paid academics within a strict peer-review model than by unknown private entities.
Actually that could be turned around to drive hardware manufacturers to open source, along the lines of, "if you want to play in this important and visible market, your drivers have to be open source".
In The Netherlands a group has succesfully fought against the use of voting machines with secret software. For now the use of voting machines is not allowed anymore and the Dutch people have to vote using pen and paper. More info: http://www.wijvertrouwenstemcomputersniet.nl/English.
"On May 16, 2008 the Dutch government decided that elections in the Netherlands will be held using paper ballots and red pencil only. A proposal to develop a new generation of voting computers was rejected."
* The code is publicly verifiable - eg, every voter is provided with a 'voting receipt' with a non-identifying UUID and their voting results. Users are allowed to look up this info online at any time they wish.
This is a classic, but how does it relate to my post? Are you pointing out that a trojan could still be hidden in public code?
If so, I agree. But I think making that code public reduces the risk of it being malicious. Eg, for one you've already made it so that the malware must be implemented as a trojan, rather than being obvious. The other is the code would be under massive scrutiny (hopefully without the developers OKing changes without actually looking at what they do, ala OpenSSL).
Read again. You cannot trust code, and making it public is almost irrelevant in this regard. You need the full resources of an "emerging" country, like China, to fully develop your own (e.g. Longsoon).
"Moral
The moral is obvious. You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) No amount of source-level verification or scrutiny will protect you from using untrusted code. In demonstrating the possibility of this kind of attack, I picked on the C compiler. I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode. As the level of program gets lower, these bugs will be harder and harder to detect. A well installed microcode bug will be almost impossible to detect."
I would be awfully surprised, if people who made millions (from Verisign) by "looking" at ssl would have made that kind of a mistake (effectively freedom frying the French National Guard).
Certainly, everything can be hacked, but if the code is running on a machine using standard off-the-shelf hardware, and running OpenBSD or another equivalently open *nix distro, and the code is interpreted code running on that machine, using the standard interpreter from that (open) language, then the chances that someone might manage to introduce a hack are heavily reduced, due to the number of eyeballs which can verify that the code is safe.
I agree that you have to look at every element of the chain, but my point is that you can construct such a trusted chain that goes all the way from the hardware to the vote-tallying software. There is still some potential for hackery in the hardware, but that could also be ruled out by designing and implementing some open hardware - a project which, I'm sure, would gather plenty of support from the open source community.
you still look @it as a technological problem. It isn't. It is a social (moral) problem, thus cannot be solved by any interpreter, BSD fork (which deceivingly, towards the BIOS pretends to be Windows ;) etc.
The social problem exists whether or not you have e-voting. It has been solved to a satisfactory level already by having election observers, etc.
One of the cool things about social problems is they don't need exact solutions. If you can solve things for 99.9% or even 99% of the cases, that's considered good enough when it comes to people
You can't fully trust code unless you've created it entirely yourself.
That doesn't mean that code you have not fully created yourself which is available to scrutinize has the same level of risk as code which you have not created that is secret.
Nor does Thompson say it is in his article - read it again.
What blows my mind is how fubar the voting machine industry has been when it has a model example of regulation in the gambling machine industry. I realize that some of the technical design goals are different but many of the regulatory aspects are extremely similar.
Reliable and trustworthy voting is the linchpin of democracy. There is no excuse for voting "irregularities" in this day and age.
The problem is that to have any benefit from having an open source solution, all of the code in the system needs to be open source, including all of the drivers etc. As drivers need to be adapted to the specific hardware that they run on, it is normally only the manufacturer of the equipment that can write them. Think video drivers in Linux, as an example. Hardware manufacturers probably see little commercial advantage in providing their source code, and even if they do, there is no guarantee that what they give out as source code is really what they have loaded into the voting machine.