[E-voting] sophisticated "layering" of software code
bobyrne at statesoft.ie
Thu Jun 2 13:40:45 IST 2005
It is very hard to make a comment on layering of code without more
information than is available below.
All code is layered to a greater or lesser extent. At the simplest you
have the layers of operating system, runtime environment (Java, .NET
framework, Access/VBA, etc.), application code, etc.
Within that there are lots of subtleties and opportunities for
mischief. You could, for example, rewrite the device driver that
mediates between the OS and the memory cards, so that reading the
same memory card on two different machines (or with two different
programs) could give different results.
There is almost no chance that sort of tampering would be caught by a
code review, because the code review would almost certainly assume
device drivers behave as expected.
OTOH spaghetti code, such as can be written by inexperienced
programmers, can be used to hide problems in a maze of function calls
and jumps across code. That _should_ be caught by code review, but as
most programmers have probably experienced it is very easy for a typo
to creep into code that does not cause the program to fail in any
obvious way, but still causes problems. I know I have wasted hours
looking at code that was broken only to see I had transpoesd two
letters somewhere. ;)
If typos like that are introduced carefully and deliberately I can see
how a code reivew would fail to notice them.
Summary: a code review is a good and useful part of an acceptance
test, but it must be combined with carefully-designed execution tests
including tests of all the boundary and exception conditions you can
Even then, putting the tinfoil hat back on, there are plenty of places
to hide trouble that will probably not be searched.
On Wednesday 01 June 2005 21:32, Catherine Ansbro wrote:
> And the post below it. (both follow below)
> These refer to incident reports from the Nov. 2004 election on
> optical scan machines. Note particularly the statements I've put
> in bold. (And especially the one about sophisticated software
> "layering." --Do you think something like this might be noticed in
> the software code review currently underway? Or could it slip
> beneath the radar, particularly if there's not much time and it's
> not obvious?)
> Great report. It is also wonderful you were able to get someone as
> cooperative as Ion Sancho to participate. I would also like you to
> examine the many EIRS machine incident reports that were found in
> Leon County during the Nov. 2004 election. It was troubling to me
> that someone as committed to accurate elections was *not able to
> pick up these problems in the L & A testing.* Many precincts in
> Leon had the inability to read and accept many ballots because of
> the optical scan calibration's inabilty to read the color of the
> ink or gradation of the pencil that was used. Also many optical
> scan machines had difficulty in accepting the ballots, so poll
> workers had to collect their ballots to be counted later. At least
> they had a paper ballot to count.
> /I would also like you to examine the many EIRS machine incident
> reports that were found in Leon County during the Nov. 2004
> / Many precincts in Leon had the inability to read and accept many
> ballots because of the optical scan calibration's inabilty to read
> the color of the ink or gradation of the pencil that was used. /
> Hi, and it's nice to see you here. The good thing about Ion Sancho
> is that he is willing to hand-count whenever he thinks it should be
> done. In many places, the elections supervisors point to bogus
> secretary of state guidelines and say they "can't" do a hand
> recount unless the election is too close to call.
> *It is not surprising that the problems you mentioned were not
> caught in the L&A test. The testing uses the writing implements
> these machines were designed for. When you introduce various kinds
> of writing implements with infra-red scanners you get those kinds
> of errors. *
> I think Ion Sancho wants to see how the electronic voting battles
> shake out (and how the next generation machines fare in objective
> tests) before upgrading to something that could be even worse. So,
> my understanding is, he uses procedural workarounds -- like hand
> counting and double checking the counts -- instead of jumping on
> the bandwagon to buy new machines.
> I think he's wise. *While the Diebold programmers, at first, appear
> clumsy, a deeper look at the software indicates that there are
> sophisticated layers below which are very hard to explain with
> reasons that would be legitimate.
> When you 've got a system that has layers of built-in problems, you
> are wise to avoid new purchases -- and even if Sancho was to ask
> for his money back, what would be the replacement? Something with
> even worse problems, that are harder to detect?
> Frankly, I wish Ion Sancho was my elections supervisor, and I'd
> feel a lot better if Thomas James was manning the King County
> Diebold optical scan system. Maybe then we'd know who the governor
> is by now.
> Thanks, and welcome here.
> By the way (I'm guessing this will interest you) -- we have two
> boxes so far from Broward. Haven't had much time to delve, we are
> scanning the seven boxes from Palm Beach.
> Love ya!
> Bev Harris
> E-voting mailing list
> E-voting at lists.stdlib.net
Brian O'Byrne, Statesoft Ltd.
Tel: +353 1 4100 993, +353 86 240 4719
More information about the E-voting