Interesting series of messages from a web site I came across. Apparently Al Gore got NEGATIVE 16022 votes in Precinct 216 of Seminole county Florida. Bush and the Supreme Court committed treason and the United States is occupied by a hostile force - the Bush Administration.
-----Original Message-----
From: Lana Hires [mailto:lhires@co.volusia.fl.us]
Sent: Wednesday, January 17, 2001 8:07 AM
To: jmglobal@earthlink.net; Glanca@ges.com
Cc: Deanie Lowe
Subject: 2000 November Election
Hi Nel, Sophie & Guy (you to John),
I need some answers! Our department is being audited by the County. I have
been waiting for someone to give me an explanation as to why Precinct 216
gave Al Gore a minus 16022 when it was uploaded. Will someone please
explain this so that I have the information to give the auditor instead of
standing here "looking dumb". I would appreciate an explanation on why the
memory cards start giving check sum messages. We had this happen in several
precincts and one of these precincts managed to get her memory card out of
election mode and then back in it, continued to read ballots, not realizing
that the 300+ ballots she had read earlier were no longer stored in her
memory card . Needless to say when we did our hand count this was
discovered.
Any explantations you all can give me will be greatly appreciated.
Thanks bunches,
Lana
* To: Support
* Subject: Memory card checksum errors (was: 2000 November Election)
* From: Guy Lancaster
* Date: Thu, 18 Jan 2001 11:41:08 -0800
* Organization: Global Election Systems Inc.
* References:
This is an overview on what memory card checksum errors are. Exactly what causes them is a separate question.
The memory card is very simply a programmable memory device with a battery backup. The Accu-Vote accesses this memory directly. If something goes wrong when the Accu-Vote is writing new data to the memory card or if the Accu-Vote crashes (as computers have been known to do) and writes to random memory locations, then the data on the memory card may be corrupted (nasty word I know but it fits). All this means is that the data is modified in an unintentional manner. This could also happen without an Accu-Vote through static discharge or some types of radiation (i.e. old airport scanners, cosmic rays???).
There are several mechanisms that we could use to detect this. We use the simplest of these which is to treat the data as a series of numbers and store totals of sets of those numbers as separate data known as checksums. If the data has been modified without updating the checksums, then the checksums will fail to add up.
The Accu-Vote keeps three different types of checksums for three different classes of data. These are text, counters, and precinct. The text checksums cover all the titles and names that are used mostly just for printing reports. Since the text data does not affect the other operations, we check it only occasionally and we allow most operations to continue after a warning.
The counters and precinct data are considered critical and the Accu-Vote is largely inoperable when these checksums fail. We do support the option to clear the counters if only they have been affected and then counting may be restarted. However there is no way to recover from corruption of the precinct data other than to clear and re-download the memory card.
All checksums are validated upon insertion of a memory card or at power on. Thus this is the most common time to detect problems. However the counter and precinct checksums are validated every time a new ballot is scanned. If an error is detected, counting is aborted.
Now to Lana's questions. The above should answer everything other than why erroneous data managed to upload. I see two possible explanations. One is that the data was corrupted after the checksums were validated. In this case the errors would show the next time the checksums were checked. The other possibility is the miniscule chance that the erroneous data managed to add up to the correct checksum. The checksums are stored as totals ranging from 0 to 65535 so the chance of this happening are less than 60,000 to 1 just based on that. Other factors add to this to make it extremely unlikely. However in this case the card would not later show checksum errors.
So John, can you satisfy Lana's request from this? I can't without more details.
Guy
* To:
* Subject: RE: Memory card checksum errors (was: 2000 November Election)
* From: "John McLaurin"
* Date: Thu, 18 Jan 2001 14:56:15 -0500
* Importance: Normal
* In-reply-to: <3A6746D4.6D7B0E4B@gesn.com>
Thanks Guy, - the pollworker did restart the unit and eventually put the unit back in election mode. It did not require redownloading the card. Am I missing something in your explanation to understand this?
John
* To: support@gesn.com
* Subject: Re: Memory card checksum errors (was: 2000 November Election)
* From: Guy Lancaster
* Date: Thu, 18 Jan 2001 12:23:47 -0800
* Organization: Global Election Systems Inc.
* References:
John McLaurin wrote:
You're probably missing the same details that I am. >From Lana's description she is referring to several checksum error events. One of them sounds like a simple counter error that could be cleared and restarted. I don't think this is the same event as the bad upload.
Guy
* To:
* Subject: RE: Memory card checksum errors (was: 2000 November Election)
* From: "Ian S. Piper"
* Date: Thu, 18 Jan 2001 14:35:01 -0600
* Importance: Normal
* In-reply-to:
Steve Ricke has been running tests on a specific unit from Seminole. He had a checksum error occur and had the same result of the card resetting to pre-election mode and being able to reset for election mode and continue. After that one error, he has since run thousands of ballots through without a repeat of the error. The original audit report for the Seminole corrupted memory card showed that it had experienced the same error when Mickey Martin and company were recounting ballots on November 9, 2000. Still testing.
Below is the sequence of events for this error. Hope it helps.
Ian
1. Ran test using memory card and accu-vote (Ser.# 71586) which had been corrupted in Seminole County, Florida.
2. Ran three 2000 ballot tests in election mode in McKinney.
3. Unit failed only once which was during the second 2000 ballot test (at about 1300 ballots),
4. Message on display "Corrupt count see official",
5. Pressed YES and NO buttons several seconds each with no change of message,
6. Turned unit OFF, then ON- resulted in "Please reinsert memory card" message,
7. Repeated turning unit OFF then ON with the same message result,
8. Reinserted card (Power ON) message displayed now "counter error ok to continue?",
9. if answered NO, returns to "Please reinsert memory card" message,
10. If answered YES, then message displayed is "Clear counters and recount?",
11. If answered YES, card is reset to pre-election mode and displays "Test ballots?",
12. We set card back into election mode. Ran another 2000 ballots without failure.
Will continue to try with other cards and accu-votes from other counties.
Steve Ricke
* To:
* Subject: RE: Memory card checksum errors (was: 2000 November Election)
* From: "Ian S. Piper"
* Date: Thu, 18 Jan 2001 14:55:06 -0600
* Importance: Normal
* In-reply-to:
I agree. Steve Ricke's sequence of events only relates to item 1 and how the memory card may have been reset. I thought it might shed some light on the subject.
Ian
* To:
* Subject: RE: Memory card checksum errors (was: 2000 November Election)
* From: "Ken Clark"
* Date: Thu, 18 Jan 2001 14:13:46 -0600
* Importance: Normal
* In-reply-to: <3A6746D4.6D7B0E4B@gesn.com>
From: owner-support@gesn.com [mailto:owner-support@gesn.com]On Behalf Of Guy Lancaster
Sent: Thursday, January 18, 2001 1:41 PM
Now to Lana's questions. The above should answer everything other than why erroneous data managed to upload. I see two possible explanations. One is that the data was corrupted after the checksums were validated. In this case the errors would show the next time the checksums were checked. The other possibility is the [60k to 1] chance that the erroneous data managed to add up to the correct checksum.
My understanding is that the card was not corrupt after (or before) upload. They fixed the problem by clearing the precinct and re-uploading the same card. So neither of these explainations washes. That's not to say I have any idea what actually happened, its just not either of those.
So John, can you satisfy Lana's request from this? I can't without more details.
The problem is its going to be very hard to collect enough data to really know what happened. The card isn't corrupt so we can't post-mortem it (its not mort). Guy if you can get the exact counter numbers that were uploaded into the races (not just president) perhaps you could guess the nature of the corruption at least, but if I had to bet the numbers were just garbage and you won't be able to tell.
About the only constructive suggestion I have is to insert a line in the AV upload code to check that candvotes + undervotes = votefor*timescounted. If it happens, punt. That would have at least prevented the embarrassment of negative votes, which is really what this is all about. Then John can go to Lana and tell her it has never happened before and that it will never happen again.
Ken
* To:
* Subject: RE: Memory card checksum errors (was: 2000 November Election)
* From: "John McLaurin"
* Date: Thu, 18 Jan 2001 15:45:54 -0500
* Importance: Normal
* In-reply-to: <01d101c0818e$2218be80$3c03a8c0@obrien>
PS – this was not the same precinct causing both problems if my memory is correct – Sophie? Tab?
* To:
* Subject: Re: Memory card checksum errors (was: 2000 November Election)
* From: "Talbot Iredale"
* Date: Thu, 18 Jan 2001 13:31:04 -0800
* References:
John,
Here is all the information I have about the 'negative' counts.
1. Only the presidential totals were incorrect. All the other races the sum of the votes + under votes + blank votes = sum of ballots cast.
2. The problem precinct had two memcory cards uploaded. The second one is the one I believe caused the problem. They were uploaded on the same port approx. 1 hour apart. As far as I know there should only have been one memory card uploaded. I asked you to check this out when the problem first occured but have not heard back as to whether this is true.
3. When the precinct was cleared and re-uploaded (only one memory card as far as I know) everything was fine.
4. Given that we transfer data in ascii form not binary and given the way the data was 'invalid' the error could not have occured during transmission. Therefore the error could only occur in one of four ways:
1. Corrupt memory card. This is the most likely explaination for the problem but since I know nothing about the 'second' memory card I have no ability to confirm the probability of this.
2. Invalid read from good memory card. This is unlikely since the candidates results for the race are not all read at the same time and the corruption was limited to a single race. There is a possiblilty that a section of the memory card was bad but since I do not know anything more about the 'second' memory card I cannot validate this.
3. Corruption of memory, whether on the host or Accu-Vote. Again this is unlikely due to the localization of the problem to a single race.
4. Invalid memory card (i.e. one that should not have been uploaded). There is always the possiblity that the 'second memory card' or 'second upload' came from an un-authorised source.
If this problem is to be properly answered we need to determine where the 'second' memory card is or whether it even exists. I do know that there were two uploads from two different memory cards (copy 0 (master) and copy 3).
Tab
* To:
* Subject: RE: Memory card checksum errors (was: 2000 November Election)
* From: "John McLaurin"
* Date: Thu, 18 Jan 2001 16:56:06 -0500
* Importance: Normal
* In-reply-to: <011801c08195$f6781930$1404a8c0@gesn.com>
Tab,
I will be visiting with Lana on Monday and will ascertain the particulars related to the second memory card. One concern I’ve had all along is “if” we are getting the full story from Lana.
I’ll be back in touch and thanks for all of y’alls (that’s southern for all of you) help.
John
* To:
* Subject: RE: Memory card checksum errors Seminole Cty.
* From: "John McLaurin"
* Date: Thu, 18 Jan 2001 18:08:28 -0500
* Importance: Normal
* In-reply-to:
John Haranzo of Seminole reports that the unit Ian has in hand had two memory card failures during the recount of one precinct. (Mickey Martin was operating the unit which may explain everything) The third downloaded card was successful at completing the count at which point they shelved the unit. Because this seems site specific to the ration of card failures 7 in 130 precincts and in general we had few across Florida and Georgia. Could the AV download unit cabled to the Host be problematic and if so should that be sent to McKinney for testing.
John
* To:
* Subject: RE: Memory card checksum errors Seminole Cty.
* From: "Ian S. Piper"
* Date: Thu, 18 Jan 2001 17:14:31 -0600
* Importance: Normal
* In-reply-to:
I believe that Steve Ricke has already made that request to John Haranzo.
Ian
* To:
* Subject: Re: Memory card checksum errors Seminole Cty.
* From: "Steve Knecht"
* Date: Thu, 18 Jan 2001 17:41:08 -0800
* References:
The Marin unit cabled to their main computer was the culprit of a majority of their failures as well. I just assumed the AV unit was bad and we sent it back to McKinney. Could it have something to do with a signal coming in from the DigiBoard or some voltage associated with a signal??
* To:
* Subject: RE: Memory card checksum errors Seminole Cty.
* From: "John McLaurin"
* Date: Fri, 19 Jan 2001 09:36:23 -0500
* Importance: Normal
* In-reply-to: <003601c081b8$e66c59c0$72d8fc9e@default>
In Marin, did it sporadically corrupt cards?
* To:
* Subject: Re: Memory card checksum errors Seminole Cty.
* From: "Steve Knecht"
* Date: Fri, 19 Jan 2001 07:08:04 -0800
* References:
Yes. During the primary in March, there were times on uploads where they would recount a precinct using a feeder in one room on a memory card, bring it to the computer room for upload - and it would corrupt when they brought it in (about 7 precincts I believe) and inserted it into the machine connected to the computer - on one precinct 3 times.
* To: support@gesn.com
* Subject: Re: Memory card checksum errors Seminole Cty.
* From: Guy Lancaster
* Date: Fri, 19 Jan 2001 10:54:05 -0800
* Organization: Global Election Systems Inc.
* References:
Steve Knecht wrote:
> The Marin unit cabled to their main computer was the culprit of a majority of their failures as well. I just assumed the AV unit was bad and we sent it back to McKinney. Could it have something to do with a signal coming in from the DigiBoard or some voltage associated with a signal??
>
No, it would take a lightning strike or similar coming across the serial cable from the DigiBoard to corrupt the memory card. ;-)
However there are things that can go wrong inside an Accu-Vote that can cause it to corrupt memory cards and/or crash (ISR, lockup*, random jump to a different prompt, etc). Thus I recommend a procedure of recording such events and if any single machine experiences 2 or more occurances over the course of an election, it's grounds for requiring service. Don't worry about a single occurance on a machine unless there is other evidence to suggest problems with that machine.
* Note that there are 2 different types of lockup. The most common seems to be that the older scanner units would lockup during operation but the AV itself is working fine. Recent firmware (since 1.94p/1.94f<) will display an error message if you hold the NO button for more than 3 seconds while the AV is waiting for another ballot in a count mode. If this works, the AV is working and it's the scanner unit itself that has locked up. I don't believe that scanner lockups can affect the memory card. Ian, when do scanner lockups indicate a need for service?
Guy
* To:
* Subject: RE: Memory card checksum errors (was: 2000 November Election)
* From: "Ken Clark"
* Date: Thu, 18 Jan 2001 16:42:50 -0600
* Importance: Normal
* In-reply-to: <011801c08195$f6781930$1404a8c0@gesn.com>
From: owner-support@gesn.com [mailto:owner-support@gesn.com]On Behalf Of Talbot Iredale
Sent: Thursday, January 18, 2001 3:31 PM
Given that we transfer data in ascii form not binary and given the way the data was 'invalid' the error could not have occured during transmission. Therefore the error could only occur in one of four ways:
(2) Invalid read from good memory card. This is unlikely since the candidates results for the race are not all read at the same time and the corruption was limited to a single race. There is a possiblilty that a section of the memory card was bad but since I do not know anything more about the 'second' memory card I cannot validate this.
Not necessarily. We grab a pointer to the head of the candidate counters for a race and then keep that pointer as the base for the current race. If that base was bogus (pointing at code say) because of some hardware glitch, then we would just happily walk the race looking at garbage. Next race the pointer base is changed and everything is okay. Now, this is still all "unlikely", but then again this has never happened before.
(4) Invalid memory card (i.e. one that should not have been uploaded). There is always the possiblity that the 'second memory card' or 'second upload' came from an un-authorised source.
If this problem is to be properly answered we need to determine where the 'second' memory card is or whether it even exists.
Heh. Second shooter theory. All we need now is a grassy knoll.
Ken
Very interesting.
I tried the link and it doesn't work anymore (surprise surprise).
Posted by: Peter at September 22, 2003 11:50 AMWell - glad I snagged the text then.
Posted by: Marc Perkel at September 22, 2003 02:09 PMNeither the Bill of Rights nor the Constitution explicitly specify that a citizen's vote must be counted as an inalienable right. The commonsense of the Constitution presumes that everyone will interpret the right to vote as the right to have one's vote counted accurately and nonfraudulantly, but those in a fascist regime would not. The fascist regime would turn the counting of the votes over to one or more corporations who are friendly to the fascists. The corporations could install electronic voting machines in a large percentage of the counties nationwide. These electronic voting machines could leave no paper trail, thus eliminating the ability to recount or thoroughly audit the veracity of the election. The votes could be tabulated in a duplicate (or triplicate) set of books (where "set of books" is a metaphor for taming the highly-technical complexities of storing information abstractly in RAM or on magnetic disk in a computer in a von Neumann addressing-scheme; no paper copies of "the set of books" would exist).
One set of books is for the local poll-workers/election-judges at each precinct to spot-check and to investigate if fraud is suspected. The other set of books is for uploading to the central county-wide (or state-wide) tabulation. The two sets of books can be made to diverge 1) via full-fledged cracking (i.e., breaking and entering a computer) by a nefarious technocrat or 2) via manipulating by the corporation who manufactured the electronic voting machine and thus wrote its software in ways to be conveniently tamperable. Cooking the second set of books can occur from hundreds or thousands of miles away if the electronic voting machines are connected to the Internet (e.g., Ethernet to broadband) or to the publicly-switched telephone network (PSTN) (e.g., a modem). The vast majority of electronic voting machines are connected via modem to the PSTN or via Ethernet to the Internet, effectively nullifying any physical security put in place by the election judges in that precinct or in that county. Thus, cooking of the second set of books can occur without any physical access to the electronic voting machines. Indeed, unless a poll-worker/election-judge notices some LEDs blinking on the external communications lines (indicating that communications are occurring between the electronic voting machine and the world outside the precinct), the second set of books can be cooked without any election official knowing and without any voter knowing.
Specifically the general technique of cooking the second set of books in the electronic voting machine is to subtract off x votes in the second set of books from the person whom the fascists want to lose and add those x votes in the second set of books to the person whom the fascists want to win. Using this technique, the total number of votes cast remains the same, thus passing one category of fraud-detection check. The first set of books are left alone so that if suspicions are raised, everything looks fine. ELECTION JUDGE: "I wonder if something funny is going on. This is a traditionally heavily Democratic precinct. Oh, the vote is 81% Democratic and 18% Republican and 1% other, which is about what it was last election. Okay, nothing wrong here." The problem is 1) that that election judge checked the first set of untampered books and 2) that the second set of cooked books is what is officially reported *automatically* *without* *human* *observation* via modem or via Internet to the county. In our example here, what really was officially reported in the second cooked set of books was: 39% Democratic, 60% Republican, and 1% other. These fraudulant vote tabulations for that precinct are what are recorded officially by the Secretary of State and officially presented for history to judge; the original votes in the first set of books are erased shortly after the election, never to be witnessed again.
This example tampering of only one precinct discussed in this posting was enough to throw this example election to the person who (according the first reality-based set of books) received less votes. If one precinct is not enough in a close election, then repeat as many times as is necessary on other electronic voting machines in other precincts to achieve the intended election outcome.
There are other ways of manipulating the vote, such as the ways described in the Grand Theft America video at http://www.bushflash.com/gta.html
Posted by: http://www.bushflash.com/gta.html at September 26, 2003 08:02 AMI searched google for
site:www.sunrise.it "checksum errors"
and
site:www.sunrise.it ~vote
Google turned out to have
1) archived versions of a couple of the posts in the thread (not all of them, strangely),
2) a thread listing which has the titles of all of the above posts,
3) a description page of of the email lists. It says "The lists are closed to Diebold Election Systems staff. Do not CC customers when posting to the lists, or forward messages from the lists to customers without permission."
The error rate and the "second card" issues are scary.
Check out the following archived news article:
Memory Card Blamed In Seminole County
Every Ballot Being Recounted By Hand
http://www.ibsys.com/sh/election2000/florida/stories/election200-florida-20001109-112839.html
Debra A. Scott, Staff Writer
November 9, 2000, 7:22 p.m. EST
ALTAMONTE SPRINGS, Fla. -- Minor mathematical errors have caused the canvassing board of Seminole County to recount by hand every one of 137,350 ballots cast on Tuesday.
Seminole County election personnel spent all night Wednesday recounting ballots.
Mathematical mistakes were found in 52 of the county's 133 precincts.
At first, the county decided to recount only the ballots with discrepancies, but representatives of the Republican and Democratic party objected.
In one precinct, there were 1,350 available voters and 986 votes were cast. However an election worker wrote that more than 3,000 ballots were used.
"It was a long day and at the end of the day it was just a matter of not properly filling out the bottom of the ballot accounting form," Seminole County election supervisor Sandy Gordon said.
Another problem popped up Thursday that could affect the vote tally.
Gordon said that there may be a vote difference in one precinct because of a faulty computer memory card that corrupted before they were able to feed all the ballots through the system.
One worker said that the discrepancy could amount to a 30 vote difference.
from
NewsMax.com archives, a story dated Friday, Nov. 10, 2000
"In Seminole County, Supervisor of Elections Sandy Goard said a problem had been identified in one precinct in which a computer memory card may have failed before all the ballots were counted. She said they are taking extra care in recounting the votes from that precinct."
http://www.newsmax.com/archives/articles/2000/11/9/221910.shtml
Looks like this "negative vote" thing wasn't entered into the final tallies.
So, I think what this internal discussion shows is that these computerized voting machines are scary (what if they couldn't go back and hand count, especially) and that the company running things is cavalier (suggesting a half-assed fix "That would have at least prevented the embarrassment of negative votes, which is really what this is all about."). But it doesn't look like there's evidence ultimately of vote fixing. Evidence that these companies are scary? Yes.
Posted by: N at September 28, 2003 09:21 PMTWO MEMORY CARDS
This is the thing that sticks as a problem here, of course.
Posted by: N at September 28, 2003 09:37 PM