Viewing entries tagged
vote by mail

Comment

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

An esteemed colleague noted the news of the USPS stopping weekend delivery, as part of a trend of slow demise of the USPS, and asked: will we get to the point where vote-by-mail is vote-by-Fedex? And would that be bad, having a for-profit entity acting as the custodian for a large chunk of the ballots in an election? The more I thought about it, the more flummoxed I was. I had to take off the geek hat and dust off the philosopher hat, looking at the question from a viewpoint of values, rather than (as would be my wont) requirements analysis or risk analysis. I goes like this ...

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

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

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

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

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

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

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

-- EJS

Comment

Comment

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Comment

Comment

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

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

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

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

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

-- EJS

Comment

Comment

Elections and the Internet: What's Helpful, and What's Not

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.

-- EJS

Comment

Comment

MOVE Act Implementation: Call For Participation

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

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

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

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

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

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

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

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

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

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

Cheers GAM|out

Comment

Comment

Why Publish Ballots?

I'd like to thank Eric Rescorla for making an excellent and pithy point about the purpose of publishing images of  marked ballots.  But first, thanks (again) to Mitch Trachtenberg of the Humboldt Transparency Project for publishing a hand-picked set of ballot images that provide a great example of the difficult borderline cases of interpreting hard-marked paper ballots -- whether it is a human or some software doing the interpreting.  Ballot publication can show how much of a given election result actually depended on these borderline cases. Eric made a broader point that is so widely misunderstood that it truly merits repetition:

The main point of publishing ballot images  is to allow people to independently verify that the images published correspond to the votes recorded for those images.

True, but verification requires more than ballot images - it requires that each image is published along with information about how that ballot's marks were interpreted as votes that were counted.  I cringe every time somebody talks about ballot image publication as though it were just posting some JPEGs on a Web site.

By viewing the images plus these "cast ballot records", members of the public can look at a ballot image and decide for themselves whether they think its votes were interpreted correctly -- and if not, whether the putative mistakes are enough to effect the outcome of a race.

And just as important, consider the cases where an election official is involved in deciding an ambiguous mark - particularly at large scales such as with vote-by-mail.  As a result, broader transparency requires that the election process maintain audit records of these decisions, in case they need to be re-visited.

So, sure, the publication of images alone is helpful for transparency, but Mitch's examples show how much interpretive leeway there can be. And in close elections, that leeway can influence whether a recount is required, or even influence an election result. So it's just as important to maintain and publish cast-ballot records, audit records, and the like.

But that is a lot of work!

And often is not feasible with current voting systems and election management technology. It's actually quite a job to maintain and publish all this information in a form useful to members of the public - a job that we're working on at the TrustTheVote Project of course, by building all of our election technology system components with the "Save Everything" principle.

-- EJS

Comment

Improving on the Minnesota Recipe

In yesterday's and other postings, I praised election officials in Minnesota, and said that election officials nationwide can learn a lot from how Minnesota conducts elections, including but not limited to audit and recount. Today I'd like to point out some improvements to the MN recipe, starting from the root cause of the need for improvements: lack of public confidence in voter registration systems. Across the country, we've seen many voters doubt whether their upcoming election day experience would be successful, because of concern over errors in voter rolls, or polling snafus in interpreting them. Based on earlier horror stories from Ohio and elsewhere, it's an undertandable concern. In many states, it's difficult even to check on one's registration status. The result of these concerns is a desire by many voters to voter early, in the theory that if there are problems with voting, they can be diagnosed and fixed early, in time for election day; but if you wait until election day to find probems, you likely won't be able to vote. I think that this concern will persist for some time, despite creditable work by state election officials to improve the accuracy and accountability of their voter registration systems and procedures.

In MN in 2008, the only form of early voting was vote-by-mail, and the huge jump of vote by mail participation is interpreted as being in part a desire by many Minnesotans to vote early for precisely the above reasons. But that huge jump on vote by mail ballots also set the stage for the Coleman-Franken dispute, and also illustrates the need for improving the recipe. Here's the problem: every county in MN has its own rules for its own election officials to perform the process of examining a vote by mail envelope, and determining whether the ballot inside should be counted. Further, each county has its own practices for logging these activities and decisions. And of course there is risk of human error as well, magnfied by the large number of VBM envelopes to examine.

Reviewing the VBM envelope processing was a key part of the MN recount procedure, as well as the controversy following it. Part of the purpose of the review was to find those cases where an election official had made an error in following their county's rules, and had mistakening excluded a VBM envelope that actually was just fine, such that the ballot inside should have been counted. When these cases had all ben reviewed and resolved, the next bit of fuel for fire came from cases where in one county a VBM envelope was excluded and in another county a VBM envelope was included even though the two envelopes had very similar imperfections. These cases were correct, but confusing because of the variation between counties of the rules for VBM envelope review.

That brings us to two improvements on the current MN recipe, that some MN election officials would like to put in place: early voting to cut down on the number of VBM ballots and hence the number of cases where an election official has to decice whether a ballot counts or not; and state-wide uniform VBM envelope processing rules, so that all such decisions are made in the same way, and all review of those decisions (esp. in a re-count) is performed uniformly. To those two procedural improvements, I would add a third, technological improvement: apply to VBM envelope processing the same kind of accountability and transparency measures that we're starting to see in some state voter registration systems. What are those measures? Stay tuned. ;-)

EJS

Comment

House Panel OKs "Voting Paper Trail" Bill

I thought that today's news about e-voting and legislation is notable as an example of the way voting technology and policy interact in our unique U.S. voting system.

First, what was Congress working on? Crafting legislation about elections; one bill to authorize payments to states for efforts to put in place paper ballots or paper audits for the November 2008 election, and another that effectively over-rules 21 states' regulations requiring a voter to have a valid "excuse" to qualify for an absentee ballot (a.k.a. vote by mail).

Comment