Viewing entries in
TrusttheVote / OSDV


OSET Featured on TechCrunch

OSET Foundation Board Member Chris Kelly, a Silicon Valley venture investor and philanthropist, and former Facebook exec, pens an op-ed for TechCrunch on the Election Day 2014.


1 Comment

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.


1 Comment


A New Opening for "Open"

I'm still feeling a bit stunned by recent events: the IRS has finally put us at the starting point that we had reasonably hoped to be at about 5 years ago. Since then, election tech dysfunction hasn't gone away; U.S. election officials have less funding than ever to run elections; there are more requirements than ever for the use of technology in election-land; and there are more public expectations than ever of operational transparency of "open government" certainly including elections; and the for-profit tech sector does not offer election officials what they need. So there's more to do than we ever expected, and less time to do it in. For today, I want to re-state a focus on "open data" as the part of "open source" that's used by "open gov" to provide "big data" for public transparency. Actually I don't have anything new to say, having re-read previous posts:

It's still the same. Information wants to be free, and in election land, there is lots of it that we need to see, in order to "trust but verify" that our elections are all that we hope them to be. I'm very happy that we now have a larger scope to work in, to deliver the open tech that's needed.

-- EJS



TrustTheVote Project Earns Backing from Knight Foundation Prototype Fund

Greetings All- Apologies for the extended radio silence.  I promise to one day be able to explain in some detail why that occasionally occurs, but for now I have to remain, um, silent on that point.  However, I am very happy to share with you that one of the additional reasons for being distracted from this forum has been work that resulted in today's announcement.

Indeed, the OSDV Foundation's TrustTheVote Project has earned a substantial grant from the Knight Foundation's Prototype Fund.  Such was a favorable consequence of being a near brides-maid in their Knight Foundation News Challenge, which we competed for earlier this Spring.  While we did not make the final cut for the major grant program, the Knight Foundation was sufficiently excited about our proposal for open data standards based election night reporting services that they awarded us a Prototype Grant.

You can learn more about our project here.  In a sentence, let me state the metes and bounds of this project.  We will share a little about what, how, why, and when in subsequent posts.

In a sentence our project is: Building an open source election night results reporting service tying directly into local and State elections data feeds (for which the TrustTheVote Project has already helped establish the required standards), with a public-facing web app, and a robust API to enable anyone to access reporting data for further analysis and presentation.

Some Details So, essentially the Knight Foundation's Prototype Fund is designed to provide a "seed grant" to enable a prototype or "early Alpha" of an app, service, or system that advances the causes of civic media and citizen engagement with news and information.  Our Election Night Reporting Service is a perfect fit.  And this 6-month project is intended to finish the development and deployment stages for an evaluation/test run on the system.  I need to point out that it will definitely be a prototype and will not include some necessary components to put the system into production, but enough framework and scaffolding to conduct a robust "alpha test for which 3 or 4 elections jurisdictions have agreed to participate.

We will announce those jurisdictions soon.  The test will utilize an early release of the Results Scoreboard -- a web-based app/service to display elections results.  The alpha will also deliver an API and data feed service.

In our next post, we will discuss some details about the project in terms of the what, how, and why. But let me say quickly that the name has some legacy meaning, because its not just about election night -- its about election reporting any time.  So, stay tuned!

I'd like to thank the tremendous support of OSDVF Board and TTV Project Advisers who worked closely with us on the Knight News Challenge application and for the work of the Core team and our CTO John Sebes on hammering out sufficient details originating in our work with Travis County, TX a couple of years ago.  Without their contributions -- many in the 11th hour and into the pre-dawn hours last March --  this would not have been possible.




Poster and Slides from OSDV at NIST Workshop on Common Data Format Standards

Many thanks to the engaged audience for OSDVer Anne O'Flaherty's presentation yesterday at National Institute of Standards and Technology (NIST), which hosted a workshop on Common Data Formats (CDFs) and standards for data interchange of election data. We had plenty to say, based on our 2012 work with Virginia State Board of Elections (SBE), because that collaboration depends critically on CDFs. Anne and colleagues did a rather surprising amount of data wrangling over many weeks to get things all hooked up right, and the lessons learned are important for continuing work in the standards body, both NIST and the IEEE group working on CDF standards.

As requested by the attendees, here are online versions of the poster and the slides for the presentation "Bringing Transparency to Voter Registration and Absentee Voting."





Help Wanted; The Search is On

Greetings All-
Sorry we've been away from the podium here for a couple of weeks.  We're heads-down on some very exciting projects.  But not nearly as exciting as what I have to announce today.  Let's get right to it.

The time has comeSome might argue it’s overdue.  Growth of the activities and work here, and the need for speed in advancing the agenda of open source elections technology triggers today’s announcement:

The OSDV Foundation Leadership Team is growing, and we're officially recruiting for a new Chief Executive Director.

The search is on, and we want your help in locating an absolute “A-player” to lead the next level of growth for the Open Source Digital Voting Foundation.

Wait a minute,” you say. “Wait a minute!  Doesn’t the Foundation already have an Executive Director… or actually like two of them?”  Oh, definitely—you're right, two of them.  John Sebes and myself, co-founders and co-executive directors (as mandated by the Foundation’s by-laws), have been tirelessly leading and managing this 4-year effort since Day 1 with the generous support and advice of our Board.

We have also have been managing all aspects of Foundation development (read: funding) and technology work (e.g., the TrustTheVote Project).  And the workload has become overwhelming.  We each need to now focus on our particular domain expertise in order to sustain and accelerate the momentum the TrustTheVote Project is gaining.

So, it is time for both of us to narrow our respective scope of efforts.  For myself, this means focusing on stakeholder community development, public outreach, adoption and deployment, and strategic alliances and backing.  In the commercial world, this might be akin to the kind of role I’ve played in the tech sector for about 1/2 of my career: running marketing and business development.

For John, this means the heavy responsibility for leading the core mission of the non-profit: open source elections technology design and development efforts. This is aligned with his commercial world experience: as an engineering manager and chief technology officer.

What’s left are all of the activities associated with day-to-day operational leadership, to effectively manage and grow the Foundation.  This includes executive leadership in major fund raising from all sources, accounting, finance, administration, legal affairs, and public relations.  It is in the commercial world, a CEO role.  In other words, with the growth in activities and work, the leadership team must expand and bring in the right talent to take this to the next level.

We’ve successfully been managing what essentially amounts to nearly a $1.0M  operation; a tiny start-up by commercial comparison, but significant by some non-profit comparisons.  We realize that we must now elevate this to a $7-10M annual operation in order to maintain the momentum we’re generating and be the kind of change agent for public elections integrity and trust according to our Charter.

And we’re experienced enough to appreciate that neither of us is well suited to provide that non-profit leadership and somehow keep doing what we do best.

The details of technology architecture and building the stakeholder community are more than full-time efforts alone.  To be sure, both John and I have managed commercial technology operations greater than $10M per year (but in those cases had staffing and resources commensurate with the size of operation).  However, the nuances of a non-profit operation, its methods of funding, and the need for our acquired domain expertise on elections technology, flat out prohibits us from trying to do it all any longer.

So, Here We Go.
We’ve uploaded a position description on the TrustTheVote Wiki.  You will find it here. And there is a companion document that provides some background, here.  We’ve engaged with our Board, an Executive Recruiter, and our advisers to expand the search.

With today’s announcement, we look to you, our backers, supporter, stakeholders, and other interested onlookers to join in the search for our ideal candidate to lead this exciting and important project blending the best in technology innovation, with the imperative agenda of “critical democracy infrastructure.”

And it’s a helluva lot of fun working to be the change agent for accuracy, transparency, verification, and security of public elections technology in a digital age.  To be sure, there's a bunch of great stuff going on here: the digital poll book project based on the Apple iPad; the election night reporting system project using open data and web services distribution; work with the Federal Elections Assistance Commission on component-level certification for the open source Tabulator we're building; and working with the IEEE 1622 Standards Group on our proposed standard for open election data formats.

Please spread the word; the search is ON.  If you know of an ideal candidate, or even think you might be one yourself, we want to hear from you.  Ping us.  You can also drop a note to "edsearch" sent to our Foundation web site domain.




2011: A Look Ahead; Another Glance Back

As Greg said in his New Year's posting, we've been planning a variety of activities for 2011, and reflecting on what we did in 2010, much that remains to do, and to do better. But at the risk of boring you with a laundry list, I wanted to provide some additional detail on some of the 2010 activities that Greg mentioned. Many of the items listed below serve to indicate how much of the work in election technology (ours and others) has to get very detail oriented in order to actually deliver. Voter Registration

  • Released version 2.0 of the TTV Online Voter Registration tool.
  • Put OVRv2 into production, operated by Open Source Labs and managed by RockTheVote.
  • Under RTV's management, OVR has served well over 200,000 registrants for the 2010 election cycle, nearing the quarter-million total.

Election Management System

  • First-ever open source election management software deployed for use in DC and VA overseas voting projects in November 2010 elections.
  • TTV Election Manager supports DC legacy data formats, VIP standard election data for VA, DC-specific jurisdiction definitions, and first-ever new VA custom jurisdictions for local referenda.
  • First-ever system for computing and proofing and entire state's worth of election data and ballot definitions.

Ballot Design

  • First-ever open source paper ballot design system supports local and state specific ballot formats and composition rules for multiple jurisdictions including DC, VA, NH
  • For VA statewide election, over 2,700 locality-specific ballots generated, including first-ever state-law compliant ballots for special classes of non-local UOCAVA voters.
  • First-ever generation of dual-use ballot documents, the same document marked either digitally or physically to become the same legal paper ballot of record.

Overseas Ballot Distribution

  • Fully localized ballots delivered to thousands of UOCAVA voters worldwide
  • Data integration with state voter record databases, ensuring every eligible UOCAVA voter gets their correct ballot
  • Public test of Digital Ballot Return - a controversial activity with many lessons learned on all sides, but we're proud to have supported the D.C. BOEE in a rare example of responsible open public testing that should be the model for any assessment of new election technology.

Open-Source Software License

  • Released the OSDV Public License, or OPL, the first open source license specifically designed to aid state and local governments in acquiring open-source technology.
  • Published the OPL Rationale document, explaining the goals of the OPL and the reasoning behind each element of the OPL as meeting government needs for software licensing.

Public Speaking and Education

As you can see from these highlights -- the tip of the proverbial iceberg -- 2010 was a busy year for us. And 2011 is shaping up to be even busier!

-- EJS



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

I’ve been out on a temporary personal leave of absence due to a family crisis, but I want to weigh in on the progress of the D.C. distance balloting project where portions of the TrustTheVote Project elections technology framework are being deployed for the upcoming election in November.  And it appears that an announcement was made today by the BoEE (Board of Elections & Ethics), hopefully consistent with my remarks here. I commented on 31.August that we believed they set a new timeline in order to make sure everything is correctly in place, and to make sure a public evaluation period could be conducted.  And I wrote that we thought that was a good idea – especially to ensure that public examination period.

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

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

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

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

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

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

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

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

[a] the application,

[b] a complete system architectural diagram,

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

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

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

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

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

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

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

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

And now you know, "the rest of the story."

I'm Gregory... ...Good Day! *

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



OSCON Shows the Movement is Growing

One of our Executive Directors, Gregory Miller, had the opportunity to attend the O'Reilly Media's Open Source Conference this week in my home town of Portland, Oregon (his too, in fact).  Summer is in full swing here, although no major heat waves so far; we've been enjoying cool morning marine layer followed by a pleasant upper 70s low 80s by mid afternoon lingering into an evening ideal for Portland's many sidewalk cafes.  This was a perfect setting for a conference that continues to grow.  But maybe its just that people prefer to visit Portland in the summer more than struggle with the congestion of the Silicon Valley... and this year that included a considerable international presence of attendees. The OSDV Foundation was invited to host a panel session on the role of open source in elections and voting systems.  Here is a copy of Gregory's presentation from that well attended session yesterday.

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

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

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

-Matt Director, Communications & Outreach



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



District of Columbia to Adopt TrustTheVote Technology for Overseas Voter Support in September Primary

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

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

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

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

-- EJS



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 osetfoundation dot org.)

We wish to publicly thank Heather Meeker and her team at 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



The Looming UOCAVA Internet Voting Debate

This is the last long post about the UOCAVA Summit underway in Munich, but in an unannounced move, below I am disclosing all of the topics and questions in tomorrow’s (apparently) much anticipated Internet Voting Debate. I apologize to those looking for a quick (more typical) blog post on the matter.  But there is (I think) interesting stuff below.

Fact: Silly though I think it is, controversy is swirling around this event; I’ve received more “hate mail” than necessary as moderator, and I believe its important to layout what exactly my line of questioning will be, so that you, the readers, can judge for yourself if I am trying to manipulate the discourse for or against the use of public packet-switched networks for transacting ballot data from public elections.  Think of this as our continuing effort to be transparent – one of our Foundation’s driving principles

So, less than 9 hours remain before we sit down to have what I intend to be a fair and balanced discussion about the challenges and opportunities, the fears, uncertainties, and doubts, and the real and present risks of using public packet switched networks for transacting public ballot data – the so-called Internet Voting debate.

And for me, I am more than ready to put this episode of a long running debate behind me.

Its not that I am no longer interested, nothing could be further from the truth.  But I look forward to slipping back into the mix of many discussing the topic without the klieg lights and responsibility of moderating the participants of a specific debate instance.

The problem is the vitriol nature of unsolicited feedback I’ve received in the past 3 days regarding this event – which is apparently getting far more attention than we anticipated.

Hate mail – its that simple.  And it’s coming from both sides of the debate.  And that’s surprising.  Activists on both sides are convinced that the OSDV Foundation, the Overseas Vote Foundation, and I are all out to railroad the other side in a debate that appears to be tilted against their interest.

Reality distortion fields – its that apparent.  They are being cast, but only I can tell you what is absolutely in my mind and what my intentions are.  And either people can choose to believe me or not.

So with one final effort on the eve of yet another intellectual wrestling match on this, let me try to set the record clear on our intention.  And to do so, in this post I am going to disclose to all interested – in advance – the questions of the Debate planned for 0900 CET tomorrow (about 2200 EDT/0100A Pacific).

First, let me share here the participant line-up:

Moderator: myself, Gregory Miller, Chief Development Officer, OSDV Foundation

Introduction: Dr. Andrew Appel, Professor Computer Science, Princeton University


Harri Hursti, Author: Hacking Democracy

Constanze Kurz, Engineer/Dipl. Inf., Humboldt University Berlin

Pamela Smith, President, Verified Voting

E. John Sebes, Chief Technology Officer, Open Source Digital Voting Foundation [*]


Alexander Trechsel, Professor of Political Science and Swiss Chair in Federalism and Democracy at the European University Institute (EUI) in Florence, Italy

Christian Bull, Senior Advisor, The Ministry of Local Government and Regional Development, Norway

Thad Hall, Associate Professor of Political Science and Research Fellow, University of Utah, USA

Tarvi Martens, Development Director at SK, Demographic Info, Computer & Network Security, Estonia

Closing Remarks: Honorable Debra Bowen, California Secretary of State

About that [*] after John’s name. Before moving to the questions, I want to comment on one of the many controversies that have bubbled up over this event.  In the 11th hour, Chantel Enguehard, Researcher and Teacher, Laboratoire d’Informatique de Nantes Atlantique rescinded her agreement to participate for this event on the “opposing side” of the argument for Internet Voting (after previously committing to do so and allowing the Conference to finance her attendance).  Ms. Enguehard has determined that it is not in her best professional (or apparently political) interest to be on any record as speaking against the use of the Internet for elections.  It is her choice, of course, but not the most courteous move to make on the eve of the debate, IMHO.

Let me be clear: I do not believe that just because someone takes a role in a debate staged for a conference as an information exercise, that such necessarily should label that participant as permanently having the opinions of that side of the argument.  And I would’ve been glad to go on record that she is participating in this capacity simply for the academic exercise of explaining the issues to the audience, but that her participation as an opponent does not necessarily reflect her otherwise neutral position on the topic.

Ms. Enguehard argues vigorously that we failed to understand the language nuances relegating the term "debate" in French to mean a discussion of many view points, including neutrals.  Sure.  And she had several weeks to inquire as to whether this was a potential language faux pas on our part (or hers).  She did not.

So, unable to reach an agreement, we’ve dismissed her (at this writing 2350 CET, Thursday) from the Debate, primarily at her insistence of modifying how we run the debate to accommodate her neutrality (you really cannot have a meaningful debate with “neutral” parties.)  The TrustTheVote Project Chief Technology Officer, John Sebes has agreed to stand in her place, although John, in fact, is trying to remain neutral himself on this controversial subject (he is against using the Internet for at least remote – home based – voting in public elections, but open to future possibilities of kiosk-based solutions provided certain issues in the client-server model can be addressed).

So we move forward with the Panelists as introduced above, and now in a move that I am taking on my own, and without advance notice to others, but to clear the air, below you will find a detail of the topics and the questions we will address in tomorrow’s debate, T-9 hours from this writing.

Before the debate begins, Dr. Andrew Appel of Princeton University will present this talk and slides.  We asked Dr. Appel, not (I repeat, not) because of his personal views, but because in looking at various knowledgeable individuals who could present a brief overview of the issues, we found Andrew’s presentation to be simple, straight forward, fair and balanced.  This has been a point of contention from the attack dogs for those in favor of iVoting, contending that we’re setting the debate up with a taint and favoritism towards the opponents by engaging Dr. Appel.  For the final time: nonsense.

Panelist’s Rules of Engagement

  1. I will address a question to either side, and a specific individual and they shall have a 2-minute answer.
  2. The opposing side shall have a 1-minute response.
  3. The original respondent may have an optional 30-second rebuttal at my discretion.
  4. We recognize that reducing this to an hour or so of “sound bites” would be a disservice to the important topic, so there are some situations, where I may engage a respondent or rebuttal in a 1-minute follow-up.  But in order to offer the audience a treatment – potentially not as comprehensive as we would like – on each topic below, “follow-up” opportunities will be allowed in limited circumstances, again at my discretion.
  5. I will do my best to rotate through each Panelist with questions; the fun part of this, any Panelist on either side may be asked to respond to any one of these questions.
  6. It is not our intention to overly control the discussion but it would be a failure to allow the discussion to dissolve into a disorderly argument, so I will respectfully as possible require adherence to this process.  And here is the enforcement clause: if a Panelist fails to yield when time is called more than once during the Debate, I will refrain from any further questions directed to that Panelist. And I do not wish to have that happen, so I look forward to everyone’s cooperation.
  7. The goal is to have an enjoyable, lively, yet informative debate.  Intellectually honest professionals can agree to disagree, and on this topic reasonable minds can and do differ.  So, remember, this is intended to be a “fun” showcase part of the Summit.
  8. Finally, in closing I will ask for a 5-minute closing statement from each side of the debate.

Debate Topics and Questions

A. eMail as a Comparator You, Panelists, are in consensus that eMail is not an appropriate way to return vote data (for example, sending an image attachment or a PDF of a marked absentee ballot). That noted, in comparison with other home-based voting schemes, these questions:

1. What does eMail voting lack that a client-server iVoting solution provides, in the scheme of voting from a home-based or remotely located PC using a World Wide Web interface?

2. What does eMail voting lack that ordinary vote-by-mail also lacks?

3. Do these answers help us identify some requirements for iVoting?

B. Data Center Management Both kiosk and home iVoting share the feature of a data center to host the various parts of an iVoting solution, including store vote data, etc.  That data center operation is a very important component of the entire iVoting operation, which gives rise to a series of questions we turn our attention to now.

Depending on time I may ask some or all of these questions:

1. Internet banking seems to work well, and is widely adopted without objection.  Does this provide a model for and lessons for iVoting?  Why or why not?

2. A bank must have a trust delegation model.  Which parts of that model would work for iVoting?

3. Are there applicable models for data center transaction audits in the banking world that provide an appropriate model for iVoting?

4. What technological expertise is required to assess the continuing reliability/trustworthiness of an iVoting solution?   Is this level of expertise accessible to the public officials who select such systems and/or who manage such systems?

5. How can election officials assess the "total cost of ownership" of an iVoting solution, beyond software license fees?  How does this compare with alternative solutions such as vote-by-mail?

6. If any of the proponents are proposing to use iVoting only for UOCAVA settings, what is the rationale for restricting the application of iVoting to this context?

C. Home vs. Kiosk iVoting Some experts draw a distinction between the use of voting kiosks or polling places with iVoting based ballot casting devices, and the use of home or office-based or otherwise remotely located computing devices to access such a ballot casting service.  Let’s ignore that particular distinction.  One thing we can stipulate is that Kiosk-based iVoting has different costs and logistics than home or remote iVoting solutions.  Let's not explore those issues.  I will ask each of the Proponents to state simply whether they’re proposing home-only, kiosk-only, or both models for iVoting systems.  Then we’ll address these questions:

1.  What are the comparative risks and advantages of both models?

2. What are the costs/benefits of these differing models?

3.   How do these costs compare to those of traditional non-iVoting polling places?

4.   How do the benefits of home or remote voting compare with Kiosk or polling place models?

D. The Paper Ballot Issue Some iVoting pilots have included the generation of a ballot-like paper that is retained by election officials.  Others do not.  Let us examine two points.

1.   What can these paper facsimiles best be used for; for example, should they be construed as ballots of record, a paper trail, a receipt, or something else?

2.   Are there chain of custody issues in the handling of these paper records that would be different for an overseas voting setting compared to a domestic voting setting?

E. Original Hand-Made Signatures Most industrialized democracies use some sort of method to authenticate the voter before they may cast a ballot.  It may be by hand written signature, voter identification card, or some other means.

1.   What methods are appropriate for iVoting systems?

2.   What is the likely leading objection to these authentication methods and how can it best be addressed?

F. Client Platform Integrity Assuming a traditional client-server model using a public packet-switched network for discussion purposes, the home/remote iVoting has a particular issue with the security risks of the remote PC being used as a voting terminal, including the integrity of the iVoting software executing on the PC, and the integrity of the vote data along the way from the voter across the network to the server.  Some of this has already been discussed, so I want to focus now on one particular aspect of integrity: data security means.  One of our Panelists mitigates these risks by using an "end-to-end" cryptographic method that allows election officials to detect large-scale client-side attacks for election fraud.  This is an interesting model, but raises these questions.

Depending on time I may ask some or all of these questions:

1.   Special end-to-end crypto protocols have been proposed in order to mitigate against the possibility against insider attacks against the servers.

1.1.        Are these methods workable, and are they practical?

1.2.        Are they ready for near term adoption and can their principles be understood sufficiently by elections officials and the public to gain wide acceptance?

2.   Is "detection" sufficient? That is, are the risks acceptable if attacks can be detected at scale?

3.   Is this acceptable-risk concept different depending on whether iVoting is for UOCAVA (overseas absentee) voters only, or for any and all eligible remote voters?

4.   Each Panelist can surely expound on whether client integrity issues must be resolved as a prerequisite for home/remote iVoting. But let's keep a tight focus on this for the benefit of our audiences.

4.1.        Please pick one reason why or why not client integrity issues must be first resolved, and explain it briefly.

4.2.        What about integrity of the Kiosk systems? Is it sufficient to have a degree of integrity comparable to those of voting devices in state side polling places?

Finally, I may have a bonus question, I am reserving from here, but it will be a follow-up from the above topical agenda.

OK, I leave it up to you, after reading the information above to make a call on whether I am intending to taint this debate or provide for a fair and balanced intellectually honest discussion on the issues, challenges, (and yes) opportunities in the use of the Internet in public elections.

Off to post-dinner gatherings; Sure its 23:55 CET.  It's Munich and the night is young, although we start in 9 hours. :-) GAM|out



A License to Adopt

Open Source Technology Licensing... We've been promising to respond to the chorus of concerns that we may drift from the standard GPL for our forthcoming elections and voting systems software platform and technology.  Finally, we can begin talking about it (mainly because I found a slice of time to do so, and not because of any event horizon enabling the discussion, although we're still working out issues and there will be more to say soon.)

gplv3-127x51From the beginning we’ve taken the position that open source licenses as they exist today (and there are plenty of them) are legally insufficient for our very specific purposes of putting publicly owned software into the possession of elections jurisdictions across the nation.

And of course, we’ve heard from activists, essentially up in arms over our suggestion that current licensing schemes are inadequate for our purposes.  Those rants have ranged from the sublime to the ridiculous, with some reasonable questions interspersed.  We’d like to now gently remind those concerned that we [a] benefit from a strong lineage of open source licensing experience dating back to the Mozilla code-release days of Netscape catalyzed by Eric Raymond’s Manifesto, [b] have considerable understanding of technology licensing (e.g., we have some deep experience on our Board and within our Advisory group, and I'm a recovering IP lawyer myself), and [c] are supported by some of the best licensing lawyers in the business. So, we’re confident of our position on this matter.

We’ve dared to suggest that the GPL as it stands today, or for that manner any other common open source license, will probably not work to adequately provide a license to the software sources for elections and voting systems technology under development by the Open Source Digital Voting Foundation.  So, let me start to explain why.

I condition this with “start” because we will have more to say about this – sufficient to entertain your inner lawyer, while informing your inner activist.  That will take several forms, including a probable white paper, more blog posts, and (wait for it) the actual specimen license itself, which we will publicly vet (to our Stakeholder Community first, and the general public immediately thereafter).

The Why of it…

The reasons we’re crafting a new version of a public license are not primarily centered on the grant of rights or other “meat” of the license, but ancillary legal terms that may be of little significance to most licensees of open source software technology, but turn out to be of considerable interest to, and in many cases requirements of Government agencies intending to deploy open source elections and voting technology in real public elections, where they’re “shooting with live ballots” as Bob Carey of FVAP likes to say.

It is possible that an elections jurisdiction, as a municipal entity could contract around some of the initial six points I make below, but the GPL (and most other “copyleft” licenses) expressly disallow the placing of "additional restrictions" on the terms of the license.  And most of the items I describe below could or would be considered "additional restrictions."  Therefore, such negotiation of terms would render a standard copyleft license invalid under their terms of issuance today.

It’s not like we haven’t burnt through some whiteboard markers thinking this through – again, we’re blessed with some whip smart licensing lawyers.   For instance, we considered a more permissive license, wrapped in some additional contract terms.  But a more permissive license would be a significant decision for us, because it would likely allow proprietary use of the software – an aspect we’ve not settled on yet.

With that in mind, here are six of the issues we’re grappling with that give rise to the development of the “OSDV Public License.”  This list is by no means exhaustive.  And I'm waiting for some additional insight from one of our government contracting lawyers who is a specialist in government intellectual property licensing.  So we’ll have more to say beyond here.

  1. Open source licenses rarely have “law selection” clauses.  Fact: Most government procurement regulations require the application of local state law or federal contracting law to the material terms and conditions of any contract (including software “right to use” licenses).
  2. Open source licenses rarely have venue selection clauses (i.e., site and means for dispute resolution).  Fact: Many state and federal procurement regulations require that disputes be resolved in particular venues.
  3. There are rights assignment issues to grapple with.  Fact: Open source licenses do not have "government rights" provisions, which clarify that the software is "commercial software" and thus not subject to the draconian rules of federal procurement that may require an assignment of rights to the software when the government funds development.  (There may be state equivalents, we’re not certain.)  On the one hand, voting software is a State or county technology procurement and not a federal activity.  But we’ve been made aware of some potential parallelism in State procurement regulations.
  4. Another reality check is that our technology will be complex mix of components some of which may actually rise to the level of patentability, which we intend to pursue with a “public assignment” of resulting IP rights.  Fact: Open source licenses do not contain "march-in rights" or other similar provisions that may be required by (at least) federal procurement regulations for software development.  Since some portion of our R&D work may be subject to funding derived from federal-government grants, we’ll need to address this potential issue.
  5. There is a potential enforceability issue.  Fact: Contracting with states often requires waiver of sovereign immunity to make licenses meaningfully enforceable.
  6. In order to make our voting systems framework deployable for legal use in public elections, we will seek Federal and State(s) certifications where applicable. Doing so will confer a certain qualification for use in public elections on which will be predicated a level of stability in the code and a rigid version control process.  It may be necessary to incorporate additional terms into “deployment” licenses (verses “development” licenses) specific to certification assurances and therefore, stipulations on “out-of-band” modifications, extensions, or enhancements.  Let’s be clear: this will not incorporate any restrictions that would otherwise be vexatious to the principles of open source licensing, but it may well require some procedural adherence.

And this is the tip of the iceberg on the matter of providing an acceptable comprehensive, enforceable, open source license for municipalities, counties, and States who desire to adopt the public works of the Open Source Digital Voting Foundation TrustTheVote Project for deployment in conducting public elections.

At this juncture, its looking like we may end up crafting a license somewhat similar in nature to the Mozilla MPL.

Hopefully, we’ve started a conversation here to clarify why it’s a bit uninformed to suggest we simply need to "bolt on" the GPL3 for our licensing needs.  Elections and voting technology – especially that which is deployed in public elections – is a different animal than just about any other open source project, even in a majority of other government IT applications.

Stay tuned; we’ll have more to show and tell.

Cheers GAM|out



MOVE Act Implementation: Call For Participation

The TrustTheVote Project issued its first formal "Call For Participation" ("CFP") to its Stakeholder Community last evening, and five elections jurisdiction have already indicated interest. The CFP is inviting collaboration from elections jurisdictions all over the country who need to determine how to comply with the mandates of the new federal MOVE Act -- particularly the requirement to provide a digital (online) means to deliver a download-ready blank ballot for any overseas voter wishing to participate in an election in their jurisdiction, and particularly one that has any federal contest included.

The TrustTheVote Project has developed a sufficient amount of its overall elections systems framework to be able to deliver a solution today for this requirement (pending any adjustments, modifications, or "tweaking" required to meet local requirements.) 

Really, this is a big deal.  You see, digitally serving anyone the official ballot for their district of residence is deceptively simple.  In fact, its non-trivial.  And yet, every jurisdiction where there are permanent residents stationed overseas either in the military or in some other NGO including simply an employer assignment needs to (and by federal law must) be able to cast an absentee ballot.  But how to get the ballot to them in time for them to prepare it and return to be counted?  We first presented a solution for this in a White Paper in December 2009.

To back up a bit, the MOVE Act was signed into law in November by the President, and essentially is intended to update and bring into the 21st century digital society the UOCAVA law from decades ago. For readers unfamiliar with these terms, here's a quick tutorial.

In 1986, Congress passed the Uniformed and Overseas Citizens Absentee Voting Act ("UOCAVA").  The UOCAVA requires that the states and territories allow certain groups of citizens to register and vote absentee in elections for Federal offices. In addition, most states and territories have their own laws allowing citizens covered by the UOCAVA to register and vote absentee in state and local elections as well. United States citizens covered by the UOCAVA include: members of the United States Uniformed Services and merchant marine; their family members; and United States citizens residing outside the United States.

After the 2008 elections cycle it was determined that up to 1 in 4 military and overseas voters were disenfranchised because they didn't receive their ballots in time.  In the autumn of 2009, Congress passed the new Military and Overseas Voter Empowerment (MOVE) Act, which is a complement and update to UOCAVA.  Among other provisions, the MOVE Act mandates that States shall provide a digital (online) means for a UOCAVA voter to manage their voter registration status and to receive a download ready blank ballot for the elections jurisdiction of their registered permanent residence.

Of course, there are those out there who shrill at the prospect that somehow, someway this could lead to Internet voting.  Very unlikely, and please don't get me started down that rat hole either.  Let me stay trained on the important point here.

The work of the TrustTheVote Project, to bring innovative open source digital voting technology to the public, already addresses the mandates of the MOVE Act.  And we've reached a point where issuing the CFP just makes sense to enlarge the pool of jurisidictions testing and evaluating our solution, and positioning themselves to acquire the tools when they are ready.

And of course, the really nice part: the software tools are free -- that's the benevolent point of the Open Source Digital Voting Foundation and the TrustTheVote Project.  Yes, we appreciate and encourage donations to the Foundation to defray the development costs (particularly if a jurisdiction desires the assistance of our technology development team to tailor the software to their exacting requirements), but the source code is free and will be theirs to do with as they wish (especially for software that does not require certification for voting systems purposes.)

Interested?  Great!  Get started by downloading the CFP here.  And get in touch with us.

Cheers GAM|out


1 Comment

OSDV Testifies (sort of) at CA Voting Systems Hearing

Greetings- So, I've taken a couple of days to decompress after a marathon of preparation for the Hearing this past Monday held by the CA Secretary of State.  Unfortunately, Secretary Bowen could not attend and preside over this important hearing as she was a victim of the global weirding that is dumping snow in multiple feet on Washington, D.C.  Somehow, I have to believe that had the Secretary presided as planned, things might have gone a just bit differently.

I took a couple of days before posting this because [a] I wanted to take in all of the kind messages we received from so many of you regarding our participation and the Hearing itself and weigh what others had perceived in watching online; and [b] give myself a chance to ensure that I wouldn't whine (too much) about how it went.  And the reason for that: whining is a waste of energy and the fact of the matter is the Hearing was a very important opportunity for everyone.

As to the way the Hearing went, the goodness of the digital world means all of it is recorded, archived, and on the public record.  So, I will not waste your gracious time reading our blog, nor my precious time writing posts completely regurgitating the turn of events.  However, I provide a couple of things here for your consideration.

First, my take is the CA Secretary of State needs to conduct another Hearing that is strictly focused on the challenges and opportunities of open source technology in elections systems.  Even had I been afforded the same amount of time as the other panelists (or even just the amount of time originally allocated) there is no way we could have had any sort of intellectually honest discussion about the many aspects of this increasingly popular topic. 

Sincerely, the fact that the topic made the agenda is an important step in the right direction.  However, there were just three questions fired at me in the midst of my providing some background on our project, and they reflect the reason I believe another Hearing is necessary.  Here they are/were, roughly paraphrasing (its on the record; you could look it up):

  1. When will your project have anything to deploy?
  2. Will your technology really be free?
  3. Is open source really better than closed, and why?

You'd probably concur that answering those questions alone should engage more than five minutes of discussion; well at least the 3rd question.  As I reflect, I goofed up the 1st answer leaving the Dias unimpressed (I suggested 2016 is when we anticipate our full system will be ready to deploy, although we have deliverables as early as, like, now) but there was simply no follow-up from the Dias, rather they fired a 2nd question as to whether our technology would be "free."  And my 2nd answer appeared to be met with doubt (at least two of the County Registrars on the Dias shook their heads in disbelief), because I answered, Yes.  But then I honestly conditioned it by adding,

If what you require is what we provide out of the box, then certainly.  If, however, you require some modification or tuning for your particular jurisdiction and you do not want to do so yourself, we ask for a donation to the Foundation to keep the project alive and defray the costs of work.

It appears I had them at "free" and lost them at "If."  Perhaps that's the challenge of a sound-bite world.  Let me just make this point at the risk of launching down a rat-hole of discussion like a Luge pilot *:

Just because the software is developed or deployed on an "open source" basis doesn't mean its free of development cost.

OK, on to my second point.  Rather than blather on about what we had to (or attempted to) say, you can read our prepared written testimony from which I derived my planned oral remarks here.  Please spend 20 minutes to give it a read because it will:

  1. Provide an overview of our motivation, charter, and project and explain clearly why (regardless of what the detractors are beginning to suggest about the potential of open source in elections) our project is viable, sustainable, adoptable, and deployable (sic, but you get the idea);
  2. Summarize our achievements, accomplishments and milestones for 2009;
  3. Offer some insight to how we believe what we're working on can help the State of California; and
  4. Present our perspectives on [a] the market transformation that can occur through open sourcing the underlying software technology of voting machinery, [b] the sustainability of the technology once our work here is complete, [c] describe 4 prospective deployment models for elections jurisdictions deciding that an open source based solution is right for them, and [d] present some thoughts on the simmering issue of re-thinking the process and model of certification.

Here's the bottom line: please indulge me, I'm really trying not to whine, because again, this was an important meeting regardless of time management issues)

What we're working on is very real, viable, sustainable, adoptable, deployable, and not disappearing any time soon.

We have over 200 hundred members in our Stakeholder Community representing a dozen States and its growing.  We're feeling increasingly validated about what seemed like a pie-in-the-sky notion three years ago.  And maybe we're starting to feel just a tiny bit justifiably irreverent towards those who insist on believing that what we're doing can't possibly be the kind of change agent we believe.

We took this Hearing pretty seriously.  So, OK, I guess I'm a wee bit miffed that after all of the hard work a number of our team members like Matthew Douglass and John Sebes put into preparing for this Hearing, and the number of Advisers who graciously took time to provide their two-cents on our prepared testimony, that I had the worst performance of my life in a regulatory testimony setting.

As one individual who was watching online sent to me in a text, I was essentially "run" after just less than 12 minutes of participation, when legacy vendors had earlier been afforded 2x or more time allotment to make their case for what: a promise of an endless supply of spare parts?  A promise of thinking about maybe considering the possibility of some common data formats for interoperability, someday?  For  a bunch of buzzword compliant hand-waving phrase dropping about transparency and open (read: disclosed) source?  Really?

Don't get me wrong, its on the public record: we support a healthy viable commercial industry for voting systems.  We believe our open source technology can pave a new road to a more competitive, customer-centric market.

But for the moment, if we're to have an intellectually honest discussion about the future of voting in California: the people, the equipment, and the costs, then surely the topic of open source technology deserves equal time to the well over an hour afforded the vendors, rather than barely 12 minutes and three questions of which the answer to the last was aborted mid-sentence.

That's weird.  And that's not the technically adept and pragmatic California Secretary of State office I've come to know.  Seriously, I refuse to believe there was any malice, just simply a series of fumbles on time management and facilities (e.g., how is it that the guy helping with AV disappears just when I'm trying to light up the LCD projector with my Mac connection?)

Again: I know the Secretary and her Deputy of Elections (at least) are committed to exploring the opportunities of innovation and new technology approaches just as much as they are intent on working with vendors to improve current offerings.  I remain convinced of this. However, we had an opportunity to provide some insight to our work and educate the Dias and the audience on the challenges and opportunities of open source, and that didn't happen as hoped... this time.

Cheers GAM|out

Oh yeah, for those of you who made it this far and wondered about my red asterisk, I promised myself I'd find a way to weave in the start of the 2010 Winter Olympics in Vancouver, opening Friday evening. Snap. ;-)

1 Comment


Shelfware or Liveware?

I'd like to answer a fine question posed by Jered in a comment to a blog posted by my esteemed colleague Pito Salas. Jered allowed as how the basic idea of OSDV was a fine idea, but asked "What’s the plan to get OSDV-based systems deployed?" A great question, but where I differ with Jered is in the idea that without professional lobbyists or political connections, new election tech would not be deployed -- we'd basically be building shelfware. We have a different approach on how to encourage adoption of new election technology, without having lobbying or advocacy being the main driver.

Decisions about election technology are made at the local level, by more than 3,000 election jurisdictions operating with the guidance and oversight of 50 states plus D.C. and the U.S. territories. In many of those states and locales, there is already dis-satisfaction with current election technology, and desire for replacements that are much, much closer to what's needed.

So, rather than lobbying Federal or state legislators to pass laws to specifically direct election officials to adopt specific new election technology -- such as the work product of the TrustTheVote project -- we have a different approach.

It's simple to say, but here is that alternative. What we do is to talk to those election officials, and get them talking with one another, in a stakeholder community of people that help us understand better how to build the new election technology that actually meets the needs that are not met by current voting systems, election management systems, voter registration systems, and so on. We listen to what's wanted, we build some of it, we demonstrate it, we document next steps, and we get feedback to drive course correction on how to continue to build out the TTV system further.

The basic theory is that if we work collaboratively and iteratively, what we end up delivering is election technology that election officials will want to deploy because it meets the previously unmet needs, because ... (drumroll) ... it does what they told us it should do. Of course, there won't be a perfect fit in any case, and those 50+ states and more (to say nothing of the thousands of localities) have distinct local needs. Flexibility of localization and customization features is just as important as getting it right with the core functionality.

So, our job is building the technology with the core functionality that's needed, and with the flexibility needed for adaption for use in a variety of locales. Lobbying and advocacy may play a role as well, but fortunately there are already literally hundreds of advocacy groups who can do the important work of advocating for adoption of TTV technology -- if we also do a good job of building the technology to provide the public accountability and transparency that is needed for public confidence in elections. And we're working hard on that, too!

-- EJS



FCC Wanders into the Internet Voting Quagmire

Why, oh why?” you’re wondering (given our teaser title, that is).  Well, at first we were we also wondering why.   This all began about a month ago, and it’s a bit clearer now.  With some breathing room made possible by the holiday, I want to explain how the FCC and online elections could be even remotely connected (no pun intended), but first, Happy Holidays, Happy Hanukkah (belated), and Merry Christmas (today) to those celebrating. Two weeks ago we responded to an FCC "request for comment;" an agency process with far more regulatory structure than the kind of “RFC” we’re used to.  But being the organization we are, with the mission we have, we felt we had to weigh in.

To be sure, we knew there would be tons of submissions from every “Who-Dog and their Larry” (and apparently we weren’t far off).  So the request was simply this: the FCC wanted input on the role of broadband in civic participation in the age of digital democracy.  And they divided that inquiry into two categories:

  1. the so-called digital town hall and related online civic interaction services (the meat and potatoes of the emerging “digital democracy”), and
  2. (wait for it) ...elections.

Of course, the activists quickly decoded the FCC inquiry about broadband in the process of elections to read: “Internet Voting” and acted accordingly.  Although we’re not advocates of using the public Internet for casting and counting of ballots any time soon, we were a bit more circumspect in our addressing the FCC’s inquiry.

You see, we’ve been rhythmically bombarded with inquiries about whether our open source voting systems development efforts include the Internet, what we think of Internet-based public elections, and when will people be able vote from their Droid or iPhone, etc.  And we tread gently on that issue because, while we're excited by the enthusiasm we're seeing for bringing real innovation into voting systems, frankly, there is far more to do to bring about trust, transparency, accuracy, and security in computers used in elections than we have resources to address as quickly as we’d like, let alone looking at a public, largely insecure transport layer for the critical data involved.  I’m sure there is some alluring if not downright techno-sexiness to that concept, but the gap between here and reality would’ve downright inspired Moses at the shore of the Red Sea.

So, we looked at the FCC inquiry when it was launched in mid-November and at first, shrugged it off as someone playing on subway rails.  Then it dawned on us: this was a chance to go on record with our position and make sure that we’re part of that conversation before someone attempts something silly like piloting an election across the cloud (OMG).

On a more serious note, we were catalyzed to comment by [1] some reality about why the FCC is wandering into this quagmire when Lord knows they have plenty to do with spectrum auctions, net neutrality, universal access fees, etc., and [2] important work we’re involved in through our partnership with the Overseas Vote Foundation and MOVE Act implementation.  I’ll have more to say about the MOVE Act in a separate post, but suffice it to note here that the Act, recently signed into law, is designed to enfranchise military and overseas voters in elections by requiring States to provide online methods for overseas voters to transmit absentee applications and voter registration information and download blank ballots for mark and return by surface postal mail.

For those readers who want to cut to the chase and see what we had to say in response to this curious FCC inquiry, have at it here.  For the rest who remain amused by our fuzzy insight, read on.

So that “reality check” is that the Obama Administration is leaning on the FCC to fashion a strategic plan for widespread broadband adoption and growth in the U.S. as part of its Reinvestment and Recovery Act of 2009.  And in the course of doing that, the FCC has been looking into the needs of citizens to access the Internet through reasonably speedy means (read: broadband).  So, civic participation would certainly constitute a valid reason for the FCC wandering into the free market’s territory of broadband build-out, right?  And if the FCC could determine the utility of broadband access to foster civic participation, then a whole bunch of justification for crafting this strategic broadband plan could be made.  Thus, the FCC needed to pose a public inquiry, and someone (we aren’t sure who, but have a theory) put the proverbial bug in the FCC collective ear that “elections” are one such “civic engagement” to be examined.  Thus the FCC waded into this quagmire (or firmly gripped the 3rd rail; choose the metaphor that paints the preferred picture) of Internet voting.

I note as an aside that one of our esteemed Sr. Members of Technical Staff, Pito Salas, posted a comment here recently about the notable absence of elections on the agenda of “open government.”  Well, it appears that while it may not have appeared on that agenda, it seems to be on the Administration’s agenda vis-à-vis the FCC inquiry.

And so we responded.

What’s the sum and substance of our position?  Well here it is in short, and you can read more if you dare.  I'll summarize with the synopsis followed by a Technology Point and a Policy Point.

For starters, The OSDV Foundation and TrustTheVote Project were pleased to have had an opportunity to provide comment on an increasingly vital aspect of broadband in the United States: its use in civic participation and the processes of democracy.

Technology Point: The use of the Internet as an element of critical democracy infrastructure is here to stay.  The 'Net is inherently insecure, but affords citizens a vital means of communication and information sharing.  Continued availability and accessibility to real broadband requires continued development of the capabilities of packet-switched networking.

Policy Point: The Internet is becoming critical infrastructure and its role in a digital democracy is sufficiently vital enough to build broadband policy around the ability of American citizens to participate in the processes of democracy in a digital age.

We encouraged the Commission to develop a comprehensive national broadband plan that particularly includes a plan for the use of broadband infrastructure and services to advance civic participation.

Technology Point: The processes of civic participation will require services that are transparent, trustworthy, accurate, and secure.  This means continued innovation in a service layer that is inherently insecure.

Policy Point: A national broadband public policy will necessarily entail a yin-yang relationship with private enterprise.  Ensuring civic engagement is a clear matter for government and a solid reason to have a broadband public policy in place, which can inform many debates and legislative initiatives.  And yet, clear roles and responsibilities between government and the privates sector in delivering this critical infrastructure is imperative.

To the extent their Plan includes consideration of broadband infrastructure for election processes and services, we advised careful consideration of what the architecture for a broadband-based voting system should look like and called upon experts and stakeholders to facilitate that understanding.  Clearly, the digital age and increasingly mobile society can benefit from digital means for such civic participation services.  However, the extent to which the challenges discussed in their inquiry can be adequately addressed remains unclear.

Technology Point: There is much to be worked out in terms of technically ensuring accuracy, transparency, trust and security in relying upon the Internet or broadband infrastructure to conduct civic engagement.

Policy Point: Fashioning this policy cannot occur in a vacuum void of competent technical input.

Nevertheless, any such Plan should consider the possibility that broadband infrastructure may be called upon in the future to support and sustain elections services in some capacity, whether strictly for back-office functions or all the way out to ballot casting and counting services.

Technology Point: If this cat is out of the bag, considerable research, development, and innovation is required before broadband infrstructure (read: Internet) can be reasonably relied upon for the level of civic engagement contemplated in the FCC inquiry.

Policy Point: Any broadband policy must consider this inevitable move toward a digital democracy.  Accordingly, issues such as digital divide, network neutrality, final mile, and quality of service assurances must be considered.

We do not recommend reliance on home or personal broadband connected digital devices for citizen-facing voting services for the foreseeable future or until such time as the challenges discussed herein are resolved to the satisfaction of the public.

Technology Point: The Internet is inherently insecure; home and personal computers are inherently insecure.  And a whole bunch of technical innovation is required to change that, and even then, these problems are likely to persist.

Policy Point: Disciplined thought leadership is imperative.  Sure we'd all like to simply cast our ballots from wherever we are with whatever device we have access to.  And some no longer consider the privacy element and vote-sale concern to be issues.  But many still do and will for some time to come.  The benefits of speeding towards a fully digital, online democracy continue to be outweighed by the risks of doing so.  That does not mean policy should forbid such, but it does compel policy makers to provide guidelines for cautiously proceeding.

That advised, we did encourage the Commission to take a citizen-centric approach to fashioning its broadband policy with regard to civic participation in terms of voting and elections services.  By “citizen-centric” we were referring to an approach that considers the wants and needs of an increasingly mobile society in a digital age.  As one simple example, we suggested the FCC consider the typical citizen voting situation wherein the voter is employed sufficiently far away from their home precinct such that it is logistically impossible for them to reach their polling place in time before or after their work day to cast their ballot, while fulfilling their responsibilities to their employer.

Technology Point: America is the consummate mobile society; whether its our propensity to relocate or our requirements of travel, the 21st century requires information services to put consumers at the center and appreciate and respect their mobility.

Policy Point: While there remains tremendous value in the traditional concepts of the polling place and election day, the fact is our 21st century society is now passing from the industrial age into the information age.  And we're in a transition period between ages.  The best policy will afford a spectrum of options, supporting everyone from those who are content to taking a day off to cast their ballots, to those who need to cast it remotely in a time shifted manner.

If there are any “best-practices” we can identify at this juncture with regard to broadband deployment of election services, two were particularly clear to us:

  1. personal or home connected devices should not be permitted to be utilized for ballot casting; and
  2. broadband connected ballot marking devices should be restricted to government authorized polling places.

Technology Point: The technical challenges to allow such are mountainous hurdles at this point, unless the venue can be controlled (and even then, issues will abound, but may be more readily addressable)

Policy Point: Respect must be sustained for the privacy imperative of casting ballots, and providing a means and venue where such can be done in a private and secure manner, while leveraging the benefits of technology requires political pragmatism.

Finally, we advised that the overseas voting challenges combined with the MOVE Act signed into law offer an opportunity to incrementally approach leveraging of broadband infrastructure to improve participation of overseas citizens, military, and diplomatic personnel in U.S. elections.  And that should begin with the delivery of blank ballots.

So, that’s our position, and we’re sticking with it.

Happy Holidays! GAM|out