[AccessD] Hiding Back End Design

We used the Diebold system in our last election.  There were a few problems.
Like about 1/3 of the machines wouldn't boot up when the polls opened
resulting in delays.  Some folks didn't get to vote.  So, no more touch
screen voting machines for a while in San Diego county.

http://pqasb.pqarchiver.com/sandiego-sub/index.html?ts=1088003747&classchk=pass

http://pqasb.pqarchiver.com/sandiego-sub/index.html?ts=1088003747&classchk=pass

Rocky

----- Original Message ----- 
From: "Hale, Jim" <Jim.Hale at fleetpride.com>
To: "'Access Developers discussion and problem solving'"
<accessd at databaseadvisors.com>
Sent: Wednesday, June 23, 2004 7:26 AM
Subject: RE: [AccessD] Hiding Back End Design


> You guys won't believe this.  Diebold was/is using Access as the DB for
its
> voting app. Talk about back end security issues!! Bring back the good 'ol
> days of hanging chads <g>! The lead in paragraphs are from Peters software
> newsletter. Incredible!
> Jim Hale
>
>
> 3. How NOT To Design an Application
> -------------------------------------
> Well, Microsoft Access made history recently by being at the center
> of an automated voting machine controversy. It seems that Diebold
> Election Systems put together an application for the very, Very,
> VERY important purpose of counting votes in US elections. 37 states
> made use of this application. The only problem? Well, there were
> many! It seems that Diebold left their source code and other
> critical information on an unprotected public web site. They used
> bad vote accounting practices. They did not secure their MS Access
> databases, and they chose to use MS Access for this critical
> application in the first place!
>
> Sometimes knowing when NOT to use MS Access is just as important as
> knowing HOW to use MS Access.
>
> An investigative reporter in the article below was able to edit the
> Diebold MS Access tables directly, change vote totals, and erase the
> audit trail from the poorly designed tables. Whooops! That could be
> called a FLAW!
>
> A database like Oracle would have been much better for this task
> because you can have triggers (event procedures) for TABLE events.
> With Oracle you can have a procedure execute when a table record is
> updated, or a table field is updated. You can only do that with
> forms in MS Access, not tables. That means that a well-designed
> Oracle database would not be as susceptible to direct table editing
> without an audit trail the way this MS Access database was.
>
> Here's the story - a very good lesson on how NOT to design a
> critical application:
>
> Link: http://www.scoop.co.nz/mason/stories/HL0307/S00065.htm
>
>
> -- 
> _______________________________________________
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com