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?

4 responses to “seeking clarity on ‘Software independence’ in voting systems

  1. I will point out that it is an idea that is still being developed: “The committee vote recommended that NIST (National Institute of Standards and Technology) develop standards for such software independent machines.” That’s not to say the bill couldn’t touch on a lesser form of it that would get rid of obviously bad ideas.

    You should check the NIST site for more info, it will likely explain the idea better:

    As for your questions, it would have been better to use numbering, but I’ll just pretend.

    Re 1) Yes — a better name might be “Independent Verification”.

    Re 2) No, so long as that system fell under the policy.

    Re 3) I think it depends on what step in the process you are in, but the idea is that at any point in the process, you should be able to check what the machine is doing. I’d read up on it via the NIST site.

    Re 4) I don’t think the idea is to make the system completely unhackable, but rather, not to permit designs that make it undetectable or worse.

    Regarding the machine misprinting, the brennan center reports point out a good fact that if the machine “plays along” and then displays/prints the wrong thing at the end of the voting session, not many people are going to catch that, and if they do, they are more likely to think that they messed up rather than the machine.

  2. The election technology blog has posted a reply to this:

  3. Looks like someone beat me too it, but I was coming to let you know about my response at the ETL Blog.

  4. Joseph Hall has posted Some comments and corrections to “Clarity on ‘Software independence’ in voting systems”.

    I still have not taken the time to review the original materials.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s