RE: [election-services] Further musings on the need for VVPAT...

[<charbel.aoun@accenture.com>]

I think the difference is in the banking system we have an established
transperency that overtime created a solid perception about the accuracy
and integrity of the process. We can always cross check our transaction
against our bank statement and we can always see a trail etc.... On the
voting side, while you are right simon I think the issue remains that
what you talk about is visible to people in the domain or with certain
level of knowledge but not as cler to the public and I think this is
where david's point brings value if we try to transpose the banking
approach to voting and create the same public transperancy and
confidence.
Cheers

Charbel Aoun
Accenture eDemocracy Services
Director of Operations and Technology - International
105 Ladbroke Grove 
London, W11 1PG
United Kingdom
M +44 794 925 2143
T  +44 207 616 8414
Octel 43/ 40363
email: charbel.aoun@accenture.com
 


-----Original Message-----
From: David Webber (XML) [mailto:david@drrw.info] 
Sent: 24 February 2005 14:45
To: sibain@tendotzero.com
Cc: election-services@lists.oasis-open.org
Subject: Re: [election-services] Further musings on the need for
VVPAT...


Simon,

OK - neato method - certainly an option to give
people voting remotely.  Personally I'd still
feel edgy about typing in my email address...as
I have no guarantee what the client software is
really doing with it.

However - I really have no way too of knowing - just
because I got that email - that my vote was really
recorded that way electronically into the system.
That of course is the point of having the paper
record in my hand and submitting it as verification.

Cheers, DW


----- Original Message ----- 
From: "Simon Bain" <sibain@tendotzero.com>
To: "David Webber (XML)" <david@drrw.info>
Cc: <election-services@lists.oasis-open.org>
Sent: Thursday, February 24, 2005 9:35 AM
Subject: Re: [election-services] Further musings on the need for
VVPAT...


> David hi.
>
> On point 1 you are only partially correct. Yes some part of the 
> process must have details of where to send a confirmation. However not

> all of the process needs this. In fact it is far better if only one 
> part does.
>
> User logs in by a PC passing their login credentials.
> Server verifies them and sets up a session on a remote database which 
> is encrypted by a hash set at the time the process was started at 
> login. This has with it a SessionId which is internal to the process.
>
> This SessionId is passed with seperate undisclosed and unknown 
> (Created at this time) details to the voting server which registers 
> the vote and passes back the SessionId to the verification server. It 
> matches the 2 and responds with a "great thanks very much" or an "O I 
> have screwed up" email.
>
> The Voting server has no idea who the user is and does not need to 
> know. The SessionId dies before the confirmation email is sent as does

> the session on the database, which itself holds no identifying 
> details.
>
> Yes somebody could hack in at this point. But to decrypt thi slot 
> would take one hell of a rack of servers, a while and details of at 
> least 3 seperate IP addressess and login details.
>
> Cheers
> Simon
>
>
> <quote who="David Webber \(XML\)">
> > More from the Vote Here discussions today.
> >
> > Here's what I compiled to support the need for paper
> > in an all digital process involving DREs only!
> >
> > DW
> >
> > 1) You cannot have an anonymous trusted verifiable computer
> >     process. eBanking works because it is not anonymous.
> >     Every eProcess out there gets to know your email
> >     address or account ID to send a confirmation
> >     somewhere in the process.  If it does not send a
> >     confirmation - then you have no verification - the
> >     DRE is thus reduced to an entertaining arcade
> >     gaming machine - for which you have no
> >     guarantees to actually what reality is.
> >     That theoretical stumbling block is key to
> >     understanding the need for a verifiable paper record
> >     in anonymous voting systems.
> >
> > 2) Voters need trust (and US Gov HAVA demands it).
> >     Paper is the most trusted mechanism everywhere.
> >
> > 3) The banks have a trusted process that handles
> >     billions of paper cheques annually.  Their error rates
> >     are infintesimally small.  These technologies are
> >     simple, proven and secure.  We need to base a
> >     trusted voting process around such crosschecking
> >     and accounting methods.  There will always be
> >     enticing exotic proprietary and uncertified and
> >     potentially compromisable technologies offered
> >     up - but a trusted process needs to be simple
> >     and obvious.
> >
> > 4) We need to develop open public specifications
> >      so that there is an open marketplace for solution
> >      providers.  This is the lesson of railways, telephones,
> >      automobiles and electricity.  The software industry is
> >      no different.
> >
> >
> >
> > 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/members/l
eave_workgroup.php.
> >
>
>
> --
> Simon Bain
> TENdotZERO
> 0845 056 3377
> 44 1234 359090
> 44 (0) 7793 769 846
>
> 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/members/l
eave_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/members/l
eave_workgroup.php.



This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information.  If you have received it in error, please notify the sender immediately and delete the original.  Any other use of the email by you is prohibited.