[E-voting] UK shelves plans for e-voting trials
caburt at alphalink.com.au
Tue Sep 13 08:11:41 IST 2005
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.
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.
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)
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.
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.
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.
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.
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.
10. web cache : we have access to a web cache such as Coral, Akamai or
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.
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.
bobyrne at statesoft.ie wrote:
> Quoting Craig Burton <caburt at alphalink.com.au>:
>> Thank you for this metered argument. This post is getting pretty
>> long but I think illustrations help.
> This is getting very long, but remains interesting and relevant.
> I'm going to keep my points very simple: Everywhere there is a risk to
> accuracy of the vote I want to know how to detect it, measure it, and
> from it.
>>> So your assertions that remote voting must be provided and that
>> improving turnout is irrelevant simply don't stack up against the
>> goal of an election.
>> Perhaps I don't convey the urgency of my opening idea well enough.
>> The gov't has to make voting available to all eligible voters.
> I think, as you pointed out yourself, that the government's obligation to
> provide citizens with an opportunity to vote is adequitely met by the
> options. I'm certainly not aware of any case where a citizen has
> claimed to be
> disenfranchised because no electronic vote is available, and I think
> would have a hard time making that case.
>>> Whether it is worth increasing turnout through making it easier to
>>> vote even at the cost of reducing the accuracy of the vote is the
>>> question I'd like to put to a statistician.
>> I think the likelihood of fraud/error having occurred is measured per
>> election and the result deemed legitimate if we find the likelihood
>> of fraud is lower than some threshold. A way to measure REV systems
>> is parallel testing and voter-verification systems.
> Given the problems with parallel testing in Belgium (where
> discrepancies were
> found but the electronic vote was accepted anyway) I'd be sceptical of
> any such
> scheme unless it included VVPB. The most obvious way of doing VVPB
> remotely is
> through postal voting, so why have the electronic version at all? We
> have postal voting.
> Also I would not accept a scheme that allowed a single election with
> electronic and VVPB, since the voting software and the state of the
> will change between elections. Thus every election is in effect using
> a new
> piece of voting software on an untested network, so every election
> should be
> subject to the tests appropriate for a new piece of software on an
> Again: if we need to test the thing by having VVPB, then why not use
> the VVPB
> that is already in place?
> Or; if you are going to run every election where a proportion of the
> REV vote is
> replicated as VVPB through the post then you really are just setting
> yourself up
> for trouble. In that case you can detect problems and measure them
> with some
> degree of statistical accuracy, but you cannot recover from the
> problem without
> repeating the vote. You have used the VVPB to detect that the REV
> channel broke,
> but you do not have a copy of the REV votes outside the broken REV
>> We then look at whether parallel votes arrive as expected and
>> whether all voters using the verification service results in no
>> reports of trouble. How many parallel tests to run can be defined in
>> advance and scale with the election. How many people use the
>> verification service will vary with the election so the sum of the
>> two measures cannot be known in advance as a fixed level of
>> confidence for that REV channel.
>>> [snip] It is possible for a computer program to display one thing to
>>> the voter while recording another thing in their name. [snip]
>> Of course this attack is possible and catastrophic for the voter
>> affected, if the attack is not detected. An REV user's computer
>> collects perhaps 4 votes in a family of 4 adult voters.
> ... but that computer will be using software sourced centrally, so it
> would be
> possible to perform this attack on many (up to every) REV user's
> computer by
> compromising the central source or by compromising the network.
> Again: how do you detect, measure and recover from this?
>> A poll site DRE collects hundreds of votes. The DRE is a much more
>> attractive target for a hack. [... snip ...] Here is how it would
>> have to work in order to succeed with any likelihood at all:
> Even if I accept that it is very unlikely, how do I detect, measure
> and recover
> from a problem?
>> The real risk to REV is denial of service or a virus that disables
>> the voter's machine.
> Agreed, DoS is a big concern with any distributed voting system. That
> would be
> easy enough to detect and measure, but the only available recovery is
> to re-run
> the vote once the DoS has ended.
>> I can't see how this kind of carpet-bomb attack could in any
>> reliable way cause an election to swing.
> But if your goal is facilitating the right to vote then whether a DoS
> reliably swing an election is irrelevant. A DoS could certainly
> deprive some
> people of their opportunity to vote.
>> >It is possible for the count program to appear to read the votes,
>> count them and produce a result when in fact it is producing a result
>> from some other means.
>> Unlike the home PC, the count system can be strongly audited and
>> controlled. The counting software can be kept very simple, short
>> etc, be published, audited, signed etc.
> You have given some more good suggestions for reducing the risk and
> some traceability at the count center, but you are still putting faith
> in a
> black box. No matter how you cut it the count computer is a single
> point of
> failure that cannot be effectively examined by the public. A manual
> vote in a
> count center, for all its faults, is observed and understood by large
> of people. For a large-scale fraud to be perpetrated in the count
> center you
> would need a large conspiracy.
> For a similar large-scale fraud to be perpetrated on a count computer
> you need
> on technically savvy person to replace just one piece of the
> programming on the
> computer. The piece that shows the result. All of the other
> precautions you
> mention can be left in place but they are useless if that one piece of
> puzzle is compromised.
>> I think it might be measured by some random sampling of home PCs, the
>> use of PC's to trap "vote viruses" and other checks and balances on
>> the process. Like any election we can only know at the end of the
>> process what the likelihood was of fraud. No one can know in advance
>> : ultimately is boils down to vigilance.
> I can accept the vigilance argument over boxes and pieces of paper,
> but how can
> I accept the vigilance argument over bits on the wire? You said
> yourself that
> the vote from the back of my computer would be encrypted and
> unreadable without
> a private key I do not have, so I cannot test that. You accept that
> rootkits are
> possible and could affect my vote before it hits the wire, but by
> design I
> cannot detect a rootkit. I cannot look at the source for the voting
> even if I could I could not attach a debugger to the running process
> on my
> machine to ensure the process is actually running the supplied source,
> and even
> if I could I could not be sure the rootkit was not affecting my debugger.
> ... and those are things that a professional programmer might attempt,
> how would
> anyone not trained in IT even begin to be vigilant?
> Again this is down to the first question: how do I detect the problem?
> 'Vigilance' is not an answer.
>> REV pilots are needed to quantify the risks. They can't be shadow
>> polls or mock elections as the conditions and constraints are not the
>> same. This is the way forward, we shouldn't just sit and wait for
>> some new super alien voting science to appear and then roll it out
>> for the masses.
> Plan a pilot that shows how the risks will be detected, measured and
> Include in the plan that the electorate is not qualified to be
> vigilant over a
> computer network. Describe how to detect problems at each voter's
> without relying on skills or knowledge not possesed by the average
> voter. Once
> the problem is detected describe how to recover any lost or
> incorrectly-recorded votes.
> Include in the plan that a DoS might not swing the election but
> certainly can
> disenfranchise voters. Describe how to recover from this problem.
> Include in the plan that the count computer might be displaying a
> result other
> than the result arrived from counting the votes. Describe how to
> detect this
> problem without breaking secrecy by allowing independent counting.
> Include in the plan how you are going to use random-sampling VVPB to
> do any more
> than detect a problem. Once the problem is detected describe how you will
> recover from it.
>> I'm confident new voting channels can be used to enfranchise voters
>> without disproportionately (or better, significantly) affecting the
>> election outcome.
> E-voting mailing list
> E-voting at lists.stdlib.net
More information about the E-voting