Re: Reply to Rons' Q's on TLV

From: Ron Crane <voting_at_lastland_dot_net>
Date: Wed May 18 2005 - 09:33:26 CDT

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":

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.


[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

OVC discuss mailing lists
Send requests to subscribe or unsubscribe to
= 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