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

bobyrne at statesoft.ie bobyrne at statesoft.ie
Sun Sep 11 15:50:49 IST 2005


Quoting Craig Burton <caburt at alphalink.com.au>:

> Brian,
>
> 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 the
accuracy of the vote I want to know how to detect it, measure it, and recover
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.
[snip]

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 existing
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 anyone
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 already
have postal voting.
Also I would not accept a scheme that allowed a single election with parallel
electronic and VVPB, since the voting software and the state of the network
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 untested
network.
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 channel.

>  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 could
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 providing
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 numbers
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 the
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 software,
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 
recovered.

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 computer
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.
>
> Craig.

Brian.




More information about the E-voting mailing list