[E-voting] various versions of the optical scan software
cansbro at eircom.net
Mon May 30 16:23:52 IST 2005
From a new recent post at BBV.
This too relates to our Irish system. I don't have reason to believe
we'd have any more control or ability to scrutinize "upgrades" (and
version numbers, and why they are needed) than happens in the US. It's
all proprietary. Closed book. Supposed to be taken on trust. Even
though it's /our/ democracy.
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