Re: [election-services] Defining a trusted voting process

["David Webber \(XML\)" <david@drrw.info>]

Paul,

I have to say that my process model deliberately excludes that
option.  It clearly violates the rule that says no direct linkage
across layers in the process.

I can see now why you think that my diagram says that is
happening!  I need to fix that!!  There cannot be any
transient connections here between layers - everything
has to rely on physical transfers that can be inspected
and those exchanges logged and auditable.

Unfortunately while from the engineering view point - it makes
sense - there are just too many people out there that would
exploit transient connectivity.  As a side bar - I realize now
that I need to explain what approved transfers may occur
and how.  The preferred method is obviously write-once
and read-only devices; but for the internet - reliable
messaging may be an option here.

In fact - you should realize that while many solution providers
have the highest moral and ethical standards, others are
marching to a different drum and clearly wish to have
customers who want to have the appearance of an open
election, when in fact the outcome is being manipulated.

That is their closed-door marketing edge and it clearly
works.  We cannot be naive here.  The work on this
trusted process model is not for the faint hearted.

Candidates here in the USA spend billions of $$ on
their campaigns collectively, and bring every kind of
resource to bear, legal and quasi-legal methods, and
so any process to be trusted has to be able to
withstand continual and sustained assaults.  If there
is the smallest crack then that will be exploited.

Separation of processes is a huge defense. Along
with opening up the process so that many solution
providers can implement each step of the process.
Having one solution provider deliver every part of
the solution has proven to be unacceptable.

That is why the UUID method - while from the
engineering stance seems simple - its just another
artifact that cannot be directly verified by a
human inspector and therefore subject to abuse.
E.g. a rogue process can introduce ballots with
UUIDs on them and you have no idea if they
are actual ballots cast or ones the machine is
just adding in itself.

This is the single largest reason for verifiable paper
ballots that are physically cast by citizens. While
its not perfect - it is physically verifiable.  This is
obviously the polling station model.
What is new is combining paper and eVotes -
so you have two separate tallies and the
electoral roll and polling totals.
These three totals should crosscheck.
This is the goal of the trusted process
and why the need for separation.

When voting via the internet or mobile phone -
then the traditional mail system becomes the
verification service (as it is in many other domains).
So your eVote will not actually count until a
matching paper confirmation is received in the mail.
If you have a printing device locally - this can be
printed there and you then immediately post it.
If you have no printer - then a remote trusted
printing facility has to mail it to you first.  That
obviously potentially effects anonymous voting to
a degree - depending on how well that process
can be automated too and secured.

Another issue with mobile phone voting is selling
votes.  The mailed paper confirmation ballot partly
mitigates that - since obviously the buyer has to
be assured the confirmation will be mailed.

We need to investigate other methods too - but
retaining anonymous voting and verifying who
is voting remotely are it seems mutually exclusive!
Traditional mailed absentee ballots have all the
same constraints and strengths and weaknesses.
Anyway, selling of votes always will happen
to a degree - what you can ensure is that it is
minimized.  The best way is if the buyer cannot be
certain that the vote was cast the way they paid
for and that access to sellers is difficult!

Overall paper confirmations are required in a close
election where a candidate asks for a formal count,
rather than just the machine tallying of eVotes.
Candidates will also need to know totals by type
of vote.  So say your opponent has 5,000 more
votes than you - but 20,000 votes were cast by
mobile phone.  You may ask for those paper
verifications to be checked.  That will require
a delay while the mailed votes are received then
scanned and crosschecked.  And so forth.

Thanks, DW

----- Original Message ----- 
From: "Paul Spencer" <paul.spencer@boynings.co.uk>
To: "David Webber (XML)" <david@drrw.info>; "eml"
<election-services@lists.oasis-open.org>
Sent: Saturday, February 19, 2005 5:22 AM
Subject: RE: [election-services] Defining a trusted voting process


> David,
>
> My mechanism relies on a "live" link between the voting machine and the
> tallying machine, rather than them being combined as you have it. This
does
> not mean that the tallying machine cannot be in the same polling station
as
> the voting machine.
>
> I also don't see why the UUIDs prevent anonymity. No record needs to be
kept
> of who was issued each UUID - only who has been issued with one and what
> UUIDs have been issued. Some system in the process needs to know which
UUIDs
> are valid.
>
> What is the benefit of the computer-generated ballot? Is it just that it
is
> easier and more reliable to count? And how does this work when voting by
> mobile phone etc.?
>
> Regards
>
> Paul
>
> > -----Original Message-----
> > From: David Webber (XML) [mailto:david@drrw.info]
> > Sent: 18 February 2005 14:22
> > To: Paul Spencer; election-services@lists.oasis-open.org
> > Subject: Re: [election-services] Defining a trusted voting process
> >
> >
> > Paul,
> >
> > I'm not known for being a Luddite ; -)  but I really
> > appreciate the alternate view of "all digital is good".
> >
> > The big issue that I cannot find a way around with digital
> > media is verification.  Example - the Diebold machines here
> > use PCMCIA cards for vote tallying.  If I'm an election
> > official and I'm holding one of these things in my hand
> > I'm not able to verify anything.  If I stick the thing in a
> > reader and the software tells me some details, I have
> > no way of knowing if that software is misleading
> > me, either intentionally or by mistake.
> >
> > So - yes - I'm seeing that UUIDs or equivalent can
> > mark ballots - snag is the human cannot verify these
> > and "ballot-stuffing" is trivially easy -  there's some
> > blank sequence in the code run that was never
> > allocated to any citizen, but all these votes are cast
> > using those codes.  They appear legitimate, even to
> > separate counting software.  To stop that you have to
> > put UUIDs on electoral rolls - and then its not
> > anonymous anymore.
> >
> > To head this all off at the pass - VVPB - voter-verified
> > paper ballot appears to be the tried and tested method
> > here.  Actual citizens holding a paper ballot in their
> > hand, inspecting it, and then placing it in the ballot box
> > or mailing it in secure post, after the evote machine has
> > generated that ballot for them.
> >
> > So - the role of the digital e-Votes combined with
> > the paper ballots brings four things :
> >
> > 1) Speed - politicians love fast election results - so
> >     not having to wait for scanning and the mail works.
> > 2) Accuracy - scanning is not perfect and being able
> >     to crosscheck is good - plus printing the ballots
> >     beats trying to punch holes in cards when it comes
> >     to enhancing scanning accuracy.
> > 3) Preventing traditional paper-based fraud like
> >     paper ballot stuffing - since the two have to be
> >     done in tandem and that's really much harder
> >     to do - especially as we are forcing the printing
> >     and eVoting to be two separate systems!
> > 4) Open access for voters.  Easier to vote, more
> >      choices in locations to vote and can do
> >      language localization automatically.
> >
> > So the Luddite view here is re-introducing paper back
> > into the digital process to ensure the process is
> > verifiable again.  I believe this is optimal - and
> > because of the need for anonymous actions - unique.
> >
> > We are able to replace paper everywhere else in
> > business - because e-records are associated with
> > a person or a company - but I think this is a special
> > case where you need the paper retained.
> >
> > DW
> >
> > ----- Original Message -----
> > From: "Paul Spencer" <paul.spencer@boynings.co.uk>
> > To: "David Webber (XML)" <david@drrw.info>;
> > <election-services@lists.oasis-open.org>
> > Sent: Friday, February 18, 2005 7:36 AM
> > Subject: RE: [election-services] Defining a trusted voting process
> >
> >
> > > Why can a fully digital system not remain truly anonymous? What if a
> > system
> > > produced UUIDs and issued these to voters? A record could be kept of
the
> > > UUID (so proving the right to vote) without any record of the
> > voter's ID.
> > >
> > > And why should they not be directly verified by citizens? What
> > if the vote
> > > were passed to a vote tallying system (from a different
> > manufacturer from
> > > that of the voting system) and the feedback on how the vote was cast
is
> > > provided by this system? If the counting process compares the vote
from
> > the
> > > tallying system with that from the voting system, falsification can
only
> > > occur by collusion. If you don't trust the counting system, use
> > two (from
> > > different manufacturers).
> > >
> > > I think paper is a red herring to placate a few Luddites. Far more
> > important
> > > is the issue of intimidation, which applies to many systems including
> > postal
> > > votes.
> > >
> > > EML messaging already supports all of this. What you are
> > looking at is an
> > > architecture. The question is whether it is right to standardise that
> > > internationally, when there are so many different voting methods in
use.
> > >
> > > Paul Spencer
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: David Webber (XML) [mailto:david@drrw.info]
> > > > Sent: 18 February 2005 03:41
> > > > To: election-services@lists.oasis-open.org
> > > > Subject: Re: [election-services] Defining a trusted voting process
> > > >
> > > >
> > > > Folks,
> > > >
> > > > Received feedback from the Maryland side - so I've
> > > > enhanced the slides a little to do some "scene-setting".
> > > >
> > > > I was kinda assuming the audience was e-vote saavy
> > > > here!
> > > >
> > > > The revised PPT slides are here:
> > > >
> > > >  http://drrw.net/backup/Ballot%20Processing%20Systems.ppt
> > > >
> > > > and the PDF is here:
> > > >
> > > >  http://drrw.net/backup/Ballot-Processing-Systems.pdf
> > > >
> > > > Thanks, DW
> > > >
> > > >
> > > > ----- Original Message -----
> > > > From: "David Webber (XML)" <david@drrw.info>
> > > > To: <election-services@lists.oasis-open.org>
> > > > Sent: Thursday, February 17, 2005 5:10 PM
> > > > Subject: [election-services] Defining a trusted voting process
> > > >
> > > >
> > > > > Team,
> > > > >
> > > > > I few weeks back I joined the Maryland True Voting technical
> > > > team here in
> > > > > the USA.
> > > > >
> > > > > Attached PPT is the results of that interaction.
> > > > >
> > > > > It's just a draft right now - but what my aim is here is to
> > understand
> > > > what
> > > > > can
> > > > > make a trusted voting process - where you combine paper and
e-Voting
> > > > > together to make use of the best of both worlds.
> > > > >
> > > > > I'm not sure what research has been thrown at this in the past
> > > > - if any -
> > > > > but
> > > > > I just came at this from sound engineering principles in
> > > > building systems.
> > > > >
> > > > > So - I want it to be:
> > > > >
> > > > > 1) simple and obvious
> > > > > 2) doable with off-the-shelf stuff - no fancy patented techniques
> > needed
> > > > > 3) fault tolerant - in that it thwarts all obvious attacks by the
> > nature
> > > > of
> > > > > its
> > > > >     process.
> > > > >
> > > > > Obviously nothing is foolproof - because conspirators could
> > > > > pose as legimate staff and negate the safeguards - but that's a
> > > > > social problem not a software engineering problem!
> > > > >
> > > > > Clearly the level of detail in the PPT is just intended as an
> > overview.
> > > > > If you are going to spec' this out completely - you need to define
> > > > > each mechanism rigorously - and also create lots of XML - but
> > > > > then we are good at that here in OASIS!
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > Thanks, DW
> > > > >
> > > > >
> > > >
> > > >
> > > > ------------------------------------------------------------------
> > > > ----------
> > > > ----
> > > >
> > > >
> > > > > To unsubscribe from this mailing list (and be removed from
> > the roster
> > of
> > > > the OASIS TC), go to
> > > > http://www.oasis-open.org/apps/org/workgroup/election-services/mem
> > > bers/leave_workgroup.php.
> > >
> > >
> > >
> > > To unsubscribe from this mailing list (and be removed from the roster
of
> > the
> > > OASIS TC), go to
> > >
> > http://www.oasis-open.org/apps/org/workgroup/election-services/mem
> bers/leave
> > _workgroup.php.
> >
> >
> >
>
>
>
>