The TrustTheVote Project CDO Greg Miller joined a panel of technology experts for a lively discussion on ways technology can expand the way citizens interact with their elected officials and their governement.
Viewing entries tagged
This evening at 5:00pm members of the TrustTheVote Project have been invited to attend an elections technology round table discussion in advance of a public hearing in Sacramento, CA scheduled for tomorrow at 2:00pm PST on new regulations governing Voting System Certification to be contained in Division 7 of Title 2 of the California Code of Regulations. Due to the level of activity, only our CTO, John Sebes is able to participate.
We were asked if John could be prepared to make some brief remarks regarding our view of the impact of SB-360 and its potential to catalyze innovation in voting systems. These types of events are always dynamic and fluid, and so we decided to publish our remarks below just in advance of this meeting.
Roundtable Meeting Remarks from the OSDV Foundation | TrustTheVote Project
We appreciate an opportunity to participate in this important discussion. We want to take about 2 minutes to comment on 3 considerations from our point of view at the TrustTheVote Project.
For SB-360 to succeed, we believe any effort to create a high-integrity certification process requires re-thinking how certification has been done to this point. Current federal certification, for example, takes a monolithic approach; that is, a voting system is certified based on a complete all-inclusive single closed system model. This is a very 20th century approach that makes assumptions about software, hardware, and systems that are out of touch with today’s dynamic technology environment, where the lifetime of commodity hardware is months.
We are collaborating with NIST on a way to update this outdated model with a "component-ized" approach; that is, a unit-level testing method, such that if a component needs to be changed, the only re-certification required would be of that discrete element, and not the entire system. There are enormous potential benefits including lowering costs, speeding certification, and removing a bar to innovation.
We're glad to talk more about this proposed updated certification model, as it might inform any certification processes to be implemented in California. Regardless, elections officials should consider that in order to reap the benefits of SB-360, the non-profit TrustTheVote Project believes a new certification process, component-ized as we describe it, is essential.
2nd, there is a prerequisite for component-level certification that until recently wasn't available: common open data format standards that enable components to communicate with one another; for example, a format for a ballot-counter's output of vote tally data, that also serves as input to a tabulator component. Without common data formats elections officials have to acquire a whole integrated product suite that communicates in a proprietary manner. With common data formats, you can mix and match; and perhaps more importantly, incrementally replace units over time, rather than doing what we like to refer to as "forklift upgrades" or "fleet replacements."
The good news is the scope for ballot casting and counting is sufficiently focused to avoid distraction from the many other standards elements of the entire elections ecosystem. And there is more goodness because standards bodies are working on this right now, with participation by several state and local election officials, as well as vendors present today, and non-profit projects like TrustTheVote. They deserve congratulations for reaching this imperative state of data standards détente. It's not finished, but the effort and momentum is there.
So, elections officials should bear in mind that benefits of SB-360 also rest on the existence of common open elections data standards.
3. Commercial Revitalization
Finally, this may be the opportunity to realize a vision we have that open data standards, a new certification process, and lowered bars to innovation through open sourcing, will reinvigorate a stagnant voting technology industry. Because the passage of SB-360 can fortify these three developments, there can (and should) be renewed commercial enthusiasm for innovation. Such should bring about new vendors, new solutions, and new empowerment of elections officials themselves to choose how they want to raise their voting systems to a higher grade of performance, reliability, fault tolerance, and integrity.
One compelling example is the potential for commodity commercial off-the-shelf hardware to fully meet the needs of voting and elections machinery. To that point, let us offer an important clarification and dispel a misconception about rolling your own. This does not mean that elections officials are about to be left to self-vend. And by that we mean self-construct and support their open, standard, commodity voting system components. A few jurisdictions may consider it, but in the vast majority of cases, the Foundation forecasts that this will simply introduce more choice rather than forcing you to become a do-it-yourself type. Some may choose to contract with a systems integrator to deploy a new system integrating commodity hardware and open source software. Others may choose vendors who offer out-of-the-box open source solutions in pre-packaged hardware.
Choice is good: it’s an awesome self-correcting market regulator and it ensures opportunity for innovation. To the latter point, we believe initiatives underway like STAR-vote in Travis County, TX, and the TrustTheVote Project will catalyze that innovation in an open source manner, thereby lowering costs, improving transparency, and ultimately improving the quality of what we consider critical democracy infrastructure.
In short, we think SB-360 can help inject new vitality in voting systems technology (at least in the State of California), so long as we can realize the benefits of open standards and drive the modernization of certification.
EDITORIAL NOTES: There was chatter earlier this Fall about the extent to which SB-360 allegedly makes unverified non-certified voting systems a possibility in California. We don't read SB-360 that way at all. We encourage you to read the text of the legislation as passed into law for yourself, and start with this meeting notice digest. In fact, to realize the kind of vision that leading jurisdictions imagine, we cannot, nor should not alleviate certification, and we think charges that this is what will happen are misinformed. We simply need to modernize how certification works to enable this kind of innovation. We think our comments today bear that out.
Moreover, have a look at the Agenda for tomorrow's hearing on implementation of SB-360. In sum and substance the agenda is to discuss:
- Establishing the specifications for voting machines, voting devices, vote tabulating devices, and any software used for each, including the programs and procedures for vote tabulating and testing. (The proposed regulations would implement, interpret and make specific Section 19205 of the California Elections Code.);
- Clarifying the requirements imposed by recently chaptered Senate Bill 360, Chapter 602, Statutes 2013, which amended California Elections Code Division 19 regarding the certification of voting systems; and
- Clarifying the newly defined voting system certification process, as prescribed in Senate Bill 360.
Finally, there has been an additional charge that SB-360 is intended to "empower" LA County, such that what LA County may build they (or someone on their behalf) will sell the resulting voting systems to other jurisdictions. We think this allegation is also misinformed for two reasons:  assuming LA County builds their system on open source, there is a question as to what specifically would/could be offered for sale; and  notwithstanding offering open source for sale (which technically can be done... technically) it seems to us that if such a system is built with public dollars, then it is in fact, publicly owned. From what we understand, a government agency cannot offer for sale their assets developed with public dollars, but they can give it away. And indeed, this is what we've witnessed over the years in other jurisdictions.
In this New Year, there are so many new opportunties for election tech work that our collective TrustTheVote head is spinning. But this week anyway, we're focused on next steps in our online voter registration (OVR) work -- planning sessions last week, meetings with state election officials this week, and I hope as a result, a specific plan of action on what we call will "Rocky 4". To refresh readers' memory, Rocky is the OVR system that spans several organizations:
- At OSDV, we developed and maintain the Rocky core software;
- RockTheVote adopted and continues to adopt extensions to it;
- RockTheVote also adapts the Rocky technology to its operational environment (more on that below, with private-label and API);
- Open Source Labs operates Rocky's production system, and a build and test environment for new software releases;
- Several NGOs that are RockTheVote partners also use Rocky as their own OVR system, essentially working with RTV as a public service (no fees!) provider of OVR as an open-source application-as-a-service;
- For a growing list of states that do OVR, Rocky integrates with the state OVR system, to deliver to it the users that RTV and these various other NGOs have connected to online a a result of outreach efforts.
With that recap in mind, I want to highlight some of the accomplishments that this collective of organizations achieved in 2012, and paved the way for more cool stuff in 2013.
- All told, this group effort resulted in over a million -- 1,058,994 -- voter registration applications completed.
- Dozens of partner organizations used Rocky to register their constituents, with the largest and most active being Long Distance Voter.
- We launched a private-label capability in Rocky (more below) that was used for the first time this summer, and the top 3 out of 10 private-label partners registered about 84,000 voters in the first-time use of this new Rocky feature, in a period of about 12 weeks.
- We launched an API in Rocky (more below), and the early adopter organizations registered about 20,000 voters.
That's what I call solid work, with innovative election technology delivering substantial public benefit.
Lastly, to set the stage for upcoming news about what 2013 holds, let me briefly explain 2 of the new technologies in 2012, because they're the basis for work in 2013. Now, from the very beginning of Rocky over 3 years ago, there was a feature called "partner support" where a a 3rd party organization could do a little co-branding in the Rocky application, get a URL that they could use to direct their users to Rocky (where the users would see the 3rd party org's logo), and all the resulting registration activity's stats would be available to the 3rd party org.
The Rocky API - But suppose that you're in an organization that has not just its own web site, but a substantial in-house web application? Suppose that you want your web application to do the user interaction (UI)? Well, the Rocky Application Programming Interface (API) is for just that. Your application do all the UI stuff, and when it's time to create a PDF for the voter to download, print, sign, and mail, your web app calls the Rocky API to request that, and get the results back. (There's an analogous workflow for integrating the state OVR systems for paperless online registration.) The Rocky backend does all the database work, PDF generation, state integration, stats, reporting, and the API also allows you to pull back stats if you don't want to manually use the Partners' web interface of Rocky.
Rocky Private Label - But suppose instead that you want something like that, but you don't actually want to run your own web application. Instead, you want a version of Rocky that's customized to look like a web property of your organization, even though it is operated by RockTheVote. That's what the private-label feature set is for. To get an idea of what it looks like, check out University of CA Student Association's private-label UI on Rocky, here.
That's the quick run-down on what we accomplished with Rocky in 2012, and some of the enabling technology for that. I didn't talk much about integration with state OVR systems, because enhancements to the 2012 "training wheels" is part of what we're up to now -- so more on that to come RSN.
And on behalf of all my colleagues in the TrustTheVote Project and at the OSDV Foundation, I want to thank RockTheVote, Open Source Labs, all the RTV partners, and last but not least several staff at state election offices, for making 2012 a very productive year in the OVR part of OSDV's work.
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:
- 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.
- Influence: We had very little (if any) influence over anything construed as policy, process, or procedure.
- 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.
- Advice: We were free to make recommendations and suggestions, and provide instructions and guidelines for server configurations, application deployment, and the like.
- 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.
- 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 Iran. We 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:
- 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;
- 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;
- (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
- 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:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
A couple of weeks ago I presented at OSCON and during the conference had an opportunity to sit down with Mac Slocum, Managing Editor for the O’Reilly Radar. We had about a half an hour conversation, for which we covered ~20 minutes of it on camera. You can find it here if you want to watch me jaw. But perhaps simpler below, I’ve listened to the tape, and captured the essence of my answers to Mac’s questions about what the Foundation is about and working on and the like. I promised Matt Douglass, our Public Relations Director I’d get this up for interested followers; apologize it took me a couple of weeks. 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:  a national ID system,  uniform standards for nationwide elections, and  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 2nd age of industrialism to the 3rd 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.
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:
- “Open Source Voting Project Succeeds in Production Deployment of New Transparent and Freely Available Elections Technology.” -or-
- “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:
- Development; and
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
Happy Friday-Apologies for the apparent radio-silence these past few weeks since returning from the Overseas Voting Summit in Munich. We've been very busy: handling 2 elections jurisdiction proposals and another large voter outreach group's request to adopt portions of our open source elections technology framework, with lots of related work effort.
But today, at the end of a particularly busy week, I am completely stoked to share a significant milestone with you:
The delivery into our Request For Comment process of the our draft public license for all of the TrustTheVote Project's software technology.
The OSDV Foundation Public License is being referred as the "OPL."
As promised several weeks ago, our Legal Department, in collaboration with and leadership from Heather Meeker of Greenberg & Traurig (our licensing counsel), has completed the first DRAFT of the OSDV Foundation royalty free open source License.
The draft is accompanied by a "Rationale Memo" which explains the reasoning behind decisions made in the drafting of this License under which all open source code from the TrustTheVote Project will be made available on a royalty free basis.
We are now passing these documents into the RFC (Request For Comment) process within our TrustTheVote Project Stakeholder Community, which numbers in excess of 200 individuals. But we want everyone's comments, and encourage you to offer your input, even if you are not yet a Stakeholder Community member (you may request an invitation to join that community from stakeholder-replies at osetfoundation dot org.)
We wish to publicly thank Heather Meeker and her team at www.gtlaw.com for all of their wonderful support and guidenace in this effort. Seriously, if you ever have any needs for technology licensing lawyers who have been at the center of the open source legal and policies issues since it all began, you need to check out Heather's team.
We believe these documents together will (finally) clarify our reasons for having to develop a new license and should put to rest the swirling rumors, theories, and opinions on our licensing strategy. We look forward to your remarks nonetheless.
Have a great weekend! Gregory
I'd like to thank Eric Rescorla for making an excellent and pithy point about the purpose of publishing images of marked ballots. But first, thanks (again) to Mitch Trachtenberg of the Humboldt Transparency Project for publishing a hand-picked set of ballot images that provide a great example of the difficult borderline cases of interpreting hard-marked paper ballots -- whether it is a human or some software doing the interpreting. Ballot publication can show how much of a given election result actually depended on these borderline cases. Eric made a broader point that is so widely misunderstood that it truly merits repetition:
The main point of publishing ballot images is to allow people to independently verify that the images published correspond to the votes recorded for those images.
True, but verification requires more than ballot images - it requires that each image is published along with information about how that ballot's marks were interpreted as votes that were counted. I cringe every time somebody talks about ballot image publication as though it were just posting some JPEGs on a Web site.
By viewing the images plus these "cast ballot records", members of the public can look at a ballot image and decide for themselves whether they think its votes were interpreted correctly -- and if not, whether the putative mistakes are enough to effect the outcome of a race.
And just as important, consider the cases where an election official is involved in deciding an ambiguous mark - particularly at large scales such as with vote-by-mail. As a result, broader transparency requires that the election process maintain audit records of these decisions, in case they need to be re-visited.
So, sure, the publication of images alone is helpful for transparency, but Mitch's examples show how much interpretive leeway there can be. And in close elections, that leeway can influence whether a recount is required, or even influence an election result. So it's just as important to maintain and publish cast-ballot records, audit records, and the like.
But that is a lot of work!
And often is not feasible with current voting systems and election management technology. It's actually quite a job to maintain and publish all this information in a form useful to members of the public - a job that we're working on at the TrustTheVote Project of course, by building all of our election technology system components with the "Save Everything" principle.
The Federal Communications Commission (FCC) asked for public comment on the use of the Internet for election-related activities (among other digital democracy related matters). They recently published the responses, including those from OSDV. I'll let Greg highlight the particularly public-policy-related questions and answers, but I wanted to highlight some aspects of our response that differ from some others.
- Like many respondents, we commented on that slippery phrase "Internet voting", but focused on a few of the specific issues that apply particularly in the context of overseas and military voters.
- Also in that context, we addressed some uses of the Internet that could be very beneficial, but are not voting per se.
- We contrasted other countries' experiences with elections and the Internet with the rather different conditions here in the U.S.
For more information, of course, I suggest reading our response. In addition, for those particularly interested in Internet voting and security, you can get additional perspectives from the responses of TrustTheVote advisors Candice Hoke and David Jefferson, which are very nicely summarized on the Verified Voting blog.
Yes, it's still a work in progress (I guess they remain that, forever.) But recently we've done quite a bit of neatening (gardening as they say among some wiki-geeks.) up of the TrustTheVote.org wiki. As we work, we will continue to add most of all we know and think as of a certain point in time. Between the TrustTheVote wiki and this blog, you should be able to have a pretty clear x-ray into the TrustTheVote project.
Wiki's, unlike blogs, don't change on a daily basis, and act more like a web site or document repository than as a newsletter or periodic update. Our goal is that as time goes by, you will be able to answer questions you have about TrustTheVote's approach and projects, status reports, images and documents, and so on.
So let me give you a tour of some items of interest in the wiki. On the front page, there are a few landmarks to help you find stuff. In the top right corner, you see a list of the major TrustTheVote projects. You see links such as "Digital Voting Records System" and "Data Layer" among others. Each of these links goes to a project page, which you will see is in various stages of completeness.
Further on the front page, on the right, below the projects, is a "Recently Changed" list, which shows you exactly what pages have been most recently edited, and actually when that was, so you can see the parts of the wiki that we are working on.
In the left margin, you see an area called "Navigations". Note the TTV Projects link which takes you to a one page table of all the projects with very brief summaries of what they are, so it's a good place to get an overview.
Also in that same section is a "Stakeholder Community" link where we are putting information that we are exchanging with out stakeholder community, "a group of election officials, election technologists, election process experts, and advocates, who have graciously offered their advice to the OSDV Foundation's TrustTheVote Project."
I hope you will find this wiki a useful resource. You may notice that at this moment it is not editable; this is because we need to figure out a way to allow people to contribute to it without at the same time opening it up to the usual vandals and spammers that love to use open wikis as a launch pad for link farms and other non-sense.