Tagged TrustTheVote

State Certification of Future Voting Systems — 3 Points of Departure

In advance of this week’s EVN Conference, we’ve been talking frequently with colleagues at several election oriented groups about the way forward from the current voting system certification regime. One of the topics for the EVN conference is a shared goal for many of us: how to move toward a near future certification regime that can much better serve state election officials in states that want to have more control, customization, and tailoring of the certification process, to better serve the needs of their local election officials.

Read more

Election Results: Data-Wrangling Los Angeles County

LA County CA is the mother of all election complexities, and the data wrangling was intense, even compared to the hardly simple efforts that I reported on previously. There are over 32,000 distinct voting regions, which I think is more than the number of seats, ridings, chairs, and so on, for every federal or state houses of government in all the parliamentary democracies in the EU.

The LA elections team was marvelously helpful, and upfront about the limits of what they can produce with the aging voting system that they are working hard on replacing. This is what we started with.

  • A nicely structured CSV file listing all the districts in LA county: over 20 different types of district, and over 900 individual districts.
  • Some legacy GIS data, part of which defined each precinct in terms of which districts it is in.
  • The existing legacy GIS data converted into XML standard format (KML), again, kindly created byLA CC-RR IT chief, Kenneth Bennett.
  • A flat text file of all the election results for the 2012 election for every precinct in LA County, and various roll-ups.
  • A sort of Rosetta Stone that is just the Presidential election results, but in a well-structured CSV file, also very kindly generated for us by Kenneth.

You’ll notice that not included is a definition of the 2012 election itself – the contests, which district each contest is for, other info on the contest, info on candidates, referenda, and so. So, first problem, we needed to reverse engineer that as best as we could, from the election results. But before we could do that, we had to figure out how to parse the flat text file of results. The “Rosetta Stone” was helpful, but we then realized that we needed information about each precinct that reported results in the flat text file. To get the precinct information, we had to parse the legacy GIS data, and map it to the districts definition.

Second problem was GIS that wasn’t obvious, but fortunately we had excellent help from Elio Salazar, a member of Ken’s team who specializes in the GIS data. He helped us sort out various intricacies and corner cases. One of the hardest turned out to be the ways in which one district (say, a school district) is a real district used for referenda, but is also sub-divided into smaller districts each being for a council seat. Some cities were subdivided this way into council seats, some not; same for water districts and several other kinds of districts.

Then, as soon as we thought we had clear sailing, it turned out that the districts file had a couple minor format errors that we had to fill by hand. Plus there were 4 special case districts that weren’t actually used in the precinct definitions, but were required for the election results. Whew! At that point we though we had a complete election definition including the geo-data of each precinct in KML. But wait! We had over 32,000 precincts defined, but only just shy of 5,000 that reported election results. I won’t go into the details of sub-precincts and precinct consolidation, and how some data was from the 32,000 viewpoint and other data from the 4,993 viewpoint. Or why 4,782 was not our favorite number for several days.

Then the final lap, actually parsing all the 100,000 plus contest results in the flat text file, normalizing and storing all the data, and then emitting it in VIP XML. We thought we had a pretty good specification (only 800 words long) of the structure implicit in the file. We came up with three major special cases, and I don’t know how many little weird cases that turned out not to be relevant to the actual vote counts. I didn’t have the heart to update the specification, but it was pretty complex, and honestly the data is so huge that we could spend many days writing consistency checks of various kinds, and manual review of the input to track down inconsistencies.

In the end, I think we got to a pretty close but probably not perfect rendition of election results. A truly re-usable and reliable data converter would need some follow-on work in close collaboration with several folks in Ken’s team — something that I hope we have the opportunity to do in a later phase of work on VoteStream.

But 100% completeness aside, we still had excellent proof of concept that even this most complex use case did in fact match the standard data model and data format we were using. With some further work using the VIP common data format with other counties, the extended VIP format should be nearly fully baked and ready work with the IEEE standards body on election data.

— EJS

Election Results: Data-Wrangling Travis County

Congratulations if you are reading this post, after having even glanced at the predecessor about Ramsey County data wrangling — one of the longer and geekier posts in recent times at TrustTheVote. There is a similar but shorter story about our work with Travis County Texas. As with Ramsey, we started with a bunch of stuff that Travis Elections folks gave us, but rather than do the chapter and verse, I can summarize a bit.

In fact, I’ll cut to the end, and then go back. We were able to fairly quickly develop data converters from the Travis Nov 2012 data to the same standards-based data format we developed for Ramsey. The exception is the GIS data, which we will circle back to later. This was a really good validation of our data conversion approach. If it extends to other counties as well, we’ll be super pleased.

The full story is that Travis elections folks have been working on election result reporting for some time, as have we at TrustTheVote Project, and we’ve learned a lot from their efforts. Because of those efforts, Travis has worked extensively on how to use the data export capabilities of their voting system product’s election management system. They have enough experience with their Hart Intercivic EMS that they know exactly the right set of export routines to use to dump exactly the right set of files. We then developed data converters to chew up the files and spit out VIP XML for the election definitions, and also a form of VIP XML for the vote tallies.

The structure of the export data roughly corresponds to the VIP schema; one flat TXT file that presents a list of each of the 7 kinds of basic item (precinct, contest, etc.) that we represent as VIP objects; and 4 files that express relations between types of objects, e.g. precincts and districts, or contests and districts. As with Ramsey, the district definitions were a bit sticky. The Travis folks provided a spreadsheet of districts, that was a sort of extension of the exports file about districts. We had to extend the extensions a bit, for similar reasons outlined in the previous account of Ramsey data-wrangling. The rest of the files were a bit crufty, with nothing to suggest the meaning of the column entries other than the name of the file. But with the raw data and some collegial help from Travis elections folks, it mapped pretty simply to the standard data format.

There was one area though, where we learned a lot more from Travis. In Travis with their Hart system, they are able to separately track vote tallies for each candidate (of course, that’s the minimum) as well as: write-ins, non-votes that result from a ballot with no choice on it (under-votes), and non-votes that result from a ballot with too many choices (over-votes). That really helped extend the data format for election results, beyond what we had from Ramsey. And again, this larger set of results data fit well into our use of the VIP format.

That sort of information helps total up the tallies from each individual precinct, to double check that every ballot was counted. But there is also supplementary data that helps even more, noting whether an under or over was from early voting, absentee voting, in person voting, etc. With further information about rejected ballots (e.g. unsigned provisional ballot affadavits, late absentee ballots), one can account for every ballot cast (whether counted or rejected), every ballot counted, every ballot in every precinct, every vote or non-vote from individual ballots — and so one — to get a complete picture down to the ground in cases where there are razor thin margins in an election.

We’re still digesting all of that, and will likely continue for some time as we continue our election-result work beyond the VoteStream prototype effort. But even at this point, we think that we have the vote-tallies part of the data standard worked out fairly well, with some additional areas for on-going work.

— EJS

Election Results: Data-Wrangling Ramsey County

Next up are several overdue reports on data wrangling of county level election data, that is, working with election officials to get legacy data needed for election results; and then putting the data into practical use. It’s where we write software to chew up whatever data we get, put it in a backend system, re-arrange it, and spit it out all tidy and clean, in a standard election data format. From there, we use the standard-format data to drive our prototype system, VoteStream.

I’ll report on each of 3 and leave it at that, even though since then we’ve forged ahead on pulling in data from other counties as well. This reports from the trenches of VoteStream will be heavy on data-head geekery, so no worries if you want to skip if that’s not your cup of tea. For better or for worse, however, this is the method of brewing up data standards.

I’ll start with Ramsey County, MN, which was our first go-round. The following is not a short or simple list, but here is what we started with:

  • Some good advice from: Joe Mansky, head of elections in Ramsey County, Minnesota; and Mark Ritchie, Secretary of State and head of elections for Minnesota.
  • A spreadsheet from Joe, listing Ramsey County’s precincts and some of the districts they are in; plus verbal info about other districts that the whole county is in.
  • Geo-data from the Minnesota State Legislative GIS office, with a “shapefile” for each precinct.
  • More data from the GIS office, from which we learned that they use a different precinct-naming scheme than Ramsey County.
  • Some 2012 election result datasets, also from the GIS office.
  • Some 2012 election result datasets from the MN SoS web site.
  • Some more good advice from Joe Mansky on how to use the election result data.
  • The VIP data format for expressing info about precincts and districts, contests and candidates, and an idea for extending that to include vote counts.
  • Some good intentions for doing the minimal modifications to the source data, and creating a VIP standard dataset that defines the election (a JEDI in our parlance, see a previous post for explanation).
  • Some more intentions and hopes for being able to do minimal modifications to create the election results data.

Along the way, we got plenty of help and encouragement from all the organizations I listed above.

Next, let me explain some problems we found, what we learned, and what we produced.

  •  The first problem was that the county data and GIS data didn’t match, but we connected the dots, and used the GIS version of precint IDs, which use the national standard, FIPS.
  • County data didn’t include statewide districts, but the election results did. So we again fell back on FIPS, and added standards-based district IDs. (We’ll be submitting that scheme to the standards bodies, when we have a chance to catch our breath.)
  • Election results depend on an intermediate object called “office” that links a contest (say, for state senate district 4) to a district (say, the 4th state senate district), via an office (say, the state senate seat for district 4), rather than a direct linkage. Sounds unimportant, but …
  • The non-local election results used the “office” to identify the contest, and this worked mostly OK. One issue was that the U.S. congress offices were all numbered, but without mentioning MN. This is a problem if multiple states report results for “Representative, 1st Congressional District” because all states have a first congressional district. Again, more hacking the district ID scheme to use FIPS.
  • The local election results did not work so well. A literal reading of the data seemed to indicate that each town in Ramsey County in the Nov. 2012 election had a contest for mayor — the same mayor’s office. Ooops! We needed to augment the source data to make plain *which* mayor’s office the contest was for.
  • Finally, still not done, we had a handful of similarly ambiguous data for offices other than mayor, that couldn’t be tied to a single town.

One last problem, for the ultra data-heads. Turns out that some precincts are not a single contiguous geographical region, but a combination of 2 that touch only at a point, or (weirder) aren’t directly connected. So our first cut at encoding the geo-data into XML (for inclusion in VIP datasets) wasn’t quite right, and the Google maps view of the data, had holes in it.

So, here is what we learned.

  • We had to semi-invent some naming conventions for districts, contests, and candidates, to keep separate  everything that was actually separate, and to disambiguate things that sounded the same but were actually different. It’s actually not important if you are only reporting results at the level of one town, but if you want to aggregate across towns, counties, states, etc., then you need more. What we have is sufficient for our needs with VoteStream, but there is real room for more standards like FIPS to make a scheme that works nationwide.
  • Using VIP was simple at first, but when we added the GIS data, and used the XML standard for it (KML), there was a lot of fine-tuning to get the datasets to be 100% compliant with the existing standards. We actually spent a surprising amount of time testing the data model extensions and validations. It was worth it, though, because we have a draft standard that works, even with those wacky precincts shaped like east and west Prussia.
  • Despite that, we were able to finish the data-wrangling fairly quickly and use a similar approach for other counties — once we figured it all out. We did spend quite a bit of time mashing this around and asking other election officials how *their* jurisdictions worked, before we got it all straight.

Lastly, here is what we produced. We now have a set of data conversion software that we can use to start with the starting data listed above, and produce election definition datasets in a repeatable way, and making the most effective use of existing standards. We also had a less settled method of data conversion for the actual results — e.g., for precinct 123, for contest X, for candidate Y, there were Z votes — similar for all precincts, all contests. That was sufficient for the data available in MN, but not yet sufficient for additional info available in other states but not in MN.

The next steps are: tackle other counties with other source data, and wrangle the data into the same standards-based format for election definitions; extend the data format for more complex results data.

Data wrangling Nov 2012 Ramsey County election was very instructive — and we couldn’t have done it without plenty of help, for which we are very grateful!

— EJS

Comments Prepared for Tonight’s Elections Technology Roundtable

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.

1. Certification

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.

2. Standards

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:

  1. 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.);
  2. 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
  3. 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: [1] assuming LA County builds their system on open source, there is a question as to what specifically would/could be offered for sale; and [2] 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.

Onward.

TrustTheVote’s Next Steps in Online Voter Registration Technology

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.

— 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.

Recapping The OSCON O’Reilly Radar Conversation

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’ReillyWell our time is limited, but you must know I can’t resist this last question, which is probably controversial but our audience is really curious about.  Will online voting ever be viable?

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

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

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

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

That said, we should be mindful that the Internet cloud has darkened the doorstep of nearly every aspect of society as we’ve moved from the 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.

-GAM|out

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

OSDV Foundation Public License Draft Published for Review

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 osdv 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