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

["Paul Spencer" <paul.spencer@boynings.co.uk>]

David,

You don't explain how transient connectivity could be exploited, especially
if restricted to a LAN within a single polling station. I therefore don't
understand the reason for "the rule that says no direct linkage across
layers in the process". EML provides messages that allow the link I
suggested to be auditable.

Similarly with UUIDs. It is no good the voting system introducing UUIDs if
they will be rejected at the count, while providing an audit trail to the
offending system. In my opinion, multiple vendors provide the best defence
against corruption within the system. This still allows for collusion, but I
have not understood exactly how your paper system works to totally avoid
this.

Regards

Paul

> -----Original Message-----
> From: David Webber (XML) [mailto:david@drrw.info]
> Sent: 19 February 2005 13:30
> To: Paul Spencer; eml
> Subject: Re: [election-services] Defining a trusted voting process
>
>
> 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.
> > >
> > >
> > >
> >
> >
> >
> >
>
>
>
> 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.