seeking clarity on ‘Software independence’ in voting systems

In response to the Timothy Ryan op-ed “A Damaging Paper Chase In Voting”, Rick Carback (one of the punchscan developers) wrote about HR811:

…the article makes an excellent point — mandating a specific technology (which has been known to be problematic since the inception of voting) is a bad idea. By contrast, the authors of the bill could have taken the approach of Software Independence, where the outcome of an election can be determined independently of a piece of software. Any software independence approach would rule out paperless DREs, a hidden audit trail printout, and other ill-conceived technology. DREs with unreliable printers for a VVPAT approach could also be excluded, but you would need to add a reliability requirement (not hard to do). Our system, and similar systems like PAV, would more easily fit into such a definition.

From the eWeek article referenced:

The Technical Guidelines Development Committee, a committee appointed by the Election Assistance Commission to study security issues involving electronic voting, voted on Dec. 5 to recommend a move to software independence in voting machines used in the United States.
…
Software independence means that election results can be determined independently of whether voting machines have software problems or had their security penetrated.
An example of such software independence would be with machines that use voter verifiable paper audit trails.
The committee vote recommended that NIST (National Institute of Standards and Technology) develop standards for such software independent machines. However, the committee stopped short of recommending that existing machines that are certified under the EAC’s best practices be decertified.
…
The EAC still has to approve whatever the TGDC comes up with by July, and that will be followed by a public comment period, and this is the first step in something that probably will not come out until March of 2008, Norden said, adding that some types of voting systems that can’t be verified or audited, such as the old mechanical lever systems, are already on their way out.

I find several aspects of the recommended software independence policy confusing. I suspect that if I found some language closer to the actual policy proposal I would understand better.

But here goes:

• Does the policy of software independence apply to systems that do not use software in the interaction of the voter with the voting system? The reference to level systems not passing the policy suggests that it does.
• If the TGDC recommendations were made policy would that prevent a jurisdiction from switching back to a system that they used to use if they had problems with a new one? For example, a jurisdiction may have troubles with electronic voting machines and want to revert back to mechanical lever or punchcard systems. Perhaps the grandfathering rules ought to tolerate reversions.
• Independant verification by whom? The example cited was a voter verified audit trail. Is the verification always by the voter?
• What is considered an acceptable independant verification? Take the example that the article cited: a voter verified audit trail.But that still yields a hackable system. Some potential problems:
  • What is the proceedure when the voter rejects the displayed audit receipt? How are patterns of problems noticed and reported on?
  • Several studies have demonstrated that many voters do not validate their votes.
  • A machine can easily print a receipt that disagrees with it’s actual behavior
  • Machines can be set up to print bogus audit trails that match bogus votes
  • When are the audit trails examined and compared to the tallies in the voting machines?