Gold or Pyrite?

In a couple of prior posts, I explained the “gold copy” or “trusted build” concept, and the role of EAC, NIST, and test labs. I can’t seem to completely bury this tale, because it raised another question about the processing of checking a voting system to see if it is legit: “Why is this checking so hard? Is the government doing its job here?”

Yes, the government is doing its job, in that voting system products are tested, and theoretically the test results include fingerprint data the theoretically an election official could use effectively. That’s the general idea. Now, I am not saying that the current test lab approach is great. It isn’t, and it lacks transparency among several other defects. Nevertheless, if there were a certified system that you trusted, then the independent test process can in fact use some techniques to fingerprint the system tested, so that you could compare a government-certified fingerprint of your system to see if it was exactly the same as the tested system. It’s just that with the current voting devices, the checking is  impractical and — if done without some very-difficult-to-achieve auditable physical security measures — almost meaningless. But that’s old news from old posts.

The remaining question for today is why current systems are impractical for checking. What is it with these existing voting systems? They are not easily validated because in most cases they simply weren’t designed for it. Validation was not required and few though it important at the time (the post-HAVA gold rush). Then, once a system is built, you really can’t go back and tack on a “field validation” feature. The government regulatory groups do not want to “change the rules” on the vendors — in part for the very good reason that the existing Gold-Rush-era rules (the Voluntary Voting System Guidelines of 2002, the year HAVA was enacted) are the current rules that are still in-process for revision. So for the foreseeable future, there is no pragmatic reason for existing systems to change.

And that brings us back to a frequent theme that shows the real benefit of openness: public benefit. Existing systems weren’t built to be validated; it’s expensive to re-architect and re-implement the systems; for-profit vendors have no incentive to do so; hence, trust benefits can only be expected to be delivered by people doing work on tech that must be to be delivered and maintained in the public trust by a public interest organization, in order to maintain public confidence.

— EJS