[E-voting] UK shelves plans for e-voting trials

Brian O'Byrne bobyrne at statesoft.ie
Tue Sep 13 12:12:02 IST 2005


Thank you, this is an excellent example to work with. We are really
getting to the meat of the issues here.

This is going to be a quick first-glance response. I'll work up
something more detailed in time. I know you are planning on another
message to outline execution and measurement, so my comments here
might be useful guidance for that.

On Tuesday 13 September 2005 08:11, Craig Burton wrote:
> Brian,
> You propose some good questions and I think examples will help
> illustrate my position.  I'll cut to the chase and attempt to
> define a pilot.  Really, a large document would do better than a
> one-page email, but I'll take a punt.  I'll propose the same format
> of pilot I have run before with a new piece which attempts to
> combat ddos.
> I'll start by spelling out what I assume we have at our disposal in
> terms of technology, time, trained and untrained personnel and what
> I can summarise as the skills or non-skills of the end-user, the
> REV voter.  I'll go in to the execution and evaluation in a reply.
> 1.  voter education : we have facilities to execute some form of
> REV education that reaches a good number of the potential REV
> users.  This is hard in a pilot, because a pilot is new, however we
> expect coverage to ultimately reach most voters if pilots are
> ongoing.  In Stratford, we had a controlled budget of GBP5K, 4
> weeks and we reached half of all voters.  Ideally we would start
> the pilot process from registration time.

Do you see education including any more than how to vote using this
I presume you will include the receipt process and anti-coercion
measures. Will you also include pointers on how to detect problems on
the end-user terminal? ie: Give people tools to be vigilant?

> 2. basic literacy : all
> potential REV voters have or have access to some minimal computer
> skills : we have to assume the REV voter can understand or have
> demonstrated to them the use of a mouse or keyboard, a windowing
> interface and a browser or assistive equivalent such as the audio
> system.  We have to assume they know the rudiments of networking
> and what "getting online" means.  All voters have to understand
> what it means to "key this address into your browser" although we
> may depict this and other instructions pictographically.  We have
> to assume that at least some of them read and follow all the
> instructions, including our VVAT advice.  We also need a minority
> of REV users to be fluent computer/Internet users.   A minority of
> people are election volunteers and psephologists in the paper world
> as well, for example.

So when my Mom says she doesn't want to go out to the polling station
because it is raining, are you going to prevent her from using the
REV channel? (My Mom has minimal experience of using a computer).

I understand your desire for a minority of REV users to be fluent
users (I'd even go further and expect some to be professional IT
people) but what is their role in this? If it is to be vigilant, then
I have a few concerns:
- The points I mentioned previously about not be able to test the
voting software still apply. ie; I still dont see how vigilance of
this nature is going to detect problems.
- What will motivate these people to be vigilant?
- I'd be concerned that experienced users will habitually practice
'safe computing' that will render them less likely to see problems.
(Anecdote: I have a laptop I use when I am on the road. There is
nothing too important on it, and I haven't bothered keeping
anti-virus software up to date on it. In two years of using it in
this way it has never contracted any malware. I loaned it to my
business partner one afternoon and within half and hour he had
installed a trojan.)

> 3. lead time : after close of withdrawals we
> have two weeks before polls start.  We provide an REV service for a
> week preceding the election day, and on the election day.  The
> dates are immovable.
> 4. central terminals : we have some budget to put up Internet
> terminals in county offices, libraries, possibly post offices etc.
> We require that these be "locked down" as kiosks or similar and
> that they are not un-monitored machines (so can't be entirely
> replaced)

In other words you have Diebold-style DRE machines in public places
without the polling-booth authentication. This is supposed to make me
feel good?

> 5. live info website : we have a "voting website" or websites and
> the ability to post messages that REV voters can read and that we
> can update this facility quickly and easily.  This website also
> forms the basis of the VVAT service which is made available after
> close of polls.

A fundamental feature of any audit trail is that it has different
failure modes to the thing being audited. An electronic audit of an
electronic vote has too many similar failure modes to be useful as an
audit. This is absolutely fundamental.

> 6. code audit : we have gov't-appointed auditors
> who have the skills to code-audit and sign a 1200 line java
> application which will be made for the REV service.  This code is
> purposefully minimal and simple enough to allow exhaustive
> analysis.  We also have another java application which is a utility
> for generating PINs, making PKI key pairs and decrypting votes, it
> has already been audited and signed.  If they want to audit it and
> sign it again, they can.

How are you going to ensure that people are running that application
when they vote? (Or is that 'vigilance' again?) As a vigilant
professional IT person how am I going to be sure I am running that
Are you going to publish the source code or algorithm along with the
public keys in use? Will you allow me to write my own application to
that algorithm and use it to vote? If not, how will you detect when I
do it without permission? (Don't suggest encryption or signing will
help here. The keys on the client are, by necessity, public keys and
I can discover them).

> 7. network : we have a distributed network of file sharing nodes
> which employ route-obfuscation techniques, such as the Freenet, and
> we have our own current software for exploiting the Freenet for
> vote carriage. We have our own system for querying deposited votes
> off the Freenet.  We have a percentage of voters willing to
> volunteer their machines as transient nodes we will help them set
> up, say 10% of voters.

So you are going to allow me, as a rabid ultra-right-wing nationalist
with paramilatary sympathies and professional IT experience, to
volunteer my machine as a temporary store for votes? Even if I cannot
do anything you can look forward to a media feeding frenzy and zero
public confidence in the system.
(No, I'm not really a provo sympathiser or ultra-right wing).

10% of voters will be required for this network? Even in little
Ireland that means over 200,000 volunteers are required for the
election. How much help are you planning on providing to this horde?
Do you really expect that many people to volunteer their time?
What about paying for network connectivity? In Ireland most home
 users are still on dialup connections. Leaving such connections on
 for a week is going to cost something.
Of course, that means only people with at least two telephone lines
can even be considered. I don't imagine anyone is going to give up
their telephone for a week out of patriotic duty.

> 8. authentication : we have at hand either a
> public key set for all voters, or the ability to have voting login
> credentials hand-delivered to all voters, or we have access to an
> established service used to authenticate e-gov or e-banking users
> such as the Tupas system Finland has.  We need a database of who is
> eligible to vote and an address to reach them, well in advance of
> the election.  Ideally we also have email to use for reminders etc.

Public key infrastructure even in small communities is difficult and
expensive. I've been involved in projects to deliver and maintain
public keys in closed communities, so I know a little about the
This feature of the system alone would seem to push up the price
beyond anything reasonable.
Surely that money would be much better spent on the sort of reforms
Ita suggested.

> 9. observers : we have a group of observers most of  whom are
> willing to cooperate with our procedures for observation.  They may
> include party reps, specialists, the ERO and a few members of the
> public.

What exactly do they observe?

> 10. web cache : we have access to a web cache such as
> Coral, Akamai or Google.

Maybe you'll get to this later, but why?
Are you suggesting outsourcing storage/transmission of votes or voter
data to foreign corporations?

> 11. evaluation : we have evaluators to find and interview voters
> and non-voters.  We have the ability to phone some of the
> constituency after the election and ask some basic questions.

What sort of information can you gain from that?
I can imagine gaining satisfaction and usability information to
improve the service in the future, but I cannot imagine being able to
use this as a way of detecting problems.

> In a broad sense, all of these things are needed.  I haven't
> defined details such as how the gov't might procure the auditors or
> how distributed authentication information needs counterfoils.  If
> voters have digital certificates I assume this to all be in place.
> I didn't describe education or "marketing" materials such as
> prepared presentations and I don't mention public consultation
> processes or materials, candidate websites, email-your-MP
> campaigns, legal compliance resources,  usability compliance
> testers, translators, disability advocates, front-line call centre
> and second-line call centre, project managers, etc etc, they are
> all needed too.
> I will elaborate on what they are for if the above seem reasonable.

Carig, I am sorry but I don't see in this anything about how to
detect, measure and recover from problems.
I see some more good suggestions for making problems less likely, but
not for knowing when they happen. I'm never going to accept 'less
likely' until I have some real numbers, and nothing you have
described so far shows how you are going to gain real numbers.

What I need to know from a trial is:
- How many people attempted to vote?
- How many votes were collected?
- How many votes were collected /correctly/?
- How do I know which votes were correct?
- Of the votes that were not correct, do I have /any/ correct record?
- Of the votes that were not correct, do I have any indication of the
likely swing introduced?
- How many votes were bought or coerced?
- How do I know the result presented was arrived from couting the

To be sure votes are recorded correctly I'll need to know they are
 not changed any time they move from one medium to another. For
 example: - From the screen on the voting terminal to the network
 card or storage.
- From the network card to the Freenet node or remote store.
- From storage to the count computer.
- From the bit of the count computer that stores the votes to the bit
of the count computer that counts the votes.
- From the bit of the count computer that counts the votes to the bit
of the count computer that displays the results.
... and anywhere else the vote might travel or be stored.

Remember that I do not believe what is on the computer screen is an
accurate reflection of what is in the computer storage unless you can
prove it.

So again for this trial, I need to know how you are going to detect,
measure and recover from problems. How you are going to make problems
less likely is interesting, but not ultimately useful until you can
put real numbers on 'less likely'.

Brian O'Byrne, Statesoft Ltd.
Tel: +353 1 4100 993, +353 86 240 4719

More information about the E-voting mailing list