You are viewing an obsolete version of the DU website which is no longer supported by the Administrators. Visit The New DU.
Democratic Underground Latest Greatest Lobby Journals Search Options Help Login

The strange case of the second database table [View All]

Printer-friendly format Printer-friendly format
Printer-friendly format Email this thread to a friend
Printer-friendly format Bookmark this thread
Home » Discuss » Topic Forums » Election Reform Donate to DU
Kelvin Mace Donating Member (1000+ posts) Send PM | Profile | Ignore Tue Oct-19-10 06:36 PM
Original message
The strange case of the second database table
Advertisements [?]
I admit to be just a tad confused by the explanation offered for the problem of the R. Whitey "typo" in Chicago.

The mistake in the Green Party candidate's name appears on a review screen that allows voters to double-check their selections and not on the screen where the vote is registered. It also is not on paper ballots, Neal said.

OK, as most regulars know, I am not partisan to conspiracy theories and like to deal in hard facts. So. I wish to leave aside allegations of criminal/nefarious intent, and simply address my central question below.

I have some experience with relational database programming, but I am in no way an expert, (hardware is my forte). I have, back in the day, written a few programs, (tech support call database, repair database, etc), nothing complicated.

Now, if I were writing a program for a voting machine to tabulate votes, I would have two tables in the database. These tables would be "candidate info" (name, party affiliation, district/ward, office being sought, unique ID code), and the "actual votes", which would then be related to the first table (the "relation" relational database) by the "unique id code" which would be a common field of both tables. So, when you cast a vote, a TRUE value would be assigned to that unique id code in the "vote" table, which would then be related to a candidate, race, etc, in the "candidate info" table.

Again, I am very much oversimplifying here for the sake of discussion.

Now, in order to create a summary screen, the data values (votes and who they assigned to) have not yet been written to the "votes" table, i.e. cast. They are simply in memory, and I am performing a "lookup" of the data entered by the voter, and matched it to the candidates/races/referendum in the info table (before each election, all the candidate info would be entered, and the "vote" table zeroed out).

To re-iterate, as votes are entered (NOT cast) by the voter, they are assigned to temporary data values in memory, when the summary screen is called up, the temporary values are displayed, and the lookup performed to match the values with "candidate info" table.

Now, if I misspell a name, that misspelling is in the "candidate info" table, meaning EVERY time I do a lookup, whether to create the ballot page or the summary screen, the same typo will appear.

In order for the error to have occurred the way the election officials explained it, there would have to be TWO "candidate info" tables, one with the name correct used to create the ballot pages, and one where the name is incorrect used to create the summary screen.

Which makes no sense to me.

WHY create two tables to lookup candidate data? I cannot think of a single rational reason (that meets the standards of good programming practice of a "security critical" application) for intentionally doing this.

As I am not professional programmer, I throw this question out to programmers with more experience who may be able to enlighten me as to why this would be a logical and reasonable practice.

Now, if folks agree with my analysis, and state that they can see no reason for the second table, this leads to four possible scenarios:

1) The second table intentional and is the product of poor programming practices.

2) The second table is unintentional, the result of poor programming practices and the legacy of a code handled by multiple programming teams, each patching their successor's mistakes, rather than re-writing the code from scratch.

3) The second table is a combination of reasons #1 and #2. Intentionally designed in by a bad programmer, then simply left in by those that followed because they forgot about it, missed it, or ignored it.

4) The second table is intentional, with some nefarious intent.

IF (and I must emphasize, IF), I am correct in my observations, then I am more inclined to view #1 or #2 as the most probable answer, as it meets my criteria of "never be quick to ascribe to treachery what can be better explained by incompetence and/or stupidity".

Diebold's code certainly meets the criteria for this, since it has handled by many different programming teams as the code passed from company to company, with no one willing to "start over" since it would cost a lot of money to actually write secure code from scratch. This, of course, make the case, yet again, that voting code MUST be disclosed to competent professionals loyal to the public good before use in any election.

Reason #3 is possible, but less likely since it requires an even greater level of incompetence than normal.

Reason #4 is possible, but I would have to see solid evidence to move in that direction.

Your constructive thoughts and criticisms of my observation, please. I am posting this, but have to dash. I will be back on later to read your responses.
Refresh | +2 Recommendations Printer Friendly | Permalink | Reply | Top
  -The strange case of the second database table Kelvin Mace  Oct-19-10 06:36 PM   #0 
  - The problem here  notesdev   Oct-19-10 07:28 PM   #1 
  - Well, I am not trying to establish  Kelvin Mace   Oct-19-10 08:51 PM   #2 
     - All we can establish with the facts we have  notesdev   Oct-20-10 12:48 PM   #6 
        - You are preaching to the choir  Kelvin Mace   Oct-20-10 01:28 PM   #7 
           - The evidence is in the method chosen  notesdev   Oct-20-10 02:09 PM   #8 
              - Uh. Speed.  Wilms   Oct-20-10 05:08 PM   #10 
              - That doesn't address the issue  notesdev   Oct-20-10 05:48 PM   #11 
              - You can have paper ballots counted by a scanner without sacrificing integrity? How? nt  Bill Bored   Oct-20-10 07:45 PM   #15 
              - I did address the issue you brought up.  Wilms   Oct-20-10 08:24 PM   #18 
                 - Some people  Kelvin Mace   Oct-21-10 12:21 PM   #23 
                    - Now that's a fair criticism of Election Officials.  Wilms   Oct-21-10 12:42 PM   #25 
              - Agreed  Kelvin Mace   Oct-20-10 07:32 PM   #14 
              - Sorry, I must disagree  Kelvin Mace   Oct-20-10 07:30 PM   #13 
                 - Cabal?  Bill Bored   Oct-20-10 08:00 PM   #16 
                    - There are a lot of problems  Kelvin Mace   Oct-21-10 12:57 PM   #26 
                       - How about this example (consider it a "hybrid case"):  Bill Bored   Oct-22-10 02:46 AM   #30 
                          - What can I say?  Kelvin Mace   Oct-22-10 08:17 AM   #31 
                             - I don't think the system was purchased with those illegal features...  Bill Bored   Oct-23-10 01:16 AM   #34 
  - How about: ballot text is editable; database records are not?  Bill Bored   Oct-19-10 11:41 PM   #3 
  - You and those prickly details, again?  Wilms   Oct-20-10 12:03 AM   #4 
  - In either case  Kelvin Mace   Oct-20-10 07:58 AM   #5 
     - re: "...with proper safeguards, OpScan is the best solution..."  Wilms   Oct-20-10 05:00 PM   #9 
     - Certainly...  Kelvin Mace   Oct-20-10 07:14 PM   #12 
        - Mostly  Wilms   Oct-20-10 08:32 PM   #19 
        - Well  Kelvin Mace   Oct-21-10 12:03 PM   #22 
           - We'll go 'round in circles.  Wilms   Oct-21-10 12:38 PM   #24 
              - I'm kind of not understanding what you are saying here  Kelvin Mace   Oct-21-10 01:04 PM   #27 
                 - He's saying that knowing the source code doesn't protect the vote.  Bill Bored   Oct-22-10 02:19 AM   #28 
                    - That's pretty much my point. Thanks Bill.  Wilms   Oct-25-10 12:23 PM   #36 
        - Not one state does #3, including yours, although NC has made some progress. nt  Bill Bored   Oct-20-10 08:42 PM   #20 
           - Hmmm, I said...  Kelvin Mace   Oct-21-10 11:51 AM   #21 
              - You missed that only ONE contest is audited, and that the expansion of the audit did NOT happen...  Bill Bored   Oct-22-10 02:25 AM   #29 
                 - Ah, now I understand  Kelvin Mace   Oct-22-10 10:57 AM   #32 
                    - AGREED! (And of course Joyce rocks!) nt  Bill Bored   Oct-23-10 01:18 AM   #35 
     - Any system that allows vote switching is NOT the best solution we have.  Bill Bored   Oct-20-10 08:22 PM   #17 
  - you don't give much detail about why HCPB is so impossible.  diva77   Oct-22-10 02:31 PM   #33 
  - Fraud AND Greed  Catbird   Oct-25-10 01:38 PM   #37 

Home » Discuss » Topic Forums » Election Reform Donate to DU

Powered by DCForum+ Version 1.1 Copyright 1997-2002
Software has been extensively modified by the DU administrators

Important Notices: By participating on this discussion board, visitors agree to abide by the rules outlined on our Rules page. Messages posted on the Democratic Underground Discussion Forums are the opinions of the individuals who post them, and do not necessarily represent the opinions of Democratic Underground, LLC.

Home  |  Discussion Forums  |  Journals |  Store  |  Donate

About DU  |  Contact Us  |  Privacy Policy

Got a message for Democratic Underground? Click here to send us a message.

© 2001 - 2011 Democratic Underground, LLC