Voting systems with no OS (was: Re: disclosure; no OS? [Re: OVC-discuss Digest, Vol 36, Issue 10])

From: Fred McLain <mclain_at_zipcon_dot_net>
Date: Fri Nov 02 2007 - 21:26:24 CDT

Again, comments in line.

On Nov 2, 2007, at 5:26 PM, Danny Swarzman wrote:

> I can think of a few reasons to have an operating system:
> - Control a graphic user interface

Why do you need a "Graphic User Interface"? How about a picture you
touch, instead of all the hogwash that goes with GUI programming? This
stuff was done, and sometimes done well, in '70s video game machines
which did not need an "OS". We tried the simple graphic+coordinates
approach with the OVC demo and it worked great. Here is how to do it:

1. Create an image of the ballot & display it. BTW, this has the
advantage of exactly matching what the elections officials approved.
2. Create a map of the "touch points" for your "buttons"
3. Apply business logic to the touched points
4. Record the results.

So other then the touch and blit image interfaces, it's all simple,
non library code.

> - Ability to load programs. If you depend on an external system to
> load the programs, then that external system would require the same
> level of scrutiny.

Nope, that is nonsense. You do not want to have an ability to "load
programs" in a critical system, especially from an "external system".
Nor do you want to have any connection to an external system. Voting
systems need to be isolated from the network. I've said before, "you
can't open a door that doesn't exist".

> - Ability to make programs readable because they are written in a
> standard language.

I'll go with that. As long as it's a "sweet" language.

> The OVS solution rests on Java, C and Linux. Only the scanner driver
> is in C. Our programs produce XML files. We make a fanatical effort
> to keep the code simple and easy to read. We want the largest number
> people possible to be able to read the code.

I find this very confusing. Last time I talked with you I was under
the impression that OVS was in the early requirements stage. What is
the "OVS solution" code you are referring to, and if it is open
source, where can I download it for review?

By the way, I don't know that either of these languages require an
underlying OS. I've written a great deal of C and Java, including
embedded systems in both languages. They do not require an "OS"
underneath. Unfortunately there doesn't seem to be a set of Java
libraries that are DO-178 level A certified, but the C libraries
(requiring no OS) do exist. Fortunately what we are doing isn't all
that complex. Heck, you can do it on a few piece of paper.

> One part that is less simple is the display of the final results.
> For that, we will use Mozilla code to produce a report. That will
> read an XML (actually EML) file with XSLT or CSS to produce a good
> display. Of course we publish the XML file so it will be easy for
> anyone verify that the formatted report displays the same information.

How about a text CSV formatted tabulation? A reporting system
somewhere else could make the results pretty, it isn't really the
responsibility of the voting system to produce CNN graphics.

> If anyone can suggest a way to improve on configuration, please do so.

Suggestion: If you can simplify your external dependencies to the
point where you can get the drivers running, without a ton of useless
code, you will be in a much easier position to be certified. The
original driver authors are a great resource. It's at first
surprising how many OSS developers are very concerned about voting. I
would not be surprised to find that the folks who did the printer,
mouse (touch screen) and display drivers volunteering their time for
an embedded version that does not require Linux or any other OS. We
are only talking about a few drivers to supplement the main line code.

Another suggestion; make it secure before you make it pretty.


> -Danny
> On Nov 2, 2007, at 11:03 AM, Fred McLain wrote:
>>> If the election software were decently modularized, you'd end up
>>> with
>>> modules that are OS in everything but name. True, it would be an
>>> open-source OS, but so is Linux, so why not take advantage of all
>>> that development that's already done, has many years of field
>>> testing
>>> behind it, and costs nothing?
>> I'm also in favor of this approach. The risk is that you are
>> introducing a vast amount of code that never will be used. Some
>> would
>> say source inspection is impossible because of the millions of lines
>> of OS code. When you write the code from scratch all you really
>> reproduce from the OS are a few drivers and some basic libraries.
> _______________________________________________
> OVC-discuss mailing list
> By sending email to the OVC-discuss list, you thereby agree to
> release the content of your posts to the Public Domain--with the
> exception of copyrighted material quoted according to fair use,
> including publicly archiving at

Instant Messaging (IM) Addresses:
Yahoo: appworx_fred, schemalogic_fred
AIM: mclain98021
ICQ: 6947005
GTalk (Jabber):
Skype: fmclain

OVC-discuss mailing list
By sending email to the OVC-discuss list, you thereby agree to release the content of your posts to the Public Domain--with the exception of copyrighted material quoted according to fair use, including publicly archiving at
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
Received on Fri Nov 30 23:17:06 2007

This archive was generated by hypermail 2.1.8 : Fri Nov 30 2007 - 23:17:31 CST