Where Open Source Requirements Fail in Voting Technology

It may surprise some readers to learn that
there 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