Re: Reply to Rons' Q's on TLV (Ron Crane)

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

Ron,

The model here is the OASIS TC process itself, underpinning
the developer forum. We have three high profile ones running
right now - one is the ebXML registry, the next is the
ebXML messaging server (Hermes), and then the jCAM
content handler toolset. All three are using SourceForge
for code management.

In each case the developer community is following the spec'
then providing feedback and enhancements. The lead time
is usually about 3 to 6 months between be release of the spec'
and the implementation to support it.

OASIS has a fully open public comment and input mechanism
for user communities to guide the specifications and
implementations - managed thru the Kavi portal system
and archives.

The initial development would be Java based, but Python or
others would be considered - depending on demand.
Definately open platform.

As to issues loading - I'm assuming the hardware is
delivered to the State or the integrator clean - not to
the developer. Then the machine that
has been configured and certified with the software
components installed, is used as the master - a cut made
from that - and then that is mastered over on to each
machine (using product like Ghost) and the machine
sealed at that point. So the software is an
exact copy on each machine, etc. If you are using
a USB connection for all this and to the printer -
then in theory someone could plug into that
maliciously. My suggest would be to install a
port monitor to log all services and activity on that.

Since the developer is not involved in this process
at all - pretty tough to fake or tweak things. I think
that also is a big change from today - where the one
company is doing everything so easy for them to
cheat.

>
> How do you guarantee it will? Why couldn't the vendor subvert the UI
> code to do whatever *it* wants, instead of what's dictated by the XML
> scripts?
>

Because we're using a standard UI engine like XForms or Adobe PDF -
not some vendor supplied engine. Therefore - again the control is
through the scripts - and you will download and install the standard
forms package. And you can inspect the scripting code as needed.

>
> The question is not really how to present the VVPAT ballot, nor whether
> we should have one -- I think we should, since its transparency and
> relative immutability are important features. The question is whether
> the VVPAT adds any real security, either in the short or the long
> terms. If you know of any studies on this question, I'd love to hear
> about them.
>

The security I'm seeing is that of providing a physical source of
voting information that is not in a digital format - and provides
a correlation source of data. Notice also that casting ballot
paper has lots of other good side effects in voter privacy,
clear intent, and physical access (the computer cannot
walk a piece of paper across a room) to the ballot box.

This appears to me to be self-evident - I'm tired of reading
academic studies that just seem to be jobs-for-the-boys
to justify a thesis here and one there (errr, you're not an
academic are you!?!) Reducing this whole
arena to simple form filling and filing exercise - rather
than a research field for PhDs! Foot note on this - I
used to suggest research topics for UMD PhD students
for three years - so I feel qual'd to pontificate a bit on this!!

>
> What about compromising the software that reconciles the three sets of
> records? Why couldn't it just report what it wants, instead of
> reporting the facts?
>

Clear this has to be OSI - and if there's one area I'd
want to devote most time to testing and scrunity its here!

Again - simple, simple, and simple. All records fed
to it are in EML 440 XML format, along with EML 460
and then it generates EML 480s and 510s. Those 510's
are then read by another simple display XML stylesheet
and that's what you see!

The actual amount of code for this should be pretty lean.
Its just reading XML records, cross-referencing and
totalling. You sort by ballotID and synch off that.

>
> But what if it's fraud? What procedures do you
> recommend for handling it?
>

There's basically two types of fraud detectable, and
undetectable. In our case - if they managed to get
a ballotID into the electoral roll tracking that then
the voting system then puts into the electronic 440
records, and then someone walks a paper
equivalent into the ballot box - darn they are good!

That's three levels of collusion - and a physical
event - without someone saying - hey - didn't I
just see your twin brother?

You definately want some means to generate
ballotIDs that is not predictable before the election,
and can be checked by the counting software,
to guard against this.

Each "pillar of trust" needs to be protected with
its own gatekeepers - no surprises there.

Otherwise - if you have records and paper
ballots showing up that do not match your
guard criteria - then you definately want to
investigate their source and trace back from
there! The election officials are going to have
to decide to call the election or not depending
on the level detected and the type of attack
used - and other external factors - like the
candidates themselves - exit polls, etc.
I think those are fairly clear who the
authorities and their roles are already
spelled out. you'd definately want to lock
down machines in suspected precincts.

What we are providing is the means to
diagnose, audit and analysize. We can hardly
predict the attack itself.

Cheers, DW
_______________________________________________
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