Reply to Rons' Q's on TLV

From: David Webber \(XML\) <"David>
Date: Wed May 18 2005 - 08:59:39 CDT

Ron,

Great questions. I'm continually refining the slides - while
at the same time trying to avoid slide deck bloat -
always a challenge!

It's probably about time I add some slides on
implementation - since things are moving on that
front.

First let me say open source is the foundation here.

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 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.

The idea here is to solve the independent teams issue,
and also provide a reference implementation that is
certified and maintained accordingly. This should also
reduce costs to localization developers significantly -
as they can focus on making a friendly and clean UI - not
the guts of the XML processing backend. This should
empower local solution providers to get into the market
and further weaken big corporate grip on overpriced
election handling.

Voter verification and our friend Shamos - see my
rebuttals to that piece of dubious "research":
 http://drrw.net/backup/Understanding%20VVPAT%20v%20VVAATT.pdf

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.

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.

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).

Yes- TLV makes life more reassured - but you still need to
do all that other physical stuff - you cannot stop doing that
and drop your guard.

Similarly - I agree - TLV does not replace the local officials
ability on the ground to check into the running of the election -
just guides and informs it. Example - someone leaves a
smartcard in a device and forgets to send it in after balloting
closes. TLV will alert you to the missing record counts.
OK - someone has to go and retrieve it - then
someone has to quarantine it - and determine if anyone had
access to it - etc, etc. If the content of the smartcard matches
the XML records the paper scanning machine said it created
- probably no foul - document and move on, etc.

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.

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
==================================================================
= 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:40 2005

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