A good question re-surfaced for us as we participated in the National Civic Summit recently. The issue was and remains about identifying a "gold build," that is, when there is a particular system/version that is certified for use as a voting system, how should election officials know that the systems that they deployed are systems that are an instance of the certified system. Previously, we provided some answers of how you could answer the question "How do I know that this voting machine is a good one" and provide in the wiki on a more technical treatment of "field validation" of voting system devices. But the  slightly different question that arose recently is: how does open source help?

The simple answer is that  open source techniques do not directly help at all. We could build a completely open system that has exactly the same architectural blockades to field validation as the current vendors' product do. However, the TrustTheVote open source project has some advantages. First, we're working on voting systems, which have sufficiently simple functional requirements (compared to general purpose computing systems) that field validation of voting devices isn't as difficult as in the more general case. *

The second advantage allows us to sidestep many of these complexities, given the relative simplicity of voting devices. We were able to  go back to the drawing board and use an architecture that simplifies the field validation problems, for the very specific and limited class of systems that are voting devices.

Openness itself didn't create these two advantages; but in conducting a public works project, we have the freedom to start fresh and avoid basic architecture pitfalls that can undermine trust. Therefore, the value of working openly is that the benefit of this work -- increased confidence and trust -- is a bit more easily achieved because field validation is fundamentally a systems trust issue, and we address in a way that can be freely assessed by anyone. And that's where the open source approach helps.

-- EJS

* NOTE: for the detail-oriented folks: in general, the twin problems of Trusted Software Distribution and Trusted System Validation are, in their general form, truly hard problems. Feasible approaches to them usually rely on complex use of cryptography, which simply shifts the burden to other hard problems in practical applied cryptography. For example, with "code signing" my Dad's computer can tell him that it thinks he should trust some new software because is it signed as being from his SW vendor (e.g., Microsoft or HP); but he wonders (rightly) why he should trust his computer's judgment in this matter, given the other mistakes that his computer makes. For more on the non-general voting-system-friendly solution, see the TrustTheVote wiki: https://wiki.trustthevote.org/index.php/Field_Validation_of_Voting_Systems