Where Open Source Requirements Fail in Voting Technology

It may surprise some readers to learn thatthere is one election technology reform situation where we are not in favor of open source as a solution.  Yes, you read that right.

This issue arose during our recent visit with the Congressional Internet Caucus in DC (we discussed this event in previous posts).  The idea of requiring current election systems vendors to disclose source code was raised in hallway discussions.  And believe it or not, we actually think that is not a great idea.  Policy wonks listening in grew perplexed looks on their faces – it was great! (You can see why we avoid advocacy work. :-)  Cooler tech heads listening in, I think, got it as we went on.

So this is a joint post more or less between myself, and our CTO, John Sebes, who offers some important insight.

What we do know is a good idea, is that future election systems should be trustworthy as a result of several factors, including published source code, open independent testing, and features for operational disclosure that enable public transparency.  And of course, we're working on that.

But in the mean time we are not so sure about the importance of compelling source code disclosure of proprietary systems.  And to be clear, we take “compelled” to mean some government regulation requiring public disclosure of heretofore “proprietary intellectual property.”  That’s the short story.  If you want to know why, John offers a fuller disclosure on this position that I've incorporated below.   Yes, some may argue we’re walking an advocacy line here, but if a policy maker is actually reading this (thank you for that), we’re simply suggesting what we believe and how it applies to our work on the TrustTheVote Project. In any event, we simply cannot reduce this to a wire feed write-byte, so apologies for the length of what follows.

OK. Here we go; strap in.  So, we believe that a fundamental goal in election technology reform ought to be to increase public confidence in technology and its use in elections.

Certainly we've seen that parts of current election technology which voting system products employ today, has had a negative impact on confidence. Would disclosure of those products' source code actually help that confidence?  Not so much, especially if it is required in spite of the vendors’ wishes (read: regulatory requirement). There are pros and cons about such disclosure, and if the vendors wanted to publish source code (without giving up proprietary rights, of course) then it might change our opinion.  But they don't want to, and that's where we are.

But wait a minute; let’s back step. What is source code disclosure supposed to accomplish, with respect to confidence and trust anyway?  Well, as our CTO expresses it, “source code disclosure is one important ingredient in a recipe for public trust of election technology (including voting systems).”  But prerequisites for this trust are that one must [a] have a specific system you claim is reliable and accurate (or whatever else you want it to be trusted for), and [b] which has been shown in practice to have these properties. Source code disclosure can then be used with various other assurance techniques (independent testing, code analysis, etc.) to help convince people that the system can be relied upon to continue to behave in a way that supports the claims.

Current election system products have a mixed record in demonstrating reliability in accuracy. And they've gotten a bad rep.  And whether or not that reputation is fully deserved (that’s for others to wrangle), reputation is part of trust.  And further, current products have not yet been shown to be amenable to other ingredients, such as independent testing and source code review (without public disclosure).  In fact, there is not one existing system today that has passed testing for the current Federal guidelines, with the current NIST-managed independent testing scheme. So it doesn't make obvious sense to us to require one ingredient of trust, when other ingredients don't seem to be available.

That being the case, we just can't see how required disclosure is a great idea. However, we understand that many people seek other outcomes (besides public trust) from disclosure of source code of current election system products. There may be some pros to doing so.  But our CTO is pretty sure (from my listening to him in D.C.) that there are cons, starting with the likelihood that some folks will pile on with claims of previously undisclosed software problems – and a lot of arguing over whether those claims are valid.  Some will be, some won't be, and the din will further erode confidence without actually making the products any better.  Likewise, there would be claims that customized attacks on the software ("hackers steal election, film at 11" etc.) would be enabled, with arguments against such claims – again with public confusion. To be sure, we’re talking about the effects on perception here, not prognosticating about "facts" that might be revealed.  If a combined 30 years of software product management has taught us anything, we know perception is part of confidence and perception is 90% of the perceiver’s reality – like it or not.

Lastly, we know (because to thicken the plot, I have been wading in technology policy for years) there are legal and policy issues (for which we won't dive into that rat-hole here) about compelling for-profit companies to give up what they believe are valuable proprietary rights resulting from lots of work and money used to create proprietary software, for which they believe is essential to their business model.

And gentle readers, but it doesn't matter whether we share that belief.  If commercial vendors believe in that value, and the government takes it away by regulatory force, then seems like such will open a policy Pandora’s Box.  And because as we’ve observed, such a “takings” would have negative as well as positive side-effects, it's hard for us this say this would actually be a great idea; maybe a good idea, or an OK idea, but not an obvious winner.

So, as “bass-ackward” as it may seem, we can't find grounds for supporting or opposing compelling such disclosure (OK, yes that was a fragment of a sentence; imagine you’re hearing it instead). For future systems, such as what the TrustTheVote Project is working on, then certainly.  Of course, John’s open-source knee is jerking, but his public-confidence hand is on top ;-) Sorry that this isn't a simple issue, and that our (yipes, dare I utter) “position” explanation isn't short.

What do you think?  Your ball.

Greg & John