Tagged overseas voting

Accurate Election Results in Michigan and Wisconsin is Not a Partisan Issue

counties

Courtesy, Alex Halderman Medium Article

In the last few days, we’ve been getting several questions that are variations on:

Should there be recounts in Michigan in order to make sure that the election results are accurate?

For the word “accurate” people also use any of:

  • “not hacked”
  • “not subject to voting machine malfunction”
  • “not the result of tampered voting machine”
  • “not poorly operated voting machines” or
  • “not falling apart unreliable voting machines”

The short answer to the question is:

Maybe a recount, but absolutely there should be an audit because audits can do nearly anything a recount can do.

Before explaining that key point, a nod to University of Michigan computer scientists pointing out why we don’t yet have full confidence in the election results in their State’s close presidential election, and possibly other States as well. A good summary is here and and even better explanation is here.

A Basic Democracy Issue, not Partisan

The not-at-all partisan or even political issue is election assurance – giving the public every assurance that the election results are the correct results, despite the fact that bug-prone computers and human error are part of the process. Today, we don’t know what we don’t know, in part because the current voting technology not only fails to meet the three (3) most basic technical security requirements, but really doesn’t support election assurance very well. And we need to solve that! (More on the solution below.)

A recount, however, is a political process and a legal process that’s hard to see as anything other than partisan. A recount can happen when one candidate or party looks for election assurance and does not find it. So it is really up to the legal process to determine whether to do a recount.

While that process plays out let’s focus instead on what’s needed to get the election assurance that we don’t have yet, whether it comes via a recount or from audits — and indeed, what can be done, right now.

Three Basic Steps

Leaving aside a future in which the basic technical security requirements can be met, right now, today, there is a plain pathway to election assurance of the recent election. This path has three basic steps that election officials can take.

  1. Standardized Uniform Election Audit Process
  2. State-Level Review of All Counties’ Audit Records
  3. State Public Release of All Counties Audit Records Once Finalized

The first step is the essential auditing process that should happen in every election in every county. Whether we are talking about the initial count, or a recount, it is essential that humans do the required cross-check of the computers’ work to detect and correct any malfunction, regardless of origin. That cross-check is a ballot-polling audit, where humans manually count a batch of paper ballots that the computers counted, to see if the human results and machine results match. It has to be a truly random sample, and it needs to be statistically significant, but even in the close election, it is far less work than a recount. And it works regardless of how a machine malfunction was caused, whether hacking, manipulation, software bugs, hardware glitches, or anything.

This first step should already have been taken by each county in Michigan, but at this point it is hard to be certain. Though less work than a recount, a routine ballot polling audit is still real work, and made harder by the current voting technology not aiding the process very well. (Did I mention we need to solve that?)

The second step should be a state-level review of all the records of the counties’ audits. The public needs assurance that every county did its audit correctly, and further, documented the process and its findings. If a county can’t produce detailed documentation and findings that pass muster at the State level, then alas the county will need to re-do the audit. The same would apply if the documentation turned up an error in the audit process, or a significant anomaly in a difference between the human count and the machine count.

That second step is not common everywhere, but the third step would be unusual but very beneficial and a model for the future: when a State is satisfied that all counties’ election results have been properly validated by ballot polling audit, the State elections body could publicly release all the records of all the counties’ audit process. Then anyone could independently come to the same conclusion as the State did, but especially election scientists, data scientists, and election tech experts. I know that Michigan has diligent and hardworking State election officials who are capable of doing all this, and indeed do much of it as part of the process toward the State election certification.

This Needs to Be Solved – and We Are

The fundamental objective for any election is public assurance in the result.  And where the election technology is getting in the way of that happening, it needs to be replaced with something better. That’s what we’re working toward at the OSET Institute and through the TrustTheVote Project.

No one wants the next few years to be dogged by uncertainly about whether the right person is in the Oval Office or the Senate. That will be hard for this election because of the failing voting machines that were not designed for high assurance. But America must say never again, so that in two short years and four years from now, we have election infrastructure in place that was designed from ground-up and purpose-built to make it far easier for election officials to deliver election results and election assurance.

There are several matters to address:

  • Meeting the three basic security requirements;
  • Publicly demonstrating the absence of the vulnerabilities in current voting technology;
  • Supporting evidenced-based audits that maximize confidence and minimize election officials’ efforts; and
  • Making it easy to publish detailed data in standard formats, that enable anyone to drill down as far as needed to independently assess whether audits really did the job right.

All that and more!

The good news (in a shameless plug for our digital public works project) is that’s what we’re building in ElectOS. It is the first openly public and freely available set of election technology; an “operating system” of sorts for the next generation of voting systems, in the same way and Android is the basis for much of today’s mobile communication and computing.

— John Sebes

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

Exactly Who is Delivering Postal Ballots? and Do We Care?

An esteemed colleague noted the news of the USPS stopping weekend delivery, as part of a trend of slow demise of the USPS, and asked: will we get to the point where vote-by-mail is vote-by-Fedex? And would that be bad, having a for-profit entity acting as the custodian for a large chunk of the ballots in an election?

The more I thought about it, the more flummoxed I was. I had to take off the geek hat and dust off the philosopher hat, looking at the question from a viewpoint of values, rather than (as would be my wont) requirements analysis or risk analysis. I goes like this …

I think that Phil’s question is based on assumption of some shared values among voters — all voters, not just those that vote by mail — that make postal voting acceptable because ballots are a “government things” and so is postal service. Voting is in part an act of faith in government to be making a good faith effort to do the job right, and keep the operations above a minimum acceptable level of sanity. It “feels OK” to hand a marked ballot to my regular neighborhood post(wo)man, but not to some stranger dropping off a box from a delivery truck. Translate from value to feeling to expectation: it’s implied that we expect USPS staff to know that they have a special government duty in delivering ballots, and to work to honor that duty, regarding the integrity of those special envelopes as a particular trust, as well as their timely delivery.

  • Having re-read all that, it sounds so very 20th century, almost as antique as lever machines for voting.

I don’t really think that USPS is “the government” anymore, not in the sense that the journey of a VBM ballot is end-to-end inside a government operation. I’m not sure that Fedex or UPS are inherently more or less trustworthy. In fact they all work for each other now! And certainly in some circumstances the for-profit operations may to some voters feel more trustworthy — whether because of bad experiences with USPS, or because of living overseas in a country that surveils US citizens and operates the postal service.

Lastly, I think that many people do share the values behind Phil’s question — I know I do. The idea makes me wobbly. I think it comes down to this:

  • If you’re wobbly on for-profit VBM, then get back into the voting booth, start volunteering to help your local election officials, and if they are effectively outsourcing any election operations to for-profit voting system vendors, help them stop doing so.
  • If you not wobbly, then you’re part of trend to trusting — and often doing — remote voting with significant involvement from for-profit entities – and we know where that is headed.

The issue with USPS shows that in the 21st century, any form of remote voting will involve for-profits, whether it is Fedex for VBM, or Amazon cloud services for i-voting. My personal conclusions:

  • Remote voting is lower integrity no matter what, but gets more people voting because in-person voting can be such a pain.
  • I need to my redouble efforts to fix the tech so that in-person voting is not only not a pain, but actually more desirable than remote voting.

— EJS

Open-Source Election Software Hosting — What Works

Putting an open source application into service – or “deployment” – can be different from deploying proprietary software. What works, and what doesn’t? That’s a question that’s come up several times in the few weeks, as the TTV team has been working hard on several proposals for new projects in 2011. Based on our experiences in 2009-10, here is what we’ve been saying about deployment of election technology that is not a core part of ballot certified casting/counting systems, but is part of the great range of other types of election technology: data management solutions for managing election definitions, candidates, voter registration, voter records, pollbooks and e-pollbooks, election results, and more – and reporting and publishing the data.

For proprietary solutions – off the shelf, or with customization and professional services, or even purely custom applications like many voter record systems in use today – deployment is most often the responsibility of the vendor. The vendor puts the software into the environment chosen by the customer — state or local election officials – ranging from the customer’s IT plant to outsourced hosting to the vendor’s offering of an managed service in an application-service-provider approach. All have distinct benefits, but share the drawback of “vendor lock-in.”

What about open-source election software? There are several approaches that can work, depending the nature of the data being managed, and the level of complexity in the IT shop of the election officials. For today, here is one approach that has worked for us.

What works: outsourced hosting, where a system integrator (SI) manages outsourced hosting. For our 2010 project for VA’s FVAP solution, the project was led by an SI that managed the solution development and deployment, providing outsourced application hosting and support. The open-source software included a custom Web front-end to existing open-source election data management software that was customized to VA’s existing data formats for voters and ballots. This arrangement worked well because the people who developed the custom front-end software also performed the deployment on a system completely under their control. VA’s UOCAVA voters benefited from the voter service blank-ballot distribution, while the VA state board of elections was involved mainly by consuming reports and statistics about the system’s operation.

That model works, but not in every situation. In the VA case, this model also constrained the way that the blank ballot distribution system worked. In this case, the system did not contain personal private information — VA-provided voter records were “scrubbed”. As a result, it was OK for the system’s limited database to reside in a commercial hosting center outside of the the direct control of election officials. The deployment approach was chosen first, and it constrained the nature of the Web application.

The constraint arose because the FVAP solution allowed voters to mark ballots digitally (before printing and returning by post or express mail). Therefore it was essential that the ballot-marking be performed solely on the voter’s PC, which absolutely no visibility by the server software running in the commercial datacenter. Otherwise, each specific voter’s choices would be visible to a commercial enterprise — clearly violating ballot secrecy. The VA approach was a contrast to some other approaches in which a voter’s choices were sent over the Internet to a server which prepared a ballot document for the voter. To put it another way …

What doesn’t work: hosting of government-privileged data. In the case of the FVAP solution, this would have been outsourced hosting of a system that had visibility on the ultimate in election-related sensitive data: voters’ ballot choices.

What works: engaged IT group. A final ingredient in this successful recipe was engagement of a robust IT organization at the state board of elections. The VA system was very data-intensive during setup, with large amounts of data from legacy systems. The involvement of VA SBE IT staff was essential to get the job done on the process of dumping the data, scrubbing and re-organizing it, checking it, and loading it into the FVAP solution — and doing this several times as the project progressed to the point where voter and ballot data were fixed.

To sum up what worked:

  • data that was OK to be outside direct control of government officials;
  • government IT staff engaged in the project so that it was not a “transom toss” of legacy data;
  • development and deployment managed by a government-oriented SI;
  • deployment into a hosted environment that met the SI’s exact specifications for hosting the data management system.

That recipe worked well in this case, and I think would apply quite well for other situations with the same characteristics. In other situations, other models can work. What are those other models, or recipes? Another day, another blog on another recipe.

— EJS

D.C. Reality Check – The Opportunities and Challenges of Transparency

Gentle Readers:
This is a long article/posting.  Under any other circumstance it would be just too long.

There has been much written regarding the public evaluation and testing of the District of Columbia’s Overseas “Digital Vote-by-Mail” Service (the D.C.’s label).  And there has been an equal amount of comment and speculation about technology supplied to the District from the OSDV Foundation’s TrustTheVote Project, and our role in the development of the D.C. service.  Although we’ve been mostly silent over the past couple of weeks, now enough has been determined so that we can speak to all readers (media sources included) about the project from our side of the effort.

The coverage has been extensive, with over 4-dozen stories reaching over 370 outlets not including syndication.  We believe it’s important to offer a single, contiguous commentary, to provide the OSDV Foundation’s point of view, as a complement to those of the many media outlets that have been covering the project.

0. The Working Relationship: D.C. BoEE & TrustTheVote Project
Only geeks start lists with item “0” but in this case its meant to suggest something “condition-precedent” to understanding anything about our work to put into production certain components of our open source elections technology framework in D.C. elections.  Given the misunderstanding of the mechanics of this relationship, we want readers to understand 6 points about this collaboration with the District of Columbia’s Board of Elections & Ethics (BoEE), and the D.C. I.T. organization:

  1. Role: We acted in the capacity of a technology provider – somewhat similar to a software vendor, but with the critical difference of being a non-profit R&D organization.  Just as has been the case with other, more conventional, technology providers to D.C, there was generally a transom between the OSDV Foundation’s TTV Project and the I.T. arm of the District of Columbia.
  2. Influence: We had very little (if any) influence over anything construed as policy, process, or procedure.
  3. Access: We had no access or participation in D.C.’s IT organization and specifically its data center operations (including any physical entry or server log-in for any reason), and this was for policy and procedural reasons.
  4. Advice: We were free to make recommendations and suggestions, and provide instructions and guidelines for server configurations, application deployment, and the like.
  5. Collaboration: We collaborated with the BoEE on the service design, and provided our input on issues, opportunities, challenges, and concerns, including a design review meeting of security experts at Google in Mountain View, CA early on.
  6. Advocacy: We advocated for the public review, cautioning that the digital ballot return aspect should be restricted to qualified overseas “UOCAVA” voters, but at all times, the BoEE, and the D.C. I.T. organization “called the shots” on their program.

And to go on record with an obvious but important point: we did not have any access to the ballot server, marked ballots, handling of voter data, or any control over any services for the same.  And no live data was used for testing.

Finally, we provided D.C. with several software components of our TTV Elections Technology Framework, made available under our OSDV Public License, an open source license for royalty-free use of software by government organizations.  Typical to nearly any deployment we have done or will do, the preexisting software did not fit seamlessly with D.C. election I.T. systems practices, and we received a “development grant” to make code extensions and enhancements to these software components, in order for them to comprise a D.C.-specific system for blank ballot download and an experimental digital ballot return mechanism (see #7 below).

The technology we delivered had two critically different elements and values.  The 1st, “main body of technology” included the election data management, ballot design, and voter user interface for online distribution of blank ballots to overseas voters.  With this in hand, the BoEE has acquired a finished MOVE Act compliant blank ballot delivery system, plus significant components of a new innovative elections management system that they own outright, including the source code and right to modify and extend the system.

For this system, BoEE obtained the pre-existing technology without cost; and for D.C-specific extensions, they paid a fraction of what any elections organization can pay for a standard commercial election management system with a multi-year right-to-use license including annual license fees.

D.C.’s acquired system is also a contrast to more than 20 other States that are piloting digital ballot delivery systems with DoD funding, but only for a one-time trial use.  Unlike D.C., if those States want to continue using their systems, they will have to find funding to pay for on-going software licenses, hosting, data center support, and the like.  There is no doubt, a comparison shows that the D.C. project has saved the District a significant amount of money over what they might have had to spend for ongoing support of overseas and military voters.

That noted, the other (2nd) element of the system – digital return of ballots – was an experimental extension to the base system that was tested prior to possible use in this year’s November election.  The experiment failed in testing to achieve the level of integrity necessary to take it into the November election.  This experimental component has been eliminated from the system used this year.  The balance of this long article discusses why that is the case, and what we saw from our point of view, and what we learned from this otherwise successful exercise.

1. Network Penetration and Vulnerabilities
There were two types of intrusions as a result of an assessment orchestrated by a team at the University of Michigan led by Dr. Alex Halderman, probing the D.C. network that had been made available to public inspection.  The first was at the network operations level.  During the time that the Michigan team was testing the network and probing for vulnerabilities, they witnessed what appeared to be intrusion attempts originating from machines abroad from headline generating countries such as China and IranWe anticipate soon learning from the D.C. IT Operations leaders what network security events actually transpired, because detailed review is underway.  And more to that point, these possible network vulnerabilities, while important for the District IT operations to understand, were unrelated to the actual application software that was deployed for the public test that involved a mock election, mock ballots, and fictitious voter identities provided to testers.

2. Server Penetration and Vulnerabilities
The second type of intrusion was directly on the District’s (let’s call it) “ballot server,” through a vulnerability in the software deployed on that server. That software included: the Red Hat Linux server operating system; the Apache Web server with standard add-ons; the add-on for the Rails application framework; the Ruby-on-Rails application software for the ballot delivery and return system; and some 3rd party library software, both to supplement the application software, and the Apache software.

The TrustTheVote Project provided 6 technology assets (see below, Section 7) to the BoEE project, plus a list of requirements for “deployment;” that is, the process of combining the application software with the other elements listed above, in order to create a working 3-tier application running on 3 servers: a web proxy server, an application server, and a database server.  One of those assets was a Web application for delivering users with a correct attestation document and the correct blank ballot, based on their registration records.  That was the “download” portion of the BoEE service, similar to the FVAP solutions that other states are using this year on a try-it-once basis.

3. Application Vulnerability
Another one of those technology assets was an “upload” component, which performed fairly typical Web application functions for file upload, local file management, and file storage – mostly relying on a 3rd-party library for these functions.  The key D.C.-specific function was to encrypt each uploaded ballot file to preserve ballot secrecy.  This was done using the GPG file encryption program, with a command shell to execute GPG with a very particular set of inputs.  One of those inputs was the name of the uploaded file. 

And here was the sticking point.  Except for this file-encryption command, the library software largely performed the local file management functions.  This included the very important function of renaming the uploaded file to avoid giving users the ability to define file names on the server.  Problem: during deployment, a new version of this library software package was installed, in which the file name checks were not performed as expected by the application software.  Result: carefully crafted file names, inserted into the shell command, gave attackers the ability to execute pretty much any shell command, with the userID and privileges of the application itself.

Just as the application requires the ability to rename, move, encrypt, and save files, the injected commands could also use the same abilities.  And this is the painfully ironic point: the main application-specific data security function (file encryption), by incorrectly relying on a library, exposed those ballot files (and the rest of the application) to external tampering.

4.  Consequences
The Michigan team was creative in their demonstration of the results of attacking a vulnerability in what Halderman calls a “brittle design,” a fair critique common to nearly every Web application deployed using application frameworks and application servers.  In such a design, the application and all of its code operates as a particular userID on the server.  No matter how much a deployment constrains the abilities of that user and the code running as that user, the code, by definition, has to be able to use the data that the application manages.

Therefore, if there is a “chink” in any of the pieces the collective armor (e.g., the server, its operating system, web server, application platform, application software, or libraries) or the way they fit together, then that “chink” can turn use into an abuse.  That abuse applies to any and all of the data managed by the application, as well as the file storage used by the application.  As the Michigan teamed demonstrated, this general rule also applies specifically, when the application data includes ballot files.

5.  Mea Culpa
Let’s be clear
, the goof we made, and “our bad” in the application development was not anticipating a different version of the 3rd-party library, and not locking in the specific version that did perform file name checking that we assumed was done to prevent exactly this type of vulnerability.  And in fact, we learned 4 valuable lessons from this stumble:

  1. Factoring Time:  Overly compressed schedules will almost certainly ensure a failure point is triggered.  This project suffered from a series of cycle-time issues in getting stuff requisitioned, provisioned, and configured, and other intervening issues for the BoEE, including their Primary election which further negatively impacted the time frame.  This led to a very compressed amount of time to stage and conduct this entire exercise;
  2. Transparency vs. Scrutiny:  The desired public transparency put everyone involved in a highly concentrated light of public scrutiny, and margins of otherwise tolerable error allowed during a typical test phase were nonexistent in this setting – even the slightest oversight typically caught in a normal testing phase was considered fault intolerant, as if the Pilot were already in production;
  3. (Web) Application Design:  Web applications for high-value, high-risk data require substantial work to avoid brittleness.  Thankfully, none of the TrustTheVote Elections Technology Framework will require an Internet-connected Web application or service – so the 3rd lesson is how much of a relief that is going forward for us; and
  4. No Immunity from Mistake: Even the most experienced professionals are not immune from mistake or misstep, especially when they are working under very skeptical public scrutiny and a highly compressed time schedule our development team, despite a combined total of 7 decades of experience, included.

So, we learned some valuable lessons from this exercise. We still believe in the public transparency mandate, and fully accept responsibility for the goof in the application development and release engineering process.

Now, there is more to say about some wholly disconnected issues regarding other discovered network vulnerabilities, completely beyond our control (see #0 above), but we’ll save comment on that until after the D.C. Office of the CTO completes their review of the Michigan intrusion exercise.   Next, we turn attention to some outcomes.

6. Outcomes
Let’s pull back up to the 30-thousand foot level, and consider what the discussion has been about (leaving aside foreign hackers).  This test revealed a security weakness of a Web application framework; how there can be flaws in application-specific extensions to routine Web functions like file upload, including flaws that can put those functions and files at risk.  Combine that with the use of Web applications for uploading files that are ballots.  Then, the discussion turns on whether it is possible (or prudent) to try to field any Web application software, or even any other form of software, that transfers marked ballots over the Internet.  We expect that discussion to vigorously continue, including efforts that we’d be happy to see, towards a legislative ruling on the notion, such to Ohio’s decision to ban digital ballot transfer for overseas voting or North Carolina’s recent enthusiastic embrace of it.

However, public examination, testing, and the related discussions and media coverage, were key objectives of this project.  Rancorous as that dialogue may have become, we think it’s better than the dueling monologues that we witnessed at the NIST conference on overseas digital voting (reported here earlier).

But this is an important discussion, because it bears on an important question about the use of the Internet, which could range from (a) universal Internet voting as practiced in other countries (which nearly everyone in this discussion, including the OSDV Foundation, agrees is a terrible idea for the U.S.), to (b) the type of limited-scope usage of the Internet that may be needed only for overseas and military voters who really have time-to-vote challenges, or (c) limited only to ballot distribution.  For some, the distinction is irrelevant.  For others, it could be highly relevant.  For many, it is a perilous slippery slope.  It’s just barely possible that worked examples and discussion could actually lead to sorting out this issue.

The community certainly does have some worked examples this year, not just the D.C. effort, and not just DoD’s FVAP pilots, but also other i-Voting efforts in West Virginia and elsewhere.  And thankfully, we hear rumors that NIST will be fostering more discussion with a follow-up conference in early 2011 to discuss what may have been learned from these efforts in 2010.  (We look forward to that, although our focus returns to open source elections technology that has nothing to do with the Internet!)

7. Our Technology Contributions
Finally, for the record, below we catalog the technology we contributed to the District of Columbia’s Overseas “Digital Vote-by-Mail” service (again, their label).  If warranted, we can expand on this, another day.  The assets included:

  1. Three components of the open source TrustTheVote (TTV) Project Elections Technology Framework: [A] the Election Manager, [B] the Ballot Design Studio, and [C] the Ballot Generator.
  2. We augmented the TTV Election Manager and TTV Ballot Design Studio to implement D.C.-specific features for election definition, ballot design, and ballot marking.
  3. We extended some earlier work we’ve done in voter record management to accommodate the subset of D.C. voter records to be used in the D.C. service, including the import of D.C.-specific limited-scope voter records into an application-specific database.
  4. We added a Web application user experience layer on top of that, so that voters can identify themselves as matching a voter database record, and obtain their correct ballot (the application and logic leading up to the blank ballot “download” function referred to above) and to provide users with content about how to complete the ballot and return via postal or express mail services.
  5. We added a database extension to import ballot files (created by the TTV Ballot Generator), using a D.C.-specific method to connect them to the voter records in order to provide the right D.C.-specific ballot to each user.
  6. We added the upload capability to the web application, so that users could choose the option of uploading a completed ballot PDF; this capability also included the server-side logic to encrypt the files on arrival.

All of these items, including the existing open-source TTV technology components listed above in 7.1 above, together with the several other off-the-shelf open-source operating system and application software packages listed in Section 2 above, were all integrated by D.C’s IT group to comprise the “test system” that we’ve discussed in this article.

In closing, needless to say, (but we do so anyway for the record) while items 7.1—7.5 can certainly be used to provide a complete solution for MOVE Act compliant digital blank ballot distribution, item 7.6 is not being used for any purpose, in any real election, any time soon.

One final point worth re-emphasizing: real election jurisdiction value from an open source solution…..

The components listed in 7.1—7.5 above provide a sound on-going production-ready operating component to the District’s elections administration and management for a fraction of the cost of limited alternative commercial solutions.  They ensure MOVE Act compliance, and do not require any digital ballot return.  And the District owns 100% of the source code, which is fully transparent and open source.  For the Foundation in general, and the TrustTheVote Project in particular, this portion of the project is an incontrovertible success of our non-profit charter and we believe a first of its kind.

And that is our view of D.C.‘s project to develop their “Digital Vote-by-Mail” service, and test it along with the digital ballot return function.  Thanks for plowing through it with us.

Where We Stand – Update on the D.C. Overseas Distance Balloting Project

I’ve been out on a temporary personal leave of absence due to a family crisis, but I want to weigh in on the progress of the D.C. distance balloting project where portions of the TrustTheVote Project elections technology framework are being deployed for the upcoming election in November.  And it appears that an announcement was made today by the BoEE (Board of Elections & Ethics), hopefully consistent with my remarks here.

I commented on 31.August that we believed they set a new timeline in order to make sure everything is correctly in place, and to make sure a public evaluation period could be conducted.  And I wrote that we thought that was a good idea – especially to ensure that public examination period.

In light of the new timetable, however, the D.C. BoEE’s ability to conduct that public review came into question due to MOVE Act’s 45-day requirement for ballot availability and the looming November generation election.

To be clear, the Foundation is committed to verifiable elections, and we would have a difficult time supporting the project in absence of a public examination of the new technology.  The OSDV is founded on the principles of transparency and trust which enforce the organization to stand by not only governmental regulation but also the public’s best interest.  Given that the deadline appears to be upon them to meet their 45-day lead-time for ballot distribution, it would seem that they cannot meet their commitment of a public evaluation period.

That is, unless you know, as Paul Harvey would say, the rest of the story.

And if you saw today’s press release from the BoEE, then you already know most of the rest of the story, but for those who haven’t …..

In fact, the District conducts its Primary on 14.September.  Given the time required to [a] certify that election and [b] produce the final ballot for the November election, it is virtually impossible for them to meet the 45-day requirement for MOVE Act compliance.  We knew this would be a problem but we remained confident they would work something out.  But then the U.S. Department of Justice denied their application for waiver of the 45-day requirement.

However, in fact, the D.C. BoEE has hammered out a separate Agreement with the United States Department of Justice to establish 04.October, 2010 as the new ballot overseas availability deadline.  That 8-page Agreement is presumably publicly available.

And finally, as I noted above, the District announced today that it would start the public examination period of the Pilot this Friday, 24.September and run it for six (6) days.

Here is what I am aware of about that: during the examination period, those who want to test and comment on the technology and usability of the service will be granted access to:

[a] the application,

[b] a complete system architectural diagram,

[c] a detailed 40 page technical white paper authored by the District’s Board of Elections CTO (and reviewed by the Foundation) and of course,

[d] access to the underlying (open) source code including source developed by the Foundation.

While we would’ve liked to have seen a longer public examination period prior to the election deployment, six days is better than nothing, at least an attempt, and potentially adequate because frankly, there just isn’t all that much “code” or that complex of an application to review.

And before someone says it, I really do not believe the BoEE will rush off to post some glowing press release on 01.October about how safe and secure the service is based on a 6-day review cycle.  If they do, I will take exception personally, here.

So, to me, the sliver of good news is there will be a public review before the DoJ stipulated ballot availability deadline.  One thing that should be of value is their CTO’s 40 page white paper — at least to the extent of answering questions about the what, why, etc.  I also have a copy of the DoJ stipulated agreement if anyone is interested.

With all of those points in mind, we continue to support the District’s plan to run its Pilot during the general election incorporating open source elections management software built by the TrustTheVote Project.

I just hope we can have some influence in the future on the length and guidelines of review periods for applications like this – if, in fact, we see any more of them.  Frankly, we’re heads down on framework components (e.g., counters, tabulators, marking devices, poll book, etc.) and have no real interest in any other overseas distance balloting project going forward, unless it is a compelling opportunity to further deploy our publicly available source code for the ballot design studio or elections management system, and the focus is on ballot generation (and not digital return).

Nevertheless, the OSDV looks forward to continuing its support of the D.C. Board of Elections and Ethics to provide greater integrity and efficiency in public elections.

And now you know, “the rest of the story.”

I’m Gregory…
…Good Day! *

[* with apologies to the late Paul Harvey’s signature sign-off]

D.C. Resets Timeline for Digital Vote By Mail Service

With the September Primary looming for the District of Columbia, they did the right thing yesterday, and hit the “reset button” on their project to pilot an alternative form of remote balloting exclusively for qualified overseas voters, as part of their MOVE Act compliance effort.  The project has been given some breathing room and will launch during the general election in November as publicly announced this morning.

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

Remote Voting Technology Workshop Wanders the Edge of an Intellectual Food Fight

[Note: This is a personal opinion piece and does not necessarily reflect the position of the Foundation or TrustTheVote Project.]

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

I am reporting tNIST_Logohis 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

Where We Stand – on D.C. and Elsewhere

We’ve been answering lots of questions about the OSDV Foundation’s role in the District of Columbia’s Pilot “digital vote-by-mail” project, including a recent post with a detailed account of the history leading up to the Pilot.  But there is one Q&A in particular that I want to share with a broader audience. It’s a two-part question:

  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

The D.C. Pilot Project: Facts vs. Fictions – From Our Viewpoint

The TrustTheVote Project of the Open Source Digital Voting (OSDV) Foundation achieved another important milestone two weeks ago this morning, this time with the District of Columbia Board of Elections and Ethics, although not without some controversy.  The short of it is, and most important to us, the Foundation has been given the opportunity to put real open source elections software into a production environment for a real public election.  But it turns out that milestone is struggling to remain visible.

[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 votesWe 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