[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Re: Asking Questions is a Good Idea



> Vince,
> I am not personnally interested in delaying the ability for those less
> fortunate than us (blind or with limited vision) the ability to vote
> privately if there is a way to provide an adequate assurance of security.

Vern,
   While I admit that for the past 100 years the illiterate and the
blind have had to vote the same way all Americans had to during
most of our nation's history, I simply do not see that bringing
them up to par via the secret ballot is of such urgency that we
need to open ourselves up to the potential of such large-scale fraud
that their vote may not count, anyways.

   Also, I find it interesting that you are concerned about the blind
but not about the greater number of illiterate voters.  Most voters
in the first federal elections, who were farmers and veterans of the
Revolutionary War, were not literate.

> I know we both understand that there is no such thing as
> absolute security, but we can reduce the risks through any of the three
> methods - People, Policy or Technology.  If there are alternatives that
> meet the security objectives without driving the cost out the roof then
> we should make provision for security to be implemented in that method.

   As ofr People and Policy, methinks that the utter refusal to fix
problems that were discovered long ago in electronic voting systems,
combined with the long history of election rigging in our nation, makes
this laughable, at the risk of making a grave understatement.

> I am very concerned that there is such a drive to require VVPB as "the
> only acceptable solution" when it is untested technology and will add
> a significant amount of cost and decrease the reliability of the vote
> recording subsystem.  These concerns are discounted without

   If you are worried about cost, use optical scanners; they are far
cheaper than a DRE with or without a printer.

> consideration by some and I would hope that you would consider the
> possibility that VVPB is not a panecea.  The RABA study indicates that

   The more hysterical argument, based on emotional appeal and in the
absence of hard facts, that I hear damning the VVPB, the more I think
there can't be a defensible reason to oppose VVPB.

> VVPB comes with it's own set of problems, not the least of which is
> "which ballot really counts" and are you providing a means to "stuff
> the ballot box" by having the Paper Ballots.  Just a few things to
> consider.

   The RABA study indicates that VVPB comes with its own set of problems?
The RABA report says that VVPB does not prevent the problem of a voter
casting multiple votes (NOT that it introduces any new problems), and
that while allowing the voter to handle the ballot would introduce
problems, use of the Mercuri method would NOT introduce any problem.

   Furthermore, the "Executive Summary" of the RABA paper ends with:
"Ultimately we feel there will be a need for paper receipts, at least
in a limited fashion."

   So, it seems to me that the RABA paper says exactly the opposite of
what you claim it says.  Please explain; enquiring minds want to know!

> R/ Vern
Vince

-----Original Message-----
From: "Vincent J. Lipsio" <Vince@lipsio.com>
Sent: Feb 4, 2004 12:29 PM
To: "COTS Special Task Group, P1583" <COTS@lipsio.com>, 
	"Security Task Group, P1583" <stds-1583-TG1@ieee.org>
Subject: 


> the bug ... was dependent on abstruse aspects of the way the
> operating system worked... A good lesson when you fly COTS
> [commercial off-the-shelf] stuff--make sure you know how it works.'

Pete,
   Many years ago, when commercial RTOSes were new, a mentor suggested
that such things were generally a bad idea simply because they
encourage programmers to use overly-fancy features that they don't
really need and don't understand.
   Long ago, I concluded that for critical systems, the guiding
principle is to keep it as simple as possible, and the presence of an
operating system with unused features and, much worse, features whose
subtleties were not thoroughly understood by those using them,
introduces complexity and unknowns that must be avoided because, if for
no better reason, the cost of V&V became prohibitive.  Therefore, for
critical systems I strongly advocate either a commercial RTOS where the
unused features can be #ifdef'ed away and the source code is available,
or simply writing one's own kernel.
   Unfortunately, the consensus in P-1583 seems to be that V&V is not
appropriate to voting equipment because it would make the devices
prohibitively expensive, that thorough testing as specified in other
IEEE standards on software engineering is "unreasonable".  I find this
attitude appalling, especially when mandated an independent audit trail
is also out of the question.  It has oft been publicly argued that "we
trust computers to fly airplanes, so why can't we trust them to count
votes?", but that is very dishonest because the in-flight software and
voting equipment software are radically different; if one told the FAA
that voting equipment software, where even a line-by-line peer review
has been rejected thus far as too costly, were as well tested as
in-flight software, they would, to borrow David Chaum's idiom,
asphyxiate themselves with laughter.

Vince Lipsio

-----------------    Commence Original Message    -----------------

Whole article at
http://zdnet.com.com/2100-1107_2-5148988.html?tag=zdfd.newsfeed

"... the technology on Mars looks awfully like that on your desk--a
general
purpose, standards-based platform like many others running a commercial
operating system doing custom tasks."

Relating the problem to previous problems years before with Pathfinder, a
spokesperson said, "the bug wasn't in their code, but was dependent on
abstruse aspects of the way the operating system worked. Linked to that, the
mission engineers had to have an extraordinary knowledge of the guts of the
operating system. As a report after the event said: 'A good lesson when you
fly COTS [commercial off-the-shelf] stuff--make sure you know how it works.'" 

[Also other instructive one focuses on FLASH memory at
http://spaceflightnow.com/mars/mera/040126spirit.html.]
--
Pete Klammer / ACM(1970), IEEE, ICCP(CCP), NSPE(PE), NACSE(NSNE)
    3200 Routt Street / Wheat Ridge, Colorado 80033-5452
  (303)233-9485 / Fax:(303)274-6182 / Mailto:PKlammer@ACM.org
 Idealism may not win every contest, but that's not what I choose it for!