Wednesday, December 14, 2005
A Transparent, Anonymous, Verifiable Voting Process: A Proposal
It is apparent to anyone with half-an-ear that there are rumblings throughout this country. Discontent and suspicions about the election process continues to grow. People distrust all parts of the process: the voting machines, the ballots designers, the precinct workers, and, of course, the politicians.
To address this problem, we need a new voting process - one that the American people can trust.
The following are the minimum requires for this process:
1) It has to be transparent. That means that the process itself must be documented and well understood, and any software used must be open source and freely available for examination.
2) It has to be anonymous. There must not be any way that someone can systematically determine which voter cast which ballot.
3) It has to be verifiable. Specifically, there has to be a paper trail of some sort that can be re-examined and re-counted.
It should also be reliable, scalable, and as inexpensive as possible.
The requirement for verifiability to rule out "lever voting machine" or "touch screen" voting machines, as neither produces a per-voter paper document. We all know about the problems with hanging chads, so "punch voting" is also out.
The system that seems most promising to me is an "optical scan" system similar to the one used where I vote. Its main drawback, it seems to me, is that it provides no feedback to the voter. How do I know that it accurately read my ballot and counted my votes the way I intended?
For that reason, I propose that the new voting process utilize:
1) an optical scanner. Although the scanner used where I vote feeds itself and looks special-purpose, I know of no reason that this could not be a simple page scanner, if that would significantly reduce costs.
2) a computer system to run the open-source software which controls the scan, picks off the votes, validates the ballot (see below), and accumulates the totals for those ballots which have been accepted.
3) a display monitor, properly positioned and shielded to show the voter (and no one else) a summary of the votes that the software recognized. It should provide the user with a button (via either a touch screen or a separate input device (see below)) to either "ACCEPT" or "REJECT" the ballot results.
A display monitor should be used for this validation step, rather than a printed receipt, for the same reason that ballots cannot be brought into the precinct - to discourage "vote buying". Disallowing outside ballots prevents vote buyers from pre-marking ballots; disallowing printed receipts denies vote buyers any evidence that a voter actually cast his vote the way the vote buyer demands. A display monitor also has the advantage of being faster, cheaper, and easier to manage than a receipt printer would be.
4) (optional) a separate input device. This could simply be a keyboard with the "A" key painted green (for "ACCEPT") and the "R" key painted red (for "REJECT").
When the voter makes his selection, precinct workers must be informed of that choice through some means. Possibly, this could be as simple as generating one of two clearly distinguishable audible tones: perhaps a gentle "ding" for "ACCEPT", and a harsh "blat" for "REJECT".
If the displayed votes are "ACCEPT"-ed, then the process is complete. A precinct worker should take the ballot, face down, and put it in a box of accepted ballots. This should occur in clear view of the voter. This box (or set of boxes) filled with accepted ballots provides a verifiable trail that can be re-scanned and re-counted should any question of irregularity arise.
On the other hand, if the displayed votes are "REJECT"-ed, a precinct worker should take the ballot, immediately shred it, and increment a count of spoiled ballots. This count, added to the number of accepted ballots, should be equal to the total number of ballots distributed: an additional check to detect voter fraud.
The rejecting voter is then offered the opportunity to re-vote, receiving a new ballot and going to the front of the voting line. There should be no limit to the number of times which a voter may reject his ballot.
If the voter declines to re-vote, then the precinct worker should increment a count of frustrated voters. This count, added to the number of accepted ballots, should be equal to the number of registered voters admitted by this precinct: an additional check to detect voter fraud.
None of this prevents fraud by precinct workers, of course. However, fraud should be controllable by other procedural means. Specifically, two precinct workers, one each from opposing political parties, should perform each step of the election process, together all times. Because they are politically opposed, one will immediately expose any attempt at voter fraud by the other.
That still leaves the possibility of human error. Controlling this must be the responsibility of all participants. However, the open source software that scans ballots and counts software should help at least this much:
1) It should display the number of ballots accepted so far. The first voter of the day knows that he or she is the first voter. If the counters are improperly reset (or if the ballot box is "stuffed" prior to the first voter) the first voter will notice and complain.
Similarly, the last voters are aware that they are last. If the number of voters per precinct is made available to the public (printed in the newspaper or published on a website), one of these last few voters will notice if the numbers are substantially different than the number they saw when they voted, and will complain. Even if they do not notice, the risk that they might should be enough to prevent anyone from risking voter fraud by discarding ballots, or "stuffing the ballot box" after the precinct has closed.
2) It should display a version number and some sort of checksum for the software in use. If this information is made public prior to the election, concerned citizens may well bring this information into the precinct with them, and use it to check the software before they let their ballot be scanned. This behavior would help ensure that unofficial versions of software are not accidentally used.
This behavior may help also help to discourage deliberate tampering. However, tampering of this kind is not entirely preventable through such means. Instead, procedural rules such as the one described above must be employed. Specifically, the software should only be acquired and installed in the presence of two persons of opposing party. If the software is already acquired, they should independently verify the size, date, and checksums of the software before allowing it to be installed. Both of these persons must be adequately qualified to perform these tasks.
What remains to make this proposal a reality is the existence of suitable open-source software to meet these requirements. Software or adequate documentation is also required to assist ballot creators in the process of generating scan-able ballots.
Technically, such an effort is not particularly challenging. However, the requirement for the software to be extremely reliable is something of a challenge, as is the meta-requirement that the software source code be as easy as possible to read and review. More importantly, challenging or not, this is an important task - one which will help to restore America's confidence in its voting process.
To address this problem, we need a new voting process - one that the American people can trust.
The following are the minimum requires for this process:
1) It has to be transparent. That means that the process itself must be documented and well understood, and any software used must be open source and freely available for examination.
2) It has to be anonymous. There must not be any way that someone can systematically determine which voter cast which ballot.
3) It has to be verifiable. Specifically, there has to be a paper trail of some sort that can be re-examined and re-counted.
It should also be reliable, scalable, and as inexpensive as possible.
The requirement for verifiability to rule out "lever voting machine" or "touch screen" voting machines, as neither produces a per-voter paper document. We all know about the problems with hanging chads, so "punch voting" is also out.
The system that seems most promising to me is an "optical scan" system similar to the one used where I vote. Its main drawback, it seems to me, is that it provides no feedback to the voter. How do I know that it accurately read my ballot and counted my votes the way I intended?
For that reason, I propose that the new voting process utilize:
1) an optical scanner. Although the scanner used where I vote feeds itself and looks special-purpose, I know of no reason that this could not be a simple page scanner, if that would significantly reduce costs.
2) a computer system to run the open-source software which controls the scan, picks off the votes, validates the ballot (see below), and accumulates the totals for those ballots which have been accepted.
3) a display monitor, properly positioned and shielded to show the voter (and no one else) a summary of the votes that the software recognized. It should provide the user with a button (via either a touch screen or a separate input device (see below)) to either "ACCEPT" or "REJECT" the ballot results.
A display monitor should be used for this validation step, rather than a printed receipt, for the same reason that ballots cannot be brought into the precinct - to discourage "vote buying". Disallowing outside ballots prevents vote buyers from pre-marking ballots; disallowing printed receipts denies vote buyers any evidence that a voter actually cast his vote the way the vote buyer demands. A display monitor also has the advantage of being faster, cheaper, and easier to manage than a receipt printer would be.
4) (optional) a separate input device. This could simply be a keyboard with the "A" key painted green (for "ACCEPT") and the "R" key painted red (for "REJECT").
When the voter makes his selection, precinct workers must be informed of that choice through some means. Possibly, this could be as simple as generating one of two clearly distinguishable audible tones: perhaps a gentle "ding" for "ACCEPT", and a harsh "blat" for "REJECT".
If the displayed votes are "ACCEPT"-ed, then the process is complete. A precinct worker should take the ballot, face down, and put it in a box of accepted ballots. This should occur in clear view of the voter. This box (or set of boxes) filled with accepted ballots provides a verifiable trail that can be re-scanned and re-counted should any question of irregularity arise.
On the other hand, if the displayed votes are "REJECT"-ed, a precinct worker should take the ballot, immediately shred it, and increment a count of spoiled ballots. This count, added to the number of accepted ballots, should be equal to the total number of ballots distributed: an additional check to detect voter fraud.
The rejecting voter is then offered the opportunity to re-vote, receiving a new ballot and going to the front of the voting line. There should be no limit to the number of times which a voter may reject his ballot.
If the voter declines to re-vote, then the precinct worker should increment a count of frustrated voters. This count, added to the number of accepted ballots, should be equal to the number of registered voters admitted by this precinct: an additional check to detect voter fraud.
None of this prevents fraud by precinct workers, of course. However, fraud should be controllable by other procedural means. Specifically, two precinct workers, one each from opposing political parties, should perform each step of the election process, together all times. Because they are politically opposed, one will immediately expose any attempt at voter fraud by the other.
That still leaves the possibility of human error. Controlling this must be the responsibility of all participants. However, the open source software that scans ballots and counts software should help at least this much:
1) It should display the number of ballots accepted so far. The first voter of the day knows that he or she is the first voter. If the counters are improperly reset (or if the ballot box is "stuffed" prior to the first voter) the first voter will notice and complain.
Similarly, the last voters are aware that they are last. If the number of voters per precinct is made available to the public (printed in the newspaper or published on a website), one of these last few voters will notice if the numbers are substantially different than the number they saw when they voted, and will complain. Even if they do not notice, the risk that they might should be enough to prevent anyone from risking voter fraud by discarding ballots, or "stuffing the ballot box" after the precinct has closed.
2) It should display a version number and some sort of checksum for the software in use. If this information is made public prior to the election, concerned citizens may well bring this information into the precinct with them, and use it to check the software before they let their ballot be scanned. This behavior would help ensure that unofficial versions of software are not accidentally used.
This behavior may help also help to discourage deliberate tampering. However, tampering of this kind is not entirely preventable through such means. Instead, procedural rules such as the one described above must be employed. Specifically, the software should only be acquired and installed in the presence of two persons of opposing party. If the software is already acquired, they should independently verify the size, date, and checksums of the software before allowing it to be installed. Both of these persons must be adequately qualified to perform these tasks.
What remains to make this proposal a reality is the existence of suitable open-source software to meet these requirements. Software or adequate documentation is also required to assist ballot creators in the process of generating scan-able ballots.
Technically, such an effort is not particularly challenging. However, the requirement for the software to be extremely reliable is something of a challenge, as is the meta-requirement that the software source code be as easy as possible to read and review. More importantly, challenging or not, this is an important task - one which will help to restore America's confidence in its voting process.
