Gentle readers, before you’re tempted to freak out that a new election service is being launched during a general (mid-term) election rather than a primary consider the unusual reality of the District of Columbia elections: the Primary is the most important Election Day where key decisions (e.g., the next Mayor) are decided.

As the Washington Post reported at lunch today:

There’s no Republican seeking the post in a city where three-quarters of voters are Democrats, so whoever wins the Sept. 14 Democratic primary has a lock on the general election in November.

Meanwhile the D.C. Elections Executive Director Rokey Suleman stated earlier this morning:

We are delaying this project to take the time to properly configure the hardware and software, conduct a public evaluation and feedback period, and educate overseas voters about their choices.

So, the District’s decision to reschedule the launch of their digital vote by mail service is sound.  It takes a bunch of pressure off their effort to launch a responsible, well thought out solution that employs the best possible efforts (given current technology) to maintain the secrecy of a remotely submitted ballot, and protect its content… in the middle of a hotly contested (local) election.  And it gives all parties involved in the technical effort (the TrustTheVote Project included) more time to make sure every detail has been considered.

And it does one more, I think, essential thing: it ensures there will be a proper public review and comment period for the solution.  To that end, we know that the D.C. Board of Elections Chief Technology Officer, Paul Stenbjorn is days away from releasing a Design Review & Rationale document, which we have been reviewing this week, commenting on, and contributing to (in the application design around the integration of our Ballot Design Studio and Elections Manager).  The paper is extensive, detailed (complete with threats analysis), and as far as I can tell, one of the most significant efforts of its kind to ever be published by a public elections administration.

At the end of the day, I see this decision, their forthcoming paper, and all of the efforts of the D.C. BOEE as demonstrating a commitment to elections integrity.  Although we may not all agree with some choices made in how overseas voters are digitally empowered to participate in elections (and the OSDV Foundation for one, remains against widespread application of remote online voting services), I believe that when the efforts of the District are fairly examined, there will be consensus that Rokey Suleman and his team are making a decent effort to do the right thing.

GAM|out

So, here it is; again not an official transcript, but a compilation of my answers after watching and listening to the video interview about a dozen times (so you don’t have to) combined with my recollection as close as I recall my remarks – expressed and intended.

O’Reilly: How are voting systems in the U.S. currently handled?  In other words, where do they come from; procurement process; who decides/buys; etc.?

Miller: Voting systems are currently developed and delivered by proprietary systems vendors, and procured by local election jurisdictions such counties and townships. The States’ role is to approve specific products for procurement, often requiring products to have completed a Federal certification process overseen by the EAC.  However, the counties and local elections jurisdictions make the vast majority of elections equipment acquisition decisions across the country.

O’Reilly: So how many vendors are there?  Or maybe more to the point, what’s the state of the industry; who are the players; and what’s the innovation opportunity, etc.?

Miller: Most of the U.S. market is currently served by just 3 vendors.  You know, as we sit here today, just two vendors control some 88% of America’s voting systems infrastructure, and one of them has a white-knuckled grip on 75% of that.  Election Systems and Services is the largest, after having acquired Premier Systems from its parent company, Diebold.  The DoJ interceded on that acquisition under a mandatory Hart-Scott-Rodino Act review to consider potential anti-trust issues.  In their settlement with ES&S, the Company dealt off a portion of their technology (and presumably customers) to the Canadian firm Dominion Systems.  Dominion was a small player in the U.S. until recently when it acquired those technology assets of Premier (as part of the DoJ acquisition, and acquired the other fomer market force, Sequoia.  And that resulted in consolidating approximately 12% of the U.S. market. Most of the remaining U.S. market is served by Hart-Intercivic Systems.

On the one hand, I’d argued that the voting systems marketplace is so dysfunctional and malformed that there is no incentive to innovate, and at worst, there is a perverse disincentive to innovate and therefore really not much opportunity.  At least that’s what we really believed when we started the Foundation in November 2006.  Seriously, for the most part any discussion about innovation in this market today amounts to a discussion of ensuring spare parts for what’s out there.  But really what catalyzed us was the belief that we could inject a new level of opportunity… a new infusion of innovation.  So, we believe part of the innovation opportunity is demonstrated by the demise of Premier and Sequoia and now the U.S. elections market is not large or uniform enough to support a healthy eco-system of competition and innovation.  So the innovation opportunity is to abandon the proprietary product model, develop new election technology in a public benefits project, and work directly with election officials to determine their actual needs.

O’Reilly: So what is the TrustTheVote Project, and how does that relates to the Foundation?

Miller:  The Open Source Digital Voting Foundation is the enabling 501.c.3 public benefits corporation that funds and manages projects to develop innovative, publicly owned open source elections and voting technology.  The TrustTheVote Project is the flagship effort of the Foundation to design and develop an entirely new ballot eco-system.

What we’re making is an elections technology framework built on breakthrough innovations in elections administration and management and ballot casting and counting that can restore trust in how America votes.  Our design goal is to truly deliver on the four legs of integrity in elections: accuracy, transparency, trust, and security.

The reason we’re doing this is simple: this is the stuff of critical democracy infrastructure – something far too much of a public asset to privatize.  We need to deliver what the market has so far failed to deliver.  And we want to re-invent that industry – based on a new category of entrants – systems integrators who can take the open source framework, integrate it with qualified commodity hardware, and stand it up for counties and elections jurisdictions across the country.

We’re doing this with a small full time team of very senior technologists and technology business executives, as well as contractors, academia, and volunteer developers.

We’re 4 years into an 8 year undertaking – we believe the full framework will be complete and should be achieving widespread adoption, adaptation, and deployment by the close of 2016 – done right it can impact the national election cycle that year.  That said, we’re under some real pressure to expedite this because turns out that a large number of jurisdiction will be looking to replace their current proprietary systems over the next 4 years as well.

O’Reilly:  How can open source really improve the voting system?

Miller:  Well, open source is not a panacea, but we think it’s an important enabler to any solution for the problems of innovation, transparency, and cost that burden today’s elections.  Innovation is enabled by the departure from the proprietary product model, including the use of open-source licensing of software developed in a public benefits project. Transparency, or open-government features and capabilities of voting systems are largely absent and require innovation that the current market does not support. Cost reduction can be enabled by an open-source-based delivery model in which procurements allow system integrators to compete for delivery license-free voting systems, coupled with technical support that lacks the vendor lock-in of current procurements. Open source software doesn’t guarantee any of these benefits, but it does enable them.

I should point out too, that one of our deepest commitments is to elections verification and auditability (sic).  And our framework, based on an open standards common data format utilizing a markup language extension to XML called EML is the foundation on which we can deliver that.  Likewise, I should point out our framework is predicated on a durable paper ballot of record… although we haven’t talked about the pieces of the framework yet.

O’Reilly:  Well our time is limited, but you must know I can’t resist this last question, which is probably controversial but our audience is really curious about.  Will online voting ever be viable?

Miller: Well, to be intellectually honest, there are two parts to that loaded question.  Let me leave my personal opinion and the position of the Foundation out of it at first, so I just address the question in a sterile light.

First, online voting is already viable in other countries that have these 3 policy features: [1] a national ID system, [2] uniform standards for nationwide elections, and [3] have previously encouraged remote voting by mail rather than in-person voting. These countries also fund the sophisticated centralized IT infrastructure required for online voting, and have accepted the risks of malware and other Internet threats as acceptable parts of nationwide online voting.   For a similar approach to be viable in the U.S., those same 3 policy features would likely require some huge political innovations, at the 50-plus state level, if not the Federal level.   There really isn’t the political stomach for any of that and particularly national ID although arguably we already have it, or creating national elections and voting standards, let alone building a national elections system infrastructure.  In fact, the National Association of State Secretaries recently passed – actually re-upped an earlier resolution to work to sunset the Federal Elections Assistance Commission.  In other words, there is a real Federalist sense about elections.  So, on this first point of socio-political requirements alone I don’t see it viable any time soon.

But letting our opinion slip into this, the Foundation believes there is a more important barrier from a technical standpoint.  There are flat out technical barriers that have to be cleared involving critical security and privacy issues on the edge and at the core of a packet-switched based solution. Furthermore, to build the kind of hardened data center required to transact voting data is far beyond the financial reach of the vast majority of jurisdictions in the country.  Another really important point is that online elections are difficult if not impossible to audit or verify.  And finally, there is a current lack of sophisticated IT resources in most of the thousands of local elections offices that run elections in the U.S.

So, while elections remain a fundamentally local operation for the foreseeable future, and while funding for elections remains at current levels, and until the technical problems of security and privacy are resolved, nationwide online voting seems unlikely in the U.S.

That said, we should be mindful that the Internet cloud has darkened the doorstep of nearly every aspect of society as we’ve moved from the 2^nd age of industrialism to the 3^rd age of digitalism.  And it seems a bit foolish to assume that the Internet will not impact the conduct of elections in years to come.  We know there is a generation out there now who is maturing having never known any way to communicate, find information, shop, or anything other than online.  Their phones exist in an always-on society and they expect to be able to do everything they need to interact with their government online.  Whether that’s a reasonable expectation I don’t think is the issue.

But I think it will be important for someone to figure out what’s possible in the future – we can’t run and hide from it, but I believe we’re no where near being able to securely and verifiably use the Net for elections.  There is some very limited use in military and overseas settings, but it needs to be restricted to venues like that until the integrity issues can be ironed out.

So, we’re not supporters of widespread use of the Internet for voting and we don’t believe it will be viable in the near future on a widespread basis.  And honestly, we have too much to do in just improving upon ballot casting and counting devices in a polling place setting to spend too many cycles thinking about how to do this across the Internet.

-GAM|out

That all changed in a big way today.

The producers and moderators of the event, I suspect sensing the potential side effects of yesterdays outcome — came together, somehow collectively made some adjustments (in moderation techniques, approach, and topic tweaking), and pulled off an excellent, informative day full of the kind of discourse I willingly laid down money (the Foundation’s money no less) in the first place to attend.

My hat is off; NIST and EAC on the whole did a great job with a comeback performance today that nearly excused all of what we witnessed yesterday.  Today, they exhibited self deprecating humor, and even had elections officials playing up their drunk driver characterization from the day before.

Let me share below what we covered; it was substantive.  It was detailed.  And it was tiring, but in a good way.  Here it is:

Breakout Session – Voter Authentication and Privacy

–Identified voter authentication and privacy characteristics and risks of the current UOCAVA voting process.

–Identified potential risks related to voter authentication and privacy of remote electronic absentee voting systems. For example, the group considered:

• Ballot secrecy
• Coercion and/or vote selling
• Voter registration databases and voter lists
• Strength of authentication mechanisms
• Susceptibility to phishing/social engineering
• Usability and accessibility of authentication mechanisms
• Voter autonomy
• Other potential risks

–Considered measures and/or criteria for assessing and quantifying identified risks and their potential impacts.

• How do these compare to those of the current UOCAVA voting processes?

–Identified properties or characteristics of remote digital voting absentee voting systems that could provide comparable authentication mechanisms and privacy protections as the current UOCAVA voting process

–Considered currently available technologies that can mitigate the identified risks. How do the properties or characteristics of these technologies compare to those of the current UOCAVA voting process?

–Started to identify and discuss emerging or future research areas that hold promise for improving voter authentication and/or privacy.  For example:

• Biometrics (e.g., speaker voice identification)
• Novel authentication methods

–Chatted about cryptographic voting protocols and other cryptographic technologies

Breakout Session – Network and Host Security

–Identified problems and risks associated with the transmission of blank and voted ballots through the mail in the current UOCAVA voting process.

–Identified risks associated with electronic transmission or processing of blank and voted ballots.  For example, the breakout group considered:

• Reliability and timeliness of transmission
• Availability of voting system data and functions
• Client-side risks to election integrity
• Server-side risks to election integrity
• Threats from nation-states
• Other potential risks

–Considered and discussed measures and/or criteria for assessing and quantifying identified risks and their potential impacts.

• How do these compare to those of the current UOCAVA voting process

–Identified properties or characteristics of remote digital absentee voting systems that could provide for the transmission of blank and voted ballots at least as reliably and securely as the current UOCAVA voting process.

–Discussed currently available technologies that can mitigate the identified risks and potential impact.

• How do the properties and characteristics of these technologies compare to those of the current UOCAVA voting process?

–Identified and discussed emerging or future research areas that hold promise for improving network and host security.  For example:

• Trusted computer and trusted platform models
• End point security posture checking
• Cloud computing
• Virtualization
• Semi-controlled platforms (e.g., tablets, smart phones, etc.)
• Use of a trusted device (e.g., smart card, smart phone, etc.)

As you can see, there was a considerable amount of information covered in each 4 hour session, and then the general assembly reconvened to report on outcomes of each breakout group.

Did we solve any problems today?  Not so much.  Did we come a great deal forward in challenge identification, guiding principles development, and framing the issues that require more research and solution formulation? Absolutely.

Most importantly, John Sebes, our CTO and myself gained a great deal of knowledge we can incorporate into the work of the TrustTheVote Project, had some badly needed clarifying discussions with several, and feel we are moving in the right direction.

We clarified where we stand on use of the Internet in elections (its not time beyond anything but tightly controlled experimentation, and there is a lacking of understanding of the magnitude of resources required to stand up sufficiently hardened data centers to make it work, let alone figuring out problems at the edge.)

And we feel like we made some small contributions to helping the EAC and NIST figure out the kind of test Pilot they wish to stand up as a guiding principles reference model sometime over the next 2 years.

Easily a day’s work for the 50-60 people in attendance over the two days.

Back to the west coast (around 3am for my Pacific colleagues

Its a wrap
GAM|out

I should have seen this coming.  What was I thinking or expecting?

I am reporting this evening from the NIST Workshop on UOCAVA Remote Voting Systems here in Washington D.C..  After a great set of meetings earlier today on other activities of the Foundation (which we’ll have more to say about soon, but had nothing to do with our contributions to the District’s UOCAVA voting Pilot) I arrived at the Wardman Park Marriott near the Naval Observatory (home of the Vice President) for the Workshop, having unfortunately missed the morning sessions.  I barely made it into the lobby, when I had my first taste of what was being served.

My first exposure to the workshop (by then on lunch break) was witnessing a somewhat heated discussion between members of the Verified Voting Foundation and Rokey Suleman, Director of Elections for the District of Columbia.  Apparently, a speaker (identity is irrelevant) of noted authority had delivered a talk before lunch in which he spoke rather condescendingly toward elections officials (likening them to “drunk drivers”).

Mr. Suleman was explaining that so far the meeting appeared to be a waste of his time (principally because of such ad hominen remarks).  Those of the Verified Voting Foundation seemed unwilling to acknowledge that this speaker had (how ever unintentionally) denigrated the hard work of elections officials (as several others later relayed to me they too perceived), emphasizing instead that this individual was, “The nicest person who would never intend such a thing.”

Diplomacy 101 teaches: Perception equals reality.

Rather, they seemed to cling to the fact that this speaker was so much of an authority (which strictly speaking this person who made the drunken driving reference, is in fact a technical authority), that this comment should be overlooked.

The argument devolved from there; the substance of which is irrelevant.  What is relevant, however, is that in the very next session after lunch, another argument broke out over legal details of the letter of the UOCAVA law(s) and the related promulgated regulations enacting new aspects of overseas voting that enable (among other things) the digital delivery of blank ballots, and – arguably – the opportunity to pilot a means of digital return.

By the way: have I mentioned this workshop is supposed to be about UOCAVA remote voting which is limited to a qualified subset of that population overseas, and not the unrestricted widespread so-called “Internet voting?” But yet, an uninformed onlooker could reasonably believe that the battle lines were being drawn over the general widespread notion of Internet Voting on the basis of the so-called “slippery slope” argument.  (Note: I’ll leave it to trained Philosophers to explain why that argument actually is illogical in its own right in most applications.)  So, take a look at the Workshop description and draw your own conclusions.

The issue seems to be overly-trained on possibilities/potential of compromise and nowhere near a discussion of probability.  What’s more, I’m so far hearing nothing of the discussions about the technical challenges we need to address and how if at all (only an official from the Okaloosa Distance Balloting Pilot attempted to offer any such presentation or agenda).

Instead, I kept hearing the rhetoric of avoidance – both in and outside of sessions.  But the Internet has darkened the doorstep of nearly every aspect of society today. Why does it feel like we’re fooling ourselves into believing that somehow this cloud won’t also darken the doorstep of elections in a digital age?  Unfortunately, it already is; and future generations may well demand it.  However, that’s a discussion for another venue — we’re supposed to be exploring remote voting solutions for qualified overseas voters.

Let me say once again:

The Foundation and TrustTheVote Project do NOT support the widespread use of the Internet for the transaction of voting data.

That restated, as far as the Internet playing any role in elections is concerned, it seems to me that we need to look carefully at how to address this challenge, scourge, or whatever we want to call it, rather than try to abolish or avoid it.  Had this mentality been applied to sending man to the moon, this nation never would have achieved four successful lunar landings out of five attempts.

But again, arguing over what role the Internet should or should not play in elections is not why I am here.  Intellectually honest discourse on the challenges and opportunities of UOCAVA remote voting solutions is why I am attending.  And I hoped I would witness (and participate in) a healthy discussion of the technical challenges beyond encryption debates and ideas on how to address them.

So far, I have not.

Instead, what I have is a seat in an intellectual food fight.  Notwithstanding a few interesting comments, speakers, and hallway chats, this sadly so far is a near waste of time (and money).  As one election official put it to me at this evening’s no-host reception:

Today reminds me of an observation by Nick Bostrom, an Oxford Philosopher: there is absolute certainty that the universe we live in is artificial.  Because that’s the only logical conclusion you can reach when you exclusively calculate possibilities without any consideration of probabilities.

Thankfully, we (at the Foundation) have much to work on regarding the use of computers in real world elections that has nothing to do with the transport layer.  Outside of these workshops, we don’t intend to address Internet solutions in our work in any significant manner.

And thankfully more, we had some very positive meetings this morning that validated the potential of our work to actually deliver publicly owned critical democracy infrastructure for accurate, transparent, trustworthy, and secure elections.

Tomorrow is another day; we’ll see what happens, and I’ll report back.
GAM|out

The OSDV Foundation was invited to host a panel session on the role of open source in elections and voting systems.  Here is a copy of Gregory’s presentation from that well attended session yesterday.

We were equally fortunate to have a couple of other opportunities to share our story and work: a gracious mention of us during Tim O’Reilly’s keynote by Bryan Sivak, the CTO of the District of Columbia, and a 20 minute interview with Gregory and O’Reilly Radar Managing Editor Mac Slocum.

In another post by Greg himself he’ll provide the questions and his answers (as best as he can recall) from that interview for those more interested in skimming the text rather than sitting through the video replay.

We appreciate Tim O’Reilly’s growing interest in our work to create publicly owned critical democracy infrastructure for elections administration and voting.  And we thank him for the opportunity to participate.

-Matt
Director, Communications & Outreach

1. Where do the OSDV Foundation and TrustTheVote Project stand on Internet voting?
2. How does this square with OSDV’s role in the D.C. Pilot?

To complement Greg’s recent post , I’ve provided what I hope is a crisp, yet complete, answer in the form of a pointed list of positions, which apply very specifically to the use of technology in U.S. elections.

On Internet Voting

• We do not support Internet voting for everyone – such all-electronic elections lack the ease of independent verification that is the strength of the method of op-scan counted paper ballots coupled with mandatory auditing.
• We do not support any of the types of Internet voting used in other countries – there is no voter-approved ballot document when the ballot itself is HTML and HTTP data exchanged by a Web browser and an i-voting server.
• We do not support any usage of email for transporting marked ballots – email is fundamentally and easily vulnerable to mischief en route from the voter to the BOE.
• These on-line methods of voting and ballot transport all have significant risks to ballot integrity, inherent in the use of the Internet.
• These on-line methods have significant risk to the “secret ballot” by making either ballots or votes attributable to specific voters.
• These on-line methods are not a form of “verified voting” where the ballot marked by the voter is the ballot that is counted.
• We fully support verified voting methods for domestic polling place voting.
• We fully support existing election practices of paper vote-by-mail.
• Our core mission is and will remain the creation of open transparent technology to support the existing election practices.
• We support existing UOCAVA voter-support methods including digital distribution of blank ballots, and express delivery (e.g., surface courier or mails) of marked paper ballots from the voter to their respective BOE.
• We believe that there may be a need for digital ballot return by those UOCAVA voters who lack timely access to rapid and reliable means of paper ballot return, and who have recently used email for digital ballot return.
• We believe that it is worth considering whether those UOCAVA voters should demonstrate a need for digital return because of that lack of timely access.

About the D.C. Pilot

• We are supporting D.C.’s Pilot effort to investigate the need for and feasibility of a Web-based alternative with significantly less risk to the “secret ballot.”
• We believe that the Pilot’s method does not make Internet voting completely safe or secure for general use.
• We believe that the Pilot’s method does not make Internet voting completely safe or secure for UOCAVA voters.
• We believe that the Pilot’s method does address some security issues of current email voting, but does not attempt to address all security issues of email voting, or all security issues of Internet usage.
• We believe that the Pilot project will create a publicly documented worked example that can be used for concrete evaluation of the Internet risks and ballot-secrecy benefits; an evaluation that should be part of consideration of whether or not any form of digital VBM methods are appropriate for continued use for UOCAVA voters.
• We believe that the worked-example benefit will be strongly supported by the Pilot project’s pre-election public review period for anyone to try the system, to examine, probe, and assess not only the technology but also its deployment and usage.
• We believe that the worked-example benefit will be strongly supported by a public post-election out-brief.
• We believe that the transparency of the Pilot will be strongly supported by system’s software being available for use independent of the DC pilot, including, but not limited to, the existing TrustTheVote Project software for election administration and ballot design, which is one of our key contributions to the project.
• We believe that much of the digital ballot technology can be dual use, applying to both UOCAVA vote-by-mail and overseas kiosk-based voting.

These statements are specific to U.S. election practices and laws, especially about U.S. military and overseas voters. We certainly respect that other countries have different needs, practices, and capabilities, and in general, a very different election landscape than in the U.S., with its 50+ different state election codes, thousands of election administration jurisdictions, dozens of electoral districts for each individual voter, and a significant portion of the electorate that must vote remotely.

Lastly, an important caveat: these are positions, opinions, and beliefs only of the OSDV Foundation; we do not advocate on behalf of any other organization; as a non-profit public benefits corporation we cannot directly lobby any public agency or institution for any policy or regulatory change. That stated, we certainly can and will continue to opine here and elsewhere, but as always our focus is on the application of technology in the administering of public elections.

– EJS

[Note: this is a much longer post than I would prefer, but the content is very important to explain a recent announcement and our role.]

I’ve waited to launch a discussion in this forum in order to let the flurry of commentaries calm on the news.  Now we need to take the opportunity to speak in own voice, rather than the viewpoint of  journalists and press releases, and provide insight and reality-checks from the authoritative source about what we’re up to: Us. For those of you who have not read any of this news, here is a sample or two.  The news is about the District of Columbia is implementing a Pilot program to digitally deliver ballot to a group of qualified overseas voters, and accept digitally returned ballots from them.  (Actually, D.C. already has accepted digitally returned ballots via Fax and eMail.)  So, the headline might be:

“District of Columbia to Launch Pilot Program to benefit Overseas & Military Voters with Digital Distance Balloting Solution Using Open Source Software from Non-Profit Voting Technology Group.”

I believe that is as simple and factual as it gets, and IMHO a fair headline.  However, here are two alternative headlines, depending on your view, interests, or issues:

1. “Open Source Voting Project Succeeds in Production Deployment of New Transparent and Freely Available Elections Technology.”
   -or-
2. “OSDV Foundation Advances Misguided Cause of Internet Voting, Despite Well Settled Dangers, Putting Election Integrity at Risk.”

If you follow our work or have read our statement on these topics before, then you recognize the headline #1 is where our interests and intentions are focused. Over the past two weeks, though, we’ve received plenty of feedback that some believe that headline #2 is the real and unfortunate news, undermining the efforts of those who tirelessly work for elections integrity. Well, that is not what we intended to do. But we do need to do a better job at communicating our goals, as the facts unfold about the project. So, let me back up a bit and start  an explanation of what we are really doing and what are real intentions are.

But first let me make the following statement, repeating for the record our position on Internet voting:

The Open Source Digital Voting Foundation does not advocate the general use of the public Internet for the transaction of voting data.  The technical team of the TrustTheVote Project strongly cautions that no Internet-based system for casting, let alone counting, of ballots can be completely secure, nor can a voter’s privacy be ensured, or the secrecy of their ballot protected.

We do not recommend replacing current voting systems by adopting Internet Voting systems. However, we think that there may be a use case in which Internet-based ballot return may be the only course of last resort for rapid delivery of a ballot in time to be counted. That case is the very limited situation of an overseas or military voter who believes that they may be disenfranchised unless they rely on a digital means to return their marked ballot, because physical means are not timely or not available. That is the situation that we genuinely believe is being restrictively addressed in the D.C. Pilot project that we are participating.

And to be crystal clear: OSDV’s role is supplying technology.  The District’s Board of Elections and Ethics is running the show, along withe the District’s I.T. organization. But why did we chose this role? The success of the TrustTheVote Project is predicated on accomplishing three steps to delivering publicly owned audit-ready, transparent voting technology:

1. Design;
2. Development; and
3. Deployment.

Design.  We are employing a public process that engages a stakeholder community comprised of elections officials and experts.  We cannot design on our own and expect what we come up with will be what will work.  It is, and must be, a framework of technology components in order to be adoptable and adaptable to each jurisdiction that chooses to freely acquire and deploy the Project’s work. None of the TV Framework specifically addresses any transport means of ballot data.   The Framework voting systems architecture includes accessible ballot marking (”ABM”) devices, optical scanners for paper ballot marked by hand or ABM, and tabulators.  The Framework elections management services architecture includes EMS components, poll books, and ballot design studio.

Development.  We are employing an open source method and process, somewhat modified and similar in structure to how the Mozilla Foundation manages development of their open source software – with a core team that ensures development continuity and leadership, complemented by a team of paid and volunteer contributors.  And the development has to be open, to go along with the open design process, and open testing, delivering on the commitment to building election technology that anyone can see, touch, and try.  We’re developing for the four legs of integrity: accuracy, transparency, trust, and security.

Deployment. But “open source” at the Foundation is also about distribution for deployment.  As we’ve said before, the  OSDV Public License, based on our “cousin’s” license, the Mozilla Public License, meets the special needs of government licensee.  And in so doing we avail the source code, and where required, resources (in exchange for a development grant to the Foundation) to make the necessary refinements and modifications to enable the adopting jurisdiction to actually deploy this open source technology.  The deployment will generally be managed by a new type of commercial player in the elections technology sector: the systems integrator who will provide qualified commodity hardware, with the Project’s software, and the services to stand it up and integrate it with other jurisdiction’s IT infrastructure where required.

Motivation
One critic has asked, “Why would you agree to support any project that uses the Internet in elections or voting?”  Our motivation for working with the District of Columbia is all about the third “D” – Deployment.   All of our efforts are merely academic, unless stakeholders who have contributed to the specifications actually adopt the resulting open source technology as an alternative to buying more proprietary elections technology, when the opportunity arises to replace or enhance their current solutions.

Now, what about that “Internet” element?

The District of Columbia Board of Elections & Ethics (B.O.E.E) was in search of a solution to enhance their compliance with the MOVE Act.  Of course, people in many election jurisdictions were asking:

If I can deliver the blank ballot and reduce the cycle time for qualified overseas voters, then why shouldn’t we go all the way and facilitate digital return of the marked ballot?

Well, there’s a host of reasons why one shouldn’t do that.  For one quick example: our valued strategic technology partner collaborating with us on data standards, the Overseas Vote Foundation, not only offers digital blank ballot delivery, but  also have renewed their courier services through the assistance of the US Postal Service and FedEx to ensure that the Military voters’ marked ballots can, in fact, make it back in time.   But on the other hand, there is an unfortunate reality that once the digital path is open, OVF, US Mails, or FedEx notwithstanding, jurisdictions will explore leveraging the Net; its happening already in several locations.  That does not make it right or preferable, but it does make it a reality that we need to address.

So, the District at least – at our encouragement dating back to March in Munich – heard our encouragement to explore options, but they did have some requirements.

Specifically, they wanted to conduct a Pilot of a solution that might be a better alternative to accepting returned marked ballots as eMail attachments or Faxed marked ballots exclusively for their overseas and military voters.  And particularly unique to their requirements was – to our delight – a fully transparent open source software solution with unbridled ownership of the resulting source code for all elements of the Pilot solution.  That, of course, is in complete harmony with our charter and mission.

Again, for those readers who know us, and understand our motivations and position on the Internet issue, you can understand our acute focus on the opportunity to deploy open source elections administration software in a real election setting. In the after-glow of this real possibility, and drilling into the details of how the ballot design studio could work for this, we realized we needed to get back to grappling with this digital ballot return detail of the Pilot project.

Initially, we were definitely concerned about how to approach this aspect of the Pilot, since we’ve been clear about our position on the use of the Internet.  But to be frank, with the prospect that the District could simply turn to commercial proprietary Internet voting systems vendors, we felt we had to help find an alternative open source approach for the limited purpose of this Pilot. We encouraged the B.O.E.E. to find an alternative means to digitally return the ballot, but neither by deploying Internet voting products, nor by continuing to rely on Fax or eMail attachments in the clear.  In return, they asked for our help in figuring out how they could implement a solution that worked with real ballot and attestation documents as digital artifacts, which could be transported on an encrypted channel.  This could be better than eMail to be sure, but still using public packet-switched networks.

We turned to several of our technical advisers and convened a meeting to discuss how B.O.E.E and OCTO could approach a digital vote-by-mail Pilot to explore this approach to improving on eMail attachments or Fax’d returns.  The meeting was frank, open, and rather than continuing the rhetoric of avoidance, we witnessed a bunch of stalwarts in information security express concerns, suggest points of mitigation, and brain storm on the possibilities.  And several were kicked around, but tossed aside for want of either acceptable user experience, cost limitations, or operational practicality.  A straw man solution was framed and members of the Core Team went off to refine it knowing that there were aspects that they simply could not address with this Pilot.  Perhaps the most important Pilot parameter: this could not and would not be an exercise to completely assess and determine solutions to all of the known vulnerabilities of securing a voting transaction over a public network.

But it was agreed that a “digital vote-by-mail” process – with the known vulnerabilities and constraints – could be a “worked example” that simply was not what proprietary commercial vendors are selling. And, it was realized that such a solution could not and should not claim any victory in improved security or privacy – no such reality can exist in this solution.

And folks, that is simply and honestly the extent to which we were and are treating this: a “worked example” to serve as a vehicle for voices on all sides of the argument to train their attention in assessing, testing, and determining the viability of such an approach strictly for those overseas and military voters.

One could say the Foundation took a calculated risk: that in order to achieve the larger goal of deploying open source elections technology into a real production environment (a first, and hopefully ground breaking step), we would have to accept that our Stakeholder, B.O.E.E would use the Internet to transport a ballot and attestation document pair using the best possible techniques currently available – HTTPS and standard encryption tools.  And at some measure, at least they had chosen not to pursue a commercial proprietary Internet voting solution, given their steadfast requirement of open source software and maximum transparency.

To my activist colleagues I offer this: we’re giving you a worked example on which to build your arguments against digital transport.  Please do so! We’re with you, believe it or not.  Very frankly, I’d be happy to support some initiative to severely restrict the use of public packet switched networks for transacting voting data.

I want to (re)focus the Project’s attention on the reason a few of us gave up our paying jobs some four years ago: to build a non-profit solution to restore trust in the computers used in the various processes of casting and counting votes.  We don’t advocate iVoting.  We do advocate accuracy, transparency, trust, and security in the use of computers in elections and intend to keep working on that open source framework. We do believe limited Pilots are worth it for the special use case of UOCAVA voters,  if such a Pilot can fuel an intellectually honest debate and/or initiatives to resolve the concerns, or end the use of the Net altogether in this regard.  We think the District of Columbia’s Pilot is such a worked example.

OK, this went way over my intended length, but in the spirit of transparency its important we explain what’s been underway for the past several weeks from an authoritative source: Us. In the next installment on this topic, we will discuss more details on the technology we’ll provide for the District’s Pilot, and reiterate our concerns, but also consider the potential of the open source movement in public elections systems.

Thanks for reading.
Greg Miller

1. Digital distribution of blank ballots via email or web;
2. Digital return of marked ballots via email or fax.

The main point of the D.C. pilot is an alternative to #2. Rather than using open email, the DC pilot will transport ballot documents in a conventionally secured private Web session between the voter and a Web server operated by the DC BOEE. I won’t repeat why open email transport is a problem, but the purpose of the pilot is to produce a worked example that is a solution to at least some of the problems that are specific to email as a way to return a marked ballot document.

– EJS

We’re pleased to echo the announcement by the District of Columbia’s Board of Election and Ethics (BOEE) that they will adopt TrustTheVote technology as part of a pilot project to support the delivery and return of overseas ballots. In Washington D.C.’s September primary election, open-source technology from the TrustTheVote Project will be used to digitally deliver and return the absentee voting kits of overseas, military and absentee voters. This pilot project will test a new form of digital “Vote by Mail” ballot transport service.

The BOEE’s announcement has the details, but the gist is this:

• Some overseas and military voters are in danger of their absentee ballots not being counted, due to delays in postal delivery back to the BOEE.
• As a result some voters use fax or email for digital return of marked ballots, but these timely methods have the side-effect of compromising the integrity and anonymity of the ballot.
• The pilot project will test a Web-based alternative process that is no less timely, but lacks these side-effects, and otherwise use same familiar methods of absentee ballot casting and counting that voters and election officials use today.
• The use of TTV’s open source software is a key part of meeting the pilot project’s goals for public visibility of open technology and transparent election operations.

We’ll be saying plenty more about these efforts as we along, you can be sure!

– EJS

Today, I’m continuing on from a recent post, which compared my in-person voting experience with one method of Internet-based voting: return of marked ballots by fax or email. Next up is a similar comparison with another form of Internet-based voting: Internet voting from home using a PC’s Web browser.

Let’s briefly recall the result at the end of the day in my polling place:
1. Some paper ballots in a ballot box.
2. Some digital vote totals in a computer, and set of paper rolls that provide a ballot-like paper trail of each voter’s activity that led to those vote totals. The paper trails can be used to check the correctness of the digital vote totals.
Let’s also recall the result at the end of the day with email ballot return:
1. Some printed versions of faxed/emailed ballots, which are treated as ballots for counting purposes.
While we’re at it, let’s recall the results of the old lever machines too:
1. Some mechanical vote totals in one or more machines
2. A hand-recorded paper transcription of the “odometer” readings. (Those machines were a lot harder to move than a computer is! So the transcriptions were the basis for vote totals.)

Now, on to home-based Web i-voting. Before doing the end-of-the-day comparison, let’s start with what the experience looks like — fundamentally, it’s Web pages. You point your browser to a Web site; you type in your voter identification, a bit like the in-person poll-book signing experience; and then you get your ballot: one or more Web pages. Various Internet voting products and services differ, but they are all fundamentally similar to something that I bet many readers have seen already: online surveys. Take a look at this simple election-like survey about music in Cuyahoga County. The web page looks like a simple ballot, with contests for vocalist and guitarist instead of governor and dog-catcher. There are candidates, and you vote by selecting one with a mouse click on a radio button next to the name of your favorite.

So far, so familiar, but when I press that submit button, what happens? Where’s my ballot? Let’s take it step by step.

• The submit button is part of an HTML form, which is part of the Web page. (You can see the HTML form if you “View Page Source” in your browser.)
• Pressing the button tells your browser to collect up the form’s data, which might include Rachel Roberts for Vocalist if you had clicked the radio button next to Rachel.
• These parts of the forms data are something that in election lingo you might call a “vote” (or “contest selection” to be precise.)
• The HTML form data, including the vote-oid data, is sent from your browser to the Web server via an HTTP POST operation.
• The HTTP transaction is typically via an encrypted SSL session, to preserve privacy en route over the Internet.
• The Web server passes the POST parameters to some election-specific Web application software, which interprets the data as votes, and stores the vote data in a database.

Now, let’s be specific about that database stuff. In surveymonkey, there is a database record for each Cleveland Music survey response, and it’s possible (if the survey was set up that way) that the record also includes some information about the person who responded. In actual government voting, though, of course we don’t want that. So even though the i-voting server has a database of voters, and even though you had to log in to the i-voting server, and even though you were only allowed to vote if the voter record said you were allowed to vote, still your vote data shouldn’t be stored with your voter record. So, the vote data is supposed to be anonymously and separately stored, becoming part of vote totals for each candidate in each contest.

Can you say “odometer“? Okay, maybe it’s not that obvious, so let me juxtapose a couple images. As I recounted earlier, a much younger me is standing in the voting booth of a lever machine, looking a big bank of little switches next to candidate names, and thinking that is the ballot. Then the big lever is pulled, the little switches flip back, and it’s like the ballot just evaporated! Though of course I was told that the counter dials in the back of the machine did tick over like the odometer on a car, recording each vote. The votes were stored on the odometers, but the ballot was gone without a trace. Now shift the scene to my first surveymonkey experience. I clicked some radio buttons, clicked submit, and poof! what I thought was a ballot just disappeared. I’m told that the counters in a database somewhere ticked over to record my “votes.” Again, votes were supposedly recorded, but there wasn’t really ever a durable ballot. Home-based web client-server Internet voting is just like that, regardless of varying technical implementation details. There’s no durable ballot document.

So, at the end of the day, we have stored vote totals in a database of a system that also logged the voter logins. At that point I don’t have an answer to “What’s the ballot” anymore than I do for lever machines or the early paper-trail-less DREs. Unlike the (much-more-insecure) email ballot delivery, we don’t really know what or where the ballots are. Recalling my experience in the Middlefield Road fire house, the vote data is similarly stored as bits on a computer, but!!! there is also the paper trail. That paper trail can be used to audit the system and detect errors and fraud, and serves as the durable record of the vote — almost a ballot, except for being on flimsy paper with some ballot information left out. But with i-voting, there is nothing even similar. Any kind of auditing that’s done, is done using data saved on the server computers, rather than looking at a ballot document that the voter also saw.

Is that so terrible? Maybe so, maybe not. A durable ballot is not a holy requirement for U.S. elections — though in some parts of the country it almost is. And a durable ballot may not be a requirement for a voting system that is specifically and only for timely assistance of overseas and military voters. Such requirements are a matter of local election law and decisions of local election officials. But my critical observation here is about voter trust. Trust derives in large measure from comprehension. And for many voters, a voting system is comprehensible if the voter knows what the ballot is, where it goes, and what happens to it. That’s why overseas voters like fax and email return. Despite the security and anonymity problems, the voter understands that ballot, how it pops out of the fax/printer on the other side of the planet, and how its counted as a paper ballot. The same can’t be said for paperless home-based i-voting. As a consequence, I think that it will be harder to build trust, at least in some parts of the country that are paper-centric. However, it may be less of a big deal if limited to overseas and military voters, whose main concern is “get the the ballot home in time to be counted.” The pilots are happening, and time will tell.

– EJS