Tagged trustworthy voting

Voter registration problems in Maryland signal larger vulnerabilities for upcoming elections

Binary data disappears in a dark hole

Voter registration data lost in Maryland

This Monday, state officials in Maryland acknowledged that problems with their “motor voter” systems are more significant than originally described:

[A]s many as 80,000 voters — nearly quadruple the original estimate — will have to file provisional ballots Tuesday because the state Motor Vehicle Administration failed to transmit updated voter information to the state Board of Elections.

— Up to 80,000 Maryland voters will have to file provisional ballots, state says (Washington Post. 6/25/18)

This announcement, made only hours before the polls opened for Maryland’s Tuesday primary, will mean more than just a minor inconvenience for the tens of thousands of voters affected. Sen. Joan Carter Conway (D-Baltimore City), chairwoman of the Senate Education, Health and Environment Committee, said that this situation will “confuse voters, suppress turnout, and disenfranchise thousands of Marylanders.”

Yet the significance of this programming error is broader still. Sen. Richard S. Madaleno Jr. (D-Montgomery), who is also running for governor of Maryland, called the incorrect registration of thousands of voters a “catastrophic failure.” In his statement, he continued, “The chaos being created by this failure subjects real harm to our most cherished democratic values,”

Is this election season hyperbole? Not at all, says John Sebes, Chief Technology Officer of the OSET Institute (the organization that runs the Trust The Vote project). In his recent article, Maryland Voter Registration Glitch: A Teachable Snafu, Mr. Sebes identifies the wide-ranging problems that will follow from these kind of disruptions at a larger scale:

If a foreign adversary can use cyber-operations to maliciously create a similar situation at large scale, then they can be sure of preventing many voters from casting a ballot.  With that disruption, the adversary can fuel information operations to discredit the election because of the large number of voters obstructed.

— John Sebes, OSET Institute

It is, in fact, the credibility of the entire election itself that is at stake. These kinds of technical problems don’t need to be the result of nefarious interference in the election process. Mr. Sebes continues,

The alleged system failure (hack, glitch, or whatever) doesn’t even need to be true!  If this accidental glitch had occurred a couple of days before the November election, and came on the heels of considerable conversation and media coverage about election hacking, rigging, or tampering then it would be an ideal opportunity for a claimed cyber-attack as the cause, with adversaries owning the disruptive effects and using information operations to the same effect as if it were an actual attack.

—  Maryland Voter Registration Glitch: A Teachable Snafu by John Sebes

Maryland is clearly vulnerable to this kind of attack on the credibility of their electoral process. Already, some are sounding the alarm that these voter registration problems weren’t identified quickly — plus, there’s no way to verify the process itself:

Damon Effingham, acting director of the Maryland chapter of Common Cause, said it was “preposterous” that it took MVA officials four days to figure out the extent of the problem and that there is no system to ensure that its system is working properly.

— Up to 80,000 Maryland voters will have to file provisional ballots, state says (Washington Post. 6/25/18)

What’s the solution?

John Sebes and the Trust The Vote project have spent years developing open source election software and systems to address these issues. But that alone isn’t sufficient. Mr. Sebes identifies the steps that election officials can take now to prevent the kind of problems that Maryland is experiencing this week:

  • “It’s partly a technology effort to re-engineer election systems to be less fragile from errors and less vulnerable to attack.”
  • “How to ensure the correctness and integrity of poll books[?] … that depends on emerging open data standards and the question of certification of poll books.”
  • “Given the great importance of public credibility … election officials must also plan for proactive public communication.”

Mr. Sebes concludes:

The Maryland glitch is not so much about failed integration of disparate data systems, but much more about unintentional catalyzing of opportunities to mount “credibility attacks” on elections and the need for a different kind of preparation.

Read the full article, Maryland Voter Registration Glitch: A Teachable Snafu by John Sebes, on the OSET Institute website.

The OSET Institute runs the TrustTheVote Project, a real alternative to nearly obsolete, proprietary voting technology. TrustTheVote is building an open, adaptable, flexible, full-featured and innovative elections operating system called ElectOS. It supports all aspects of elections administration and voting including creating, marking, casting, and counting ballots, as well as managing all back-office functions. Check out this overview of the TrustTheVote Project to learn more. If you’re involved in the election process, as an election official, or an academic or researcher, join the TrustTheVote Project as a stakeholder to help develop and deploy open, secure, reliable, and credible election technologies. If you’re concerned about the health of our election systems, you can donate or volunteer. If you have any questions about the TrustTheVote Project, contact us today.

Another Laudable Online Voting Architecture Concept But…

Recently, we were asked about a concept authored by a former technology executive at Citrix (yes, those folks) back in 2012 regarding a potential end to end secure voting system.  But that was actually part of a larger question: whether and to what extent digital security must now live beneath the operating system software layer rather than on top of it.  The author’s ideas for an online voting system are laudable and his credentials are credible. His follow-on article last year (2015) is interesting, and more to the point of hardware-level security alluded to in the first article.  I offer a couple of comments below including some points by our CTO on this approach because it is something baked into ElectOS.

First, we agree that a hardware root of trust is an essential ingredient for any trustworthy computing device running mission critical software.  The author, Ahmed Sallam (now CEO at DeepSAFE Technology) rightly points that out, but we doubt that Citrix has an existing product that can safely run an Internet Voting client.  We’d love to be proven wrong on that, but it does not change the fact that the core problem is one of successfully combining many ingredients.  This is one of the well known ingredients.

There is, from my perspective a well-developed and detailed technical white paper providing a worked example of a hardware root of trust from Apple for its iOS mobile operating system.  This hardware rooted security layer has allowed Apple to develop Apple Pay and their biometric authentication management system (you can see a very good overview video here (may require Safari Browser to watch) of how it works).  For those wishing to dive deeper, here is the NIST Draft Guidelines for Hardware Rooted Security in Mobile Devices.

At a deeper level of detail, our CTO (John Sebes) agrees with the technical architecture for the server side, but he believes that for the client side, Ahmed’s approach is a bit of overkill.  As John observes, “If I understand it right, the Sallam model seeks to allow trusted and un-trusted code to run on a device, with a full operating system and all.”

So, the client architecture that John and the TrustTheVote Project have been advocating from the beginning, starts with a consumer device that has a hardware root of trust and a hypervisor that can validate a boot image as coming from a trustworthy source. John reports that we nearly have that today.  And it has to have the ability to do both:

  • a normal local boot into a full service mobile device OS to work as a phone browser, etc.; and
  • a boot from an external physical device with the boot image for something else.

One such “something else” will probably be a banking App, but the one we’re interested in is a Voting (ballot casting) App — with a single purpose: it runs only that one App and the SW stack under it, immune to malware, etc.  That’s not even that hard, but there are interesting PKI (Public Key Infrastructure) issues for ensuring that a given voting App is the real {authentic | authorized} voting App, and performing strong authentication of the user-voter, etc.

Now for the “But…” part of this.  Fundamentally, we agree with Ahmed’s vision and concept; however, Citrix will be a potential player in the iVoting technology arena if and only if it is a major player in the mobile computing technology computing ecosystem.  From what we can tell, Citrix is moving in that direction.

So to summarize, at the end of the day,

  1. Do we believe Citrix has a solution for iVoting? No.
  2. Do we believe the author of both articles referenced here, Ahmed Sallam (now since departed from Citrix and CEO of DeepSAFE) has a credible vision and concept for online voting? Yes.
  3. Do we believe that concept is complete and in terms of what we understand about the totality of the problem? No.
  4. Will the hardware root of trust (hardware layer security below the operating system), such as the elegant model embodied in iOS and articulated by the NIST Guidelines be a key ingredient going forward? Yes.
  5. Are we (anyone) there yet for a voting App/system? No.

Voting Heartburn over “Heartbleed”

Heartbleed is the latest high-profile consumer Internet security  issue, only a few weeks after the “Goto Fail” incident. Both are recently discovered weaknesses in the way that browsers and Web sites interact. In both cases and others, I’ve seen several comments that connect these security issues with Internet voting. But because Heartbleed is pretty darn wicked, I can’t not share my thoughts on how it connects to the work we do in the TrustTheVote project — despite the fact that i-voting is not part of it. (In fact, we have our hands full fixing the many technology gaps in the types of elections that we already have today and will continue to have for the foreseeable future.)

First off, my thanks to a security colleague Matt Bishop who offered an excellent rant (his term not mine!) on Heartbleed and what we can learn from it, and the connection to open source. The net-net is familiar: computers, software, and networks are fundamentally fallible, there will always be bugs and vulnerabilities, and that’s about as non-negotiable as the law of gravity.

Here is my take on how that observation effects elections, and specifically the choice that many many U.S. election officials have made (and which we support), that elections should be based on durable paper ballots that can be routinely audited as a cross check on potential errors in automated ballot counting. It goes like this:

  • Dang it, too many paper ballots with too many contests, to count manually.
  • We’ll have to use computers to count the paper ballots.
  • Dang it, computers and software are inherently untrustworthy.
  • Soooo ….  we’ll use sound statistical auditing methods to manually check the paper ballots, in order to check the work of the machines and detect their malfunctions.

This follows the lessons of the post-hanging-chads era:

  • Dang it, too many paper ballots with too many contests, to count manually.
  • We’ll have to use computers to directly record votes, and ditch the paper ballots.
  • Dang it, computers and software are inherently untrustworthy.
  • Oops, I guess we need the paper ballots after all.

I think that these sequences are very familiar to most readers here, but its worth a reminder now and then from experts on the 3rd point — particularly when the perennial topic of i-voting comes up– because there, the sequence is so similar yet so different:

  • Dang it, voters too far away for us to get their paper ballots in time to count them.
  • We’ll have to use computers and networks to receive digital ballots.
  • Dang it, computers and software and networks are inherently untrustworthy.
  • Soooo …. Oops.

— EJS

A Northern Exposed iVoting Adventure

NorthernExposureImageAlaska’s extension to its iVoting venture may have raised the interests of at least one journalist for one highly visible publication.  When we were asked for our “take” on this form of iVoting, we thought that we should also comment here on this “northern exposed adventure.” (apologies to those fans of the mid-90s wacky TV series of a similar name.)

Alaska has been among the states that allow military and overseas voters to return marked absentee ballots digitally, starting with fax, then eMail, and then adding a web upload as a 3rd option.  Focusing specifically on the web-upload option, the question was: “How is Alaska doing this, and how do their efforts square with common concerns about security, accessibility, Federal standards, testing, certification, and accreditation?

In most cases, any voting system has to run that whole gauntlet through to accreditation by a state, in order for the voting system to be used in that state. To date, none of the iVoting products have even tried to run that gauntlet.

So, what Alaska is doing, with respect to security, certification, and host of other things is essentially: flying solo.

Their system has not gone through any certification program (State, Federal, or otherwise that we can tell); hasn’t been tested by an accredited voting system test lab; and nobody knows how it does or doesn’t meet  federal requirements for security, accessibility, and other (voluntary) specifications and guidelines for voting systems.

In Alaska, they’ve “rolled their own” system.  It’s their right as a State to do so.

In Alaska, military voters have several options, and only one of them is the ability to go to a web site, indicate their choices for vote, and have their votes recorded electronically — no actual paper ballot involved, no absentee ballot affidavit or signature needed. In contrast to the sign/scan/email method of return of absentee ballot and affidavit (used in Alaska and 20 other states), this is straight-up iVoting.

So what does their experience say about all the often-quoted challenges of iVoting?  Well, of course in Alaska those challenges apply the same as anywhere else, and they are facing them all:

  1. insider threats;
  2. outsider hacking threats;
  3. physical security;
  4. personnel security; and
  5. data integrity (including that of the keys that underlie any use of cryptography)

In short, the Alaska iVoting solution faces all the challenges of digital banking and online commerce that every financial services industry titan and eCommerce giant spends big $ on every year (capital and expense), and yet still routinely suffer attacks and breaches.

Compared to the those technology titans of industry (Banking, Finance, Technology services, or even the Department of Defense), how well are Alaskan election administrators doing on their shoestring (by comparison) budget?

Good question.  It’s not subject to annual review (like banks’ IT operations audit for SAS-70), so we don’t know.  That also is their right as a U.S. state.  However, the  fact that we don’t know, does not debunk any of the common claims about these challenges.  Rather, it simply says that in Alaska they took on the challenges (which are large) and the general public doesn’t know much about how they’re doing.

To get a feeling for risks involved, just consider one point, think about the handful of IT geeks who manage the iVoting servers where the votes are recorded and stored as bits on a disk.  They are not election officials, and they are no more entitled to stick their hands into paper ballots boxes than anybody else outside a
county elections office.  Yet, they have the ability (though not the authorization) to access those bits.

  • Who are they?
  • Does anybody really oversee their actions?
  • Do they have remote access to the voting servers from anywhere on the planet?
  • Using passwords that could be guessed?
  • Who knows?

They’re probably competent responsible people, but we don’t know.  Not knowing any of that, then every vote on those voting servers is actually a question mark — and that’s simply being intellectually honest.

Lastly, to get a feeling for the possible significance of this lack of knowledge, consider a situation in which Alaska’s electoral college votes swing an election, or where Alaska’s Senate race swings control of Congress (not far-fetched given Murkowski‘s close call back in 2010.)

When the margin of victory in Alaska, for an election result that effects the entire nation, is a low 4-digit number of votes, and the number of digital votes cast is similar, what does that mean?

It’s quite possible that those many digital votes could be cast in the next Alaska Senate race.  If the contest is that close again,  think about the scrutiny those IT folks will get.  Will they be evaluated any better than every banking data center investigated after a data breach?  Any better than Target?  Any better than Google or Adobe’s IT management after having trade secrets stolen?  Or any better than the operators of military unclassified systems that for years were penetrated through intrusion from hackers located in China who may likely have been supported by the Chinese Army or Intelligence groups?

Probably not.

Instead, they’ll be lucky (we hope) like the Estonian iVoting administrators, when the OCSE visited back in 2011 to have a look at the Estonian system.  Things didn’t go so well.  OCSE found that one guy could have undermined the whole system.  Good news: it didn’t happenCold comfort: that one guy didn’t seem to have the opportunity — most likely because he and his colleagues were busier than a one-armed paper hanger during the election, worrying about Russian hackers attacking again, after they had previously shut-down the whole country’s Internet-connect government systems.

But so far, the current threat is remote, and it is still early days even for small scale usage of Alaska’s iVoting option.  But while the threat is still remote, it might be good for the public to see some more about what’s “under the hood” and who’s in charge of the engine — that would be our idea of more transparency.

<soapbox>

Wandering off the Main Point for a Few Paragraphs
So, in closing I’m going to run the risk of being a little preachy here (signaled by that faux HTML tag above); again, probably due to the surge in media inquiries recently about how the Millennial generation intends to cast their ballots one day.  Lock and load.

I (and all of us here) are all for advancing the hallmarks of the Millennial mandates of the digital age: ease and convenience.  I am also keenly aware there are wing-nuts looking for their Andy Warhol moment.  And whether enticed by some anarchist rhetoric, their own reality distortion field, or most insidious: the evangelism of a terrorist agenda (domestic or foreign) …said wing nut(s) — perhaps just for grins and giggles — might see an opportunity to derail an election (see my point above about a close race that swings control of Congress or worse).

Here’s the deep concern: I’m one of those who believes that the horrific attacks of 9.11 had little to do with body count or the implosions of western icons of financial might.  The real underlying agenda was to determine whether it might be possible to cause a temblor of sufficient magnitude to take world financial markets seriously off-line, and whether doing so might cause a rippling effect of chaos in world markets, and what disruption and destruction that might wreak.  If we believe that, then consider the opportunity for disruption of the operational continuity of our democracy.

Its not that we are Internet haters: we’re not — several of us came from Netscape and other technology companies that helped pioneer the commercialization of that amazing government and academic experiment we call the Internet.  Its just that THIS Internet and its current architecture simply was not designed to be inherently secure or to ensure anyone’s absolute privacy (and strengthening one necessarily means weakening the other.)

So, while we’re all focused on ease and convenience, and we live in an increasingly distributed democracy, and the Internet cloud is darkening the doorstep of literally every aspect of society (and now government too), great care must be taken as legislatures rush to enact new laws and regulations to enable studies, or build so-called pilots, or simply advance the Millennial agenda to make voting a smartphone experience.  We must be very careful and considerably vigilant, because its not beyond the realm of reality that some wing-nut is watching, cracking their knuckles in front of their screen and keyboard, mumbling, “Oh please. Oh please.”

Alaska has the right to venture down its own path in the northern territory, but it does so exposing an attack surface.  They need not (indeed, cannot) see this enemy from their back porch (I really can’t say of others).  But just because it cannot be identified at the moment, doesn’t mean it isn’t there.

</soapbox>

One other small point:  As a research and education non-profit we’re asked why shouldn’t we be “working on making Internet voting possible?”  Answer: Perhaps in due time.  We do believe that on the horizon responsible research must be undertaken to determine how we can offer an additional alternative by digital means to casting a ballot next to absentee and polling place experiences.  And that “digital means” might be over the public packet-switched network.  Or maybe some other type of network.  We’ll get there.  But candidly, our charge for the next couple of years is to update an outdated architecture of existing voting machinery and elections systems and bring about substantial, but still incremental innovation that jurisdictions can afford to adopt, adapt and deploy.  We’re taking one thing at a time and first things first; or as our former CEO at Netscape used to say, we’re going to “keep the main thing, the main thing.”

Onward
GAM|out

ATOMS=GOOD, ELECTRONS=BAD?

Seems to me that I’ve seen more interesting videos, alarming articles, and research studies of problems with e-voting than with old-fashioned hand-count paper ballot elections. We hear about many ways and reasons to doubt election results that use machines in some part of the process, and about how “all manual count” elections are the “gold standard.” Good soundbites.

But I wonder:

Are there actually any elections that are “all manual”?

I don’t think so. Certainly the tabulation of results, the transport of results up the chain, the tracking of warehouses full of ballots, the design of ballots, the collection of voter registrations, and the creation and management of poll books, must use computers all along the chain. Is there a single state or county where computers are used for none of these activities? I suspect not.

So, where are the cool videos and PR campaigns illustrating the ways in which an all manual count could be compromised? I’ve seen magicians do some impossible things while manipulating pieces of paper. And there are a lot of magicians.

And by the way, we also use computers… to control whether and in what direction to launch missiles,  to control the brakes in my car (oops, bad example :),  to “land a man on the moon”, and of course our whole financial system only exists inside of the black boxes that are called computers.

Yeah I know the litany of differences between these applications and elections. I am well aware of them. But the differences don’t stop me from questioning the ultra-black-and-white, ultra-soundbite, that I hear all the time:

computers/internet=BAD, manual/physical=GOOD

It might as well be

atoms=GOOD, electrons=BAD

I know as a society we don’t like nuance, but as people who are devoted to making things better, techies and non-techies alike, I’d like to see and read fewer statements like: “We will never ever do X”, “Y is the absolute only way to do this.”

Things are never that black and white. And while we may need to keep it simple to win the argument, it’s more than about just winning the argument. It’s about discovering real weaknesses (and there are always trade-offs — I can hear the black-and-white crowd saying: “We should not ever make ANY trade-offs when it comes to our Democracy”, which is my point, exactly) and so we should always be seeking honest ways of imagining and testing to discover true improvements.

How to Trust a Voting Machine

[Today’s guest post is from election technology expert Doug Jones, who is now revealed as also being an encyclopedia of U.S. elections history. Doug’s remarks below were in a discussion about how to effectively use post-election ballot-count audits as a means to gain trust in the correct operation of voting machines — particularly timely, given the news and comment about hacking India’s voting machines. Doug pointed out that in the U.S., we’ve had similar voting-machine trust issues for many years. — ejs]

Lever machines have always (as used in the US) contained one feature intended for auditing:  The public and protective counters, used to record the total number of activations of the machine.  Thus, they are slightly auditable.  They are less auditable than DRE machines built to 1990 standards because they retain nothing comparable to an event log and because they do not explicitly count undervotes — allowing election officials to claim, post election, that the reason Sam got no votes was because people abstained rather than vote for him.  (Where in fact, there might have been a bit of pencil lead jammed in the counters to prevent votes for Sam from registering).

One of the best legal opinions about mechanical voting machines was a dissenting opinion by Horatio Rogers, a Rhode Island supreme court judge, in 1897.  He was writing about the McTammany voting machine, one that recorded votes by punching holes in a paper tape out of view of the voter.  I quote:

It is common knowledge that human machines and mechanisms get out of order and fail to work, in all sorts of unforseen ways. Ordinarily the person using a machine can see a result.  Thus, a bank clerk, performing a check with figures, sees the holes; an officer of the law, using a gibbet by pressing a button, sees the result accomplished that he sought; and so on ad infinitum. But a voter on this voting machine has no knowledge through his senses that he has accomplished a result.  The most that can be said is, if the machine worked as intended, then he has made his holes and voted.  It does not seem to me that this is enough.

I think Horatio Rogers opinion applies equally to the majority of mechanical and DRE machines that have been built in the century since he published it.

— Doug Jones

Mandatory disclaimer:  The opinions expressed above are mine!  The various institutions with which I am affiliated don’t necessarily agree.  These include the U of Iowa, and the EAC TGDC. – dj

OSDV Responds to FCC Inquiry about Internet Voting

The Federal Communications Commission (FCC) asked for public comment on the use of the Internet for election-related activities (among other digital democracy related matters).  They recently published the responses, including those from OSDV.  I’ll let Greg highlight the particularly public-policy-related questions and answers, but I wanted to highlight some aspects of our response that differ from some others.

  • Like many respondents, we commented on that slippery phrase “Internet voting”, but focused on a few of the specific issues that apply  particularly in the context of overseas and military voters.
  • Also in that context, we addressed some uses of the Internet that could be very beneficial, but are not voting per se.
  • We contrasted other countries’ experiences with elections and the Internet with the rather different conditions here in the U.S.

For more information, of course, I suggest reading our response. In addition, for those particularly interested in Internet voting and security, you can get additional perspectives from the responses of TrustTheVote advisors Candice Hoke and David Jefferson, which are very nicely summarized on the Verified Voting blog.

— EJS

To Trust or Not to Trust, That is the Question

I thought I’d share a comment and response I got about trusting software to count votes. The comment was a very sensible one, though a mis-perception: that TTV is suggesting that software should be trust to count vote correctly. Not so! Here is the true but less simple story.

  • Many election officials want to conduct elections with paper ballots.
  • Most of those election officials want to count paper ballots using optical scanning and analysis software.
  • Most of those election officials conduct statistical audits, in order to mitigate risk that the tabulation software malfunctioned in a way could have effected the election result.

In other words, the latter group of election officials don’t trust the software to do the vote counting right, and use selective hand-count audit in addition to software counting.

  • TTV development of scanning/tabulation software does not depend on the election officials’ choices on how to conduct audits as part of an optical scan/tabulation method.

In other words, we don’t make any assumptions about whether or how people trust software, and what additional non-technological steps they take to mitigate risk. To repeat what you may have heard me say before, we just make the technology; we don’t tell the administrators how to deal with the risks that they manage, but we do listen to them to make sure that we’re making technology that they can manage in the way that they want to. If their audit scheme can be improved by new features of the software, then we want to learn enough to provide features that are truly helpful.

— EJS

Banned in Germany, Part 2

In a recent post, I gave my view of a recent German High Court ruling that involved election technology.  It seems I may have confused some readers by talking about what was, in some sense, the side effect.  So, I should say a bit more about the main point.

Throwing out a recent election was the main point of the petition to the court.  The petitioners started with a premise — that the Nedap voting machines were unlawful for use in Germany — and reached a conclusion that the recent election using those machines was flawed and should be invalidated.

Petitioners lost.  The court declined to invalidate the election, although they did agree with the premise that the Nedap machines did not meet the requirements for comprehension by an ordinary person without specialist computing technical knowledge (my paraphrase of the requirement).

I wouldn’t be 100% certain until the next German election cycle shows us the Nedap system being completely tossed out, but it sure looks like Nedap and similar systems would under this ruling and opinion, be disallowed going forward.

So, to those who drew the conclusion that because the Court declined to invalidate the election meant that the underlying voting technology used remains “legal” (under German law), … I (and actual lawyer’s I’ve asked) respond, ” not so much.”

I also point out that the ruling provided some interesting speculation on what kinds of voting systems could or would meet the constitutional requirement for comprehensibility.  With many readers, opinions vary.

I already provided my guesses.  Others’ range from a ringing validation of e-voting including Internet voting, to a validation of the principle of “software independence” which has been under discussion in the EAC for some years.  That’s a pretty wide range of opinion!

But I’m not the lawyer in the OSDV Foundation family (nor do I play one on a blog), so I won’t effort to opine further on the jurisprudence of the  (foreign) court ruling, but I have to note that I really like the German election law’s principle that it is every citizen’s constitutional right to be able to understand the systems used to cast and count their ballots.  It’s a great goal for the TrustTheVote Project, as we develop election technology with transparency.

— EJS

“Adoptability” and Sustainability of the TrustTheVote Project

Ok, so rumors of my being radio silent for months due to my feeble attempts to restore my software development skills are greatly unbounded.  I’ve been crazy busy with outreach to States’ elections officials, as our design and specification work is driven by their domain expertise.   In the midst of that, I received a question/comment from a Gartner analyst, Brian Prentice, who I consider to be very sharp on a number of topics around emerging technologies, trends, and open source.  If you have a chance you should definitely check out his blog.

In any event, I thought it would be interesting to simply post my reply to his inquiry here, to potentially shed some light on our strategy and mindset here at the OSDV Foundation and the TrustTheVote Project in particular.  So with that, here it is…

Greetings Brian
I am replying directly (as Marie requested).   Please let me train on your specific question with regard to the TrustTheVote Project and States’ participation to ensure viability, “adoptability” (sic) and of course, sustainability.   Quickly, if I may, I owe you a background brief in ~150 words…

I can understand if you’re wondering “Who are these guys, and if they matter, why haven’t I heard of them?” Fair enough.  Backed by the likes of Mitch Kapor, a team of notable Silicon Valley technologists have been (intentionally) quieting plowing away on a hard problem: restoring trust in America’s voting technology by producing transparent, high assurance systems… and helping it to be freely deployed as “public infrastructure.”  To avoid the trouble with announcing vaporware (and because we have no commercial agenda wrapped up in a competitive first-mover advantage stunt), we’ve remained under the PR radar (except for those avid OSS folks who have been following our activities on the Net.)  Now we’re being pressed by many to go public given the level of work we’re accomplishing and the momentum we’re achieving.  So, here we are.  Now, to your question:

To what extent has the TrustTheVote Project displaced bespoke state-specific VR efforts. The success of any open source project is directly related to the vitality of the community that supports it.  As I would see it, TTV needs states to move away from their own software solutions and instead to contributing to TTV project.

1. All states who register voters are under a HAVA mandate to provide for a centralized voter registration database, and to varying extents are either self-vending or looking to outside (expensive) proprietary solutions.

2. Early on in our nearly 3 year old project we recognized that we did not want to build the ideal “Smithsonian solution” (i.e., an elegant solution that no one adopted, but made a perfect example of how it could’ve and should’ve been done).  Therefore, we realized that amongst all stakeholders in America’s elections systems, the States’ Elections Directors and local elections jurisdictions officials are the front lines and arguably have the most at stake — they succeed or fail by their decisions on what technology to choose and deploy to manage elections.   So, we created a stakeholder community we affectionately call the “Design Congress,” comprised of States’ elections directors.   Ideally, at full implementation, we will have all 50 states and 5 territories represented.   Currently, 18 states have expressed interest at some level, and about 12-15 are committed, on board, and advising us.  In many cases, we even have Secretaries of States’ themselves involved.

3. The TTV Project’s voter registration system is part of a larger elections management system we’re designing and building — under the advice and counsel of those very States’ elections directors and other domain experts who are actively “weighing in.”  We use a process very similar to that of the IETF (Internet Engineering Task Force) called the “RFC” or “Request for Comment.”

4. In the case of our Voter Registration Design Specification, we were encouraged by a number of States to freely adopt specs of their own, and in fact, CA encouraged us to look closely at theirs as a basis. We did.  In other cases (such as for our work on Ballot Design Studio, Ballot Casting/Counting services, Tabulators, etc.), some States are freely contributing to our overall code base (their “IP” is generally paid for by taxpayer dollars and they necessarily cannot sell, but can give it away, so they are eager to contribute to this public digital works project.)

5. So, you are 110% correct in your observations, and the TrustTheVote Project is already fully on track with you in building a strong stakeholder community to drive the design and specifications of all parts of the voting technology ecosystem we’re examining, re-thinking, designing, developing, and offering in an open source manner.

Our goal is simple: create accountable, reliable, transparent, and trustworthy elections and voting systems that are publicly owned “critical democracy infrastructure.”

And our work is gaining the attention of folks from the U.S. DoJ, the Obama Administration’s OSTP, the American Enterprise Institute, the Brookings Institute, several universities, States’ Secretaries, and of course, folks like Rock The Vote, and the Overseas Vote Foundation.

I (and our CTO or anyone here appropriate) would love an opportunity to brief you further; not because we have anything to promote or sell in the commercial sense, but because a growing group of some of the best in technology and public policy sectors are working together in a purely philanthropic manner, to produce something we think is vitally important to our democracy.

Cheers
Gregory Miller, JD
Chief Foundation Development Officer
Open Source Digital Voting Foundation