A long form look on the Estonian iVoting experience and our thoughts on why it’s not feasible here at home.
Viewing entries tagged
Alaska will allow absentee voters to submit their ballot via a "secure online voting solution", aka e-mail. We're holding our breath.
Ms. Voting Matters would really like to wave her magic wand and allow everyone on the planet to cast their votes, securely, with their smart phones, tablets, or laptops. Really truly, I would do it if I could. But I can’t. The Internet of Voting is just not safe and secure enough now, no matter how much we all would wish it so. Let me share why.
Now, let’s turn to Plouffe’s notion of “digital voting.” Honestly, that phrase is confusing and vague. We should know: it catalyzed our name change last year from Open Source Digital Voting Foundation (OSDV) to Open Source Election Technology Foundation (OSET).
…not much we think.
Yesterday’s news of Microsoft co-founder billionaire Paul Allen’s investing $40M in the Spanish election technology company Scytl is validation that elections remain a backwater of innovation in the digital age.
But it is not validation that there is a viable commercial market for voting systems of the size typically attracting venture capitalists; the market is dysfunctional and small and governments continue to be without budget.
And the challenges of building a user-friendly secure online voting system that simultaneously protects the anonymity of the ballot is an interesting problem that only an investor of the stature of Mr. Allen can tackle.
We think this illuminates a larger question:
To what extent should the core technology of the most vital aspect of our Democracy be proprietary and black box, rather than publicly owned and transparent?
To us, that is a threshold public policy question, commercial investment viability issues notwithstanding.
To be sure, it is encouraging to see Vulcan Capital and a visionary like Paul Allen invest in voting technology. The challenges facing a successful elections ecosystem are complex and evolving and we will need the collective genius of the tech industry’s brightest to deliver fundamental innovation.
We at the TrustTheVote Project believe voting is a vital component of our nation’s democracy infrastructure and that American voters expect and deserve a voting experience that’s verifiable, accurate, secure and transparent. Will Scytl be the way to do so?
The Main Thing
The one thing that stood out to us in the various articles on the investment were Scytl’s comments and assertions of their security with international patents on cryptographic protocols. We’ve been around the space of INFOSEC for a long time and know a lot of really smart people in the crypto field. So, we’re curious to learn more about their IP innovations. And yet that assertion is actually a red herring to us.
Here’s the main thing: transacting ballots over the public packet switched network is not simply about security. Its also about privacy; that is, the secrecy of the ballot. Here is an immutable maxim about the digital world of security and privacy: there is an inverse relationship, which holds that as security is increased, privacy must be decreased, and vice-verse. Just consider any airport security experience. If you want maximum security then you must surrender a bunch of privacy. This is the main challenge of transacting ballots across the Internet, and why that transaction is so very different from banking online or looking at your medical record.
And then there is the entire issue of infrastructure. We continue to harp on this, and still wait for a good answer. If by their own admissions, the Department of Defense, Google, Target, and dozens of others have challenges securifying their own data centers, how exactly can we be certain that a vendor on a cloud-based service model or an in-house data center of a county or State has any better chance of doing so? Security is an arms race. Consider the news today about Heartbleed alone.
Oh, and please for the sake of credibility can the marketing machinery stop using the phrase “military grade security?” There is no such thing. And it has nothing to do with an increase in the 128-bit encryption standard RSA keys to say, 512 or 1024 bit. 128-bit keys are fine and there is nothing military to it (other than the Military uses it). Here is an interesting article from some years ago on the sufficiency of current crypto and the related marketing arms race. Saying “military grade” is meaningless hype. Besides, the security issues run far beyond the transit of data between machines.
In short, there is much the public should demand to understand from anyone’s security assertions, international patents notwithstanding. And that goes for us too.
The Bottom Line
While we laud Mr. Allen’s investment in what surely is an interesting problem, no one should think for a moment that this signals some sort of commercial viability or tremendous growth market opportunity. Nor should anyone assume that throwing money at a problem will necessarily fix it (or deliver us from the backwaters of Government elections I.T.). Nor should we assume that this somehow validates Scytl’s “model” for “security.”
Perhaps more importantly, while we need lots of attention, research, development and experimentation, the bottom line to us is whether the outcome should be a commercial proprietary black-box result or an open transparent publicly owned result… where the “result” as used here refers to the core technology of casting and counting ballots, and not the viable and necessary commercial business of delivering, deploying and servicing that technology.
Alaska's extension to its iVoting venture may have raised the interests of at least one journalist for one highly visible publication. When we were asked for our "take" on this form of iVoting, we thought that we should also comment here on this "northern exposed adventure." (apologies to those fans of the mid-90s wacky TV series of a similar name.) Alaska has been among the states that allow military and overseas voters to return marked absentee ballots digitally, starting with fax, then eMail, and then adding a web upload as a 3rd option. Focusing specifically on the web-upload option, the question was: "How is Alaska doing this, and how do their efforts square with common concerns about security, accessibility, Federal standards, testing, certification, and accreditation?"
In most cases, any voting system has to run that whole gauntlet through to accreditation by a state, in order for the voting system to be used in that state. To date, none of the iVoting products have even trying to run that gauntlet.
So, what Alaska is doing, with respect to security, certification, and host of other things is essentially: flying solo.
Their system has not gone through any certification program (State, Federal, or otherwise that we can tell); hasn't been tested by an accredited voting system test lab; and nobody knows how it does or doesn't meet federal requirements for security, accessibility, and other (voluntary) specifications and guidelines for voting systems.
In Alaska, they've "rolled their own" system. It's their right as a State to do so.
In Alaska, military voters have several options, and only one of them is the ability to go to a web site, indicate their choices for vote, and have their votes recorded electronically -- no actual paper ballot involved, no absentee ballot affidavit or signature needed. In contrast to the sign/scan/email method of return of absentee ballot and affidavit (used in Alaska and 20 other states), this is straight-up iVoting.
So what does their experience say about all the often-quoted challenges of iVoting? Well, of course in Alaska those challenges apply the same as anywhere else, and they are facing them all:
- insider threats;
- outsider hacking threats;
- physical security;
- personnel security; and
- data integrity (including that of the keys that underlie any use of cryptography)
In short, the Alaska iVoting solution faces all the challenges of digital banking and online commerce that every financial services industry titan and eCommerce giant spends big $ on every year (capital and expense), and yet still routinely suffer attacks and breaches.
Compared to the those technology titans of industry (Banking, Finance, Technology services, or even the Department of Defense), how well are Alaskan election administrators doing on their shoestring (by comparison) budget?
Good question. It's not subject to annual review (like banks' IT operations audit for SAS-70), so we don't know. That also is their right as a U.S. state. However, the fact that we don't know, does not debunkany of the common claims about these challenges. Rather, it simply says that in Alaska they took on the challenges (which are large) and the general public doesn't know much about how they're doing.
To get a feeling for risks involved, just consider one point, think about the handful of IT geeks who manage the iVoting servers where the votes are recorded and stored as bits on a disk. They arenot election officials, and they are no more entitled to stick their hands into paper ballots boxes than anybody else outside a county elections office. Yet, they have the ability (though not the authorization) to access those bits.
- Who are they?
- Does anybody really oversee their actions?
- Do they have remote access to the voting servers from anywhere on the planet?
- Using passwords that could be guessed?
- Who knows?
They're probably competent responsible people, but we don'tknow. Not knowing any of that, then every vote on those voting servers is actually a question mark -- and that's simply being intellectually honest.
Lastly, to get a feeling for the possible significance of this lack of knowledge, consider a situation in which Alaska's electoral college votes swing an election, or where Alaska's Senate race swings control of Congress (not far-fetched given Murkowski's close call back in 2010.)
When the margin of victory in Alaska, for an election result that effects the entire nation, is a low 4-digit number of votes, and the number of digital votes cast is similar, what does that mean?
It's quite possible that those many digital votes could be cast in the next Alaska Senate race. If the contest is that close again, think about the scrutiny those IT folks will get. Will they be evaluated any better than every banking data center investigated after a data breach? Any better than Target? Any better than Google or Adobe's IT management after having trade secrets stolen? Or any better than the operators of military unclassified systems that for years were penetrated through intrusion from hackers located in China who may likely have been supported by the Chinese Army or Intelligence groups?
Instead, they'll be lucky (we hope) like the Estonian iVoting administrators, when the OCSE visited back in 2011 to have a look at the Estonian system. Things didn't go so well. OCSE found that one guy could have undermined the whole system. Good news: it didn't happen. Cold comfort: that one guy didn't seem to have the opportunity -- most likely because he and his colleagues were busier than a one-armed paper hanger during the election, worrying about Russian hackers attacking again, after they had previously shut-down the whole country's Internet-connect government systems.
But so far, the current threat is remote, and it is still early days even for small scale usage of Alaska's iVoting option. But while the threat is still remote, it might be good for the public to see some more about what's "under the hood" and who's in charge of the engine -- that would be our idea of more transparency.
Wandering off the Main Point for a Few Paragraphs So, in closing I'm going to run the risk of being a little preachy here (signaled by that faux HTML tag above); again, probably due to the surge in media inquiries recently about how the Millennial generation intends to cast their ballots one day. Lock and load.
I (and all of us here) are all for advancing the hallmarks of the Millennial mandates of the digital age: ease and convenience. I am also keenly aware there are wing-nuts looking for their Andy Warhol moment. And whether enticed by some anarchist rhetoric, their own reality distortion field, or most insidious: the evangelism of a terrorist agenda (domestic or foreign) ...said wing nut(s) -- perhaps just for grins and giggles -- might see an opportunity to derail an election (see my point above about a close race that swings control of Congress or worse).
Here's the deep concern: I'm one of those who believes that the horrific attacks of 9.11 had little to do with body count or the implosions of western icons of financial might. The real underlying agenda was to determine whether it might be possible to cause a temblor of sufficient magnitude to take world financial markets seriously off-line, and whether doing so might cause a rippling effect of chaos in world markets, and what disruption and destruction that might wreak. If we believe that, then consider the opportunity for disruption of the operational continuity of our democracy.
Its not that we are Internet haters: we're not -- several of us came from Netscape and other technology companies that helped pioneer the commercialization of that amazing government and academic experiment we call the Internet. Its just that THIS Internet and its current architecture simply was not designed to be inherently secure or to ensure anyone's absolute privacy (and strengthening one necessarily means weakening the other.)
So, while we're all focused on ease and convenience, and we live in an increasingly distributed democracy, and the Internet cloud is darkening the doorstep of literally every aspect of society (and now government too), great care must be taken as legislatures rush to enact new laws and regulations to enable studies, or build so-called pilots, or simply advance the Millennial agenda to make voting a smartphone experience. We must be very careful and considerably vigilant, because its not beyond the realm of reality that some wing-nut is watching, cracking their knuckles in front of their screen and keyboard, mumbling, "Oh please. Oh please."
Alaska has the right to venture down its own path in the northern territory, but it does so exposing an attack surface. They need not (indeed, cannot) see this enemy from their back porch (I really can't say of others). But just because it cannot be identified at the moment, doesn't mean it isn't there.
One other small point: As a research and education non-profit we're asked why shouldn't we be "working on making Internet voting possible?" Answer: Perhaps in due time. We do believe that on the horizon responsible research must be undertaken to determine how we can offer an additional alternative by digital means to casting a ballot next to absentee and polling place experiences. And that "digital means" might be over the public packet-switched network. Or maybe some other type of network. We'll get there. But candidly, our charge for the next couple of years is to update an outdated architecture of existing voting machinery and elections systems and bring about substantial, but still incremental innovation that jurisdictions can afford to adopt, adapt and deploy. We're taking one thing at a time and first things first; or as our former CEO at Netscape used to say, we're going to "keep the main thing, the main thing."
As frequent readers will note, Internet voting as a discussion topic is one we increasingly tire of -- there is so much else to do! that unlike Internet Voting, can actually be done today! Let's talk instead about what tech innovations can do speed up the long lines at polling places, for example. But nevertheless, today, esteemed colleagues were asking for a "definitive statement" on i-voting, having been asked for such by folks who work for legislators interested in the topic. So I thought I'd share what I like to say when legislators, staffers, etc. ask for "definitive". Basically 3 steps.
Look to the National Institute of Standards and Technology (NIST), the U.S. government's top authority on technology issues. They've studied the use of the Internet for everything in elections, including voting.
- Read their conclusion on top half of page 69 of NIST's "Threat Analysis of Voting Systems" (here), supported by analysis in pages 42-46.
- Also briefly flip through NIST's 36 pages of "Information System Security Best Practices" (here) for Internet-connected election support systems.
- Think about whether state or local election officials would have the funding to comply with NIST guidelines, even for the lower bar of distributing blank ballots, much less the higher bar of Internet Voting.
That's pretty much it.
PS: While we're on the topic, my thanks to Jeremy Epstein for tackling another topic on i-voting (botnets, one among several i-voting topics that I am happy to leave to Jeremy and other colleagues in the security world), and for letting me put my 2 cents in for his Freedom To Tinker blog today. Thanks Jeremy, for doing the $0.98, and keep up the good work ! -- ejs
An esteemed colleague noted the news of the USPS stopping weekend delivery, as part of a trend of slow demise of the USPS, and asked: will we get to the point where vote-by-mail is vote-by-Fedex? And would that be bad, having a for-profit entity acting as the custodian for a large chunk of the ballots in an election? The more I thought about it, the more flummoxed I was. I had to take off the geek hat and dust off the philosopher hat, looking at the question from a viewpoint of values, rather than (as would be my wont) requirements analysis or risk analysis. I goes like this ...
I think that Phil's question is based on assumption of some shared values among voters -- all voters, not just those that vote by mail -- that make postal voting acceptable because ballots are a "government things" and so is postal service. Voting is in part an act of faith in government to be making a good faith effort to do the job right, and keep the operations above a minimum acceptable level of sanity. It "feels OK" to hand a marked ballot to my regular neighborhood post(wo)man, but not to some stranger dropping off a box from a delivery truck. Translate from value to feeling to expectation: it's implied that we expect USPS staff to know that they have a special government duty in delivering ballots, and to work to honor that duty, regarding the integrity of those special envelopes as a particular trust, as well as their timely delivery.
- Having re-read all that, it sounds so very 20th century, almost as antique as lever machines for voting.
I don't really think that USPS is "the government" anymore, not in the sense that the journey of a VBM ballot is end-to-end inside a government operation. I'm not sure that Fedex or UPS are inherently more or less trustworthy. In fact they all work for each other now! And certainly in some circumstances the for-profit operations may to some voters feel more trustworthy -- whether because of bad experiences with USPS, or because of living overseas in a country that surveils US citizens and operates the postal service.
Lastly, I think that many people do share the values behind Phil's question -- I know I do. The idea makes me wobbly. I think it comes down to this:
- If you're wobbly on for-profit VBM, then get back into the voting booth, start volunteering to help your local election officials, and if they are effectively outsourcing any election operations to for-profit voting system vendors, help them stop doing so.
- If you not wobbly, then you're part of trend to trusting -- and often doing -- remote voting with significant involvement from for-profit entities - and we know where that is headed.
The issue with USPS shows that in the 21st century, any form of remote voting will involve for-profits, whether it is Fedex for VBM, or Amazon cloud services for i-voting. My personal conclusions:
- Remote voting is lower integrity no matter what, but gets more people voting because in-person voting can be such a pain.
- I need to my redouble efforts to fix the tech so that in-person voting is not only not a pain, but actually more desirable than remote voting.
Gentle Readers:This is a long article/posting. Under any other circumstance it would be just too long.
There has been much written regarding the public evaluation and testing of the District of Columbia’s Overseas “Digital Vote-by-Mail” Service (the D.C.’s label). And there has been an equal amount of comment and speculation about technology supplied to the District from the OSDV Foundation’s TrustTheVote Project, and our role in the development of the D.C. service. Although we’ve been mostly silent over the past couple of weeks, now enough has been determined so that we can speak to all readers (media sources included) about the project from our side of the effort.
The coverage has been extensive, with over 4-dozen stories reaching over 370 outlets not including syndication. We believe it’s important to offer a single, contiguous commentary, to provide the OSDV Foundation’s point of view, as a complement to those of the many media outlets that have been covering the project.
0. The Working Relationship: D.C. BoEE & TrustTheVote Project Only geeks start lists with item “0” but in this case its meant to suggest something “condition-precedent” to understanding anything about our work to put into production certain components of our open source elections technology framework in D.C. elections. Given the misunderstanding of the mechanics of this relationship, we want readers to understand 6 points about this collaboration with the District of Columbia's Board of Elections & Ethics (BoEE), and the D.C. I.T. organization:
- Role: We acted in the capacity of a technology provider – somewhat similar to a software vendor, but with the critical difference of being a non-profit R&D organization. Just as has been the case with other, more conventional, technology providers to D.C, there was generally a transom between the OSDV Foundation’s TTV Project and the I.T. arm of the District of Columbia.
- Influence: We had very little (if any) influence over anything construed as policy, process, or procedure.
- Access: We had no access or participation in D.C.’s IT organization and specifically its data center operations (including any physical entry or server log-in for any reason), and this was for policy and procedural reasons.
- Advice: We were free to make recommendations and suggestions, and provide instructions and guidelines for server configurations, application deployment, and the like.
- Collaboration: We collaborated with the BoEE on the service design, and provided our input on issues, opportunities, challenges, and concerns, including a design review meeting of security experts at Google in Mountain View, CA early on.
- Advocacy: We advocated for the public review, cautioning that the digital ballot return aspect should be restricted to qualified overseas “UOCAVA” voters, but at all times, the BoEE, and the D.C. I.T. organization “called the shots” on their program.
And to go on record with an obvious but important point: we did not have any access to the ballot server, marked ballots, handling of voter data, or any control over any services for the same. And no live data was used for testing.
Finally, we provided D.C. with several software components of our TTV Elections Technology Framework, made available under our OSDV Public License, an open source license for royalty-free use of software by government organizations. Typical to nearly any deployment we have done or will do, the preexisting software did not fit seamlessly with D.C. election I.T. systems practices, and we received a “development grant” to make code extensions and enhancements to these software components, in order for them to comprise a D.C.-specific system for blank ballot download and an experimental digital ballot return mechanism (see #7 below).
The technology we delivered had two critically different elements and values. The 1st, "main body of technology" included the election data management, ballot design, and voter user interface for online distribution of blank ballots to overseas voters. With this in hand, the BoEE has acquired a finished MOVE Act compliant blank ballot delivery system, plus significant components of a new innovative elections management system that they own outright, including the source code and right to modify and extend the system.
For this system, BoEE obtained the pre-existing technology without cost; and for D.C-specific extensions, they paid a fraction of what any elections organization can pay for a standard commercial election management system with a multi-year right-to-use license including annual license fees.
D.C.’s acquired system is also a contrast to more than 20 other States that are piloting digital ballot delivery systems with DoD funding, but only for a one-time trial use. Unlike D.C., if those States want to continue using their systems, they will have to find funding to pay for on-going software licenses, hosting, data center support, and the like. There is no doubt, a comparison shows that the D.C. project has saved the District a significant amount of money over what they might have had to spend for ongoing support of overseas and military voters.
That noted, the other (2nd) element of the system – digital return of ballots – was an experimental extension to the base system that was tested prior to possible use in this year’s November election. The experiment failed in testing to achieve the level of integrity necessary to take it into the November election. This experimental component has been eliminated from the system used this year. The balance of this long article discusses why that is the case, and what we saw from our point of view, and what we learned from this otherwise successful exercise.
1. Network Penetration and Vulnerabilities There were two types of intrusions as a result of an assessment orchestrated by a team at the University of Michigan led by Dr. Alex Halderman, probing the D.C. network that had been made available to public inspection. The first was at the network operations level. During the time that the Michigan team was testing the network and probing for vulnerabilities, they witnessed what appeared to be intrusion attempts originating from machines abroad from headline generating countries such as China and Iran. We anticipate soon learning from the D.C. IT Operations leaders what network security events actually transpired, because detailed review is underway. And more to that point, these possible network vulnerabilities, while important for the District IT operations to understand, were unrelated to the actual application software that was deployed for the public test that involved a mock election, mock ballots, and fictitious voter identities provided to testers.
2. Server Penetration and Vulnerabilities The second type of intrusion was directly on the District’s (let’s call it) “ballot server,” through a vulnerability in the software deployed on that server. That software included: the Red Hat Linux server operating system; the Apache Web server with standard add-ons; the add-on for the Rails application framework; the Ruby-on-Rails application software for the ballot delivery and return system; and some 3rd party library software, both to supplement the application software, and the Apache software.
The TrustTheVote Project provided 6 technology assets (see below, Section 7) to the BoEE project, plus a list of requirements for "deployment;" that is, the process of combining the application software with the other elements listed above, in order to create a working 3-tier application running on 3 servers: a web proxy server, an application server, and a database server. One of those assets was a Web application for delivering users with a correct attestation document and the correct blank ballot, based on their registration records. That was the "download" portion of the BoEE service, similar to the FVAP solutions that other states are using this year on a try-it-once basis.
3. Application Vulnerability Another one of those technology assets was an "upload" component, which performed fairly typical Web application functions for file upload, local file management, and file storage – mostly relying on a 3rd-party library for these functions. The key D.C.-specific function was to encrypt each uploaded ballot file to preserve ballot secrecy. This was done using the GPG file encryption program, with a command shell to execute GPG with a very particular set of inputs. One of those inputs was the name of the uploaded file.
And here was the sticking point. Except for this file-encryption command, the library software largely performed the local file management functions. This included the very important function of renaming the uploaded file to avoid giving users the ability to define file names on the server. Problem: during deployment, a new version of this library software package was installed, in which the file name checks were not performed as expected by the application software. Result: carefully crafted file names, inserted into the shell command, gave attackers the ability to execute pretty much any shell command, with the userID and privileges of the application itself.
Just as the application requires the ability to rename, move, encrypt, and save files, the injected commands could also use the same abilities. And this is the painfully ironic point: the main application-specific data security function (file encryption), by incorrectly relying on a library, exposed those ballot files (and the rest of the application) to external tampering.
4. Consequences The Michigan team was creative in their demonstration of the results of attacking a vulnerability in what Halderman calls a "brittle design," a fair critique common to nearly every Web application deployed using application frameworks and application servers. In such a design, the application and all of its code operates as a particular userID on the server. No matter how much a deployment constrains the abilities of that user and the code running as that user, the code, by definition, has to be able to use the data that the application manages.
Therefore, if there is a “chink” in any of the pieces the collective armor (e.g., the server, its operating system, web server, application platform, application software, or libraries) or the way they fit together, then that “chink” can turn use into an abuse. That abuse applies to any and all of the data managed by the application, as well as the file storage used by the application. As the Michigan teamed demonstrated, this general rule also applies specifically, when the application data includes ballot files.
5. Mea Culpa Let’s be clear, the goof we made, and “our bad” in the application development was not anticipating a different version of the 3rd-party library, and not locking in the specific version that did perform file name checking that we assumed was done to prevent exactly this type of vulnerability. And in fact, we learned 4 valuable lessons from this stumble:
- Factoring Time: Overly compressed schedules will almost certainly ensure a failure point is triggered. This project suffered from a series of cycle-time issues in getting stuff requisitioned, provisioned, and configured, and other intervening issues for the BoEE, including their Primary election which further negatively impacted the time frame. This led to a very compressed amount of time to stage and conduct this entire exercise;
- Transparency vs. Scrutiny: The desired public transparency put everyone involved in a highly concentrated light of public scrutiny, and margins of otherwise tolerable error allowed during a typical test phase were nonexistent in this setting – even the slightest oversight typically caught in a normal testing phase was considered fault intolerant, as if the Pilot were already in production;
- (Web) Application Design: Web applications for high-value, high-risk data require substantial work to avoid brittleness. Thankfully, none of the TrustTheVote Elections Technology Framework will require an Internet-connected Web application or service – so the 3rd lesson is how much of a relief that is going forward for us; and
- No Immunity from Mistake: Even the most experienced professionals are not immune from mistake or misstep, especially when they are working under very skeptical public scrutiny and a highly compressed time schedule – our development team, despite a combined total of 7 decades of experience, included.
So, we learned some valuable lessons from this exercise. We still believe in the public transparency mandate, and fully accept responsibility for the goof in the application development and release engineering process.
Now, there is more to say about some wholly disconnected issues regarding other discovered network vulnerabilities, completely beyond our control (see #0 above), but we’ll save comment on that until after the D.C. Office of the CTO completes their review of the Michigan intrusion exercise. Next, we turn attention to some outcomes.
6. Outcomes Let's pull back up to the 30-thousand foot level, and consider what the discussion has been about (leaving aside foreign hackers). This test revealed a security weakness of a Web application framework; how there can be flaws in application-specific extensions to routine Web functions like file upload, including flaws that can put those functions and files at risk. Combine that with the use of Web applications for uploading files that are ballots. Then, the discussion turns on whether it is possible (or prudent) to try to field any Web application software, or even any other form of software, that transfers marked ballots over the Internet. We expect that discussion to vigorously continue, including efforts that we’d be happy to see, towards a legislative ruling on the notion, such to Ohio’s decision to ban digital ballot transfer for overseas voting or North Carolina’s recent enthusiastic embrace of it.
However, public examination, testing, and the related discussions and media coverage, were key objectives of this project. Rancorous as that dialogue may have become, we think it’s better than the dueling monologues that we witnessed at the NIST conference on overseas digital voting (reported here earlier).
But this is an important discussion, because it bears on an important question about the use of the Internet, which could range from (a) universal Internet voting as practiced in other countries (which nearly everyone in this discussion, including the OSDV Foundation, agrees is a terrible idea for the U.S.), to (b) the type of limited-scope usage of the Internet that may be needed only for overseas and military voters who really have time-to-vote challenges, or (c) limited only to ballot distribution. For some, the distinction is irrelevant. For others, it could be highly relevant. For many, it is a perilous slippery slope. It's just barely possible that worked examples and discussion could actually lead to sorting out this issue.
The community certainly does have some worked examples this year, not just the D.C. effort, and not just DoD’s FVAP pilots, but also other i-Voting efforts in West Virginia and elsewhere. And thankfully, we hear rumors that NIST will be fostering more discussion with a follow-up conference in early 2011 to discuss what may have been learned from these efforts in 2010. (We look forward to that, although our focus returns to open source elections technology that has nothing to do with the Internet!)
7. Our Technology Contributions Finally, for the record, below we catalog the technology we contributed to the District of Columbia’s Overseas “Digital Vote-by-Mail” service (again, their label). If warranted, we can expand on this, another day. The assets included:
- Three components of the open source TrustTheVote (TTV) Project Elections Technology Framework: [A] the Election Manager, [B] the Ballot Design Studio, and [C] the Ballot Generator.
- We augmented the TTV Election Manager and TTV Ballot Design Studio to implement D.C.-specific features for election definition, ballot design, and ballot marking.
- We extended some earlier work we’ve done in voter record management to accommodate the subset of D.C. voter records to be used in the D.C. service, including the import of D.C.-specific limited-scope voter records into an application-specific database.
- We added a Web application user experience layer on top of that, so that voters can identify themselves as matching a voter database record, and obtain their correct ballot (the application and logic leading up to the blank ballot "download" function referred to above) and to provide users with content about how to complete the ballot and return via postal or express mail services.
- We added a database extension to import ballot files (created by the TTV Ballot Generator), using a D.C.-specific method to connect them to the voter records in order to provide the right D.C.-specific ballot to each user.
- We added the upload capability to the web application, so that users could choose the option of uploading a completed ballot PDF; this capability also included the server-side logic to encrypt the files on arrival.
All of these items, including the existing open-source TTV technology components listed above in 7.1 above, together with the several other off-the-shelf open-source operating system and application software packages listed in Section 2 above, were all integrated by D.C’s IT group to comprise the “test system” that we’ve discussed in this article.
In closing, needless to say, (but we do so anyway for the record) while items 7.1—7.5 can certainly be used to provide a complete solution for MOVE Act compliant digital blank ballot distribution, item 7.6 is not being used for any purpose, in any real election, any time soon.
One final point worth re-emphasizing: real election jurisdiction value from an open source solution.....
The components listed in 7.1—7.5 above provide a sound on-going production-ready operating component to the District’s elections administration and management for a fraction of the cost of limited alternative commercial solutions. They ensure MOVE Act compliance, and do not require any digital ballot return. And the District owns 100% of the source code, which is fully transparent and open source. For the Foundation in general, and the TrustTheVote Project in particular, this portion of the project is an incontrovertible success of our non-profit charter and we believe a first of its kind.
And that is our view of D.C.‘s project to develop their “Digital Vote-by-Mail” service, and test it along with the digital ballot return function. Thanks for plowing through it with us.
24 hours ago I, along with some others, was actually considering asking for a refund. We had come to the EAC, NIST, and FVAP co-hosted UOCAVA Remote Voting Systems 2 Day Workshop, expecting to feast on some fine discussions about the technical details and nuances of building remote voting systems for overseas voters that could muster the demands of security and privacy. And instead we had witnessed an intellectual food fight of ideology. That all changed in a big way today.
The producers and moderators of the event, I suspect sensing the potential side effects of yesterdays outcome -- came together, somehow collectively made some adjustments (in moderation techniques, approach, and topic tweaking), and pulled off an excellent, informative day full of the kind of discourse I willingly laid down money (the Foundation's money no less) in the first place to attend.
My hat is off; NIST and EAC on the whole did a great job with a comeback performance today that nearly excused all of what we witnessed yesterday. Today, they exhibited self deprecating humor, and even had elections officials playing up their drunk driver characterization from the day before.
Let me share below what we covered; it was substantive. It was detailed. And it was tiring, but in a good way. Here it is:
Breakout Session – Voter Authentication and Privacy
--Identified voter authentication and privacy characteristics and risks of the current UOCAVA voting process.
--Identified potential risks related to voter authentication and privacy of remote electronic absentee voting systems. For example, the group considered:
- Ballot secrecy
- Coercion and/or vote selling
- Voter registration databases and voter lists
- Strength of authentication mechanisms
- Susceptibility to phishing/social engineering
- Usability and accessibility of authentication mechanisms
- Voter autonomy
- Other potential risks
--Considered measures and/or criteria for assessing and quantifying identified risks and their potential impacts.
- How do these compare to those of the current UOCAVA voting processes?
--Identified properties or characteristics of remote digital voting absentee voting systems that could provide comparable authentication mechanisms and privacy protections as the current UOCAVA voting process
--Considered currently available technologies that can mitigate the identified risks. How do the properties or characteristics of these technologies compare to those of the current UOCAVA voting process?
--Started to identify and discuss emerging or future research areas that hold promise for improving voter authentication and/or privacy. For example:
- Biometrics (e.g., speaker voice identification)
- Novel authentication methods
--Chatted about cryptographic voting protocols and other cryptographic technologies
Breakout Session – Network and Host Security
--Identified problems and risks associated with the transmission of blank and voted ballots through the mail in the current UOCAVA voting process.
--Identified risks associated with electronic transmission or processing of blank and voted ballots. For example, the breakout group considered:
- Reliability and timeliness of transmission
- Availability of voting system data and functions
- Client-side risks to election integrity
- Server-side risks to election integrity
- Threats from nation-states
- Other potential risks
--Considered and discussed measures and/or criteria for assessing and quantifying identified risks and their potential impacts.
- How do these compare to those of the current UOCAVA voting process
--Identified properties or characteristics of remote digital absentee voting systems that could provide for the transmission of blank and voted ballots at least as reliably and securely as the current UOCAVA voting process.
--Discussed currently available technologies that can mitigate the identified risks and potential impact.
- How do the properties and characteristics of these technologies compare to those of the current UOCAVA voting process?
--Identified and discussed emerging or future research areas that hold promise for improving network and host security. For example:
- Trusted computer and trusted platform models
- End point security posture checking
- Cloud computing
- Semi-controlled platforms (e.g., tablets, smart phones, etc.)
- Use of a trusted device (e.g., smart card, smart phone, etc.)
As you can see, there was a considerable amount of information covered in each 4 hour session, and then the general assembly reconvened to report on outcomes of each breakout group.
Did we solve any problems today? Not so much. Did we come a great deal forward in challenge identification, guiding principles development, and framing the issues that require more research and solution formulation? Absolutely.
Most importantly, John Sebes, our CTO and myself gained a great deal of knowledge we can incorporate into the work of the TrustTheVote Project, had some badly needed clarifying discussions with several, and feel we are moving in the right direction.
We clarified where we stand on use of the Internet in elections (its not time beyond anything but tightly controlled experimentation, and there is a lacking of understanding of the magnitude of resources required to stand up sufficiently hardened data centers to make it work, let alone figuring out problems at the edge.)
And we feel like we made some small contributions to helping the EAC and NIST figure out the kind of test Pilot they wish to stand up as a guiding principles reference model sometime over the next 2 years.
Easily a day's work for the 50-60 people in attendance over the two days.
Back to the west coast (around 3am for my Pacific colleagues ;-)
Its a wrap GAM|out
[Note: This is a personal opinion piece and does not necessarily reflect the position of the Foundation or TrustTheVote Project.] I should have seen this coming. What was I thinking or expecting?
I am reporting this evening from the NIST Workshop on UOCAVA Remote Voting Systems here in Washington D.C.. After a great set of meetings earlier today on other activities of the Foundation (which we’ll have more to say about soon, but had nothing to do with our contributions to the District’s UOCAVA voting Pilot) I arrived at the Wardman Park Marriott near the Naval Observatory (home of the Vice President) for the Workshop, having unfortunately missed the morning sessions. I barely made it into the lobby, when I had my first taste of what was being served.
My first exposure to the workshop (by then on lunch break) was witnessing a somewhat heated discussion between members of the Verified Voting Foundation and Rokey Suleman, Director of Elections for the District of Columbia. Apparently, a speaker (identity is irrelevant) of noted authority had delivered a talk before lunch in which he spoke rather condescendingly toward elections officials (likening them to “drunk drivers”).
Mr. Suleman was explaining that so far the meeting appeared to be a waste of his time (principally because of such ad hominen remarks). Those of the Verified Voting Foundation seemed unwilling to acknowledge that this speaker had (how ever unintentionally) denigrated the hard work of elections officials (as several others later relayed to me they too perceived), emphasizing instead that this individual was, "The nicest person who would never intend such a thing."
Diplomacy 101 teaches: Perception equals reality.
Rather, they seemed to cling to the fact that this speaker was so much of an authority (which strictly speaking this person who made the drunken driving reference, is in fact a technical authority), that this comment should be overlooked.
The argument devolved from there; the substance of which is irrelevant. What is relevant, however, is that in the very next session after lunch, another argument broke out over legal details of the letter of the UOCAVA law(s) and the related promulgated regulations enacting new aspects of overseas voting that enable (among other things) the digital delivery of blank ballots, and – arguably – the opportunity to pilot a means of digital return.
By the way: have I mentioned this workshop is supposed to be about UOCAVA remote voting which is limited to a qualified subset of that population overseas, and not the unrestricted widespread so-called "Internet voting?" But yet, an uninformed onlooker could reasonably believe that the battle lines were being drawn over the general widespread notion of Internet Voting on the basis of the so-called "slippery slope" argument. (Note: I'll leave it to trained Philosophers to explain why that argument actually is illogical in its own right in most applications.) So, take a look at the Workshop description and draw your own conclusions.
The issue seems to be overly-trained on possibilities/potential of compromise and nowhere near a discussion of probability. What’s more, I’m so far hearing nothing of the discussions about the technical challenges we need to address and how if at all (only an official from the Okaloosa Distance Balloting Pilot attempted to offer any such presentation or agenda).
Instead, I kept hearing the rhetoric of avoidance – both in and outside of sessions. But the Internet has darkened the doorstep of nearly every aspect of society today. Why does it feel like we’re fooling ourselves into believing that somehow this cloud won’t also darken the doorstep of elections in a digital age? Unfortunately, it already is; and future generations may well demand it. However, that's a discussion for another venue -- we're supposed to be exploring remote voting solutions for qualified overseas voters.
Let me say once again:
The Foundation and TrustTheVote Project do NOT support the widespread use of the Internet for the transaction of voting data.
That restated, as far as the Internet playing any role in elections is concerned, it seems to me that we need to look carefully at how to address this challenge, scourge, or whatever we want to call it, rather than try to abolish or avoid it. Had this mentality been applied to sending man to the moon, this nation never would have achieved four successful lunar landings out of five attempts.
But again, arguing over what role the Internet should or should not play in elections is not why I am here. Intellectually honest discourse on the challenges and opportunities of UOCAVA remote voting solutions is why I am attending. And I hoped I would witness (and participate in) a healthy discussion of the technical challenges beyond encryption debates and ideas on how to address them.
So far, I have not.
Instead, what I have is a seat in an intellectual food fight. Notwithstanding a few interesting comments, speakers, and hallway chats, this sadly so far is a near waste of time (and money). As one election official put it to me at this evening's no-host reception:
Today reminds me of an observation by Nick Bostrom, an Oxford Philosopher: there is absolute certainty that the universe we live in is artificial. Because that’s the only logical conclusion you can reach when you exclusively calculate possibilities without any consideration of probabilities.
Thankfully, we (at the Foundation) have much to work on regarding the use of computers in real world elections that has nothing to do with the transport layer. Outside of these workshops, we don't intend to address Internet solutions in our work in any significant manner.
And thankfully more, we had some very positive meetings this morning that validated the potential of our work to actually deliver publicly owned critical democracy infrastructure for accurate, transparent, trustworthy, and secure elections.
Tomorrow is another day; we'll see what happens, and I'll report back. GAM|out
The TrustTheVote Project of the Open Source Digital Voting (OSDV) Foundation achieved another important milestone two weeks ago this morning, this time with the District of Columbia Board of Elections and Ethics, although not without some controversy. The short of it is, and most important to us, the Foundation has been given the opportunity to put real open source elections software into a production environment for a real public election. But it turns out that milestone is struggling to remain visible. [Note: this is a much longer post than I would prefer, but the content is very important to explain a recent announcement and our role.]
I’ve waited to launch a discussion in this forum in order to let the flurry of commentaries calm on the news. Now we need to take the opportunity to speak in own voice, rather than the viewpoint of journalists and press releases, and provide insight and reality-checks from the authoritative source about what we're up to: Us. For those of you who have not read any of this news, here is a sample or two. The news is about the District of Columbia is implementing a Pilot program to digitally deliver ballot to a group of qualified overseas voters, and accept digitally returned ballots from them. (Actually, D.C. already has accepted digitally returned ballots via Fax and eMail.) So, the headline might be:
“District of Columbia to Launch Pilot Program to benefit Overseas & Military Voters with Digital Distance Balloting Solution Using Open Source Software from Non-Profit Voting Technology Group.”
I believe that is as simple and factual as it gets, and IMHO a fair headline. However, here are two alternative headlines, depending on your view, interests, or issues:
- “Open Source Voting Project Succeeds in Production Deployment of New Transparent and Freely Available Elections Technology.” -or-
- “OSDV Foundation Advances Misguided Cause of Internet Voting, Despite Well Settled Dangers, Putting Election Integrity at Risk.”
If you follow our work or have read our statement on these topics before, then you recognize the headline #1 is where our interests and intentions are focused. Over the past two weeks, though, we’ve received plenty of feedback that some believe that headline #2 is the real and unfortunate news, undermining the efforts of those who tirelessly work for elections integrity. Well, that is not what we intended to do. But we do need to do a better job at communicating our goals, as the facts unfold about the project. So, let me back up a bit and start an explanation of what we are really doing and what are real intentions are.
But first let me make the following statement, repeating for the record our position on Internet voting:
The Open Source Digital Voting Foundation does not advocate the general use of the public Internet for the transaction of voting data. The technical team of the TrustTheVote Project strongly cautions that no Internet-based system for casting, let alone counting, of ballots can be completely secure, nor can a voter’s privacy be ensured, or the secrecy of their ballot protected.
We do not recommend replacing current voting systems by adopting Internet Voting systems. However, we think that there may be a use case in which Internet-based ballot return may be the only course of last resort for rapid delivery of a ballot in time to be counted. That case is the very limited situation of an overseas or military voter who believes that they may be disenfranchised unless they rely on a digital means to return their marked ballot, because physical means are not timely or not available. That is the situation that we genuinely believe is being restrictively addressed in the D.C. Pilot project that we are participating.
And to be crystal clear: OSDV's role is supplying technology. The District's Board of Elections and Ethics is running the show, along withe the District's I.T. organization. But why did we chose this role? The success of the TrustTheVote Project is predicated on accomplishing three steps to delivering publicly owned audit-ready, transparent voting technology:
- Development; and
Design. We are employing a public process that engages a stakeholder community comprised of elections officials and experts. We cannot design on our own and expect what we come up with will be what will work. It is, and must be, a framework of technology components in order to be adoptable and adaptable to each jurisdiction that chooses to freely acquire and deploy the Project’s work. None of the TV Framework specifically addresses any transport means of ballot data. The Framework voting systems architecture includes accessible ballot marking ("ABM") devices, optical scanners for paper ballot marked by hand or ABM, and tabulators. The Framework elections management services architecture includes EMS components, poll books, and ballot design studio.
Development. We are employing an open source method and process, somewhat modified and similar in structure to how the Mozilla Foundation manages development of their open source software – with a core team that ensures development continuity and leadership, complemented by a team of paid and volunteer contributors. And the development has to be open, to go along with the open design process, and open testing, delivering on the commitment to building election technology that anyone can see, touch, and try. We’re developing for the four legs of integrity: accuracy, transparency, trust, and security.
Deployment. But “open source” at the Foundation is also about distribution for deployment. As we've said before, the OSDV Public License, based on our “cousin’s” license, the Mozilla Public License, meets the special needs of government licensee. And in so doing we avail the source code, and where required, resources (in exchange for a development grant to the Foundation) to make the necessary refinements and modifications to enable the adopting jurisdiction to actually deploy this open source technology. The deployment will generally be managed by a new type of commercial player in the elections technology sector: the systems integrator who will provide qualified commodity hardware, with the Project’s software, and the services to stand it up and integrate it with other jurisdiction’s IT infrastructure where required.
Motivation One critic has asked, “Why would you agree to support any project that uses the Internet in elections or voting?” Our motivation for working with the District of Columbia is all about the third “D” – Deployment. All of our efforts are merely academic, unless stakeholders who have contributed to the specifications actually adopt the resulting open source technology as an alternative to buying more proprietary elections technology, when the opportunity arises to replace or enhance their current solutions.
Now, what about that “Internet” element?
The District of Columbia Board of Elections & Ethics (B.O.E.E) was in search of a solution to enhance their compliance with the MOVE Act. Of course, people in many election jurisdictions were asking:
If I can deliver the blank ballot and reduce the cycle time for qualified overseas voters, then why shouldn’t we go all the way and facilitate digital return of the marked ballot?
Well, there’s a host of reasons why one shouldn’t do that. For one quick example: our valued strategic technology partner collaborating with us on data standards, the Overseas Vote Foundation, not only offers digital blank ballot delivery, but also have renewed their courier services through the assistance of the US Postal Service and FedEx to ensure that the Military voters' marked ballots can, in fact, make it back in time. But on the other hand, there is an unfortunate reality that once the digital path is open, OVF, US Mails, or FedEx notwithstanding, jurisdictions will explore leveraging the Net; its happening already in several locations. That does not make it right or preferable, but it does make it a reality that we need to address.
So, the District at least – at our encouragement dating back to March in Munich – heard our encouragement to explore options, but they did have some requirements.
Specifically, they wanted to conduct a Pilot of a solution that might be a better alternative to accepting returned marked ballots as eMail attachments or Faxed marked ballots exclusively for their overseas and military voters. And particularly unique to their requirements was – to our delight – a fully transparent open source software solution with unbridled ownership of the resulting source code for all elements of the Pilot solution. That, of course, is in complete harmony with our charter and mission.
Again, for those readers who know us, and understand our motivations and position on the Internet issue, you can understand our acute focus on the opportunity to deploy open source elections administration software in a real election setting. In the after-glow of this real possibility, and drilling into the details of how the ballot design studio could work for this, we realized we needed to get back to grappling with this digital ballot return detail of the Pilot project.
Initially, we were definitely concerned about how to approach this aspect of the Pilot, since we’ve been clear about our position on the use of the Internet. But to be frank, with the prospect that the District could simply turn to commercial proprietary Internet voting systems vendors, we felt we had to help find an alternative open source approach for the limited purpose of this Pilot. We encouraged the B.O.E.E. to find an alternative means to digitally return the ballot, but neither by deploying Internet voting products, nor by continuing to rely on Fax or eMail attachments in the clear. In return, they asked for our help in figuring out how they could implement a solution that worked with real ballot and attestation documents as digital artifacts, which could be transported on an encrypted channel. This could be better than eMail to be sure, but still using public packet-switched networks.
We turned to several of our technical advisers and convened a meeting to discuss how B.O.E.E and OCTO could approach a digital vote-by-mail Pilot to explore this approach to improving on eMail attachments or Fax’d returns. The meeting was frank, open, and rather than continuing the rhetoric of avoidance, we witnessed a bunch of stalwarts in information security express concerns, suggest points of mitigation, and brain storm on the possibilities. And several were kicked around, but tossed aside for want of either acceptable user experience, cost limitations, or operational practicality. A straw man solution was framed and members of the Core Team went off to refine it knowing that there were aspects that they simply could not address with this Pilot. Perhaps the most important Pilot parameter: this could not and would not be an exercise to completely assess and determine solutions to all of the known vulnerabilities of securing a voting transaction over a public network.
But it was agreed that a “digital vote-by-mail” process – with the known vulnerabilities and constraints – could be a “worked example” that simply was not what proprietary commercial vendors are selling. And, it was realized that such a solution could not and should not claim any victory in improved security or privacy – no such reality can exist in this solution.
And folks, that is simply and honestly the extent to which we were and are treating this: a “worked example” to serve as a vehicle for voices on all sides of the argument to train their attention in assessing, testing, and determining the viability of such an approach strictly for those overseas and military voters.
One could say the Foundation took a calculated risk: that in order to achieve the larger goal of deploying open source elections technology into a real production environment (a first, and hopefully ground breaking step), we would have to accept that our Stakeholder, B.O.E.E would use the Internet to transport a ballot and attestation document pair using the best possible techniques currently available – HTTPS and standard encryption tools. And at some measure, at least they had chosen not to pursue a commercial proprietary Internet voting solution, given their steadfast requirement of open source software and maximum transparency.
To my activist colleagues I offer this: we’re giving you a worked example on which to build your arguments against digital transport. Please do so! We're with you, believe it or not. Very frankly, I’d be happy to support some initiative to severely restrict the use of public packet switched networks for transacting voting data.
I want to (re)focus the Project's attention on the reason a few of us gave up our paying jobs some four years ago: to build a non-profit solution to restore trust in the computers used in the various processes of casting and counting votes. We don’t advocate iVoting. We do advocate accuracy, transparency, trust, and security in the use of computers in elections and intend to keep working on that open source framework. We do believe limited Pilots are worth it for the special use case of UOCAVA voters, if such a Pilot can fuel an intellectually honest debate and/or initiatives to resolve the concerns, or end the use of the Net altogether in this regard. We think the District of Columbia's Pilot is such a worked example.
OK, this went way over my intended length, but in the spirit of transparency its important we explain what’s been underway for the past several weeks from an authoritative source: Us. In the next installment on this topic, we will discuss more details on the technology we'll provide for the District's Pilot, and reiterate our concerns, but also consider the potential of the open source movement in public elections systems.
Thanks for reading. Greg Miller
Some of the feedback on my internet/email voting post can be summed up this way:
Is email voting really that bad? Sure, emailed ballots can be snooped, tampered, or diverted en route, but so can paper vote-by-mail ballots - yet we still use them. So what, specifically, is so much worse about emailed ballots?
First off, I have to say: "great question!" because it is asking about a comparison between two voting methods that appear to be very similar, but differ fundamentally, as Pito said in his blog post comparing vote-by-mail with atoms and vote-by-mail with bits. I can shed some light on the technological differences, in my laundry list below. But first I should point out the most important difference between the risks faced by the vote-by-mail (VBM) paper ballots en-route from voter to destination, and the analogous risks for email return.
The difference is, in a word, comprehension by voters. The threats to paper VBM are well-understood, relatively simple to state, and currently accepted as a trade-off for the ability to vote from overseas. Sure, an unknown number of postal workers in an unknown chain of national postal services, all can find VBM ballots, and mess with them or help other to do so. We know that, we're not keen on it, but it beats not voting all all if you live overseas.
But if you really want to claim that the risks of email are comparable to postal mail, then you have to appreciate a set of broader and more complex technological threats to emailed ballots. Here are some of those threats, that perhaps not everyone is familiar with, including not only a wide variety of technology that can mess with the ballots, and but also a wide variety of people with access to ballots.
- The email ballot's first step is in the telephone company of the place where the overseas voter lives. From the voter's computer, the email passes through telco equipment such as dial-up modems, digital subscriber link access modules (DSLAMs) for DSL service, or coax/cable service equivalents. Telco staff with access to this equipment have access to the ballot.
- The next step is transport onward from the telco to the voter's local Internet Service Provider (ISP), using a variety of network switches and routers and firewalls operated by the telco or the ISP. Again, everyone with access to these devices -- including remote access via the network -- has access to the ballot. The voter has to trust their immediate ISP to not read or tamper or block the email - not to be taken lightly for some overseas voters living in countries where the government actively intercepts Internet traffic.
- The next steps consist of more transport, via several ISPs along the way to the ISP of the voter's email service provider. A variety of protocols may be used, but Post Office Protocol (POP3) is fairly common, and the ISPs often have visibility on the POP3 sessions. Again, the voter has to trust these ISPs, and all the people with access to the network gear.
- The voter also has to similarly trust their email service provider, and the staff with access to the POP3 servers or similar, as well as the SMTP servers that move the mail onward towards it destination.
- Onward from the voter's email service provider, there is more transport via more ISPs, and as before the voter is typically not aware of which or how many ISPs, and how many routers and email servers are involved. From an overseas voter's home PC, it would not be unusual for an email to transit 5 ISPs, 4 mail servers, and 50 hops on the 3 phases of transport. (Those phases are: (1) from voter to their SMTP server, (2) thence to the BOE's SMTP server, and (3) then from the BOE's SMTP server to the email's destination.)
- At some point the email arrives on the SMTP server for the email address that the voter sent their email to -- hopefully, the SMTP for the BOE. From there onward, the email goes from the BOE's SMTP server to wherever the email finally arrives. In this 3rd phase, the email is accessible in the same way as in the first phase, but in reverse order: all the servers and routers and all the people with local or remote access to them, at these organizations: BOE's email service provider, the service provider's ISP, and the telco systems that deliver the BOE's ISP's traffic to the BOE computer that is the final destination of the email.
- And all that is assuming that the email actually arrives - which is not guaranteed, and can't be verified! Even a confirmation reply email can be easily forged.
Is all that different enough from postal threats? Sure, those overseas postal people can misbehave, but they have to first find a paper VBM ballot, then physical access to it, and time and space to work on the ballot, without significant risk of observation. With email, by contrast:
- There is a wide array of technology and systems and people with access to them.
- The access includes remote access where the people don't have to be physically proximate to the computer or the email data passing through it.
- And that's just the insiders, the people with legitimate access to these systems. But let's not forget the risks that some of these computers or systems have been compromised by purely digital adversaries -- a threat made all the more real by successful attacks on Google and several other top-tier technology companies.
I'm pretty sure that most overseas voters and most election officials do have a good understanding of paper vote-by-mail and its risks. I may be wrong, but I expect most of them do not have a similar understanding of this complex set of digital threats to emailed ballots en route, and have not assessed those risks to be at parity with the risks of paper VBM en route. Until and unless that understanding and assessment actually happens, then internet/email voting cannot fairly be said to parallel paper vote-by-mail as an equitable solution.
There is some interesting recent "Internet Voting" news from North Carolina and Georgia. The contrast is in ideal example of different ways of incorporating the Internet into election technology, sometimes helpful, sometimes not. From North Carolina, the news is on voting by eMail. This is explicitly permitted by NC law, and my NC colleagues tell me that state officials will be encouraging overseas military voters to return a ballot as PDF file attachment to eMail, during elections this year. Why now? Well, thanks to the MOVE Act of last year, it's now common practice to deliver blank ballots to overseas voters, typically as a PDF either sent to the voter by email, or downloaded by the voter from a state government Web site. That's great, because for many voters, there simply isn't time to wait for the paper ballot to arrive, mark it, and send it back via postal mail. Now that the ballot's outbound journey can be digital, though, there are still people who are in a situation where they doubt that postal delivery will get their ballot back in time to be counted.
So, a seemingly simple and obvious solution is to have the ballot's return journey be digital as well. But eMail is really not a great way to do that. One could say an awful lot about all the various problems, but let's just observe that with eMail the voter is surrendering anonymity of their ballot and the integrity of the ballot en route. On that route, the eMail message passes through several computers, whose operators can easily read it, and modify it or throw it away if they don't like it, all without the sender or receiver detecting it. (For a good video explanation of this, see Andrew Appel's Internet Voting primer, starting at about 2:15 into the playback.)
Now, I recognize that there are military voters who really are in a situation where there isn't time for even a one-way postal journey of a ballot. They may not have been in a position (literally) to download the blank ballot as soon as it was available. They may be in a situation where the first of the return post is military transport where bullets have priority over ballots and there is no assurance on when the ballot will get to where it can enter the military or local postal service.
But there has to be a better way than essentially telling these voters to either take the chances with lateness of postal return, or give up the secrecy of their ballot and take their chances with the ballot being modified or blocked en route. What would a better way be? Well, the news from GA is of some legislation regarding a pilot where overseas and military voters obtain a blank ballot and return it, digitally. The legislation doesn't say how, but it does nicely summarize a lot of requirements for authentication, privacy, anonymity, and integrity of marked ballots returned digitally. So it's an encouraging starting point for something that would be better. We'll have to stay tuned to see what GA's future pilot efforts can learn from NC's present.
Whew. We're through it, and for all the angst, sweat, and tears, I sense it went well. I want to thank the Panelists for being so good-natured (and well behaved as to the time limits in responses). We had some intense moments of heated disagreement and heated agreement. I'll have some more to say later when more recovered, but I believe this is the start of an on-going conversation that brought out the challenges and opportunities of using the Internet in the elections and voting processes.
- Apologies to Operation Bravo for getting it absolutely wrong on the Pilot locations (polling being on verses off Military base). I learned a valuable lesson to not try and wedge in that final question in the middle of the night when its too late to wake anyone to confirm facts. Good thing I had the "Plan B" question.
- Apologies to the activists who hounded me about using a coin toss to determine which side went first on closing remarks. I agreed to do so, put the 2 Euro in my pocket to toss, and then completely forgot in the rush of the final moments before going live to actually toss the coin, and had to randomly point at one side to go first at closing. DoH!
For whatever its worth, I will not declare a winner or loser. You can watch it on Vimeo or YouTube yourself when it finally posts in a couple of weeks.
But I will say this, as Moderator I thought the Proponents Team pulled it together in the closing argument and made some interesting points after earlier seemingly dropping some balls on answers. And I thought the Opponents Team could've registered a far stronger closing statement after slicing through issues with surgical precision throughout the preceding 80 minutes.
One More Apology
One final, off-topic comment that constitutes another, more serious "mea culpa." It has been called to my attention by a County Elections Official from Ohio who was "in the trenches" in 2004 and 2006, that our Every Vote Counts booklet has an error on the time-line page claiming a recount was required in the 2004 Ohio results due to machine errors. This is completely false on all counts and I allowed ourselves to be drawn in by some faulty reporting and research. In fact, some recounts in 2006 (not '04) were due to some scanning equipment malfunctions of a mechanical nature only. The machine issues otherwise alleged have never been substantiated and this Election Official, Rokey Suleman (now running elections in D.C.) has good reason to be frustrated with me by something unintentionally picking at an old battle scar.
We're going to fix that. I am committed to transparency. First, may I please publicly apologize to Rokey Suleman for my public relations and outreach teams' embarrassing goof. The buck (er, book) stops with me; they're my team and I take full responsibility for that. There are no excuses. We should have done closer proofing of the work. OSDV Foundation has a great story to tell, and I hate the possibility of diluting it with an errant statement or representation.
Here is the repair list:
- We will correct that page before any further printing of that booklet. I will do my best to halt further distribution of this version, but apologize in advance if there remain copies floating about or accidentally further distributed.
- More importantly, we're going to give Rokey Suleman our podium here to explain to all of you reading, the story inside Ohio from one of the gentleman who was in the middle of it; from his personal and direct experience. Mr. Suleman has agreed to draft that for our publication here under his name as a guest blogger.
Furthermore, I note that we learned here in Munich that Rokey is doing some amazing things in his new appointment running D.C. elections. And he has a deep commitment to overseas and military voters. I find him to be highly motivated, and passionately committed to accurate, transparent, trustworthy, and secure elections. And I am impressed by his innovative attitude and intense commitment to seeing the District of Columbia (America's answer to the Vatican ;-) ) be a thought leader and model for elections in the 21st century and digital age. His passion for transparency (and interest in open source methods) is refreshing.
I hope this small token of our regrets will allow Rokey Suleman another reasonably public forum to set the record straight (in this case, apparently skewed again at our own hands).
Otherwise, the Debate was fun and exhausting and I can't wait for the video replay. Cheers
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
- I will address a question to either side, and a specific individual and they shall have a 2-minute answer.
- The opposing side shall have a 1-minute response.
- The original respondent may have an optional 30-second rebuttal at my discretion.
- 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.
- 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.
- 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.
- 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.
- 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
I have arrived in Munich, reached my hotel and actually caught a nap. It was a sloppy slushy day here from what I can tell; about 30 degrees and some wet snow; but spring is around the corner. On the flight over the Pole last evening (I’m a horrible plane sleeper) I worked on final preparations for our Technology Track at this year’s UOCAVA Summit (which I wrote about yesterday). I thought I’d share some more about this aspect of the Conference. This is another long post, but for those who cannot be in Munich at this conference, here are the details. Historically, as I see it, the Summit has been primarily a policy discourse. While the Overseas Vote Foundation always has digital services to show off in the form of their latest Web facilities to support overseas voters, Summit has historically been focused on efforts to comply, enforce, and extend the UOCAVA (Uniformed and Overseas Citizens Absentee Voting Act). This year, with the passage of the MOVE Act (something I also wrote about yesterday), a new tract of topics, discussion, (and even debate) has surfaced, and it is of a technical nature. This is in principle why the Overseas Vote Foundation approached the OSDV Foundation about sponsorship and co-hosting. We thought about it, and agreed to both.
Then came the task of actually putting together an agenda, topics, speakers, and content.
I owe a tremendous “thank you” to all of the Panelists we have engaged, and to Dr. Andrew Appel of Princeton, our Chief Technology Officer John Sebes, and our Director of Communications, Matthew Douglass, for their work in helping produce this aspect of Summit. Our Director of Outreach Strategy, Sarah Nelson should be included in here for her logistics and advance work in Munich. And of course, I would be remiss if I left out the fearless and brilliant leader of the OVF, Susan Dzieduszycka-Suinat, for all of her coordination, production work, and leadership.
A quick note about Andrew: I’ve had the privilege of working with Professor Appel on two conferences now. Many are aware that one of our tract productions is going to be a debate on so-called “Internet Voting” and that Dr. Appel will give the opening background talk. I intend to post another article tomorrow on the Debate itself. But I want to point out something now that certain activists may not want to hear (let alone believe). While Andrew’s view of Internet-based voting systems is well known, there can be no doubt of his interest in a fair and balanced discourse. Regardless of his personal views, I have witnessed Andrew go to great lengths to examine all sides and build arguments for and against public packet switched networks for public ballot transactions. So, although several are challenging his giving the opening address, which in their view taints the effort to produce a fair and balanced event, I can state for a fact, that nothing is further from the truth.
Meanwhile, back to the other Track events.
We settled on 2 different Panels to advance the discussion of technology in support of the efforts of overseas voters to participate in stateside elections:
- MOVE Act Compliance Pilot Programs – titled: “Technology Pilots: Pros and Cons, Blessing or Curse”
- Technology Futures – titled: “2010 UOCAVA Technology Futures”
Here are the descriptions of each and the Panelists:
Technology Pilots: Pros and Cons, Blessing or Curse
The title is the work of the Conference Sponsor, OVF, but we agree that the phrase, “Technology Pilots” trips wildly different switches in the minds of various UOCAVA stakeholders. The MOVE Act requires the implementation of pilots to test new methods for U.S. service member voting. For some, it seems like a logical step forward, a natural evolution of a concept; for others pilots are a step onto a slippery slope and best to avoid at all costs. This panel will discuss why these opposing views co-exist, and must continue to do so.
- Paul Docker, Head of Electoral Strategy, Ministry of Justice, United Kingdom
- Carol Paquette, Director, Operation BRAVO Foundation
- Paul Stenbjorn, President, Election Information Services
- Alec Yasinsac, Professor and Dean, School of Computer and Information Sciences University of South Alabama
Moderator: John Sebes, Chief Technology Officer, TrustTheVote Project (OSDV Foundation)
2010 UOCAVA Technology Futures
UOCAVA is an obvious magnet for new technologies that test our abilities to innovate. Various new technologies now emerging and how they are coming into play with UOCAVA voting will be the basis of discussion. Cloud computing, social networking, centralized database systems, open source development, and data transfer protocols: these are all aspects of technologies that can impact voting from overseas, and they are doing so.
- Gregory Miller, Chief Development Officer, Open Source Digital Voting Foundation
- Pat Hollarn, President, Operation BRAVO Foundation
- Doug Chapin, Director, Election Initiatives, The Pew Center of the States
- Lars Herrmann, Redhat
- Paul Miller, Senior Technology and Policy Analyst, State of Washington
- Daemmon Hughes, Technical Development Director, Bear Code
- Tarvi Martens, Development Director at SK, Demographic Info, Computer & Network Security, Estonia
Moderator: Manuel Kripp, Competence Center for Electronic Voting
The first session is very important in light of the MOVE Act implementation mandate. Regardless of where you come down on the passage of this UOCAVA update (as I like to refer to it), it is now federal law, and compliance is compulsory. So, the session is intended to inform the audience of the status of, and plans for pilot programs to test various ways to actually do at least two things, and for some (particularly in the Military), a third:
- Digitally enable remote voter registration administration so an overseas voter can verify and update (as necessary) their voter registration information;
- Provide a digital means of delivering an official blank ballot for a given election jurisdiction, to a requesting voter whose permanent residence is within that jurisdiction; and for some...
- Examine and test pilot digital means to ease and expedite the completion and return submission of the ballot (the controversy bit flips high here).
There are, as you might imagine, a number of ways to fulfill those mandates using digital technology. And the latter (3rd) ambition raises the most concern. Where this almost certainly involves the Internet (or more precisely, public packet-switched networks), the activists against the use of the Internet in elections administration, let alone voting, are railing against such pilots, preferring to find another means to comply with the so-called “T-45 Days” requirement of placing an official ballot in the hands of an overseas voter, lest we begin the slide down the proverbial slippery slope.
Here’s where I go rogue for a paragraph or two (whispering)... First, I’m racking my brain here trying to imagine how we might achieve the MOVE Act mandates using a means other than the Internet. Here’s the problem: other methods have tried and failed, which is why as many as 1 in 4 overseas voters are disenfranchised now, and why Sen. Schumer (D NY) pushed so hard for the MOVE Act in the first place. Engaging in special alliances with logistic companies like FedEx has helped, but not resolved the cycle time issues completely. And the U.S. Postal Service hasn’t been able to completely deliver either (there is, after all, this overseas element, which sometimes means reaching voters in the mountainous back regions of say, Pakistan.) Sure, I suppose the U.S. could invest in new ballot delivery drones, but my guess is we’d end up accidentally papering innocent natives in a roadside drop due to a technology glitch.
Seriously though (whispering still), perhaps a reasonable way forward may be to test pilot limited uses of the Internet (or hec, perhaps even Military extensions of it) to carry non-sensitive election data, which can reach most of the farther outposts today through longer range wireless networks. So, rather than investing ridiculous amounts of taxpayer dollars in finding non-Internet means to deliver blank ballots, one proposal floating is to figure out the best, highest integrity solution using packet-switched networks already deployed, and perhaps limit use of the Internet solely for  managing voter registration data, and  delivering blank ballots for subsequent return by means other than eMail or web-based submission (until such time as we can work out the vulnerabilities on the “return loop.”) While few can argue the power of ballot marking devices to avoid under-voting and over-voting (among other things), there is trepidation about even that, let alone digital submission of the completed ballot. As far as pilots go, it would seem like we can make some important headway on solving the challenges of overseas voter participation with the power of the Internet without having to jump from courier mule to complete Internet voting in one step. That observed, IMHO, R&D resulting in test pilots responsibly advances the discussion.
Nevertheless, the slippery slope glistens in the dawn of this new order. And while we'll slide around a bit on it in these panels, the real sliding sport is the iVoting Debate this Friday -- which I will say more about tomorrow.
OK, back from rogue ;-)
So, that this is where the first Panel is focused and where those presentations and conversations are likely to head in terms of Pilots. In my remaining space (oops, I see I’ve gone way over already, sorry), let me try to quickly comment on the second panel regarding “technology futures.”
I think this will be the most enjoyable panel, even if not the liveliest (that’s reserved for the iVoting Debate). The reason this ought to be fun is we’ll engage in a discussion of a couple of things about where technology can actually take us in a positive way (I hope). First, there should be some discussion about where election technology reform is heading. After all, there remain essentially two major voting systems commercial vendors in the industry, controlling some 88% of the entire nation’s voting technology deployment, with one of those two holding a ~76% white-knuckled grip market share. And my most recent exposure to discussions amongst commercial voting vendors about the future of voting technology suggest that their idea of the future amounts to discussing the availability of spare parts (seriously).
So, I’m crossing my fingers that this panel will open up discussions about all kinds of technology impact on the processes of elections and voting – from the impact of social media, to the opportunities of open source. I know for my 5 minute part I am going to roll out the TTV open source election and voting systems framework architecture and run through the 4-5 significant innovations the TrustTheVote Project is bringing to the future of voting systems in a digital democracy. Each speaker will take 5 minutes to rush their topic, then our moderator Manuel will open it wide up for hopefully an engaging discussion with our audience.
OK, I’ve gone way over my limit here; thanks for reading all about this week’s UOCAVA Summit Technology Tract in Munich.
Now, time to find some veal brätwurst und ausgezeichnet bier. There is a special meaning for my presence here; my late parents are both from this wonderful country, their families ended up in Munchen, from which both were forced out in 1938. Gute nacht und auf wiedersehen!
I am on my way to Munich, as I post this, for the 2010 UOCAVA Summit. The OSDV Foundation is a co-host this year, and we’re coordinating the technology track of this 3-day gathering focused on the issues and opportunities for our overseas voters. This year’s event is arguably the most important UOCAVA (Uniformed and Overseas Citizens Absentee Voting Act) gathering since the passage of the Act in 1986. Last November, Congress and the President brought UOCAVA into the 21st century by passing the MOVE Act into law – which is somewhat like an amendment to UOCAVA. And 2 very important outcomes will be showcased this week in Munich.
As an aside, you may be asking why Munich and not, say, Washington D.C.? Good question (especially as I spend 17 hours of my day traveling from the west coast to Munich). But there is rhyme and reason here. Every election year in the U.S. (which means every other year) the Overseas Vote Foundation produces the UOCAVA Summit in Europe to bring together all of our fellow citizens and their organizations stationed abroad to learn the latest developments in efforts to include Americans overseas in the processes of democracy state-side. This includes large corporations with major installations in Europe and abroad, as well as NGOs and of course, the Military. What you may not realize is [a] there are over 6 million Americans abroad, and [b] recent studies, which catalyzed the MOVE Act, indicate that as many as 1 in 4 overseas citizens are unable to participate in U.S. elections for a variety of reasons, but due mostly to verifying their registration status and/or receiving and casting a ballot in time to be counted. So, this being a mid-term election year, the Summit is in Europe, and this time, Munich.
Now, what about those two outcomes?
The first major outcome of the MOVE Act to play prominently in this year’s conference is one of the fundamental mandates of the Act that states in relevant part, that elections jurisdictions shall provide a digital means to obtain a blank ballot for any overseas voter at least 45 days before an election.
At first glance, you might say, “Duh, of course, like, aren’t we already doing that?” And the answer is, by and large, no. But in this always-on digital age, making blank official ballots available for download, casting (filling out by marking choices), and then returning (through expedited mail means), seems to be the proverbial no-brainer. And now, federal law makes it mandatory.
Of course, caution: we don’t exactly want an unchecked number of blank ballots loose in cyberspace either (I’ll leave it as an exercise for the reader to realize why that might be a bad idea). So, we need to ensure that we only issue ballots to a qualified recipient, and in fact, each qualified recipient returns one, and only one completed ballot. Yes, yes, I know it is "block and tackle" sort of stuff. But the devil is in the digital details.
Accordingly, there will be much to discuss about implementing MOVE Act mandates, particularly blank ballot delivery by digital means (read: downloadable, probably a PDF). And, of course, the TrustTheVote Project is excited about this, because there is an opportunity to showcase the work underway on open source solutions to design, generate, and distribute blank ballots (that would be our Ballot Design Studio component of the TTV Elections and Voting Technology Framework -- incidentally, we're moving so fast that we have yet to update a bunch of documentation on the Ballot Design Studio project component on the Wiki... yes we need more help!).
The good news for our fellow overseas citizens is that this is a funded mandate, and all states and elections jurisdictions are hard at work determining how to meet the mandate. And there's more good news because at least a few states are already there. Non-profit organizations (NGOs) as well as the Department of Defense through the Federal Voting Assistance Program (FVAP) are also working hard to make services available ASAP. So, it will happen. And perhaps the OSDV Foundation open source technology – a publicly owned asset – will have a chance to play a role in that work.
There are many who are energized to make this as easy as possible in a digital age. And to some, providing blank ballots in a downloadable PDF is merely a start to bringing the processes of democracy into the digital age.
Therein lies the 2nd prominent outcome to be showcased this week.
You see, rightly or wrongly (and the arguments both ways are non-trivial) some believe that if the blank ballot is available digitally, there is no reason why we cannot cut the cycle time of overseas voting completely by making it possible to fill out the ballot digitally and then returning it by digital means.
The Department of Defense, for example, argues from the simple point-of-view of risk management. To many in the military, the benefits of a far greater probability of having their ballot received and counted far outweigh the risk of a ballot being read, intercepted, or even hacked (let alone revealing the identity of the casting citizen). A military statesman, whom I have a great deal of respect for, points out that shooting with "live ballots" is nothing compared to shooting with live bullets, so this is an easy decision (i.e., to adopt as digital a process as soon as possible to ensure speedy delivery and return of ballots).
For other overseas citizens, whose mail services are far better and accessibility challenges are far fewer, the digital means to complete the “ballot transaction” represents a powerful convenience given their remote (absentee) status.
But this opens “Pandora’s Internet Voting Box” to the opponents of this proposed digital efficiency, because if digital ballot casting is extended to our military, and then expanded to include overseas voters, goes the argument, then every absentee voter on the planet (including those merely “out of town” on elections day) will cry foul if they too are not allowed to participate in this highly efficient 21st century manner.
Then the horns kick in, and my shoes start to squeak, because this is a slippery slope, and gosh darn it, this sort of thing could lead to Internet voting! That is the 2nd outcome of this week’s conference: the great debate on whether public packet-switched networks should be used to transact ballot data in public elections.
At times, we’ve alluded to our position on that matter in blog posts and other content here on the Blog and our project Wiki. And I will leave it as an exercise for the bored and curious to “look it up.” What I will say is this: contrary to several concerns raised, I signed up for, and remain committed (with a fiduciary sense of responsibility) to moderating a fair and balanced debate on Internet Voting or what we’ve coined ‘iVoting.” And I have no intention whatsoever of attempting to sway the debate in one direction or another, favour one side or another, or allow my opinions to color my commentary or line of questioning.
To some, the use of the Internet in public elections is inevitable as we progress into the digital age. Maybe so. And to several European nations, this step has already been successfully achieved. Bear in mind that there are historical and key cultural differences between the USA and Europe in matters of public elections making adoption of methods like vote-by-mail as well the Internet both palatable and plausible.
To others, this is a nightmare unfolding before their eyes. These opponent activists have relied on academics and other domain experts’ assertions, observations, and statements, which are necessarily technically accurate. The (valid) concerns of these technically precise professionals have fueled the fury within opponents who reasonably fear for the integrity of our elections, if they are conducted across a digital means where compromises and vulnerabilities are an inherent part of the architecture of packet-switched networks. And caution should be exercised.
Does this mean that the notion of using the power and capability of the Internet to enable this important aspect of our digital democracy should be outlawed, forbidden, and eliminated from consideration?
Is there a middle ground that provides a way forward wherein carefully supervised experimentation, research, and further development into designs and deployments that address the persistent integrity issues?
Should we realize and respect that going forward democracies in a digital age must provide a plurality of means by which its citizens can participate in elections, whether that be by mail, in person at a polling place, partially through digital means, or entirely on-line?
Or are the integrity issues raised largely unwarranted in the face of technical capabilities, processes, policies, or procedures that are being drowned in the calls for a legislative mandate to make illegal the use of the Internet in any capacity in public elections? (Note: keep it on the down low, but packet-switched networks have been used to back-haul aggregate election data for years.)
All of these are the questions and issues are being discussed (and debated) this week in Munich at the 2010 UOCAVA Summit. And they are being driven by both [a] the passage of the MOVE Act into U.S. law and [b] the full throttle intent by some groups to advance all of the potential capabilities of digital delivery of ballots for (at least) overseas voters. Stay tuned.
Thanks again to David Jefferson for his post yesterday on the lessons for Internet voting of the Google/China news (NYT: In Rebuke of China, Focus Falls on Cybersecurity). To answer some follow-up questions, I'll explain a bit about the term vote servers that David referred to. Let's start with a little background on Internet voting. Many peoples' cybersecurity concerns about i-voting have a focus on the vulnerability of the voter's Internet-connected computer, on which a Web browser is used for i-voting. The browser communicates with an i-voting Web server (or vote server), displays ballot items, allows the user to make vote selections, and so on (very similar to what many people do with surveymonkey and similar services on the Internet today). The security concerns are valid, whether the client computer is a home PC or a special-purpose kiosk system in a physically controlled polling place set up in a military base overseas.
But just as important is the "server side" of i-voting - the Internet-connected vote server, the Web server front-end, the database it uses, and all the other datacenter infrastructure. That infrastructure is one basket with all the eggs - the data that is used to create an election result. So of course there is concern over that basket being a target itself. After, why trouble with renting botnet time, crafting malware to distribute to already-hacked PCs, and the other work required to tamper with some of the i-ballots at the source? Why bother, if you can tamper with all of the ballots' votes at the single destination? Good question, and the typical answer is that attacking the source is much easier, if you assume that an i-voting datacenter uses "industry best practices" for security, as is the common claim of i-voting vendors and service providers.
But as the continuing Google/China news shows us, dedicated, politically motivated adversaries have been quite able to penetrate the defenses of the I.T. plant of some of the biggest most tech-savvy companies with some of the best I.T. and security staff in the world. That being the case, why should anyone blithely accept any claim that a i-voting datacenter is sufficiently defended to protect the vote data and the election itself?
Now, nobody is suggesting that the Chinese government would try to hack Internet elections for real U.S. government offices. But now look at it from the point of view of a responsible election official, pondering the offers of for-profit vendors of proprietary i-voting solutions, who have indeed run a few election pilots and would like to have the business of running full elections out of their data-centers using their i-voting systems. The vendors claim that they have spent "enough" time, money, and effort on security. The question is whether ...
... some small company that has run a few election pilots has any chance of locking down its vote servers so tightly that it can withstand a similarly determined "highly sophisticated and targeted attack" when Google and these other big company's cannot?
That's not a rhetorical question! The vendors are probably not the right judges about "enough" but there are several U.S. election officials who are currently mulling i-voting for overseas and military voters; they are the ones who need to weigh the risks and benefits, the required security and controls -- hopefully with the advice from some of several the election technology and security experts at work on election tech or policy today.