One, voting in private with internet voting might encourage vote buying. I suppose technically the same vote buying could be done with absentee mail-in ballots, and it might happen but it is more physical work and risk involved. In internet voting scheme, you might have some spyware type program that verifies how you voted and then sends you the “check” or whatever.

Other issue is that you cannot have secret ballot AND verifiable elections. It’s fine if you want to promote getting rid of secret ballot, but no crypto anything can make it possible to prove your vote didn’t get hacked/switched/recorded wrong, and with no paper trail and still be a secret ballot. If you can prove how you voted and what was recorded, that means someone else can do it and you have no secret ballot. Internet voting is impossible if we cling to concept of secret ballots.

Second, when the voter casts a paper ballot, the voter has no notion what happens later. All later processing is – to the voter – a black box, run by folk the voter does not know and has no reason to trust. Voters have no notion whether that physical ballot was later counted or shredded. Voters have no reason to “trust the vote”.

You can tell stories … but “trust us, we are from the government” is not and should not be universally convincing. Voters need verification.

As a voter, do I have any way of knowing if my votes were counted? I do not, as the voting process lacks any sort of end-to-end check. To the voter, the vote collection and counting process is entirely opaque. Likely very few voters are anything close to certain their votes are always correctly counted (and this is a rationale response to an opaque process).

Curiously, one of the most secure voting systems is the most simple.
… Gather all voters into a single room.
… Place all ballots in a ballot box, in plain view.
… Unseal and count the votes in plain view of all voters.
Clearly this is not easily scalable to millions of voters – but the point is you can trust the voting process, even if you do not trust those who handle and count the votes.

The voting process can be less transparent, when you know and trust those who process the votes. This too is not scalable to millions of voters. Trust is required in our present voting system, and trust is not present.

Take a page from network design. When you cannot trust the network, you need some check on errors. Early networks has some over-elaborate designs (remember ISO OSI?), but in the end we came to realize and end-to-end check was critical, and everything else was secondary.

In large voting processes, voters have on reason to trust the folk involved in the process. If a voter can verify that their votes were counted, trust is not required.

The end-to-end check is key.

http://blog.verifiedvoting.org/2010/05/13/531#more-531

However, need to clarify something regarding the EAC report and what the totality of legislative mandates are regarding electronic absentee voting for UOCAVA voters.

Although the MOVE Act does not itself mandate the examination of the electronic casting of voted ballots in the authorized pilot programs, the 2002 and 2005 National Defense Authorization Acts do require EAC to develop guidelines for the electronic return of voted ballots. Specifically, 42 USC 1973ff (note) states:

“(a) Establishment of Demonstration Project.—
“(1) In general.—Subject to paragraph (2), the Secretary of Defense shall carry out a demonstration project under which absent uniformed services voters are permitted to cast ballots in the regularly scheduled general election for Federal office for November 2002 through an electronic voting system. The project shall be carried out with participation of sufficient numbers of absent uniformed services voters so that the results are statistically relevant.
“(2) Authority to delay implementation.—…the Secretary [of Defense] may delay the implementation of such demonstration project until the first regularly scheduled general election for Federal office which occurs after the Election Assistance Commission notifies the Secretary that the Commission has established electronic absentee voting guidelines and certifies that it will assist the Secretary in carrying out the project. …”

That’s where we are now – EAC and NIST, supported by FVAP, are in the process of developing those guidelines. And the Pilot Program Testing Guidelines are one of the first steps in developing testable systems (in this case a kiosk-based system) that will help this process advance to full, remote PC-based electronic absentee voting guidelines.

MOVE Act then expanded on that electronic absentee voting guideline development requirement saying in Section 589(e)(1) that EAC and NIST were required to support FVAP’s MOVE Act authorized pilot programs by issuing the guidelines directed above by the 2002 and 2005 laws. The MOVE Act then goes on to say in Section 589(e)(2):
“In the case in which the Election Assistance Commission has not established electronic absentee voting guidelines … by not later than 180 days after enactment of this Act [April 26, 2010], the Election Assistance Commission shall submit to the relevant committees of Congress a report containing the following information:
“(A) The reasons such guidelines have not been established
as of such date.
“(B) A detailed timeline for the establishment of such
guidelines.”

So, it was not the MOVE Act Pilot programs that drove this EAC report, per se, but the mandate in the 2002 and 2005 National Defense Authorization Acts on EAC and NIST to provide FVAP with the electronic absentee voting guidelines for casting voted ballots by the military electronically. Finally, if one goes back and looks at the Senate and House Armed Services Committee reports as well as the Conference Committee reports, for the 2002 and 2005 National Defense Authorization Acts, the Congressional intent is clear that such electronic absentee voting systems are to be remote, PC-based electronic voting systems.

Regardless of what you think of that law mandating the development of remote PC-based systems for the electronic casting of voted ballots by military voters, that is the law, and EAC, NIST, and FVAP are obligated as federal agencies to pursue its execution.

The question is, as you well know, how?

Bob Carey
Director, FVAP

I agree with the notion of distribution among the states as a way to avoid a single point of failure. Indeed in 2000 we had what appeared to be a failure in the Florida election with the design of the ballots. I am sure this is not the first or the last time this will happen and I am not sure why the fretting about Internet voting, except that the potential scale can go as wide as a state.

The way that elections are being piloted right now implies that a small set of vendors are getting their hand at helping certain jurisdiction to test out the ballot presentation process. The issue then is not in the idea of a hack attack taking down the whole election. The issue is that a small set of vendors would actually be responsible for all Internet voting. And that means that when one system is compromised in one county, that could spread to other states quite easily, and very quickly.

Since the underlying technology solutions used by states is not a secret due to transparency laws, in fact the notion that each state is separate unto itself goes away when a small set of vendors run elections for all 50 states.

There are seemingly 2 options:
1. Increase the number of vendors to ensure that no 2 counties or states run the same technology and makes security by obfuscation and lack of standards the order of the day. This is basically how elections are run now.

2. Use an open source solution or even a set of open source solutions that work teogether, that is available for all states/counties to use. The code will be open, transparent, the systems as well. Anyone can inspect the code for issues, problems. Independent sources will be able to understand the limitations and FIX them, by the people who can.

In the first option, a small number of companies win outright and gather the spoils. There will not be a huge number of these companies simply due to the way economies of scale work. They will buy each other and consolidate into a few eventually simply due to economics and how high tech usually works.

In the second option, it will take a very very long time for high quality open source solutions to arise simply because THERE IS NOT AS MUCH MONEY in this work. So there is much less to go around as licenses are free. In theory only hardware, if any, needs to be bought, and services to install/manage/maintain.

As the election officials and others who run elections become younger and more technologically mature and proficient, there may be a time in the future that they can THEMSELVES install this technology as long as it is cheap and cheerful.

The other issue for open source is that monolithic, hard to manage apps are HARD to create simply due to the nature of the development process. This is a negative because it takes that much longer to create the solutions, but the crafting of the designs and solutions are that much better thought through.

I’d say the option #2 is the only clear way to proceed in the long term, but both options 1 and 2 will continue to wage battle in the short term. In theory both can operate simultaneously in concert to see which cultural philosophy wins out. This could be the first real huge win for open source in government. And that the DoD must take a stance on this issue to give some guidance for these abroad pilots that are on the horizon in 2010 and 2012.