[rohrpost] vote-auction war nichts dagegen

[sebastian at rolux.org]

LINKS

Black Box Voting
http://www.blackboxvoting.com
http://www.blackboxvoting.org

Complete Diebold Memos
http://mirror1.coolmacguy.com/lists.gtar
http://mirror2.coolmacguy.com/lists.gtar

News Stories
http://slashdot.org/search.pl?query=diebold
http://search.wired.com/wnews/default.asp?query=diebold



BACKGROUND

Bev Harris

Internal Memos: Diebold Doing End-Runs Around Certification

Our voting system, which is part of the public commons has recently been
privatized. When this happened, the counting of the votes, which must be a
public process, subjected to the scrutiny of many eyes of plain old citizens,
became a secret.

The computerized systems that register voters, will soon sign voters into the
polling place using a digital smart card, record the vote we cast, and tally it
are now so secret they are not allowed to be examined by any citizens group, or
even by academics like the computer scientists at major universities.

The corporate justification for this secrecy is that these systems adhere to a
list of "standards" put out by the Federal Election Commission, and that an
"ITA" (Independent Testing Authority) carefully examines the voting system,
which is then provided to states for their own certification.

As it turns out, the states typically do not examine the computer code at all,
relying instead on a "Logic and Accuracy" test which will not catch fraud and
has frequently missed software programming errors that cause the machines to
miscount.

A Diebold message board has been used since 1999 to help technicians in the
field interact with programmers to solve problems. The contents of this message
board were quietly sent to reporters and activists around the world, most likely
by a Diebold employee. In a letter to WiredNews, Diebold has acknowledged that
these memos are from its own staff message boards.

Bev Harris is author of Black Box Voting: Ballot Tampering In The 21st Century



SELECTED MEMOS

 From Nel Finberg, Technical Writer, Diebold Election Systems

(Note: Metamor/Ciber is the ITA assigned to certify the software)

alteration of Audit Log in Access

To: "support"
Subject: alteration of Audit Log in Access
From: "Nel Finberg"
Date: Tue, 16 Oct 2001 23:31:30 -0700
Importance: Normal

Jennifer Price at Metamor (about to be Ciber) has indicated that she can access
the GEMS Access database and alter the Audit log without entering a password.
What is the position of our development staff on this issue? Can we justify
this? Or should this be anathema?
Nel



Reply from Ken Clark, principal engineer for Diebold Election Systems

RE: alteration of Audit Log in Access

To:
Subject: RE: alteration of Audit Log in Access
From: "Ken Clark"
Date: Thu, 18 Oct 2001 09:55:02 -0700
Importance: Normal
In-reply-to:

Its a tough question, and it has a lot to do with perception. Of course everyone
knows perception is reality.

Right now you can open GEMS' .mdb file with MS-Access, and alter its contents.
That includes the audit log. This isn't anything new. In VTS, you can open the
database with progress and do the same. The same would go for anyone else's
system using whatever database they are using. Hard drives are read-write
entities. You can change their contents.

Now, where the perception comes in is that its right now very *easy* to change
the contents. Double click the .mdb file. Even technical wizards at Metamor (or
Ciber, or whatever) can figure that one out.

It is possible to put a secret password on the .mdb file to prevent Metamor from
opening it with Access. I've threatened to put a password on the .mdb before
when dealers/customers/support have done stupid things with the GEMS database
structure using Access. Being able to end-run the database has admittedly got
people out of a bind though. Jane (I think it was Jane) did some fancy footwork
on the .mdb file in Gaston recently. I know our dealers do it. King County is
famous for it. That's why we've never put a password on the file before.

Note however that even if we put a password on the file, it doesn't really prove
much. Someone has to know the password, else how would GEMS open it. So this
technically brings us back to square one: the audit log is modifiable by that
person at least (read, me). Back to perception though, if you don't bring this
up you might skate through Metamor.

There might be some clever crypto techniques to make it even harder to change
the log (for me, they guy with the password that is). We're talking big changes
here though, and at the moment largely theoretical ones. I'd doubt that any of
our competitors are that clever.

By the way, all of this is why Texas gets its sh*t in a knot over the log
printer. Log printers are not read-write, so you don't have the problem. Of
course if I were Texas I would be more worried about modifications to our
electronic ballots than to our electron logs, but that is another story I guess.

Bottom line on Metamor is to find out what it is going to take to make them
happy. You can try the old standard of the NT password gains access to the
operating system, and that after that point all bets are off. You have to trust
the person with the NT password at least. This is all about Florida, and we have
had VTS certified in Florida under the status quo for nearly ten years.

I sense a loosing battle here though. The changes to put a password on the .mdb
file are not trivial and probably not even backward compatible, but we'll do it
if that is what it is going to take.

Ken



Reply by Nel Finberg

RE: alteration of Audit Log in Access

To:
Subject: RE: alteration of Audit Log in Access
From: "Nel Finberg"
Date: Wed, 17 Oct 2001 14:48:16 -0700
Importance: Normal

Thanks for the response, Ken. For now Metamor accepts the requirement to
restrict the server password to authorized staff in the jurisdiction, and that
it should be the responsibility of the jurisdiction to restrict knowledge of
this password. So no action is necessary in this matter, at this time. Nel



 From Tyler to Ken Clark, Diebold Election Systems

Re: Nichols Lab

To: >,
Subject: Re: Nichols Lab
From: "Tyler"
Date: Mon, 15 Feb 1999 14:04:19 -0600

In point of fact, the user documentation MUST be completed before attempting
certification. It is my understanding that the documentation is a certification
requirement. I don't know how closely Nichols will scrutinize the documentation,
but I wouldn't feel comfortable going forward with certification with what we
have for GEMS. Ostensibly, the documentation we submit to Nichols will become
the "certified" documentation and we ostensibly shouldn't provide anything but
that to customers. But then again, with regards to the entire NASED
certification process, I can never quite get a handle on the relationship
between "ostensible" and "reality."... :-)



 From Ken Clark

RE: AVTS - Diagnostics & Installation

To: "Support Team (E-mail)"
Subject: RE: AVTS - Diagnostics & Installation
From: "Ken Clark"
Date: Tue, 6 Jul 1999 16:41:56 -0500
Importance: Normal

 > From: owner-support at gesn.com On Behalf Of > Juan Rivera

 > > I do not feel that it is necessary or desired to do this on each and every >
election. We, the manufacturer, are supposed to set the > procedures to follow >
for this equipment since we build it.

I hate more than anyone else in the company to bring up a certification issue
with this, but a number of jurisdictions require a "system test" before every
election. I just helped Knecht yesterday with an RFP from Riverside that
required this. That is why the AccuVote displayes the silly ***System Test
Passed*** message on boot up instead of "memory test passed", which is all it
actually tests.

No argument from me that it is pointless. You could probably get away with a
batch file that prints "system test passed" for all I know. We will do something
along those lines with the new unit after a memory test or whatever.

Ken



 From Ken Clark

RE: Testing sb100 database 1.14.2 (asap please)

To: "SUPPORT (E-mail)"
Subject: RE: Testing sb100 database 1.14.2 (asap please)
From: "Ken Clark"
Date: Fri, 7 Jan 2000 09:38:52 -0600
Importance: Normal

 > Do you all think it would be a good idea to get Jeff Dean to send us 10 or >
so precincts by eight parties with pre-printed test decks from one of the >
California sites for Jane to test AccuVote and CC???? If so, > I'll call Jeff >
Dean and set up asap.

*Any* testing we can do on 1.14 is a good idea. With the risk of sounding
alarmist, 1.14 really needs more testing. Even though much of GEMS looks the
same from the outside, the guts changed substantially between 1.11 and 1.14.
That's why you see all kinds of things completely unrelated to shadow races
broken in the early 1.14 releases.

Hats off to everyone posting 1.14 bug reports.

Ken

(The above memo is important because it documents that the "guts" of GEMS 1.14
are substantially changed from the certified version, 1.11 -- it was then used
in elections, but according to Diebold's own chart of which versions were
certified, version 1.14 was never certified.)



 From Steve Knecht

1.14 vs. 1.15 GEMS versions

(uncertified versions used.)

To: "Global Support"
Subject: 1.14 vs. 1.15 GEMS versions
From: "Steve Knecht"
Date: Fri, 14 Jan 2000 17:10:34 -0800

Is it the intention of development staff that California March election will be
run on some version of 1.14 or will we end up in the 1.15 range. Can you comment
on the following: Are the changes being made now to 1.15 GEMS things that are in
the ballot layout realm, and will not impact ballot processing, or tabulation
issues?? In other words, is it possible that changes made from now on will break
things we're starting to test, such as memory card up/download, central count,
etc. We are beginning testing of 1.14.4 this week. Should we be testing with
something else?

I guess a little summary picture of what you expect over the next 3 weeks of
testing would be helpful. I'd say we will have to lock down GEMS by mid -
February, AVTS ballot station is to go on-line, along with a pollbook function
by Feb. 7, but we are supposed to do testing and L&A prior to this. No panic
yet, just wondering where we're going to lock some of this down for the March
primary.

Here is the related memo from Ken Clark:

Needless to say, the changes were extensive. The paint is still wet, and I
expect people will want some tweaks in functionality as well as the obligatory
bug fixes. We'll treat the early 1.15 series as "prereleases" for LHS testing so
California does not have to suffer. Once 1.15 looks at least as solid as 1.14
though, we'll end the 1.14 branch. 1.14 and earlier Databases will upgrade to
1.15 without harm as usual. People testing 1.14 are encouraged to try out 1.15
to avoid any surprises when they are forced to upgrade.

Ken



(Here is a whole series of odd memos pertaining to how they should handle the
inconvenience of an uncertified version number popping up on the screen in
Florida)

 From Greg Forsythe

Florida Certified Versions

To: "Support"
Subject: Florida Certified Versions
From: "Greg Forsythe"
Date: Thu, 17 Feb 2000 11:12:02 -0500
Organization: Global Election Systems, Inc

Just received a call from Beverly Hill, Alachua County. She has a survey form
from the state regarding versions and things. She is at the SA screen and the
version is 1.92-15. Saturday, Feb. 12 she created a screen test database. This
copy has 1.92-14. 1.92-14 is certified, 1.92-15 is not. SOLUTION REQUIRED! Greg
Forsythe



 From Nel Finberg

Re: Florida Certified Versions

To:
Subject: Re: Florida Certified Versions
From: "Nel Finberg"
Date: Thu, 17 Feb 2000 09:51:10 -0800

I am currently looking into the problem with Beverly. Nel



 From Greg Forsythe

Re: Florida Certified Versions

To:
Subject: Re: Florida Certified Versions
From: "Greg Forsythe"
Date: Thu, 17 Feb 2000 12:55:09 -0500
Organization: Global Election Systems, Inc
References: <007301bf7961$cda9d030$cdbb2fd1 at greg

Hernando's original database installed with Gunzip shows 1.92-09. Their copy has
1.92-14. It appears that when the database is gunzipped from the original
diskette it carries the version from the source. When a copy is made on the
customer's computer the version relates to the version the customer's computer
programmed for. Solution might be to make the copy the official database showing
the correct version. Comments .....



 From Nel Finberg

Re: Florida Certified Versions

To:
Subject: Re: Florida Certified Versions
From: "Nel Finberg"
Date: Thu, 17 Feb 2000 10:24:37 -0800
References: <007301bf7961$cda9d030$cdbb2fd1 at greg

The problem has been fixed. Nel



 From Greg Forsythe

Re: Florida Certified Versions

To:
Subject: Re: Florida Certified Versions
From: "Greg Forsythe"
Date: Thu, 17 Feb 2000 13:33:55 -0500
Organization: Global Election Systems, Inc

Well done Nel! How did you fix it? Did you delete the original and use the copy?
If the diskettes had been sent in an unzipped format using Number 10, the
Restore function in the System Administration Menu, would the database have come
up with the version the customer's machine was running the first time and cause
no problems? Greg



 From Nel Finberg

Re: Florida Certified Versions

To:
Subject: Re: Florida Certified Versions
From: "Nel Finberg"
Date: Thu, 17 Feb 2000 13:13:25 -0800
References:

What we failed to do at the time the date was repaired in Alachua's database
(which showed question marks in the date field as a result of being prepared in
patch 15) was set the database release file to patch 14. This is what I did this
morning as well as set the release files for all of the remaining databases on
their system. It should be noted that it could be that a lot of databases were
initially set up with earlier versions of VTS, which we should be attentive to,
given the stringency of certification in the state. I will clean up release
files on the new Florida accounts in the next few days. Nel



 From Nel Finberg

Re: Florida Certified Versions

To:
Subject: Re: Florida Certified Versions
From: "Nel Finberg"
Date: Thu, 17 Feb 2000 10:09:56 -0800

(uncertified versions used.)

You are correct. However, Hernando's database should technically have been
compiled using patch 14, not patch 9. We do want to make sure that ballots have
been successfully tested and memory cards uploaded, particulary given the
initial version conflict. It would be a good idea to get rid of the original
diskette in order to remove the perception of version conflicts.

Nel



 From Nel Finberg

Re: Florida Certified Versions

To:
Subject: Re: Florida Certified Versions
From: "Nel Finberg"
Date: Thu, 17 Feb 2000 10:24:37 -0800

The problem has been fixed. Nel



 From Cathi Smothers

GEMS Versions

From: Cathi Smothers [mailto:csglobal at earthlink.net]
Sent: Monday, June 05, 2000 5:02 PM
To: Ken Clark
Okay. Here's a "stupid new employee" question.
I need to get the MN accounts upgraded to 1.16. How do I know which version of
GEMS (i.e. 1.16.3, 1.16.4, etc.) to use?



 From Ken Clark

RE: GEMS Versions

To:
Subject: RE: GEMS Versions
From: "Ken Clark"
Date: Mon, 5 Jun 2000 18:00:49 -0500
Importance: Normal
In-reply-to:

From: Cathi Smothers [mailto:csglobal at earthlink.net]
Sent: Monday, June 05, 2000 5:02 PM
To: Ken Clark

Hope you don't mind the support list follow up. Certainly not a stupid question,
and its worth a post on this topic every once in a while.

Baring any certification issues, the latest stable release is what you want to
upgrade accounts to. We always let people know when a release is for testing
only in the release announcements. Testing releases are usually 1.X.1.Y
releases. For example 1.16.1.1-6 were all testing releases. At some point we
conclude that testing is going well, and declare the branch stable. A new
testing branch is then opened, and only bug fixes go into the stable branch.
Right now 1.16.latest is considered stable, 1.16.4 being the current release by
my mail. How stable the stable branch really is has everything to do with how
much testing by support it receives.

Its fair to say the nature of this company and business make this process fairly
informal, perhaps more so than I would like. Testing releases go out to
customers when they shouldn't, and new features get added to stable branches
when they shouldn't. It is not entirely undisciplined either though. Obviously
you need to keep an eye on the support and bugtrack lists. Sometimes a bug slips
into a stable branch, in which case its better to ship a version you trust, or
wait for it to get corrected.

Secondly, does the upgrade simply consist of installing the new executable file
or are there other components that need to be installed as well? They are
currently using 1.11.8.

There are several components.
The GEMS exe
The ABasic directory and abasic.ini
The Reports directory and reports.ini
Locale.ini

The DLL files shipped on the GEMS CD get updated from time-to-time as well,
though not often. Is usually a good idea to order the CD for a long-haul
upgrade. Its not really clear whether 1.11->1.14 qualifies as long haul or not.
That really depends on your comfort level. There is never any harm in ordering a
CD. Other frequently asked questions while I am here:

Features are always propagated forward. I suppose one day we might remove a
feature, but I've never seen it happen.

Baring bugs, artwork and memory cards are still compatible after GEMS upgrade
unless there is a big announcement to the contrary. Its only happened once that
artwork was incompatible after upgrade, and memory cards have never been
incompatible.

The database changes between major releases (1.15->1.16) but not minor releases
(1.16.1->1.16.2). You can downgrade out of trouble between minor releases, but a
major release upgrade is a one way trip.

Ken



 From Jeff Hintz

Software for Los Angelas, CA

To: "Support Team (E-mail)"
Subject: Software for Los Angelas, CA
From: "Jeff Hintz"
Date: Thu, 31 Aug 2000 12:31:06 -0500
Importance: Normal

I am going out to LA next week, and I would like to know what software version
of Gems & AVTS is being sent out on their equipement. Thanks, Jeff Hintz

(uncertified versions used.)



 From Rodney D Turner

RE: Software for Los Angelas, CA

To:
Subject: Re: Software for Los Angelas, CA
From: "Rodney D Turner"
Date: Thu, 31 Aug 2000 13:31:55 -0500
References: <000201c01371$42bb57a0$0903a8c0 at Jeff

Hi Jeff, I have completed the computer for LA and Alameda. The computer for LA
has GEMS 1-16-9 and the AVTS units have 3-13-1-4. The computer for Alameda has
GEMS 1-16-10 and GEMS 1-16-9 ( there is a short-cut on the desktop for GEMS
1-16-9) the AVTS units have 3-13-1-4. All of the AVTS units including VIBS, have
an OS of Windows NT. Because of NT, you have to remove the floppy from the drive
during start-up. If you do not, NT changes the Imation drive from "A" to "D". If
you forget to take out the disk from the drive, you have to restart without the
disk in the drive to get it back to drive "A". Drop me a line Jeff, if you have
any questions, or concerns. Rodney rodney at gesn.com



 From Talbot Iredale

RE: Software for Los Angelas, CA

To:
Subject: Re: Software for Los Angelas, CA
From: "Talbot Iredale"
Date: Thu, 31 Aug 2000 12:03:50 -0700

(uncertified versions used.)

Jeff and Rodney, LA and Alameda will need a revised version of GEMS and maybe
BallotStation to support the import/export that they require. I am working on it
now but I am certain there will be more changes.



 From Larry Dix

RE: Software for Los Angelas, CA

To:
Subject: RE: Software for Los Angelas, CA
From: "Larry Dix"
Date: Thu, 31 Aug 2000 15:41:58 -0500
Importance: Normal

Tab – Would you be willing to venture an outside guess as to when the revised
GEMS version will be ready. This really becomes an issue since I need to
coordinate staff to be onsite. Is this also the case for Alameda? Coordination
of time and staff is everything on these 2 installs. Larry J. Dix Global
Election Systems



 From Ken Clark

Re: Gems-1-17-1

To:
Subject: RE: GEMS-1-17-1
From: "Ken Clark"
Date: Thu, 31 Aug 2000 17:33:04 -0500
Importance: Normal
In-reply-to: <058c01c0138a$f76e27e0$1204a8c0 at gesn.com>

Is this a "testing" release or not? (Ashamed to ask). I think the hallucinations
ought to be resurfacing with Steve already. Ken



 From Talbot Iredale

(uncertified versions used.)

RE: GEMS-1-17-1

To:
Subject: Re: GEMS-1-17-1
From: "Talbot Iredale"
Date: Thu, 31 Aug 2000 16:14:23 -0700
References:

This is no more of a test release than 1.16.9 was though I would not be
surprised if we have to make more changes to fully support LA and Alameda. Tab
Re: Software for Los Angelas, CA



 From Steve Knecht

To:
Subject: Re: Software for Los Angelas, CA
From: "Steve Knecht"
Date: Fri, 1 Sep 2000 09:10:49 -0700
References: <000201c01371$42bb57a0$0903a8c0 at Jeff>

(uncertified versions used.)

Jeff, I think my thread may be out of sync, but discussion with Tab yesterday
indicated that you'd be at least at 1.17.1 or higher to provide you with the
"import" capability with their database. I believe Rodney / Mike would have to
tell you what they loaded onto AVTS. Tab is still working on several programs
that may affect what AVTS Rev and GEMS rev we both end up with.



 From Tari Runyan

1-17-7-5 testing

To: "SUPPORT (E-mail)"
Subject: 1-17-7-5 testing
From: "Tari Runyan"
Date: Mon, 23 Oct 2000 08:21:16 -0600

(uncertified versions used.)

I have tested this version to the extent I am able - twice even and unless
anyone else has discovered anything - i think it can be released to the Ca
Counties - Let me know if anyone else has any concerns as I would like to get
this out this morning. Thank you

(There are dozens more memos like this, and hundreds that document the use of
uncertified versions of the voting system, spanning a period from 1999 to 2003.)