Friday, September 24, 2004
On Touchscreen Voting
There was an article in the Berkeley Daily Planet, May 7-9, "Cal Grad Proposes Touchscreen Alternative" in response to the decertifications of electronic voting machines in Californis. It proposed to layer more complexity onto the system by adding the ever popular dead trees to the mix. The article then posited associated policies and procedures to correct the underlying deficiencies.
My experience with my MG motorcars demonstrates the futility of this approach. When design problems were found, they tended to layer a solution on top of the problem, but not to solve it. As layer upon layer was added with each step, it further obfuscated the original architecture with its associated problems. New solutions caused inconsistencies with other no longer visible aspects of the system. The result is a delicately balanced system that requires special knowledge on the part of all involved.
Adding a paper trail to an electronic voting system is just such a layered solution.
I propose a much simpler solution to the problem of vote authentication, storage, tabulation and verification. Vote tabulation in a repeatedly verifiable fashion is trivial once vote authentication and storage are solved. I solve them with cooperatively developed open source, commodity hardware, write-once media (CD), a reread verification step to allow the voter to correct errors, and digital signatures. No dead trees are required.
The first problem to be addressed is authenticity of a vote. It is often argued that once a vote is cast on a computer even the most comprehensive checks sometimes can't ensure the machine won't make a switch. This is inaccurate given currently available verification and authentication capabilities. We can know that a vote is recorded digitally on a non-modifiable medium exactly as the voter requested it be.
The keys to this are code transparency for the programs that run the voting and tabulating machines along with recording the votes on a write-once medium like CD.
The big problem with current touchscreen machines is that proprietary manufactures will not disclose the code listings for each and every piece of code in their machines. If we cant see the code, we cannot know what it is doing.
The solution to this problem is open source. Program listings for systems much more complicated than this application have been publicly available and cooperatively maintained for decades. The most obvious instance is the Linux operating system. But, there are open source solutions available for each and every layer of program needed to implement a touchscreen voting application. As reference, I would suggest you take a look at projects tracked by sourceforge.net or even the finished packages at freshmeat.net.
For hardware, I would recommend commodity components. I'd get multiple manufacturers to build them from well known components such as mini-CD writers, Intel or like commodity processors packaged with a touchscreen into a commodity voting machine. Given the open source nature of all code for such a machine, the market would be worldwide and the units would be cheap.
I would also cooperatively develop a set of quality assurance (QA) acceptance test suites that could be downloaded and run on any new piece of hardware. The manufacturers could use these in their QA. Election folks could use them to vet any new purchases.
OK, now the process. Because it is open source, the state could read, verify and digitally sign OS CDs that each county could download and use as boot CDs for their machines. The county elections personnel could prepare a ballot XML file for each district that would also be burned onto the CD. The CD could then be digitally signed in any of a number of ways that would reveal any subsequent tampering.
A voter-verified audit trail would not be provided on paper. It would be provided on the little CDs the machines use. After the voter has finished selecting their choices for each office and measure and verified their choices on a summary screen, the record would be digitally signed and written to the CD. The record of the vote would then be reread from the CD, and the voter presented with a second summary screen. Should the voter not like what they see, a vote nullification record would be written to the CD, and the voting process would begin again. The voter gets two chances to verify their vote. Once before it is written to CD, and a second time when it is reread from that CD. Since the information is recorded as XML marked up text, it would be directly readable from the CD by an file browser on any machine with a CD drive.
The data CD's could be preloaded and sealed into the machines prior to distribution to the polling sites. It available, phone lines using secure, signed encrypted connections to a central repository could be used to transmit preliminary results to the tabulator system. That system, however, could then verify all vote files against the physical CD when the actual voting machines are returned to the election center. Since such a machine itself would be commodity and open source, those processes would be repeatable and verifiable.
In information systems our mantra is Garbage in, garbage out. The time to deal with uncertainty is as close to the source as possible. We like to deal with potentially inaccurate data during the acquisition phase. The tricks employed by advocates of a paper trail address this but only in a cumbersome way. They are mostly back-end compensation. They provide only the appearance of security while at the same time increasing the load on the election management team at the time they are most burdened. Simplifying the system and vetting its components in advance will make things run much more smoothly on election night.
My experience with my MG motorcars demonstrates the futility of this approach. When design problems were found, they tended to layer a solution on top of the problem, but not to solve it. As layer upon layer was added with each step, it further obfuscated the original architecture with its associated problems. New solutions caused inconsistencies with other no longer visible aspects of the system. The result is a delicately balanced system that requires special knowledge on the part of all involved.
Adding a paper trail to an electronic voting system is just such a layered solution.
I propose a much simpler solution to the problem of vote authentication, storage, tabulation and verification. Vote tabulation in a repeatedly verifiable fashion is trivial once vote authentication and storage are solved. I solve them with cooperatively developed open source, commodity hardware, write-once media (CD), a reread verification step to allow the voter to correct errors, and digital signatures. No dead trees are required.
The first problem to be addressed is authenticity of a vote. It is often argued that once a vote is cast on a computer even the most comprehensive checks sometimes can't ensure the machine won't make a switch. This is inaccurate given currently available verification and authentication capabilities. We can know that a vote is recorded digitally on a non-modifiable medium exactly as the voter requested it be.
The keys to this are code transparency for the programs that run the voting and tabulating machines along with recording the votes on a write-once medium like CD.
The big problem with current touchscreen machines is that proprietary manufactures will not disclose the code listings for each and every piece of code in their machines. If we cant see the code, we cannot know what it is doing.
The solution to this problem is open source. Program listings for systems much more complicated than this application have been publicly available and cooperatively maintained for decades. The most obvious instance is the Linux operating system. But, there are open source solutions available for each and every layer of program needed to implement a touchscreen voting application. As reference, I would suggest you take a look at projects tracked by sourceforge.net or even the finished packages at freshmeat.net.
For hardware, I would recommend commodity components. I'd get multiple manufacturers to build them from well known components such as mini-CD writers, Intel or like commodity processors packaged with a touchscreen into a commodity voting machine. Given the open source nature of all code for such a machine, the market would be worldwide and the units would be cheap.
I would also cooperatively develop a set of quality assurance (QA) acceptance test suites that could be downloaded and run on any new piece of hardware. The manufacturers could use these in their QA. Election folks could use them to vet any new purchases.
OK, now the process. Because it is open source, the state could read, verify and digitally sign OS CDs that each county could download and use as boot CDs for their machines. The county elections personnel could prepare a ballot XML file for each district that would also be burned onto the CD. The CD could then be digitally signed in any of a number of ways that would reveal any subsequent tampering.
A voter-verified audit trail would not be provided on paper. It would be provided on the little CDs the machines use. After the voter has finished selecting their choices for each office and measure and verified their choices on a summary screen, the record would be digitally signed and written to the CD. The record of the vote would then be reread from the CD, and the voter presented with a second summary screen. Should the voter not like what they see, a vote nullification record would be written to the CD, and the voting process would begin again. The voter gets two chances to verify their vote. Once before it is written to CD, and a second time when it is reread from that CD. Since the information is recorded as XML marked up text, it would be directly readable from the CD by an file browser on any machine with a CD drive.
The data CD's could be preloaded and sealed into the machines prior to distribution to the polling sites. It available, phone lines using secure, signed encrypted connections to a central repository could be used to transmit preliminary results to the tabulator system. That system, however, could then verify all vote files against the physical CD when the actual voting machines are returned to the election center. Since such a machine itself would be commodity and open source, those processes would be repeatable and verifiable.
In information systems our mantra is Garbage in, garbage out. The time to deal with uncertainty is as close to the source as possible. We like to deal with potentially inaccurate data during the acquisition phase. The tricks employed by advocates of a paper trail address this but only in a cumbersome way. They are mostly back-end compensation. They provide only the appearance of security while at the same time increasing the load on the election management team at the time they are most burdened. Simplifying the system and vetting its components in advance will make things run much more smoothly on election night.
