Brace yourself for the Ohio State backlash.

woah! Brad, let me make sure that I read this correctly... You mean to tell me that in the face of incontrovertable facts, bone stupid common sense and (perhaps!) an acknowledgement of the minimum procedures necessary to run a democratic election, election officials in DC actually DID THE RIGHT THING (at least for now) and stopped an attempt to undermine our democracy with technology? My mind is blown! This goes against everything that I thought this country stood for since Shrub! I need to sit down and think about this for awhile!

Brad, good coverage. But you should know I'm not "of the RISKS Digest" - the RISKS digest has been a public forum for computer scientists and others to share risks for over 25 years.

Thanks, Jeremy. Will correct that right away. And thanks for ur good work on this beat! Have a feeling this latest (Internet Voting) nightmare is just beginning...

On the banks of the Red Cedar
There's a school that's known to all
Its specialty is winning
And those Spartans play good ball

Fie on Wolverines, I say, fie!

Brad, your links used to post to Facebook with titles, graphics, and description, e.g., on June 22 at http://www.facebook.com/SaveOurVote. Now all we get is the reproduced link. We add the titles but it still lacks the picture. Anything you can do on your end?

Why did these peeps not use OpenBSD as the server operating system for this e-voting application??? It's the most SECURED O/S on the planet and free to download & use. It's based on Berkely Unix which was developed at the University of California (Berkeley) back in the 70s.
Not even the CIA can hack into a BSD system.
Visit the OpenBSD project in Western Canada at http://OpenBSD.org and be amazed.

Paper ballots are remarkably resilient from remote manipulation. Just sayin'.

Barbara Glassman - Thanks for pointing that out. Haven't made any changes on this end, so let me look into that!

Thanks, Barbara! I was wondering the same thing.

I just want vote by mail. Easy for me and the post office needs the business.

@Max, you said "Why did these peeps not use OpenBSD" - I'm not sure whether or not they did (according to the DC diagram at http://www.dcboee.us/DVM/Visio-BOEE.pdf, they're using VMWare ESX, but it doesn't say what they're running on top). But the vulnerabilities were application vulnerabilities, not OS problems. So they would exist regardless of the underlying platform. That's the problem with application-level vulns - hardening the OS generally doesn't help.

Why don't they just use a paper ballot system? Even the most SECURED system would still leave us wondering if somebody on the inside could mess with the votes. Go back to the future - paper ballots, hand marked, stuffed in a clear plexiglass locked box, then dumped out on a table and counted before anybody that wants to watch. How hard is that?

shw

Brad-
A couple of points:
1. Your assertion that the Foundation is advocating Internet voting is patently wrong, and void of intellectual honesty. Anyone who reads the trustthevote.org blog will be properly informed on just where we stand regarding "Internet voting." the record is clear, we do NOT support widespread use of it. Which leads me to point #2:

2. Our role in the D.C. project was to deploy our ballot generator, and we also assisted them with developing a "worked example" of returning ballots by some means other than their current process of eMail or Fax (!) We fully intended this public evaluation to uncover any problems that might prevent its safe use (i.e., the PDF uploader vulnerability that is the center of attention here). They (U. Michigan) DID, and the BoEE thanked them and did the RIGHT THING: took the site down and canceled its use this November. (we applaud them too) However, without this worked example to illustrate what could go wrong, everything was academic jousting. To that extent, we believe this entire exercise has been a complete success (particularly since the D.C. BoEE did the right thing and took the site down.

But please refrain from falsely accusing us of something we're NOT doing: advocating the use of Internet voting systems. We're busy working on voting system source code that can be adopted adapted and deployed to bring about accuracy, transparency, trust and security in any voting system that uses a computer for counting and in some cases preparing or casting a ballot. NONE of our system architecture is intended for any public packet switched network; NONE of it. Your charge just killed your credibility in my mind because perusing our blog posts would set that record straight. I have been a big supporter of you and your cause, but this just baffles me why you would make such a baseless charge.

Jonathan Simon has written an excellent piece on the recent special election in Massachusetts and its anomalies.
http://electiondefenseal...OrNot_Final8-30-10_1.pdf

Hope that link works. If not, go to the Election Defense Alliance and read his article-- Believe It Or Not.

To those who say "why don't you use paper", the DC system (and similar systems) are intended for UOCAVA voters - military and overseas voters who may be a thousand miles from the nearest ballot box and with irregular mail delivery. The goal is to allow them to cast their vote - many overseas voters who request absentee ballots never receive them, and some number that get sent back get lost in the mails.

(As an example, my sister, who has lived in the same small town overseas for 40 years, sometimes gets her blank ballot and sometimes doesn't. And it's a whole lot harder for military people who are moving from location to location, so between when they request their ballot and when it arrives they may have moved several times.)

I don't say this to endorse Internet voting, but rather to suggest that it's not as simple as "drop your marked ballot in the clear ballot box".

Of course we could do like some countries and do away with absentee voting, but methinks that would be a political non-starter!

Gregory Miller @ 14:

Happy to correct and/or amend the article above to point folks towards your comment and/or objection to my coverage.

But before I do, quick question to help me under stand OSDV's position: While you say that OSDV is not "advocating Internet voting" and that you "do NOT support widespread use of it", do you support it's use under federal grants available for pilot programs for Internet Voting use by overseas and military voters? (as occurred in this D.C. sitch?)

Also, did you warn D.C. against their Internet Voting scheme before you participated in the program, or anytime during its implementation? If so, do you have any documentation of that? If not, why didn't you? And why would you participate in a program that you believed to patently unsafe and unsecured for voters? Wouldn't a principled stand require you to not participate at all in such a scheme?

Look forward to your thoughts.

Brad-
To your questions:
1. For those jurisdictions with military and other qualified overseas voters who have no other reasonable means to return their ballots in time, we support the DoD/FVAP program to explore the LIMITED use of online services. The risk of doing so is clear and present, but we believe it is up to the Elections Officials to make that risk assessment. So for this limited use of overseas UOCAVA voters, the alternative is eMail or Fax return, which we believe is even worse. So call it a choice of evils, and in that regard, we support the FVAP effort, so long as it is limited to qualified UOCAVA voters. By qualified I mean that they can demonstrate that relying on alternative means like those provided by the Overseas Vote Foundation (for instance) is not reasonable to ensure timely return and avoid disenfranchisement.

2. Yes, we have discussed the dangers of using the public packet switched network with several officials in D.C. We've presented slides from Dr. Appel and felt we informed them. NO, unfortunately, I do not have documentation of that, but there are officials in D.C. who would verify my assertion here. And to provide some protection, we strongly pursued the concept of a public test of the demonstration system BEFORE any public deployment and that if any vulnerabilities were uncovered that could not be timely resolved (and re-tested) before going live, then it had to be pulled. That happened. No live data was ever used; no real ballots, and no access to any voter information was ever involved.

3. We participated in the program on the basis that we would have an opportunity to put some of our open source components (the ballot generator for instance) into a production setting, and this production setting involved a very restricted use of a digital means of ballot transfer for qualified overseas "UOCAVA" voters ONLY. We continue to believe the Internet is unsafe for transacting ballots. We believed the method the District wanted to use was better than eMail or Fax, and if one looks at their architecture rationale document (43 page technical white paper available on their site) the approach appeared to offer a means worth examining and piloting for this very restricted audience, whose alternative return methods are guaranteed less private or secure.

In retrospect, had we known that putting this system into a public review cycle, with fully transparent code would result in such a backlash if a vulnerability in deployment was uncovered, we never would've participated.

To be sure, the greatest enemy to all sides was a mismanagement of time. The cycle time for evaluation was greatly compressed. The rush to deploy components resulted in basic block-and-tackle errors (from what we can tell; we have NO role in the data center, access to it, or even visibility on what exactly happened on their back-end.) But for sure, the mismanagement of time and process is the real teachable element here. I say that, because in a more reasonable time frame, the configuration screw-ups that occurred would've been trapped and corrected before the public review. But the theory was to put it out there and let people have at it BEFORE any decision to turn it live was made.

I also point out, that one of our agenda items was to push this along so the elections verification community could, in fact, have a venue, forum, and real worked example on which to make their case. And they have it and are doing so. I still think that there is a success in what happened.

One final point, the CTO's office in D.C. is conducting their own internal investigation into the U. Michigan's findings. I understand there will be more to come out, that may clarify the Haldermann team's findings. We'll see, it is entirely out of our hands.

Call me suspicious, but the actual name of the Michigan Fight song is "The Victors". Perhaps someone leapt to conclusions re; the meaning of the message? Also, a really clever hack might have used the Iowa Fight Song. Go Hawks!