% fortune -ae paul murphy

Yet more on Evoting

Back in 2004, when I wrote my evoting series for Linuxinsider, I was sure that a voting machine constructed on Sun Ray technology would need to print ballots for backup and function in a traditional polling place - but I was wrong on both counts.

The reasons for that are first that polling places put unnecessary burdens on voters and electoral officials alike; and secondly that paper ballots printed in parallel with electronic vote recording create their own problems but are useful only as backups to the electronic record and not as controls against fraud.

Imagine that we have:

1. voter lists constructed from public records with voters able to identify themselves to the system using simple documentation like a driver's license, discharge card, tax document, or other legally acceptable means;

2. a simple process to produce an on-screen ballot appropriate to the jurisdiction(s) and remaining votable issues affecting the voter's primary or declared residence;

3. two servers, A and B, set up in, and run by, each state (or run federally in embassies or on military bases) such that a transaction on the A database is automatically mirrored on B, and vice versa; and,

4. dual national data centers set up to get all of the data from all As and all Bs as these update.

With Sun Ray technology you can't fake a device - because only registered devices will work and either adding one or turning one off can be made to trigger an alarm and a log entry.

Since the voting software will not trigger a countable vote unless the entire chain is intact - it's an eligible voter's first and only allowed vote on the issue, the machine being used is legitimate, the end to end encryption is correct- the only things the accumulator systems have to do is record each vote and then strike that voter from the eligible list for each ballot item voted on.

Since the Sun Ray cannot be separately programmed and can't be replaced with a fake, the process controls needed to ensure that the records arriving at the local accumulators are correct are relatively simple - and the A/B structure ensures that multiple audit and operational teams log and scrutinise each action.

The same is true at the national level: there are few opportunities to cheat, and appropriate controls can be put in place to limit their usability.

Notice that printing a local ballot is pointless - if the on-screen process completes, the vote has been recorded in at least two places - and four a few seconds later. If it doesn't, then the failure is obvious.

Notice too, that any public place where Sun Ray terminals are in use during normal working hours and in which appropriate privacy can be guaranteed - schools, public buildings, hospitals, the PX, an embassy interview room - can be used along with all of the existing (i.e. no marginal cost) network infrastructure.

To my knowledge there are two technical challenges with this:

1. ballot secrecy must be protected - i.e. the system cannot update the vote count and record the voter's eligibility change in the same transaction or in any other way that would allow these two events to be closely correlated by someone with full access to all data and all logs; and,

2. the system has to be able to cope with blackouts - areas where there normally isn't adequate network service, areas where power failures or civil emergencies intervene, or areas affected by third party attacks on network performance or infrastructure.

I think the A/B structure (different teams, different auditors) coupled with decisions not to record things like write times, can be used to address the first set of issues while the nature of the system protects against the second. Thus a snowstorm in New Mexico need not affect the presidential vote because people don't have to go to any particular polling place and allowing voting to start early or end late has no significant organisational, or cost, consequences.