EAC and VVSG - XML considerations

From: David Webber \(XML\) <"David>
Date: Tue Jul 12 2005 - 21:09:06 CDT


I think our postings crossed in the mail.

The <vote_process_terms> I posted I
believe address the concerns you noted
about the EAC VVSG and XML.

This could be expanded on by citing
specifics as you have done. However the intent
is to provide something succinct and clear that
legislators can use to frame requirements.

See my comments below.

Thanks, DW
A small nit.

Putting something in XML does not make it open or even human readable.

>>> correct - however - it can make it conform to an explicit
       standard - that is machine verifable by independently written
       certification code - that is our intent by using EML formats.

If you dont realease the Document descriptors a third party may not
be able to work with it. And under some cases the DMCA might even be
construed as forbidding reverse engineering of an unpublished DDT.
>>> Again - insisting on publically published specifications - this
      get covered - they cannot use this cheat.

Second, for good, laudable reasons, and at the request of the state
elections officials, Acupoll had to encrypt its XML. thus the XML is
not readable until it is decoded in the central tabulator.
>>> That's OK - OASIS EML provides for encryption of the XML,
       but using W3C approved digital signature techniques, that
       again are verifiable.

Third, a mischevious company could in principle rotate it's XML ddt
through a pre-programmed but secret set so as to render the utility
of having a published DDT for any given election worthless to any
third party trying to write a general purpose reader.
>>> No - obfuscation of the XML will cause it to fail certification.

So the point is specifying XML itself is not sufficient.
>>> Correct - you need the full weight of specifications and formats
       such as OASIS EMl is providing.

The specification needs to be that a third party would be
unencumbered in writing a data reader. One can quibble if this DDT
needs to be perfectly ope (as I think it should) or available for a
very minor license fee (one might argue that accupoll's encryptiion
scheme is clever enough to be worth charging for)
>>> Again - we're not supporting propriety schemes here - only
       open public ones that can be verified and are royality free
       and unencumbered by IPR.

Also since other than OVC, at present open source is not forthcoming
and wont be from any company using Windows one should at least
recognize that there are degrees of closed source.

>>> OASIS EML is developing open source code for handling of
       XML records and voting artifacts that conforms to the
       EML specifications - http://emlvoting.org

from the most pernicious to the least I would rank these as follows.

1) pure closed source
2) escrowed source. Generally this is impossible to view since
companies will fight the escrow release triggers

3) viewable by NDA. the problem is NDAs keep the best eyes out and
prevent publication of bugs

4) NDA but NDA allows publication of sufficient code to explain any
bugs found.

5) NDA is specific to voting systems only. Would not prevent a
programmer from writing simmilar code for say a postage stamp vending

6) Copyrighted but open source

7) Copyleft open source (GNU like)

7) free open source (BSD like)

>>> With OASIS EML we are saying that 7) is preferred
       for voting systems! Vendors could choose any of these
       though - provided their product passes the certification
       tests. However - I suspect that in reality marketing
       pressures will mean that States buy products that are
       7) enabled as a preference.
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 Sun Jul 31 23:17:16 2005

This archive was generated by hypermail 2.1.8 : Thu Sep 15 2005 - 11:43:09 CDT