Hi All
David and I have had another iteration of the draft paper and it’s
attached for your final comments please. We’ve tried to accommodate all views
expressed on the first version plus I’ve steered it away from us appearing to
be any sort of campaigning group for evoting – see my views in email below.
For the purposes of this submission we need to be agnostic on solutions,
however if we get selected and asked to attend the workshop we could then
develop our ideas in the open debate giving the audience the benefit of our
experience. But let’s get this paper finalised and submitted first.
If anyone has got any further examples for the Experiences
section please let me have details.
Responses by this Friday please – 23rd July.
From: John Borras
[mailto:johnaborras@yahoo.co.uk]
Sent: 15 July 2010 10:57
To: 'election-services@lists.oasis-open.org'
Subject: RE: [election-services] Draft position paper for EAC/NIST
UOCAVA workshop
OK caught up now and thanks to all for their input so
far.
My starting point is which of the workshop topics we should be
seeking to address. I’ve annotated the topics list below with views that
reflect my earlier comments, but are we agreed on that as the starting
point?
David – it’s not clear to me which of these, or all of them, you
are attempting to cover in your draft paper?
The sponsoring
organizations seek to understand:
·
Desired/required
functional properties of UOCAVA remote voting systems - Possible pointer to CoE Rec
·
Advantages
and disadvantages of different UOCAVA remote voting system architectures
- Possibly
·
Ways
to express and compare risks, including using metrics - No
·
Risks
associated with using the Cyber Infrastructures such as the Internet - Yes
·
Risks
associated with domestic and UOCAVA mail-in absentee voting - No
·
Risks
associated with remote electronic voting - Yes
·
Domestic
and UOCAVA mail-in absentee voting and remote electronic voting risk
comparisons - No
·
Experiences
with remote electronic absentee voting systems – Possibly, eg UK pilots, Dutch trials etc.
The workshop
organizers are soliciting position papers on these topics.
I think we can address most of these selected points using the
material in App B of our Spec document, see extract attached. This
expresses opinions that the TC has already signed up to but doesn’t get us
deeply into the more contentious aspects of this whole debate.
I would also suggest that we reference the Council of Europe
Recommendation which is very explicit on all aspects of remote/unattended
voting and provides “standards” to be followed on most of the above
topics. These are based on legal views supporting true democracy etc so
EAC/NIST should ignore them at their peril IMO.
See http://www.coe.int/t/dgap/democracy/Activities/GGIS/E-voting/Key_Documents/Rec(2004)11_Eng_Evoting_and_Expl_Memo_en.pdf
It’s good that we now have an extension until 30 July to submit
our paper as it will give us a bit more time to get our views co-ordinated and
a draft paper agreed. Can I suggest that you all give your views on
the question I’ve posed above, ie what is it we should be covering, then David
and I will have a telecon to work through all the opinions to date and come up
with a further draft paper for your consideration.
From: John Borras
[mailto:johnaborras@yahoo.co.uk]
Sent: 14 July 2010 09:27
To: 'David RR Webber (XML)'; 'Zelechoski,Peter'
Cc: 'eml '
Subject: RE: [election-services] Draft position paper for EAC/NIST
UOCAVA workshop
Hi guys
Juts a holding reply for now as I’m out most of today.
Will get back later with a detailed appraisal.
Bottom line for me has always been that the TC stays out of all
the political, academic and security issues around evoting. EML is there as
a technical tool to support whatever the customer decides he wants to do and we
believe we can support pretty much any solution, etc etc….. So when
we stand up representing the TC we avoid these awkward issues whenever possible
and put the ball back in the politicians court.
So with that in mind I’ll send you my detailed comments asap.
From: David RR Webber
(XML) [mailto:david@drrw.info]
Sent: 13 July 2010 21:02
To: Zelechoski,Peter
Cc: eml
Subject: RE: [election-services] Draft position paper for EAC/NIST
UOCAVA workshop
Thanks for your comments.
For the record - I've based this all closely on the current FVAP
requirements for internet ballot delivery - that my team and others are
currently implementing for roughly 20 states who are working that program.
Therefore I'm not just making this up - this models what States and FVAP
are currently doing for the 2010 election cycle for UOCAVA voters.
I've made specific notes in line below to your items.
-------- Original Message
--------
Subject: RE: [election-services] Draft position paper for EAC/NIST
UOCAVA workshop
From: "Zelechoski, Peter" <pzelechoski@essvote.com>
Date: Tue, July 13, 2010 1:56 pm
To: "David RR Webber (XML)" <david@drrw.info>, "eml "
<election-services@lists.oasis-open.org>
As a member of this TC I believe we need to be cognizant that this
is an OASIS TC, not an anti eVoting group (I am sorry if I step on toes saying
that but I participate in this TC to improve the ability of electors to have
confidence in elections using computers). If we are presenting this paper
as a TC work, we MUST address it from an EML stand point – NOT from a
standpoint of what we personally believe about computers in voting.
The point is here that we want to show how EML can support eVoting -
but also the challenges. We're not trying to solve this. It's a complex
problem - that involves not just software but process and laws too - and that
is why NIST is having the workshop - to understand what is available.
Similarly it would be wrong for us to say - eVoting is easy - here is how
you do it with EML. However - saying - if you do eVoting then here are
the safeguards you need today - is prudent - so if people do
this without those safeguards we are not at fault.
There is no prohibition in providing voters a receipt for their
vote. There are many reasons and places where a receipt showing how a
voter voted would not be given but a receipt showing the voter voted and the
vote was received for processing is often given (an “I voted today” sticker at
the polling place is very common).
There's a huge difference between a confirmation and a receipt.
Many states legally forbid receipts. For FVAP they have also ducked
even sending back an email saying "Confirm ballot received" or
similar. Now of course the point here is that in the banking world - you
do get a receipt - in your monthly statement and your returned checks. In
the voting world there is no equivalent - that say summarizes your ballot - 6
votes cast, 1 undervote, or similar - so you know that not only was your voted
counted - but that the vote reflected your actual cast selections.
Once I, as a voter put my paper ballot in the ballot box, I have
nothing that ties that back to me; nor do I ever get anything that allows me to
see that my exact vote was counted the exact way I think I marked it. So,
I refrain from drawing that parallel.
That's not what is happening for FVAP. States will
authenticate your returned ballot - so its only partly secret ballot.
Otherwise anyone can duplicate ballots and cast them. Once the ballot
is authenticated - then it will be added to the UOCAVA votes pile and hence
become anonymous at that point.
The point on votes sold/influenced is a good one and holds true
for all unobserved voting (voting that does not take place in an environment
where the voter is given privacy by way of a controlled facility/process.
The listed mitigation aspects seem correct, regardless of voting
method.
I believe transparency and auditability are our primary points
and are the strengths most obvious for EML.
I do not agree that a “paper ballot is required to ensure audit
trail and verification”; dual pathing and encrypting/signing offer techniques
that can yield an independent validation/audit. I don’t think it has not
been deployed in any election but we need to avoid mandating something based on
personal bias or lack of common usage.
While good tools dual pathing and encryption both fail the need to
be able audit independently of the computers. As we have seen repeatedly
in the US - having solely digital records has led to inability to verify actual
cast votes - and or loss of cast votes. Plus what FVAP is currently
contemplated for UOCAVA does not involve dual pathing. The Figure 2
with the A and B verification hints at dual pathways - without going into the
complexity details at this stage. Then there is the fact that NIST with
their VVSG SI have de facto required paper as the single foolproof means to
ensure that is met currently. So the conclusion is that paper is the preferred
dual path mechanism today - that is simple and clear for legislators to
comprehend and is also easiest for existing election boards to handle and is
the common usage today.
From: David RR Webber (XML) [mailto:david@drrw.info]
Sent: 2010-07-13 11:40 AM
To: eml
Subject: [election-services] Draft position paper for EAC/NIST UOCAVA
workshop
Importance: High
Attached word doc. This follows the approach we used for the
previous NIST workshop.
Notice they limit to 5 pages of content and PDF - so once everyone
is happy with content - we can generate PDF from this.
I've deliberately made this high level - since they are calling merely
for topic input at this time - more formal papers and presentations would be at
the actual event.
From my work with UOCAVA - and knowledge of the previous SERVE
project - the biggest challenge I see is that legislators have only a slim
grasp of the issues - have a hard time comparing e-voting and the internet with
say online banking - and so I've tried to break this down using pictures and
bullet points for now - to compare the similarities and differences.
I see our audience here is beyond the technical one at NIST itself
- and more to the decision makers at the state and federal levels who need
clear answers.
Obviously for the actual event we'd want to do something much more
formal.
The deadline is COB July 16th on this - Friday - so our group here
needs to make quick review and comments so we can hit that.
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates
this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php