[E-voting] software versions
cansbro at eircom.net
Wed Jun 1 21:23:09 IST 2005
I post this because I don't know how much care (if any) has been given
to developing of proper procedures for upgrades/bug fixes/fees/(refunds)
of the proposed Irish system. I remember the CEV report mentioning the
software was constantly changing, so there was no way it could be
See the whole thread for more info; the responses to the post below
include revelations that Diebold was /charging its customers/ for
critical bug-fixes! (This, when the problems were so severe a full
product recall would have been the only ethical thing to do.) Would we
in Ireland have had any protection from this kind of thing? Bug fixes
being called "updated versions" and then charging us taxpayers for it?
Posted on Monday, May 30, 2005 - 07:10 am: Edit Post
View Post/Check IP
Post (Moderator/Admin Only)
A quick note here: The version number (1.94) is a matter of some
consternation over at DU.
While it is true that there are only two certified versions for the chip
in the precinct-based optical scan (1.94w and 1.96.4) there have
actually been many other versions in use. This can be found in the
Diebold memos -- see Chapter 13
(http://www.blackboxvoting.org/bbv_chapter-13.pdf) for specifics.
The version used in New Hampshire has never been certified at all. Also,
there is a version 2.0.1 used for the high speed central count optical
scans (absentee ballot processing machines).
You can find all the version numbers that are certified up through Oct
2004 in the Black Box Voting Document Archive, here:
To deal with variability in versions used, we had Hursti examine the
whole source code evolution for the optical scan.
I think it is around 1.95.4 where the changes in the optical scan
firmware are significant enough that we would want to do a new round of
testing to check vulnerabilities again.
The 1.96 version is used in California, but most of the Florida optical
scan counties are still on 1.94 levels, as is much of the rest of the
U.S. We had an opportunity for a field test with the 1.94 software, and
we took it.
Therefore, only the 1.94 series -- which is still very widely used -- is
mentioned in this article. No comment on 1.96 (yet).
Regarding the upgrade of California counties to 1.96, which took place
AFTER the March 2004 primaries if I'm not mistaken, I am interested in
whether counties had to pay for the upgrade to the new 1.96 software.
I'm guessing they did, but those of you in California may know for sure.
If so, it calls into question what process triggered that upgrade. For
example, did the Voting Systems & Procedures Panel in California spot
these flaws and require the upgrade? Does the upgrade to 1.96 even solve
the issue of an editable executable program living on the memory card?
Because the design flaw is so significant, a PRODUCT RECALL at Diebold
expense is the only ethical way to address this. It certainly should NOT
be addressed by consultants working quietly behind the scenes with
Diebold, passing costs for upgrades along to the taxpayers.
Therefore, the process taking place behind the scenes during upgrades to
1.96, as well as questions about whether this vulnerability exists in
1.96, need to be addressed.
The 1.96 versions may have the exact same flaws. Or not. It's a secret.
Privatized vote-counting. Ain't it grand?
More information about the E-voting