Re: Reply to Rons' Q's on TLV

From: David Webber \(XML\) <"David>
Date: Wed May 18 2005 - 11:12:50 CDT

Ron,

OK - more answers here.

My view on the open source solution is that the
county or state government is responsible for
installing the open source from the trusted certified
and approved copy / site.

Since the goal here is to script *everything* with XML,
the configuration process should be:
1) install open source
2) install XML scripts that election officials have
    either created or certified, or both, that control
    presentation and voting choices, etc.
3) install any unique localization code - this would
    most definately *not* replace the OSI code. If
    changes are needed there - those must be done
    thru the OSI project. The actually coding here
    reason for it, etc, would have to be known
    and justified. Most localization should be
    possible thru 2) above.
4) Post- election - random inspect machines to
    ensure code not tampered with.

The XML scripts contain standard ballot layouts
and UI presentation details - that must conform to
EU regulations - so "cheats" on presentation should
be avoided - since the OSI will present the ballot
in the perscribed manner.

On the subject of guidelines and VVPAT - we
definately need more guidelines - but basically
I view voting as yet-another-government-form-filling
exercise. There are standards for government forms,
and ensuring that information is clearly and unambiguously
presented - there is also a wealth of work - by likes of
HP, Microsoft, Apple, Adobe, et al - on how to do this
correctly. It's *not* rocket science!!!

BTW - did I mention that we're using off-the-shelf
hardware here - not any custom bespoke vendor stuff.
Should run on any PC type platform the State or County
has picked to use. There maybe some barebones hardware
requirements - no CD drive, no wireless, etc, sealed case,
but otherwise - its a stock machine and printer.

The three sets of records are designed to prevent tallying
fraud. Even if the scanning software has been compromised
- the OSI routines that count the electronic voting records
would have to be similarly tainted - but there exists no way
for the two pieces of software to communicate! And the
XML being used is rigorously checked to ensure the content
conforms to EML 440 XML - no "extra" data allowed.

Again - if you design the paper cast summaries correctly
you should be able to use off-the-shelf scanner with XML
scripts to configure how the vote is read and the resulting
XML 440 created. Goal is to minimize opportunity for
tampering.

If mismatch is found - it could be legitimate - a spoiled
ballot for example - or a cancelled ballot. So you really
only want to count a vote where both paper and electronic
match. The idea is to keep this simple - so people can
re-vote easily with confidence - if something screws up.

The only exception would be hardware failure. Say
printed votes are cast fine from one machine by voters,
but then the digital records are later unreadable. That would
require an official ruling that would allow the paper votes
to be counted still. Obviously this would be expected
to be isolated occurence, and documented, etc.

Then coupled votes are matched to the ballotIDs that
were authorized by the electoral roll - so you cannot
just spew pairs of votes into the system.

We've hopefully thought this thru pretty good - and
using the standard XML formats for everything
really ties things down another notch - rather than
letting vendors create proprietary record formats,
etc.

DW

----- Original Message -----
From: "Ron Crane" <voting@lastland.net>
To: "David Webber (XML)" <david@drrw.info>; "Open Voting Consortium
discussion list" <ovc-discuss@listman.sonic.net>
Sent: Wednesday, May 18, 2005 10:33 AM
Subject: Re: [OVC-discuss] Reply to Rons' Q's on TLV

> On May 18, 2005, at 6:59 AM, David Webber ((XML)) wrote:
>
> > ...We're working at OASIS on putting together a component
> > toolset around each of the key EML XML's - 440, 410,
> > and so on. The idea is that implementers use the
> > open source components
>
> I'm glad to hear about open source, and want to hear more. How do you
> guarantee its integrity? That it actually ends up in the machines on
> election day?
>
> > and then simply add their own
> > localization logic and UI to that. So in the EU, that will
> > be in Danish, Latvian, German, Italian, etc - and reflect
> > local voting practice and traditions. Under the hood the
> > open source components enforce the TLV processing
> > and handling of the XML and associated counts,
> > crosschecks, etc.
>
> And what guarantees that the UI for the voting station doesn't contain
> code to perpetrate presentation frauds? Or the UI for the
> reconciliation station to perpetrate tabulation frauds by presenting
> the results -- that the OASIS code so carefully cross-checked --
> differently from their true values? For that matter, if the UIs run on
> the same hardware as the OASIS code, what prevents them from simply
> overwriting it with their own code?
>
> > Voter verification and our friend Shamos - see my
> > rebuttals to that piece of dubious "research":
> > http://drrw.net/backup/Understanding%20VVPAT%20v%20VVAATT.pdf
>
> Hmm, that document talks about audio verification vs. visual
> verification. Maybe you meant to point me to something else?
>
> > Basically - the printed ballot should be a self-evident
> > summary - that even a 5th grader can verify at a glance.
> >
> > Not some "trick" SAT-style 5 choices - and which box did
> > you check test - that runs into pages of tiny font text!?!
> > I find Shamos work distasteful and insulting to voters - he also
> > ignores basic work on human short-term memory and ability
> > to do verification.
> > Enough said - a well designed paper verification works.
>
> I've heard intimations that someone has have conducted a real study on
> short-term use of VVPAT. Do you know anything about this? In any case,
> we need more than a short-term study if we're going to entrust voter
> verification with any significant responsibility for security. We need
> to know whether it will "work" over the long term. Voting systems will
> be used for decades, long after the original reasons for their adoption
> have faded from memory. They must continue to work securely even in
> such an environment of reduced vigilance. [1]
>
> > Hardware inspections are something that could be done to bolster the
> > process - and you would definately want to quarantine machines
> > that the crosschecks showed issues with. However - notice that
> > hacks and loaders have to surmount 4 barriers - they have to
> > corrupt electoral roll tracking systems, and the voting system, and
> > the ballot printing, and the counting system, all of which are
> > separate on different devices, and open source.
>
> I don't think they do. They just need to corrupt the ballot casting
> station so that it, for example, omits disfavored candidates sometimes,
> or makes their identifiers smaller or dimmer than those of favored
> candidates, or their selection areas smaller or oddly-shaped, etc.
> While these "presentation frauds" might not deter determined voters,
> they're very likely to skew the choices of those -- and there are many
> -- who decide how to vote only in the voting booth.
>
> > Prudence is still required however. You will notice that the
> > OASIS EML is required to conform to the EU Council of Ministers
> > recommendations on election management - and so that whole
> > laundry list of physical checks and controls are inferred in TLV
> > (online links to that are in the OASIS EML specs).
>
> I'll check that out.
>
> > As to systematic fraud - I have a few things on this.
> >
> > 1) TLV should allow you to gauge the scope and the
> > frequency - so if each voting station has one or two
> > occurences - then you can see a pattern that would
> > be missed in a random audit. Since you are aiming
> > for 100% crosschecking - even a small # of
> > descrepancies would be cause to investigate further.
> >
> > 2) Deterrence - today hackers know they are most
> > unlikely to be caught. With TLV a full audit trail is
> > retained and 100% crosschecking is built-in so
> > hackers run a very high risk.
> >
> > 3) Goof-ups do happen - so having three sets of
> > counts helps diagnose this - and gives remediation
> > options. Example - hardware failures, people
> > inserting stuff in upside down - forgetting to
> > enter a operator code, or switching the machine
> > off by mistake, etc, etc. The idea is to provide
> > election officials with options to solve these in
> > a reasonable way.
>
> I like the 3 sets of records. But they don't prevent presentation
> frauds at the casting station, nor tallying or presentation frauds at
> the reconciliation station.
>
> -R
>
> [1] Also, please don't discount the problem of legalities: what would
> actually happen were a voter to discover a mismatch? Would she just get
> to re-vote? Or does OASIS propose model legislation that would require
> a full-scale investigation? What effect would that have on the election
> in which the mismatch was discovered?
>
> > Hope that answers your questions adequately.
> >
> > DW
> >
> >>
> >> Having briefly examined the TLV approach, I have some observations.
> >>
> >> First, it seems to treat open source as an afterthought, and does not
> >> discuss how to guarantee that the publicly-reviewed software makes it
> >> into the voting machines on election day [1]. This makes the system
> >> vulnerable to presentation frauds during vote casting, and frauds
> >> during the comparison process. I don't see anything about random
> >> manual
> >> spot checks on the comparison process in the official docs, either,
> >> though you seem to think they're acceptable (though not required).
> >>
> >> Second, it relies upon independent teams implementing various portions
> >> of the system, and, further, those teams staying truly independent for
> >> as long as the system is deployed. This doesn't account for the forces
> >> of consolidation (e.g., Diebold's acquisition of Global Election
> >> Systems), nor for the regrettable fact that vigilance wanes over time.
> >>
> >> Third, voter verification. While this is great for transparency, I
> >> don't think that, over the long term, it'll do much for security. Most
> >> voters will not understand that verification is a critical element of
> >> the entire system's security. Rather, after a brief burst of
> >> enthusiastic verifying, they'll come to view the system itself as
> >> "secure", and verification as optional. [2] Of course this problem
> >> affects OVC's system to a degree as well, but less than OASIS's,
> >> because OVC's security rests more firmly on properly-implemented open
> >> source principles.
> >>
> >> Fourth, I didn't see anything about hardware inspections, which makes
> >> OASIS vulnerable to malware loaders in the casting and comparison
> >> machines. (See the Shamos rebuttal OVC just published).
> >>
> >> -R
> >>
> >> [1] E.g., David Mertz's process described in our recent Shamos paper.
> >>
> >> [2] Further, without a useful legal process to handle actual
> >> mismatches
> >> during verification, its effect is limited to correcting the votes of
> >> those who happen to find such mismatches, rather than correcting the
> >> systemic fraud that may underlie those mismatches.
> >>
> >
> > _______________________________________________
> > OVC discuss mailing lists
> > Send requests to subscribe or unsubscribe to
> > arthur@openvotingconsortium.org
> >
>
>

_______________________________________________
OVC discuss mailing lists
Send requests to subscribe or unsubscribe to arthur@openvotingconsortium.org
==================================================================
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
==================================================================
Received on Tue May 31 23:17:41 2005

This archive was generated by hypermail 2.1.8 : Tue May 31 2005 - 23:17:52 CDT