Slashdot Mirror

An anonymous reader writes "Another American election is almost here, and while electronic voting is commonplace, it is still overwhelmingly run by closed source, proprietary systems. It has been shown that many of these systems can be compromised (and because they are closed, there may be holes we simply cannot know about). Plus they are vulnerable to software bugs and are often based on unstable, closed-source operating systems. By the inherent nature of closed software, when systems are (optionally!) certified by registrars, there is no proof that they will behave the same on election day as in tests. The opportunities for fraud, tampering and malfunction are rampant. But nonetheless, there is very little political will for open source voting, let alone simple measures like end-to-end auditable voting systems or more radical approaches like open source governance. Why do we remain in the virtual dark ages, when clearly we have better alternatives readily available?"

phil reed writes "Given the latest fiasco in Florida's continuing attempts to implement a decent voting system, I thought it would be appropriate to alert Slashdot readers to the work of Dr. Rebecca Mercuri. She's been studying voting systems for many years, and has developed well-considered positions on what makes a good electronic voting system (and what makes a bad one). Her comments on the Florida 2002 election can be found in the current Risks Digest. And, if you think that creating a computer-based voting system is easy, she provides a suggested list of questions that should be answered by any developer." Mercuri's statement in Risks is well worth reading. With all due respect, she is wrong in some respects: it is possible to create a fully-verified electronic system. Start with completely open code and thoroughly examined hardware, create an audited system for installing the code on the hardware, and make it tamper-evident so that you know the same code is still there when the machine reaches the voting booths. Bootable, hologrammed, serial-numbered CD-ROMs with individual private keys would do the trick. Mercuri is thinking in terms of vendors selling proprietary "solutions", where she's absolutely right: there's no way to verify that what people punch in is what is actually recorded.

phil reed writes "Given the latest fiasco in Florida's continuing attempts to implement a decent voting system, I thought it would be appropriate to alert Slashdot readers to the work of Dr. Rebecca Mercuri. She's been studying voting systems for many years, and has developed well-considered positions on what makes a good electronic voting system (and what makes a bad one). Her comments on the Florida 2002 election can be found in the current Risks Digest. And, if you think that creating a computer-based voting system is easy, she provides a suggested list of questions that should be answered by any developer." Mercuri's statement in Risks is well worth reading. With all due respect, she is wrong in some respects: it is possible to create a fully-verified electronic system. Start with completely open code and thoroughly examined hardware, create an audited system for installing the code on the hardware, and make it tamper-evident so that you know the same code is still there when the machine reaches the voting booths. Bootable, hologrammed, serial-numbered CD-ROMs with individual private keys would do the trick. Mercuri is thinking in terms of vendors selling proprietary "solutions", where she's absolutely right: there's no way to verify that what people punch in is what is actually recorded.

phil reed writes "Given the latest fiasco in Florida's continuing attempts to implement a decent voting system, I thought it would be appropriate to alert Slashdot readers to the work of Dr. Rebecca Mercuri. She's been studying voting systems for many years, and has developed well-considered positions on what makes a good electronic voting system (and what makes a bad one). Her comments on the Florida 2002 election can be found in the current Risks Digest. And, if you think that creating a computer-based voting system is easy, she provides a suggested list of questions that should be answered by any developer." Mercuri's statement in Risks is well worth reading. With all due respect, she is wrong in some respects: it is possible to create a fully-verified electronic system. Start with completely open code and thoroughly examined hardware, create an audited system for installing the code on the hardware, and make it tamper-evident so that you know the same code is still there when the machine reaches the voting booths. Bootable, hologrammed, serial-numbered CD-ROMs with individual private keys would do the trick. Mercuri is thinking in terms of vendors selling proprietary "solutions", where she's absolutely right: there's no way to verify that what people punch in is what is actually recorded.