Black Box Voting:Second Volley /Truth About Rob-Georgia/Thread 2

FOLKS... The other threads getting way to big to navigate even with my broadband connection so please allow me to start a new one with the same subject: Here's the old one....
http://www.democraticunderground.com/discuss/duboard.php?az=show_mesg&forum=104&topic_id=12577&mesg_id=12577&page=

the interview -- because that thread got into a lot of side topics:

1) Rob was told BY DIEBOLD to apply uncertified patches and was told BY DIEBOLD to pull them off an ftp site. He was also told BY DIEBOLD not to tell the state voting machine examiner, Dr. Brit Williams, that he was applying patches.

"... "If you would have realized the scolding I got for actually speaking to Brit. The whole quality control issue, I kept having to remind them, I'm the one that pointed this out -- we want this to be right..."

I'm going to pull out a few more of these. There is some really important stuff in that interview that we should be discussing.

Bev

On edit -- more:

"You know one of the main things that really just made me so upset, they were just like, 'This Brit guy, don't even speak to him, it's a political game, you've gotta play the politics.' Well, he walks in and says 'What are you guys doing?'

I said, 'We're putting in an update.' He said, 'Will it change what it does?' We said, 'Just do your normal test, we're supposed to get the machines ready for you.'

He tells someone at the office and they freaked out. They were like, 'What the heck are you doing???'

"I wasn't supposed to talk to him at all, I guess. The guy had a flannel shirt on, he was kicking it and he was very genuine and open and there we are in the same room together, but because I actually spoke to him I got reprimanded. They said, 'If they ask you any question, you gotta say 'Talk to Norma, to one of us.''

... getting more...

Harris: "Who are some of the names working in that office?"
Behler: "Norma Lyons and Wes Craven -- they're from Diebold.."

Another important point in this article is that, after Dr. Brit Williams, the official state certifier, who in on the board that CHOOSES the national certifiers for all voting machines nationwide, found out that they were yanking unexamined, untested patches off an FTP site and putting them on all the machines, he went along with it.

"Behler: I go back to the office. Brit was there, and he says 'What's it look like for Fulton?'

I said 'There's no way were going to able to get to Fulton County by Thursday.' I said we could probably be out there by Friday or Saturday. He said 'There's no way we can do it at the same time, you know that.' "

Also, Dr. Williams was literally working alongside Rob at times, while Rob was installing patches, and knowing that Rob was installing patches.

Another important point: This goes all the way to the top

"Behler: 'Finally, I raised it as high as you go, I raised it to Bob Urosevich, he's the head of it. I told him personally, 'This is bad, I don't see us putting an election on with these machines!'

..."This is an example we did: We would plug it in, boot it 3 times, unplug it, boot it three more times. I wrote a sheet on this. This guy came in from McKinney, he was about the second in command. He's a good friend of Bob Urosevich. About second to Bob, at least now, he got a promotion. Greg? Something like that. He flew in and I went to Dekalb and I tested and together we went through, and we wrote down every single error, and he booted them himself, and was looking at the results and seeing how sporadic they were. and we found out of the machines we tested, about 75% of the machines had different sporadic things. He was working with me and we were writing them down, we literally wrote everything down."

Harris: "Do you have a copy of that?"

Behler: "I don't think I have it. I have some email. I'd have to look. I know we came back and he copied it and he -- Greg Lowe (spelling?) is his name. I drove him out there. Brit was there, KSU was doing their testing. They were bombing these machines out left and right."

and

Harris: "When I asked Diebold if there was anyone named Rob in Georgia, they said no. Did they know about you?"

Behler: "They knew me and they knew me well. I met Bob Urosevich a couple different times, and Ian, and then Greg Lowe, he got promoted ...he was basically Bob's right hand man."

....

Good Lord, THIS IS WORSE THAN I THOUGHT!!! (Just kiddin' Bev. Keep up the good work.)

or a halleluyah chorus?

If I understood the previously jumbled explanation, these could be MS Windows CE service packs.

I noticed you wrote "pull them off an ftp site"

Whose site was it?

>>If I understood the previously jumbled explanation, these could be MS Windows CE service packs.

And they could have been emails from outer space. What is your point?

At that point in time, they should not have been making ANY changes of any kind.

The GA regulations clearly state that re-certification isn't necessary for improvements to the machines, much less vendor supplied upgrades to the operating system.

The proposed scenario has now gone beyond Diebold - the state's certifier is acccused of being part of the conspiracy. At some point, somebody's got to question whether this "investigation" is trying to justify its own existence.

So again I ask ... was it an MS service pack and whose ftp server did it come from?

Sheesh. PC support specialists (no not the dude at the PC shop, but people who's full time job is to maintain PC software/OS in a big company) will only apply a MS patch if there are no other options, because virtually every patch creates new problems. In a voting system it would be ludicrous to allow any changes right before an election becaise you could not do serious testing to be sure the patch didn't screw some other part of the system.

"if there are no other options"

As described in the report - there were no other options.

But there is an option, the clear option. Do nothing. Stick with the system as configured and tested. The point of the testing is to test a particular configuration. You simply don't mess with the configuration after that. If you're worried about security, never engage the modems, have the precincts call in the voting tallies. Surely they have a backup plan like that? It would be gross negligence to not have a backup plan, wouldn't it? I think so, and I'll bet any seasoned software programmer would agree.

BTW - I'm not saying that their testing was sufficient -- I'm not in a position to know.

and they wouldn't have had a voting system if they hadn't applied what I assume at this point are service packs - which are signed.

Once the problem was isolated to the operating system, I'm not surprised what happened ... and according to the ilnk I've posted elsewhere in this thread, conforming with the process.

They have 2 choices:

1) Don't apply the patches in which case the system won't work

2) Apply the patches, know that they can't be tested, and knowingly send out machines which weren't certifiably tested.

It's quite clear that there was a significant flaw in the design of this product. Neither of these options is acceptable. No chance.

the code was fine but the operating system had an error in one of its hooks - often a reason for service packs, which as I noted, are signed by MS.

If the timeline is as Bev Harris described it, nobody did anything wrong: the machines were upgraded before the state certification.

The state certifies the voting machine prior to it being delivered to the state warehouse. What Bev is describing is acceptance testing. State certification is like military Qualification testing. You get certified prior to selling a single product. What Brit was doing was acceptance testing which is a receiving test of a qualified product. So if a single bit was flipped from the certified version to the delivered version, the certification is void. Whether or not the code change affects even a pixel on the screen color, the proper review would have to be taken. Sure, Brit could rule that the change was too minor or unnecessary to retest the qual but I never read that he had a chance to review the change and make an official ruling and then have Cox at the state sign off as well.

Going to bed, will read more tomorrow.
JNC

I simply doesn't matter if MS signed a patch or not. It's the MS patches usually cause other problems!! You simply don't change a single byte of information on the "certified" system, *particularly* one a crappy as MS, *particularly* when the patch comes from MS!

In this case, it looks as though their test suite wasn't sufficient to catch the clock problem in the MS OS. But, who in the world could design a test suite for the MS OS? I postulate that's a near impossible task.

You can't build a rock solid house (the application) on a mushy foundation (the OS)!
--
On edit -- added the house analogy and corrected a typo

What Pobeka said is very true:

PC support specialists (no not the dude at the PC shop, but people who's full time job is to maintain PC software/OS in a big company) will only apply a MS patch if there are no other options, because virtually every patch creates new problems.

... actually being installed. Can't seem to find any MS-CE service packs. So if they were upgrading CE then is would be an entire OS upgrade. Testing is needed.

Of course if custom application software is being downloaded, then recertification is absolutely required.

http://www.microsoft.com/windows/Embedded/ce.net/downloads/updates/default.asp

QFE is a Microsoft term for the delivery of individual service updates to certain products. Occasionally, these QFEs may be collected into a service pack, which is more convenient to download and install than individual QFEs.

You know, latest fixes and security patches for the CE/Pocket PC 2002 OS. The Windows CE Platform Builder is for building CE applications. (Sorry but recertification is required!) No OS upgrades found in your link. No cigar. Anyway, thanks for looking.

I guess I'm still doomed searching for a CE service patch for my Pocket PC 2002 equipped PDA. I might be able to get the PDA manufacturer to support upgrading my PDA to PocketPC 2003. Hopefully there is no hardware incompatibility.

Mo' on Platform Builder for our other CE researchers ...
http://www.microsoft.com/windows/embedded/ce.net/previous/evaluation/tools/overview/default.asp

BTW: I don't have any .NET applications yet running on my PDA.

Dr. Williams' own document dated April 2003 says that they will maintain security by not applying Windows patches.
(of course, ignoring the fact that sometimes the patches are critical for security...)

http://www.votescount.com/georgia.pdf

Is what Williams wrote.

from this media backgrounder

http://www.georgiacounts.com/media_backgrounder4.pdf

State Certification:Following NASED certification units then must pass state certification tests. Dr. Britt Williams of Kennesaw State University's (KSU) Computer Science department, who is a nationally recognized expert on election systems, serves as the state's consultant and performs all testing. The state testing examines both hardware and software for accuracy and reliability, and mock elections are conducted on the equipment, witnessed by county election officials.

and from the "lies.htm"

"Him and I were scheduling this, figuring it out how to get to these machines and do the update before KSU has to test them"

And rob-Georgia also covered that in his interview, as I recall. The particular testing referred to was to punch in a vote once the machine was installed. That's NOT the same thing as the GA certification process. I don't offhand know if L&A testing was included in the official certification process or not, but I can assure you that even if it is, L&A testing was NOT all there was required for certification.

Eloriel

and once again, turned to a source Bev Harris didn't provide. I furnished the link.

No, the stages are as described. If you understand what I posted, there is no "story."

... if, as in previous post, 3rd party properiety software is being downloaded to the touchscreens at inappropriate intervals in the certification and election stages of system use.

I live in Georgia. I was the one who first found Brit Williams' docs on the internet.

Eloriel

I've shown where Dr Williams' statement is consistent with the published protocol. But I had to do my own search to find it.

He's been called a liar, but apparently he's not. You may live in Georgia but I think you've done us all a disservice.

and that should be more than obvious to the casual reader.

It is clear to ANYone who can comprehend standard, everyday, 5th grade English that the "test" purportedly done by Brit Williams in the rob-Georgia interview was conducted once all the machines arrived and were set up -- in some cases mere days before the election.

This is NOT the sum total of what the Georgia certification protocols calll for. In fact, it's patently ridiculous and defies the common sense rule for someone to imagine, as you have, that running a few votes through a few (or even all) machines just days prior to a major national election is sufficient for certification.

That you DO imagine just that scenario demonstrates that you are totally unfamiliar with Georgia's certification requirements. And your posts demonstrate that you don't particularly care; it's sufficient for your purposes to muddy the waters with distortions, mischaracterizations, obfuscations, distractions and some of the wildest logical faults and failures I've seen in a while.

So, WHO'S doing the disservice?

Eloriel

And according to the Scoop report, the machines were upgraded before after national certification and before Williams did his part: the state certification. This is exactly what Dr Williams wrote.

the machines were upgraded before after national certification and before Williams did his part: the state certification. This is exactly what Dr Williams wrote.

Well, your incoherence in that post aside, no, you're still suggesting that the L&A test once the machines are put together onsite IS the state "certification," and that's just not the case.

Eloriel

There's the national certification, the state certification, then there's the L&A test. It's not yet clear, but it appears that Dr Williams could be telling the truth when he says that the machines at the warehouse were repaired before the state certification.

Is there any certfication issue when 'software' is immediately downloaded after an election?

Your flippant attitude is grating on my nerves. But, then again, your abrasive tone is likely helping to bring folks into the debate opposite of your position. If there is anything that DUers are good at doing, it's seeing through con-games...

I suggest that you answer the questions instead of trying to do everything you can to avoid answering the questions, Fredda.

I would love to upgrade my PDA's CE 2002 to the latest service pack. If you have a link to Microsoft where I can get the service pack I would be mighty grateful. Can't find a CE service pack otherthan if I was running SQL Server on it.

http://support.microsoft.com/default.aspx?scid=fh;EN-US;sp

 

... touche.

Kinda like the Prime Minister's Questions sessions in the House of Commons.

You find those CE service packs yet? :shrug: :evilgrin:

1984 and before:

1982: Elkhart, Indiana, program failed in midstream, programmer rebooted or patched the system on the fly during the election process. (S 10 3:8); more in (S 10 4)

S Election frauds, lawsuits, spaghetti code, same memory locations used for multiple races simultaneously, undocumented GOTOs, COBOL ALTER verb allowing self-modifying code, calls to undocumented/unknown subroutines, bypassable audit trails (S 11 3); Report from the Computerized Voting Symposium, August 1986 (S 11 5)

h Clerical error blamed for election computer program mishap (S 11 5)

SHrf System designs, bad software engineering, standards (Eva Waskell, S 11 3)

Sh Texas beefs up security of computerized voting (S 12 1)

..... 1988 U.S. election events:

..... 1992 U.S. election events:

hf Oregon computer error reversed election results (S 18 1:16)

hf Programming error reverses DistAtty election landslide in Oregon (S 18 1:16)


..... 2000 U.S. election events:

f$ Also in 2000, Pennsylvania county wins $1M for faulty MicroVote computer voting machines (R 21 10)

..... 2001 U.S. election events:

f Programming error scrambles San Bernadino election results (S 27 1:15, R 21 74)

VSm Implications of power outage during Nov 2001 Pennsylvania election (R 21 80)

h Election problems before the election in Virginia result from 2000 census redistricting; electronic rolls lost 18,000 voters (S 27 1:17, R 21 74)

..... 2002 U.S. election events:

h Compton California Mayoral election screwup from lack of randomization of candidate ordering (S 27 3:16, R 21 91)


SAf Palm Beach's new electronic voting machines have problems (S 27 6:15, R 22 16) and more on lack of accountability (S 27 6:16, R 22 17)

fmiSP(HI?) Florida Primary 2002 problems: touchscreen machines not working, showing the wrong candidate, or nonworking authorization cards; some huge voter delays, Governor authorized two-hour extensions although some already shut-down machines could not be restarted; lame testing; purchase contract makes it a felony violation if any devices provided for internal examination; serious reliability problems reported in Georgia and Maryland; comments from the Georgia Secretary of State (R 22 25); comments from Mercuri on MIT/Caltech press release (R 22 26);

fmiSP(HI?) U.S. general election 2002: Glitches widely reported in FL, TX, AL, NV, GA, CA, SC, NE, NJ; Voter News Service outage (R 22 38); iVotronic machines lose 294 votes in Wake County NC (R 22 33); 2-3 hour waits in Florida early voting result from voter anticipation of election day problems! (R 22 34); factual errors reported in CNN article, particularly regarding use of old FEC standards, not new, and still voluntary; other errors (R 22 36); in FL Palm Beach and Broward counties and Georgia, voters found touch-screen machines that showed votes for untouched candidates; Broward programming error omitted 34,000 votes; 70,000 absentee and Spanish-language ballots missing from turnout but (supposedly) included in counts; Houston voters in 5 precincts had straight-party votes rejected; half of the Pulaski County AK had not been assigned precincts after redistricting, were not allowed to vote; NE long-shot candidate was given a premarked ballot for his opponent (R 22 36); more on exit polls (R 22 35,37); Broward County vote total short by 104,000 votes (R 22 36-37); 67 memory cards misplaced in Georgia, representing 2,180 ballots (R 22 37); "The right to have the vote counted is infringed, and we have lost the integrity of our voting system, when the ease with which ballots can be manipulated is greater than the ease with which the manipulation can be detected." (Kevin Craig, 2000) www.electionguardians.org (R 22 37); chip glitch hands victory to wrong candidate in Nebraska (R 22 38); Voters can report election irregularities at VoteWatch.us (R 22 38); problem in White Plains NY with sticking lever machine (R 22 44); vote only by mail in Oregon (R 22 35)

Sm?f?H? 2002 unofficial election results in Alabama reversed, cause still unexplained: electronic results wrong, hardcopy results correct (R 22 60-61, S 28 3:10)

fiSP(HI?) Columns by Lynn Landes on questionable ownership of voting machine companies (felons, etc.), also citing VoteScam, 1992 book by James and Kenneth Collier; interactive modems capable of controlling voting machines in real-time (R 22 25,37-38); ideal voting systems? (R 22 34); further discussion of the Mercuri Method, alternatives, and butterfly ballots again, and other discussions (R 22 27-31,38)

SH? Diebold AccuVote system integrity questioned in Georgia because of the use of an unprotected FTP site for storing election software, election results files, upgrade files, etc. (for example, see The Register, 8 Feb 2003; surprising Max Cleland defeat linked?

SPH Powervote electronic vote machines open to tampering: bogus ballot face (R 22 44)

*m Explosion of nickel-cadmium batteries used in electronic voting (R 22 28)

..... Other election items in the U.S.:

m Computer miscounts StarWars (Strategic Defense Initiative) vote in the House of Representatives (358 ayes & 237 nays, which adds up to much more than 435!!!) (S 13 3)

*h Computer data-entry error in vote tallying (2828, not 28) (S 13 4)

f/h? 8 Durham NC precincts had correct totals counted twice (S 15 1)

f/h? Virginia governor's race also had totals counted twice (S 15 1)

h Undeleted leftover test data reverses Yonkers NY election results (S 15 1:12)

rf Manual districts required live fudging of Michigan election system (S 15 1)

fh Other risks in unaccountable computerized elections (S 19 1:6)

m CMU elections suspended because roster database system was down (S 19 2:8)

SH Cat registered as voter to show risks (no pawtograph required) (S 20 1:16)

m Static electricity affects ballot counting (S 22 1:18)

VSH San Jose State voting computer crashes, "fixed". (S 18 1:18)

m Computer disk crash gives ballots with 2 candidates omitted (S 20 1:17)

hfm 1995 San Francisco elections (S 21 2:19)

mfie Problems in Montgomery County election, 7 Nov 1995: anti-moisture spray effects, delays, bad operator initialization, phantom votes (R 17 50,56)

h Risks of global editing in voting context: name `Pollack' changed to `Turnoutack' (S 14 5)

$f Votes lost in Toronto (S 14 1, 14 5); Toronto district finally abandons computerized voting; year-old race still unresolved (S 15 2)

SHm SQL Slammer DDoS attack disrupted the 25 Jan 2003 NDP leadership convention voting in Toronto (election.com) (R 22 59)

h Read-ahead synchronization glitch and/or eager operator causes large data entry error, giving wrong winner in Rome Italy city election (S 15 1)

fm DB and WWW on one machine mess up 2001 Australian Capital Territory election (S 27 1:15, R 21 71-72); see earlier anticipation (R 21 67)

f/h/H? Computer error in Cape Town election affects results (R 18 17)

f Swedish election results delayed by computer errors, 140% returns (S 17 1)

$h Mis-set parameter invalidates Oslo parliamentary election (S 19 1:5)

SAfe Electronic voting systems: more on system integrity and accountability (R 22 66); New South Wales forced to hand-count poll result after inadequately tested computer upgrade (R 22 69); crash of Will County, Illinois, Web site for tallying and publishing election results after being deluged with bogus requests (R 22 69)

S Injured technician's inability to provide the password delays vote count in Mali (S 27 3:18, R 22 05)

hi Brazilian computer blocked twins, like-named siblings from voting (S 12 1) (This problem may still have existed in 1994, unless new report was old.) (R 16 45)

fe Voting machine inflexibility causes postponement of Brazil's standard time cutover from daylight time because law requires 8 to 5 voting (R 22 33); Brazil modified 3% of their machines to use the Mercuri Method (R 22 24) - see article in November 2002 IEEE Spectrum.

why no link?

http://www.csl.sri.com/users/neumann/illustrative.html#24

I didn't include it originally because it's a listing of computer problems in general and even in the section about voting problems many of them aren't necessarily computer problems but voting irregularities like chad, etc. I edited the list to try to reflect voting machine problems.

"IBM auto dashboard system can shoot water at drivers not answering questions properly"

i PC virtual-parrot squawks confuse firemen (S 26 6:10, R 21 46)

Thanks :evilgrin: :thumbsup: I love it.

So, here we have the guy (Rob) tasked with checking in and assembling the machines "hangin'" with Dr. Britian Williams (HEAD of security for the Georgia election) in his flannel shirt being told "we're installing patches" contrary to the policies and procedures HE HIMSELF has written and he did what?

How much longer until you're done with us?

Thanks.

and thought you were replying to me. upon a second glance at the thread tree i see your post was directed at someone else. i apologize for response.

but I thought the way message boards work is that sometimes we post threads and sometimes we respond to other people's threads. Like a two way street, give and take, etc.

?

I thought I was one of the "we" on this board and I'm certainly not ready for this topic to go away anytime soon. It also seems pretty much confined to one thread for now so I'm not sure what your beef is...bored with it? Then stay out of it.

Everyone knows Bev's web address by now, can the discussion continue there?

Maybe for the latecomers, Bev can buy an ad here at DU to direct people there.

If it pisses you off so much! How many forums are there on this site? Is this topic taking all of the space on those forums? Like I said, at this moment in time I see ONE thread on the GD front page dealing with this...the other one was locked because it got too long. This isn't your board...who the hell do you think you are?

:grr:

but I'm done now. I'll stay out of it. Just one last plea to wrap things up at some point before election 2004. Not asking as the owner of the board, just as one person here.

?????????:shrug: :wtf:

to a political discussion board. :wtf:

but this discussion isn't the only discussion.

There's also Rush Holt's bill, for example.

Sort GD by number of views, you may see where I'm coming from when I ask when enough is enough for any single topic.

it's what you might expect people would be interested in on a board that started as a result of the 2000 Florida debacle.

Vote counting fraud has had and, unless it's stopped, will continue to have disaterous consequences for the country and the world.

But if you don't want to participate in the conversation.....

I've managed to post quite a bit about sex and religion and God knows what else during all this black box voting stuff.

Maybe we should remove the DU Lounge from "our" board too?

Have a beer, think about the Hulk's wang, take a nap.

Wake up and fight again.

oh. you were kidding.

well i'm definitely not interested in talking about the hulk's wang (computer generated) then.

that goddamn thing does not exist in nature.

<looks in pants>

Heh,

You think I'm joking, until you realize how many of those hotshot California computer nerds are unemployed...

Just how many California counties are using these insecure voting systems, eh?

Maybe MoPaul can make a campaign poster for the Hulk's Wang!

Enquiring minds want to know:

Who's got the bigger Wang?

Arnold or the Hulk?

( The bad news is that this is not a joke... )

... election cycle, of which Davis' recall will be the main event.

The political battlefields in California are going to be very bloody after this, and Darrell Issa will be wishing he'd spent his money on something else.

BTW, touch screen voting machines are the lead editorial in the San Jose Mercury News this Friday morning.

Mercury News Editorial:
"Touch-screen machines need verification system"

http://www.bayarea.com/mld/mercurynews/news/opinion/6280225.htm

...that which they wish to view? :shrug:

Could it possibly be that most people are interested in this? :wow:

Its only one discussion thread ...

:nopity:

I'm noticing the high read counts and performance does seem much slower than right after July 7th.

I think there was a software problem. I tried to post a relatively short reply. Got a message about "no memory" (I think it was) and after that all I could see was the initial post, not the response tree, nothing.

Some of the posts on these "black box" threads are so depressing... How about some positive suggestions, instead of all this chest thumping and mud slinging?

Let's see, I have a few...

If my job depended on "black box voting machines" I would not dig in and fight, I would run away and hope to find some honest work. Maybe wash dishes in a restaurant if I had to.

If the county I lived in used these black box voting machines I would be in my election official's office every day warning them that they must come up with some "plan B" for use when these machines are decertified, because these machines WILL be decertified if this American democracy is not dead. Paper ballots and hand counting are not a bad thing.

I would also try to convince my county election officials to impound a few of these machines and all the related documentation before Diebold and others come to destroy the evidence. (The shredders at Diebold and ES&S are probably running at full speed today... ) Remind your election officials that they will be respected and admired for protecting democracy.

This fire is lit, and it's not going to be extinguished.

Thanks for starting another thread trumad.

I thought I'd take advantage of this smaller thread to clear a few things up. I've posted numerous times on previous threads, often disputing things that Bev and the others have been saying. After getting accused of lying about my place of employment and who my friends are, I realized that an important fact has somehow gotten lost in the shuffle and that many of you now regard me as "the enemy". So let's get one thing clear:

I think the Diebold product sucks.

The dispute I have with people is primarily technical in nature as to why it sucks. Now this may seem like a nitpick, but when you start posting on really technical places like slashdot its important to get all you ducks in a row. I suppose at this point perhaps its too late, but things seem to be going ok so I'm not going to worry about it anymore. I'm just going to write this post and answer any questions resulting from it and let things be. So on to my grip about Diebold.

The Diebold product sucks because it has a single, fundamental design flaw: it relies heavily upon the notion that access to the machine can be controlled. As Bev has demonstrated, the votes are stored in database files without any type of encryption or digital signatures. As a result, any person who gains access to the machine, remotely or otherwise, can alter totals to their hearts content. This is a fundamental and completely unnecessary aspect of the design.

Consider an ATM machine. Having physical access to an ATM machine does a potential thief absolutely no good. Heck, even if a thief were to physically steal the entire machine, all s/he would get is whatever money is stored in the machine. Even though all the hardware and software for connecting to the bank's network and making transactions is present in the machine, possession of all that knowledge is still not sufficient for a thief to actually make any transactions. The reason this is true is because the machine was designed to work that way. The banks knew that if a person could hack into their financial network simply by learning how ATM machines work, they would be screwed. There is simply no way that you can insure that every person who worked on the design of the machines is honest, and no way of guaranteeing that someone couldn't steal a single machine and then reverse engineer it. As a result they chose to design a machine in such a way that perfect knowledge of it operating procedures buys you nothing. The fundamental idea involved in this decision is a now well held principle that security through obscurity (i.e. making the knowledge of how things work hidden or confusing) doesn't work. This is the flawed principle that Diebold embraced with relish.

You see, its perfectly possible to design a voting machine exactly like an ATM machine (one that would produce, just like an ATM, a paper receipt as an audit trail). You could make it work in such a way that gain access to the machine buys you nothing. Sure, a thief could steal the machine and take with him/her all the votes inside, but that doesn't really do any good because everyone would know that the machine was missing--it would be just like stealing a ballot box full of paper ballots. Sure, its a setback because you have to re-run the election, but its not an unrecoverable tragedy.

Perhaps now you can understand why I have chimed in on the "wrong" side of few comments by fredda and scottxyz. In the end, all the discussions surrounding whether modems can be made outgoing only or whether or not Access is a robust database are irrelevant. Yes, modems can be made outgoing only--but that will not protect you from the fundamental flaw of the Diebold product. Yes, Access sucks as a database, but converting it to Oracle or any other more robust RDB would not help either. The fundamental problem with the Diebold product is in its architecture, not its choice of hardware or third party software.

BTW, I also have numerous problems with Diebold process, e.g., putting untested patches on at the last minute.

irrelevant. even some of the things that are fascinating to me personally and i want to know about. that's why level-headed discussions of the issue re: activism:

http://www.verifiedvoting.org/help.asp

and the grasp of simple concepts like:

"Without a voter-verifiable audit trail, it is not practical to provide reasonable assurance of the integrity of these voting systems by any combination of design review, inspection, testing, logical analysis, or control of the system development process."

are extremely important.

seems like most of the press being generated and the discussion that seems to go nowhere is stuck in the design review and inspection mode, which in my opinion, only adds fuel to the fire for conservatives who want to dismiss the issue as a conspiracy theory.

I want to repeat that I am not disparaging or deameaning the people who are working hard to learn more. I am simply stating my opinion about what i think is a positive approach and what isn't.

I made one post that asked Fredda to shut up and that was a mistake.... In hindsight, Fredda's simply asking questions that other folks will ask as well. If her questions can't be answered and either proven right or wrong then the whole BlackBox thing will fall apart. "Intellegent" dissent is good for the cause....

So keep asking those questions Fredda and I hope both sides of this issue learn from the give and take.

... IMHO!

While I may have devoted a great deal of energy to picking apart Fredda's arguments, I do welcome them, in that they function as a sort of "devil's advocate" and they may anticipate arguments that others may bring up once this story gets out.

For that reason, I do not favor even deleting posts on this thread, because it is always valuable to know what sort of arguments people might bring up.

I feel that in my two main posts so far I have laid out ample technical arguments as to why this GEMS Access database is not something any respectable manager would buy for a company, nor would a polling staffer buy it for vote-tallying work.

Fredda has raised some points, and I think by and large they were captivating but not central. This doesn't mean that such points won't be raised by other people, so it might be said that Fredda is performing a valuable service by vetting the arguments presented here.

and may not be soluble with the much-touted voter verified paper trail w/ spot checks.

What the first article said was that the reporting architecture at the county level may be susceptible to fraud. And it may have been going on for some time. I think it's going to take a while for everyone to get their heads around the implications of this.

remind me please why this is so - if the computer spits a piece of paper out that the voter verifies and then places in a lockbox, how is that not auditable? If a manual recount takes place they can verify the paper trail against the electronic count. what am i missing?

also as a follow up to last night I received this auto-response today:

"Thanks for your note. I'm interested in what you have to say about
your inquiry but I can't read it right now.

Information on the DIAC-03 workshop can be found at
http://www.cpsr.org/program/sphere/diac-03. You can also
ask Fiorella de Cindio (fiorella.de.cindio@rcm.dico.unimi.it)
for information.

I'll be back in e-mail contact around August 1, 2003.
If you don't hear back from me soon after that please feel
free to send me a reminder.

-- Doug Schuler
Public Sphere Project
Computer Professionals for Social Responsibility"


********************************************************************
* SHAPING THE NETWORK SOCIETY *
* Patterns for Participation, Action, and Change *
* http://www.cpsr.org/program/sphere/patterns/ *
* Tomorrow's information and communication infrastructure *
* is being shaped today... *
* But by whom and to what ends? *
* Public Sphere Project (CPSR) http://www.cpsr.org/program/sphere *
********************************************************************
++++++++++++++++++++++

I'll keep looking around for some other like minded experts who might be able to give the research being done a look...

and reported 200 votes for Repub and 300 votes for Dem. Now this is put into GEMS CandidateCounter accurately. Later the SumCandidateCounter is changed to 300 votes for Repub and 200 votes for Dem. Further suppose that Repub now beats Dem by 100 votes.

A spot check the night of the election (and all detail reports come from CandidateCounter) shows the precinct as reporting accurately. The precinct numbers are then sealed and never reported to the candidates. (Believe it or not, Bev reports that this is happening in Washington state!)

Later, the numbers are moved from SumCandidateCounter to CandidateCounter. A new detail report is printed and it will add up to the summary results. (In Washington state, this is what the candidates get a week later!)

Unless someone takes the trouble to get the original precinct totals and compare it with the published detail report, the election is thrown. And if you could do this with paper ballots at the precinct level, you could do this with any voting system.

We now need the paper trail for touch screen units, a spot check, AND a way of recording exactly what each precinct reports the night of the election.

a further check on what's reported the night of the election would make things more secure, but your point above neglects the point that there would still be the paper ballots to go back to should the election be contested. Making it further safer still with an additional check is even better.

but both situations are the opposite of saying "there's no system that can be made secure ever" and then coming to the conclusion that the best way for people to spend their time is investigating the design and development stages of a test system that was used in a prior election, thinking if they can prove this one set of files is faulty from a security standpoint they're going to break the lid off a story of national importance (my post above demonstrates that even if this system is faulty it's only one instance in many). Unless of course the intention is to prove intent to commit fraud and bring down officials, which I think I recall reading it wasn't.

many, if not most, election laws prevent anyone from recounting the ballots. In the coming weeks and months we'll see how this applies to precinct totals.

The intent of all this is honest elections. What we are learning is that "eternal vigilance" is necessary and that computers at any level only increase the opportunity for fraud unless the system is open and watched like a hawk.

I remember I posted my vague suspicions about the vote totals and their trip from precinct to county level, a number of threads ago.

But, your explanation of what's actually happening in Washington state is much clearer -- as long as those precinct totals are sealed, anything could be happening. Jeez.

Ya know, here in Harris County, Texas, the newspaper has long printed the precinct totals for major races, like mayor or senator. BUT, they're printed a number of days after the election. Hmmmmm.

The type that lists (journals) all system-database activities like downloading patches, maintaining text screens, and system backups?

there is NO WAY to guarantee security.

Diebold STILL inching up. You mean NO word has gone out. No one is concerned? No one worries that their foreign markets will dry up, machines will be recalled, lawsuits will be offered, treason proven?

Interesting. This is another indicator of the slow take this story is getting. Diebold(DBD) stock on the DOW 45.18??

How about the other companies. Of course Diebold is much bigger than just voting machines but a skittish market seems way too ignorant considering opposition to this product.

Of course their stock continues to rise. The story hasn't made it mainstream yet (media is still locked in the Laci Peterson story). And that HAVA money certainly does help!!!

Of course we are now entering a sensitive period with insider knowledge. Anyone thinking to profit through 'put' trades on Diebold could be subjected to SEC investigation. All readers and posters beware.

because of a growing realization of the potential for fraud in electronic voting or knowledge that a book is coming out which should stimulate reassessment of the whole area is NOT subject to SEC Insider Trading rules. This is NOT insider information. Insider information is secret stuff, known ONLY to the corporate insiders who know something good or bad that others have no way of knowing.

That said, I find a real disconnect between the fact that DIEBOLD stock price has been inching upward while there is an ever-widening circle of people who are very concerned about the continuation of electronic voting and a widening smaller circle of people who are determined to try to stop it in its tracks. The market moves on rumors, especially rumors that are that widespread. Almost always by the time a piece of information becomes newsworthy enough to make the papers or get a mention on TV, the market has already moved and it is too late for an investor to make a profitable transaction.

So what IS moving DIEBOLD's stock price? Inquiring minds want to know. It has got to be businesses of the company other than voting hardware and software that are moving the stock.

"A modest proposal - from a programmer
How's this for a voting system: Carbon-paper ballots, in triplicate. Voter checks off their choices. White copy goes in the white bin (tallied by Republican-appointed polling officials). Pinnk copy goes in the pink bin (tallied by Democratic-appointed polling officials). "Goldenrod" or "canary" copy goes in the yellow bin (tallied by a UN-approved auditing company)"

HEY! That's MY idea. NCR paper. I wrote about it a couple of weeks ago on one of Bev's threads and have advocated it for more than a year. A little bit different from Scotty's, though. One copy to ballot box, one copy to voter, one copy to designated non-governmental trustee such as Riggs, Wells Fargo, UPS. Serially numbered ballots for each precinct. Publication of results by ballot number posted at each precinct for thirty days so voters can go look to make sure their vote was allocated properly.

In many states, the law requires that voters are not to receive any type of proof on how they voted. The reasoning behind this is that if they could prove to a thrid party how they voted, they could sell their vote and corrupt politicians could buy them.

if they put the receipt in a lockbox instead of taking it offsite, then it's the same as putting a paper ballot in a lockbox.

For optical scan ballots, there is only one copy so the voter will not take it out of the polling place or their vote will not count. If you have your vote counted on a DRE, what is the incentive to make sure your paper receipt goes in a box when there is a guy outside offering you $20 for proof that you voted for his candidate? It is an FEC guideline in the 1990 standards that the receipt can not leave the polling place. FEC 1990 standards were accepted by 37 states. These guidelines are in the 2002 standards so all 50 states must comply next year.

True, there is no way to guarantee security in a computer voting system. Nor is there a way to guarantee security in a optically scanned ballot system. Nor is there a way to guarantee security in a punch card system. Nor is there a way to guarantee security in a simple paper ballot. The bottom line is this: no system is totally secure--everything has flaws.

Given this fact, you must choose the type of system that is more secure than all the others. For me, that system is computer based. If we can make computers that handle trillions of dollars in bank transactions secure enough to place our trust in, we can make voting machines secure enough to place our trust in. Voter verified paper based audit trails are a key part of insuring this.

we can see everything, because there is accountability to consumers, to the bank regulators, to auditors, to the fdic, etc.

Here we have a system that appears to be accountable to no one. Once it is in place, there appears to be no further checking except surface testing thats done by the county clerk when it comes time to set up the machines for the next election. There are no outside observers of the function of the system. No "consumers" can verify that their votes were counted accurately. There are no statements sent out. There are no certified/bonded auditors looking at the system and its results comparing original ballots to produced reports. There is no hands on supervision.

IMHO, until there is a system that can do this while maintaining secrecy, it is not possible to have a computer system we will all feel comfy with.

However, what you have described is a failure of the current process, not a failure intrinsic to computer voting systems. Moreover, the process flaws you describe could just as easily apply to any type of voting systems, not just computer systems.

Remember, my post was in response to a person that claimed computer voting system were inherently flawed. I disputed this, claiming that a properly design computer system was no less secure than other systems. Given a computer voting system that provides a voter verified paper audit trail, I'm betting you cannot conceive of a method of rigging an election that would not also apply to normal paper ballot systems as well.

most people tend to drop their guard when computers are involved. If you're like me and use Quicken for your checkbook, when was the last time you hand reconciled your checkbook or credit card statement? You spot check some expenses and then take for granted the fact that computers can add.

If fraud is exposed, and I still think it's a long shot that any fraud will be uncovered (even if it did occur), it will be the blind faith we put into computers that will be the lead culprit.

Yes, it's a failure of the current process.

And yes, paper ballots can be messed with too. However. The difference in using computers as we do today and the way we use paper ballots is remarkable and, in part, the key to preventing fraud. If I understand correctly, this is what Bev is working hard to change.

For example, if ONE person printed the ballots, distributed the ballots, counted the ballots, produced the tally reports and, in the end, decided who won, would anyone trust the outcome? No...but this is exactly what we have in place in many parts of this country using a computer that produces the ballot, distributes the ballot, counts it and reports the answer.

Paper ballots, and I can only speak for my county which uses the scan ballots, are seen by numerous people before and on election day. They are distributed and collected by a group of poll workers who all have oversite on the process. They are placed in a special, locked ballot box in full view of everyone at the poll and carried to the county clerks office 25 miles away for counting. The ballots are under the protection of not one but at least two and often several poll workers and county employees. At the County Clerk's office, several people are in charge of scanning and verifying ballots. Even with this kind of oversite we can't ever be absolutely certain our election haven't been tampered with. But until this kind of oversite is in place for computers, we won't have system we can trust.

My point was, you can't do it with a computer alone.

It's unreasonable for us to just say, well, people can figure out how to steal votes and elections no matter what we do.

Yes, some dead people will probably vote in some election. Yes, some ballot boxes may be misplaced or stolen.

But, the crucial difference in using electronic voting vs. paper, for me, is that with paper, maybe only one precinct gets stolen. With electronic voting, a whole state can be stolen, perhaps with only one or a few people's actions. And, it's almost impossible to catch and impossible to figure out who did it -- thus, there is virtually NO potential for punishment -- and thus, the risk/reward ratio is almost irresistable for those tempted by ill-gotten power or money.

And, when two or three voting machine companies are operating in more than half the states, well, a handful of creeps can steal Congress and/or the Presidency. (And they need not be wearing robes next time!)

So, saying there will always be shenanigans around voting is like saying, hey, there will always be violence. But, the old-fashioned low tech violence, like with a single gun, is a lot easier to corral than a nuclear bomb.

I think electronic voting, as currently constructed, has the destructive potential of using a bomb on democracy. And, I don't like the looks of those who own the red button.

This is not your father's vote-tampering. With standard systems running everywhere and no paper ballots, vote-counts can be manipulated at every level of society, from a little tweaking of a few precincts that decides electoral totals to targetted payback against "enemies" to controlling local zoning boards - all done by one very small group of operatives.

Has it happened? Not that I can prove.
Could it happen? I think so.
Will it happen? It depends on what we do.

Read my post again. I proposed a computer based system with a voter verified paper audit trail.

That's the message I'm picking up from this part of the thread. The system will be fraud-proof only to the extent it is open and verifiable. But the more open it is, the less possible it becomes to have a truly secret ballot.

If that's the case, then no amount of redesign will make the system work, because you can't be a little bit private any more than you can be a little bit pregnant. Any setup with enough privacy to protect the individual vote will also have enough privacy to enable fraud.

Am I right or wrong about this? And if I'm wrong, why am I wrong and how do you design around it?

If a box of paper ballots turns up in the river then it's immediately obvious that something is wrong, and the crime can be investigated. If a few electronic bits in a computer memory are manipulated it's not so obvious that a crime has been committed, and it is much harder to investigate.

and some of them are equivalent to precinct totals and county totals, etc.

The point is that there has been a lot of thought in banking about how to prevent people from stealing money and that's why a lot of the internal controls have been put in. Also, the bank processes are audited by the bank, by the state, by the Feds, etc. and they are audited regularly and repeatedly. They even have auditors who audit their IT systems, programs, code, and security.

So, if one were worried about the possibility of someone wanting to steal votes, one would put internal controls in the processes, the equipment, the code, etc. And several different organizations would audit them. There would not be secrets about how everything worked nor would misleading information be accepted.

So, when we get serious about maintaining the integrity of the ballot and the counting of votes, we'll do the same for voting machines.

No system is perfect, whether electronic or manual, because of human temptations and corruption.

Banks and corporations have handled this by having independent auditors. There's a lot of money at stake, and the only way to get an approximation of fairness and transparency is via independent auditing.

The same thing should be done for voting. Paperless systems are pure fantasy; every time a company has tried to implement one, there's always been paper backups and auditing.

Voting is no different. Electronic or not, there needs to be a paper trail, and there needs to be independent auditing. Anyone can understand this.

Which is why what I was suggesting is a comptuer based system with a voter verified paper audit trail. Its the best of both worlds.

if you have a way of auditing the computer results, compare them with a paper receipt that is verified by the voter after they place their vote, then it doesn't matter if the computer system isn't secure. if it's wrong the paper takes precedence. the only motivation then for the proprietor to make it good is not to lose contracts over forcing too many expensive recounts due to instability or inaccuracy.

I submitted the tip and nothing. Why not, "Rumor has it Diebold may have fucked up US Elections. Click here."

Oh, would that piss off all the Fascists who hang out there. I forgot, it has to be something to make you angry without fully understanding the reasons.

:kick:

http://www.congress.org/congressorg/issues/alert/?alertid=2726156&content_dir=ua_congressorg

Someone posted the following over at Congress.org, and it has been viewed 619 times so far.

"Computer polling threatens democracy

Computerized voting stations were presented as the cure for the types of election day controversies that have plagued us in the past. Unfortunately, they've become the greatest threat to democracy itself.

These machines, which produce no paper trail, are programmed, maintained, and operated by private corporations. These companies, in turn, tell us the results.

Consider the recent victory of Republican Senator Chuck Hegel in Nebraska. All polls indicated that he would lose to the Democratic incumbent, yet he scored a massive victory, even taking districts that were strongly Democratic. His success seemed unexplainable until one journalist revealed that Chuck Hegel owned the company which had built the machines and counted 80% of the votes."

more...

also nobody seems interested that there are 4 more co-sponsors to Rush Holt's proposed legislation HR 2239 over at this thread

http://www.democraticunderground.com/discuss/duboard.php?az=show_topic&forum=104&topic_id=18630

anyone know how to keep current on the co-sponsors? I can't find anything using Google News, or Congress.org.

Believe it or not this poll says it is Zell Miller, shrub, and of course Ms. Voting Fraud herself, Cathy Cox. To help correct this poll a little I put my vote in for Mark Taylor being the most popular.

I'm not thrilled about W being in the top three, but Cox and Miller as the Democrats? Give me a break.

<http://www.billshipp.com/polls/2003/jul-14.shtml>

OK, this is ScottXYZ again, the Microsoft Access programmer who posted the long post last night explaining why MS-Access is never used for mission-critical applications, why the presence of unnecessary add-ins such as "TimeDateStamp Adjuster" is obviously suspicious, and pointing out that vote-totalling code doesn't need to be complicated or proprietary.

(That was post 278 in the old thread:

http://www.democraticunderground.com/discuss/duboard.php?az=show_topic&forum=104&topic_id=12577&mesg_id=12577&page=

which is now locked due to length.)

Thank you to those who found my comments helpful. I have specific replies to points raised by Junkdrawer, Fredda, German-Lefty, SDent, grasswire, and Cocoa.

I am replying at length because

(1) It would be irresponsible of me to make so many insistent claims without following up, and

(2) The issue of electronically-enabled voter fraud is extremely important, particularly given the increasingly plausible possibility that the current apparent 50/50 ideological split in this country may be in fact nothing more than an illusion made possible by various structural inefficiencies in our communication and decision-making systems exploited by a minority (corporate-financed campaigns and politicians, corporate-controlled one-way mass media, and corporate-controlled blackbox voting).


Cocoa
In fact, my point (2) above is my response to Cocoa who in post 26 in the current thread asked

"I ask when enough is enough for any single topic{?}"

I understand that you may have been getting tired with a techie discussion when other more overtly political questions are also very pressing right now. But I hope you agree how vital it is for the votes to be counted, Cocoa! Voting fraud is not some side issue here - it may very well be the thing which has been inexplicably skewing our county's politics for so long, causing the mysterious mismatch some are starting to notice between what the People want (liberal democracy) and what the Politicians have been giving us (creeping corporate fascism).

I also disagree with what Cocoa said in post 25 in this thread:

Everyone knows Bev's web address by now, can the discussion continue there?

Maybe for the latecomers, Bev can buy an ad here at DU to direct people there.

Democratic Underground, as well as the growing number of politically-oriented web logs or "blogs", may be helping the country finally break out of the political paralysis caused in large part by centralized "broadcast" media, which have recently come under more and more corporate control and further strangled our country's dialog. The fact that this voter-fraud thread has had several thousand views (which is now easy for us to verify with DU's new software) shows that people are really concerned about this potential case of voter fraud. I think it's important for this discussion about what Bev has discovered to spread all over the internet and then into the mainstream media as soon as possible, so it would not make sense to impose an artificial limit on how long this particular thread gets or how many people choose to view it. As I stated already, there are many people who are starting to suspect that the right wing is much smaller than it appears to be, and that it has maintained an illusion of strength by "gaming" structural weaknesses in our current communications and voting systems.

I thought this was obvious, but maybe some people aren't cynical enough to see it: It won't matter at all if we come up with strong candidates and positions on DU, if the voting systems and broadcast systems are rigged against us. That's how important I and many others feel this voting-fraud issue is, and Cocoa should not discourage this thread to continue. (I only got really involved with this thread because I have a lot of experience programming in Access and I thought it would be helpful to Bev and the others if I tried to provide some technical underpinning to their intuitions regarding this possible breaking scandal, which, as Bev stated, may turn out to be bigger than Watergate.)


Junkdrawer
What Junkdrawer said in post 285 at the old thread is absolutely shocking. I just know that Access is a insecure database never used for mission-critical programming - I had no idea the GEMS programmers actually went further and disabled the few (albeit admittedly hackable) built-in security features Access does provide:

1.) As much as possible, provide the APPEARANCE of a secure and auditable system.....

WHILE

2.) Provide copious opportunity to hack the database without leaving a trace.

From Bev's article (and previous posts on DU1) we know:

* They could have used database-enforced referential integrity - they did not.

* They could have used Autonumber primary keys - they did not.

* They could have cleared the summary report tables before each report - they did not.

* They could have used Access database encryption - they did not.

* They could have used an Access database password - they did not.

* They could have used System.mdw based user/group security - they did not.

What they did seems more of a conjuring trick: divert the buyer's attention with meaningless "security" while designing a structure that seems purpose-built for cheating.

Some further elucidation of Junkdrawer's shocking revelations:

GEMS violated standard database practice by shutting off MS-Access's Autonumber primary keys
I hadn't studied up on some of the details of GEMS (like most programmers, knowing it's written in proprietary Access code with add-ins is really quite damning enough without asking for any further gory details) and so I didn't even realize GEMS was this bad. Autonumber (sequential, machine-assigned) primary keys are such a standard practice in database design that I've never heard of a database that didn't use them for the main (or "most granular") table (in this case, the ballot table). Having an Autonumber primary key for the main table is so standard in Access that if the programmer forgets to create one, MS-Access will display a warning message, where if the programmer clicks on the default 'OK' key or hits the 'Enter' button, the system will automatically rectify the programmer's violation of standard database practice, creating the Autonumber primary key for them. Many CASE (computer-assisted software engineering) tools for database design also recognize the near-universal practice of assigning the equivalent of MS-Access's Autonumber key, and helpfully automate this by letting the programmer switch the "automatic numerator" setting to on during database design.

So by not using MS-Access's built-in Autonumber primary keys, GEMS programmers went out of their way to do something totally non-standard, and in so doing they got rid of the rudimentary auditing even Access provides: the sequentially numbered system-generated key for each ballot. (In a simple scenario, this Autonumber key would provide some simplistic auditing capability: you could do a rudimentary check for tampering just by looking for "gaps" in the series of Autonumber primary for all the records, same way waiters and waitresses use pads of pre-numbered slips for taking orders, where any "gap" in the numbering is immediately obvious. Yes, like anything, Autonumbers could be altered and the numbering could be restarted at a different point in Access, there's even a rather lengthy workaround in the Help system that explains how to do this - it involves creating a separate auxiliary table, as I recall - but that's still no reason to go to the trouble of shutting off the rudimentary audit trail provided by the built-in Autonumber feature.)

Failing to follow standard practice of referential integrity
The other thing Junkdrawer mentions is that the GEMS programmers did not use "database-enforced referential integrity" (also know as DRI or declarative referential integrity). This is also shocking. Integrity means just what you think it would mean in this context - the prevention of errors in data-entry and tallying. Specifically, referential integrity is the feature that makes sure you can't for example enter an Invoice record without already having an existing Client record to attach it to. (This supports the well-known parent/child relationship between records - referential integrity ensures that there are no "orphan" records.) In a voting system, not implementing referential integrity would allow you to do strange things, like set the candidate on a ballot to a non-existent candidate, or set a ballot's county to a non-existent county. These "orphan" records would then simply disappear from any candidate-by-candidate or county-by-county subtotal reports. Wow! I can't believe anybody paid for a database this bad, for a major election no less!

Not implementing referential integrity is a common mistake made by non-programmers (typically Excel power users who want to upgrade to Access), but it's not something a professional database programmer would ever think of not implementing. It's just standard practice because it's worked well at preventing database corruption through lost records for the past few decades.

By the way, when you switch on declarative referential integrity in your Access database, you get an additional option you can also switch on: the "cascade update" feature. This means that if you were to update the spelling of the id in the parent record (say you change the spelling from "John Candidate" to "John Q. Candidate", or you change the spelling of a county from "Dade" to "Miami/Dade") your edit to the parent record will "ripple down" to all of its children records (the ballots, in this example) and they won't become orphaned and disappear from subtotals on reports. Another very important standard feature, available as a check-box which it takes the programmer just a few seconds to set in Access, and the bozos (or criminals) writing GEMS didn't bother to do it! This is negligent and incompetent, and those programmers are either stupid or they are criminals.

Good databases don't even need summary tables
Regarding summary tables - I don't even use 'em, if they're not absolutely necessary. Summary tables by definition involve copying records out of a summary query into another, usually to attain speed enhancements. The problem is, all this copying and deleting just creates another opportunity for errors or fraud. It quite often happens that someone "forgets" to delete the records from the summary table, and you end up getting double or triple subtotals without even knowing something's wrong.

It is safer to just write a "live" summary query (not using summary tables) which computes subutotals based on the underlying detail table. A "live" query "rolls up" the data from an underlying table (in this case, the ballot table) and displays the subtotals (in this case, the subtotals by candidate, and possibly by county). The nice thing about this is that the subtotals in the "live" query are always synchronized with the detail records in the underlying table, and no additional coding or user intervention is required to keep the summary query and the detail table in sync.

Of course, this summary-table problem goes back to one of the other problems with Access being a "toy" database: once you get up into range of several million records in the detail, Access slows down a lot (programmers say refer to this as a lack of "scalability"), and this is what necessitates inelegant, error-prone workarounds (also known as "kludges" or "hacks") such as summary tables in the first place. As we all know, industrial-strength databases handle millions (and billions) of records with ease - this is why it only takes a few seconds to do a search on google or to pull up a customer flight reservation.

Why should America's voting systems be any less efficient than google or SABRE?


Fredda Weinberg
In three separate responses, Fredda made three separate mistakes - one technical, one logical, and one rhetorical - which might lead a programmer, a sensible person, and a conspiracy-theorist to reject Fredda's "arguments" as garbled at best, or simply erroneous - or even deliberately misleading.

Fredda's main technical mistake
Fredda's technical mistake (post 326 in the old thread) was this:

"It's a standalone system / why would it need a system.mdw file?"

and it's a doozie!

A programmer would not justify such a confused statement with a response - they just wouldn't waste time talking to the person who made it.

If you're less familiar with Access and Windows programming and have some time to kill, you can slog through a boring discussion below of why such a statement is so nonsensical. Otherwise just skip down to Fredda's other technical mistakes below.

Main rebuttal to Fredda's main technical mistake
As all programmers know, "standalone" means a program that runs on one machine; it doesn't mean that it the program uses one file. I'm sure even many non-programmers have often noticed the blizzard of files that get copied all over our machine when we install a new program. This is why the statement "It's a standalone system / why would it need a system.mdw file?" is so bewildering as to be unparsable. Whether or not a system is "standalone" has nothing to do with whether or not it needs a "SYSTEM.MDW" file to implement user ids and logins.

Alternate rebuttal to Fredda's main technical mistake
Now, to be charitable, let's parse. Maybe I'm missing something, maybe Fredda is not trying to say that a standalone system doesn't use more than one file - maybe she's referring to the fact that there are two levels of (remember, easily hackable) "security" provided for Access - database-level passwords and user passwords. Maybe Fredda means, "Why implement user-level security if it's not running on multiple user's machines?" This could be an honest mistake by a progammer who made the incorrect assumption that a program running on only one machine doesn't need to have user ids & logins.

But, as I explain below, just because a program runs on one machine doesn't mean that only one person will be using it, and doesn't mean that it's a good idea to shut off the admittedly hackable user-password security that MS-Access does provide. As a matter of fact, when the programmer does implement user-password security in MS-Access, this allows the programmer to do a few more security-enhancing things, such as storing the user's id along with any record they change. I've done this in databases I've delivered to clients, and they appreciate the audit trail this provides, so they can see if it was Betty or Bob who updated such-and-such a record. I have also extended this capability in my Access databases to even keep an audit trail for deleted records. (This little trick of course required setting up an additional table, which I called 'Transactions', where I stored a record every time someone added, changed or deleted a record in the database.) The point here is, although Access, like all computer programs, is hackable (in the alarming and extreme ways German-Lefty points out, where you can make a machine pretend to do one thing when it's actually doing another), you do get some additional security if you switch on user-level passwords, and you can even build some auditing capabilities on top of that. If you've shut off user-level passwords, you of course get zero security, and you can't build any auditing tools that track the user id, because there are no user ids in the system.

As you may have guessed, although theoretically any computer system can be hacked, this doesn't prevent most programmers from going ahead and implementing user-level passwords, and auditing of record inserts, updates, and deletes by user id. None of these safeguards were taken with the GEMS system.

As Junkdrawer mentioned (see quote above), you can have either a database password or user-level passwords or both in Access:

- A database password creates one password which is requested whenever the database gets opened by anyone

- User passwords create pairs of user ids / passwords much like what we use on websites to login.

(According to Junkdrawer, GEMS has neither of these rudimentary security features.)

If you only create a (hackable) database-level password for an Access database, no additional files are needed. If you create user logins & passwords, there are stored in the (hackable) *.MDW file (typically called SYSTEM.MDW).

So maybe Fredda is saying that because this vote-tallying system is "standalone" (only meant to run on one machine), it therefore will have only one user, and what... therefore we don't need user-level passwords?

This makes no sense on several levels. First of all, it seems very unlikely that a voter system (even a vote-tallying system) would be designed to have only one user. At the very least, during different phases of development and deployment, there would be a programmer, an administrator, one or more operators, and one or auditors logging into such a system. So the decision to write an Access database that runs on one machine, and the decision to implement user-level security, are independent decisions ("orthogonal" decisions, in programmer parlance). One has nothing to do with the other, and once again Fredda's statement "It's a standalone system / why would it need a system.mdw file?" is utter nonsense on the technical level.

Fredda's other technical mistakes
Fredda says about Access: "Undependable? What does that mean?" It means it crashes. I won't say how often, but... it does crash. It means it has lots of weird library-not-found bugs which happen when you load it on a new machine and which necessitate going into the 'Tools' > 'References' menu to tinker around and fix things. In fact, one sense of the word, MS-Access isn't even "standalone", because in order for the GEMS system to run, you need to have the MS-Access database installed (and, in order to do the compaction procedure I outline below, it's not even enough to just have MS-Access installed, it has to be installed using the 'Custom' option to enable compaction to be performed.) True standalone programs are something many of us have seen - we download them or buy them on a CD, pop the thing in, double-click the 'Setup' icon, and the thing installs a bunch of stuff all over the place and we end up with a double-clickable icon on our desktop which can run all by itself. Access "programs" actually aren't standalone in this sense - they only run if the main Access program is installed in a certain way on the machine. This annoys many developer because it makes their Access apps harder to distribute, more fragile to install.

But anyways. I'm not going to dig up quotes from all over the place about how Access is not as stable as other database systems. I've already quoted a couple of derisive remarks from slashdot.org to convey a sense of how little respect the programming community has for Access when it comes to building mission-critical, secure applications.

This is why, as I said, the Department of Defense and banks and airlines have official policies against running their core, mission-critical systems on any Microsoft programming product, particularly the inexpensive "desktop" versions (such as Access) sold to home users, small business and single-building departmental users.

"Undependable" means a lot of other technical things. For example, it is a well-known fact that the longer you run an Access program to do queries and reports, the main file keeps growing even though you aren't adding any records to it. Similar to the well-known "memory leak" in Windows (which makes certain versions of Windows crash if it's simply left running too long, due to insufficient memory resulting from failure on the Microsoft programmers' part to free up memory that's no longer in use) this growing-file problem in Access is simply because of lazy and/or sloppy programming by the designers of Access at Microsoft, who let the program gobble up extra disk space temporarily to do its computations, without freeing up that temporary disk space when the computations are finished.

A minor inconvenience, yes, but it's always been a hassle in my career as an Access programmer, it's always kind of made me look bad to my clients, but it's part of Access so we have to live with it. As a programmer, I've got a couple choices how to handle this annoying and unnecessary inconvenience: (a) Instruct the user how to periodically go in and do 'Tools' > 'Database' > 'Compress' (and this necessitates doing a "full" or "custom" install of Access, not the "typical" install - which usually means another call to the help desk), or (b) To avoid having the user go into menus, I keep a separate copy of the database around (I usually put it in a folder called 'pristine') for them to copy over their working copy periodically, also a procedure fraught with danger. Yeah, there's other options too, involving additional coding or "add-ins", and while they may solve the problem caused by the sloppy or lazy Microsoft programmers, more-professional database designers prefer to use databases with "zero administration" rather than needlessly complicating their apps. Some databases don't need a DBA (database administrator); Access is not one of them.

Any of these file-compression workarounds are fairly easy but you know how users often get confused when you make them do an administrative task that involves saving a file. That old mismatch between the 'File Save' dialog view of the file system and the user's familiar 'Desktop' view of the file system rears its ugly head, and people do lots of weird things, like saving the file in the wrong place and ending up with multiple versions of it scattered all over their hard disk (which later get out of synch, say, when more votes are added to the database from a county reporting in and the votes get added to the wrong copy of the database), or maybe overwriting an existing file.

What's the solution? Non-programmers here may be reassured to hear that even in the realm of computer science, common-sense thinking is important (at least to leading practitioners in the field), and the strategy of minimizing the number of opportunities for some user inadvertently screwing up is a vital and legitimate part of strategies aimed at ensuring that a system is "dependable". People making software purchasing decisions weigh in these human factors, and every effort is made to minimize the amount of extraneous work required to keep a database afloat. The extra crap you have to go through just to keep an Access database from chomping through your hard drive over time is an unnecessary hassle and a danger, and enlightened programmers and managers avoid it by... not using Access.

"Undependable" also means that there are arguably more known, unfixed bugs (and more likelihood of unpredictable bugs in the future) in Microsoft Access than in most if not all competing major database packages, particularly in Access programs like GEMS when an incautious (or malicious) programmer gets carried away and throws in a whole bunch of unnecessary "add-ins" and "plug-ins" resulting in spaghetti code and possible backdoors. (For example, many copies of Access 97 had a very famous bug that cropped up right when you installed the program and prevented you from running anything at all in it. You had to go to the KnowledgeBase on the web, or call the Microsoft 900 number to get the fix for this. Typical shoddy programming from the 800-pound gorilla, Microsoft, whose motto has been and always will be "When you're #1, you don't have to try harder.")

Experienced, capable programmers have found that another pragmatic, real-life philosophy has great applicability even in the techie world: "KISS" (Keep It Simple, Stupid). Access is known to be bloatware and buggier than other databases, and its lack of simplicity due to bloat and bugs is one reason why smart people steer away from it for mission-critical apps when they have a choice.

The overall point here is that, as all programmers know, Access is nowhere near a top-tier product. I'm not saying I hate it - hey, I've used it for years on small, non-mission-critical jobs - but all programmers know it's not dependable enough for anything where security and auditability are important.

Fredda's logical mistake
In post 320 in the old thread, Fredda makes another statement about GEMS which, upon closer inspection, is difficult to parse, simply from a logical or semantic perspective.

"It's used in a standalone, desktop application that gathers the totals from the remote machines and produces reports."

Am I the only one disturbed by the logical or semantic tension between the words "standalone" and "remote" here? How does this "standalone" application gather totals "from the remote machines"? Either it's hooked up to a network - or we're using some kind of really old-fashioned "sneakernet" where dozens of diskettes are physically mailed to a central location and manually inserted one-by-one into this computer running GEMS - yet another security nightmare.

I am honestly baffled by this statement. Either Fredda is wrong and GEMS is not a standalone application because it's wired to other machines, or Fredda means they implemented a sneakernet for GEMS, which opens up a whole 'nother can of worms from a security standpoint.

Either way, its a confusing, confused statement, and furthermore it doesn't really seem to be a rebuttal to any of the relevant technical points raised by me or JunkDrawer.


Fredda's rhetorical mistake
This is more subtle but again you don't need to be a programmer to pick up on it. In post 325 in the old thread, T Roosevelt agrees with what I said in my post 278, saying "Access was not written to be a mission-critical application. It was written to be basic, quick and dirty desktop database for common everyday people to be able to use (yes, the history of Access is VERY relevant)."

Note the use of the common multi-word English idiomatic expression "quick and dirty" with its whole range of positive and not-so-positive meanings such as simple, convenient, easy-to-use, good enough for non-mission-critical jobs.

Now look at Fredda's response to T Roosevelt:

"There's nothing 'dirty" about Access and for a desktop system that only accumulates vote totals, it's more than adequate."

When I heard Fredda substitute the wholly negative word "dirty" for T Roosevelt's less-negative phrase "quick and dirty", my straw-man radar kicked in. Either Fredda doesn't know what "quick and dirty" means (unlikely, since Fredda's mastery of English indicates Fredda is a native speaker), or Fredda is deliberately misquoting here, grasping at irrelevant points while neglecting bigger technical issues that have been brought up.

Nobody went so far as to say Access was "dirty". Earlier, when Fredda could bandy around the term "one-way dialup modem" (and I still neither know what one is nor do I care - all I need to know is that after one party makes a call, you generally have a two-way connection), this discussion wandered way off-topic on a wild goose chase in pursuit of a straw man, the "one-way dialup modem", when the real issue here is what I keep saying, good programmers don't use Access for mission-critical tasks because it provides weak or no built-in security and auditing. I bet if the word "dirty" had a technical ring to it, we'd be off on another wild goose chase.

A conspiracy-theorist might say that Fredda is deliberately trying to set up a straw man in this discussion by misquoting people. This, on top of Fredda's many other mistakes on so many other issues and failure to address technical issues such as the lack of primary keys in GEMS, the lack of referential integrity in GEMS, the lack of security in Access, the lack of either database-level or user-level password-protection in GEMS - these lapses do not make Fredda very credible on this whole topic.

Summary of rebuttals to Fredda
Yes, Fredda, to keep the discussion at the non-technical and irrelevant level you have kept trying to keep it at, Access is "adequate" as a desktop database for non-mission-critical work, but then again, a ten-dollar calculator with a paper printout might also be "adequate" in this sense. And yes, there is nothing "dirty" about Access, but nobody ever said there was, and you're not arguing cogently if you choose to misquote people while failing to address the technical points.

The fact remains that systems where security is an issue are never programmed in Access, and I don't see why national elections should be any exception.

To summarize, programmers working on important projects never consider using MS-Access, because it's not secure (its password system is very hackable, and when combined with add-ins it's even more hackable, and there's no built-in facilities for providing an audit trail), it's not as dependable as better-made database systems (it requires excessive error- or tampering-prone administration) As I note below that German-Lefty points out, no computer system is inherently secure. But an Access program with a bunch of suspicious backdoor plugins and no Autonumbering and no referential integrity is simply beyond the pale.

Yes, as Fredda said, Access might be "adequate" in some minimal, legalistic sense that complies with some badly-written FEC regulations, and in that spirit, other approaches such as cutting and pasting a bunch of rows into Excel might be "adequate" or even using a old-fashioned calculator (with or without a roll that spits out a paper printout) might also be "adequate" in some narrow, niggling sense of the word. If Fredda is just trying to prove this narrow point, then Fredda may be right - GEMS might satisfy the letter (but surely not the spirit) of FEC regulations. Big deal, is all I can say to that. The rest of the people on this thread aren't just arguing about satisfying badly-written FEC regulations - we're looking at the bigger picture of trying to make every vote count.

A CEO purchasing a major app to run their business on, and a democracy investing in a program to total ballots in, would never even think of using MS-Access, would never consent to purchase the thing as "proprietary" "non-open-source". I always gave my clients access to my Access code, because they paid for it. Does anybody get to see the source of the Diebold code - even the people who paid for it?


SDent
In post 328 in the old thread SDent has an honest question about the DateTimeStamp Adjuster "add-in":

"My dummy question is whether it's possible something like this could have been 'left behind' in the system or if the DateTimeStamp Adjuster has actually been added to the Access database application they've created?

And, in another post on the old thread (341) SDent ask another apparently honest question about the other potential backdoor add-in, PE Explorer.

Both questions can be answered from a technical perspective as well as a legal perspective.

These might seem like legitimate questions. The DateTimeStamp Adjuster could be something accidentally left behind, and the PE Explorer (which, according to DEMActivist, apparently gives a backdoor to the entire system) could be too, and just because these dangerous-looking add-ins are there doesn't mean somebody actually misused them. But the purpose of the DateTimeStamp Adjuster is obviously to overwrite the system-assigned date/time stamp on records, and the purpose of the PE Explorer is to give somebody a backdoor to the entire system, and this is not something you want to allow any user to be able to do in a database where maintaining an audit trail is important.

Arguing the technical question of whether there might be an innocuous use for such add-ins is beside the point, and you don't need a programmer to tell you that, just use your head. These potential backdoors are not something a reasonable person would expect to find in an accounting system or in a vote-tallying system. They just raise a red flag, because they're unnecessary and they would be a great way to facilitate tampering.

Think back to the important, asymmetric legal notions of "burden of proof" and "proof beyond a reasonable doubt" - asymmetric in that they place more burden on the accuser than on the accused. This asymmetry is typical in situations where one party is known to have more motive and means to cheat, and the other party is known to have less means to verify or defend. The burden falls on the shoulders of the party with the means and motive to cheat to prove that they're not cheating.

Looking at these bizarre, non-standard, backdoor-enabling "add-ins" we have two choices: either put the burden of the proof on the voters, who would have a very hard time showing that these add-ins wasn't used for any hanky-panky, particular because of Diebold's bogus "propietary code" argument. This is really all SDent's "honest questions" amount to, and it is quite easy to answer: No thank you, we don't want to buy programs with backdoors in them, just like we don't want to buy freshman-level SQL code in a "proprietary" "blackbox" just because the vendor is trying to pretend it's some kind of trade secret.

A lawyer might say the presence of such unusual add-ins is prima facie evidence of tampering, and I say this more as a citizen than as a programmer, and so can you.

We don't even have to go so far as to accuse Diebold of criminal intent or criminal acts to say we don't want such trapdoors in our software. We can say, yes of course we trust you Diebold, but please don't put trapdoor add-ins in the voting software you write. This goes back to the whole issue of transparency in voting, which, as I mentioned at the start of my first post 278 on the old thread, Australia is trying to foster by using open-source, publicly available ballot-tallying code, instead of proprietary, "blackbox" trade-secret-protected code.

To put it most briefly: I think you're barking up the wrong tree SDent if you're searching google trying to find out more about trapdoor add-ins such as DateTimeStamp Adjuster. If we so clearly have the right to demand that software not have such potential trapdoors in the first place (after all, we're the ones soliciting the bids, we're the ones writing the RFQ), why not just say so and avoid the issue of whether a potential backdoor was actually used or not?

Now, from a technical perspective, I am a strict follower of the KISS (Keep It Simple, Stupid) philosophy in programming, and it's paid off for me in a big way, it's one of the reasons my clients have loved my programs: because I don't add all kinds of extra, fragile add-ins, my programs don't break. Lots of amateur programmers get seduced by the bells-and-whistles of ActiveX controls and OCX controls additional DLLs, in the end it just means that their programs break more often or can't be installed on additional machines.

I've seen this happen time and time again at jobs - at the last investment bank I worked at (yes it was an Access database but it was just departmental-sized, a data-analysis app for the CFO, so security issues weren't a concern, because he trusted his managers, and output was checked against all kinds of other systems all over the bank), there was a programmer before me who had loaded his screens up with all kinds of cute add-ins, and it turned out the program was so damn complicated they couldn't even install it on an additional machine because they couldn't round up all the DLLs it depended on! (In Windows programming magazines, you often see this referred to as "DLL Hell". It's a very real problem and intelligent programmers sidestep it in a very Zen-like way by... not using add-ins.) I am very clear with my clients about add-ins: I don't use them. SQL is enough to do data-entry and totalling; you don't need anything more. The minute you start adding more junk to the system, you're creating more potential points of failure, and the programmers that do the best work don't add any extra junk. So from a technical point of view, having these creepy-sounding TimeDateStamp Adjuster and PE Explorer is a sign of amateur work at best, and a sign of something more sinister at worst.


German-Lefty
I agree with everything German-Lefty said in post 284 of the old thread. German-Lefty quite correctly points out that the issue of voting is a whole lot more complicated than I made out in my post 278, particularly the problems of (1) letting people just vote once, and making sure their vote indeed gets counted and (2) keeping details about who voted for what secret (to avoid both coercion and vote-buying).

And the additional frightening scenarios German-Lefty raises are unfortunately quite possible:

"I can build a terminal that looks like it counts your vote but doesn't.
I can build a terminal that looks like it runs your software but doesn't."

I glossed over a lot of the complexities involved in "secure electronic voting" and focused instead on picking apart the insecure aspects of the GEMS system written in Microsoft Access. As a hint about where I stand on electronic voting given current technology, I closed by saying that even as a programmer I still favor paper ballots, and I proposed my triplicate carbon-copy idea with the white and pink and yellow copies going in different boxes to be counted by different parties (say Democrats, Republicans and UN reps). I still think such low-tech solutions may be our best hope in view of the innumerable ways you can tamper with an e-voting system. Maybe voting, like other vital functions such as eating and having sex, can't be done virtually, and maybe we should just accept that fact and get over our fascination with hi-tech and instead build a system that acknowledges the temptations of tampering and does its best to mitigate them using tried-and-true old-fashioned methods such as independent verification by multiple parties. Banks know this too - remember the little note on the envelope where you make your deposits to ATMs, where it says that the envelope will be opened by two people. When a lot is at stake, there's really nothing like good old-fashioned verification by multiple human beings.

Regarding e-voting cryptography approaches (which is just one aspect of the overall e-voting question, primarily affecting the point where a vote is "in transit" from a voting station to a central tabulating station) I have heard of the "blind signature" approach which German-Lefty mentions, but I am still new to the whole e-voting scene and I am aware that other cryptography technologies such as "homomorphic encryption" and "threshold cryptography" exist as well. Frankly, I don't even know enough at this point to say which, if any, of these three cryptography technology approaches is workable, nor do I know the answers to a whole host of other e-voting architecture issues I have seen papers on. As I mentioned earlier in this post, I think that cryptography is only one small possible feature of an overall "architecture" which might solve the e-voting problem. Apparently there are lots of unsolved issues in e-voting at this point, mainly because of all the secrecy and privacy and identity issues involved.

It might seem odd for a programmer to favor old-fashioned paper ballots, and in the past I, like many starry-eyed techies, always used to daydream about using bank ATMs or Internet terminals to get rid of our current outmoded system of voting and implement something better.

Last week, when I started researching the subject, I came across an avalanche of papers published on the internet showing just how hard it is to implement secure electronic voting, and I agree with German-Lefty and many others who say that "we're just not there yet". This is why, for the moment, we're better off using something old-fashioned and physical we can control and trust (like carbon-copy independently-counted triplicate paper ballots) rather than having the illusion of high-tech security in a very flawed system such as GEMS with all its potential backdoors. Hi-tech is fun in certain areas, but in voting an important concern is that everyone understands and believes the system is secure, and all things "e" are still such a mystery at this point that we're probably better off sticking with something that the average person feels comfortable with and can trust and verify.

I believe, as I'm sure German-Lefty does, that notions such as "open-source" and "password protection" and even the mythical "one-way dialup modem" which this thread has been talking about are actually quite tangential to the deeper issues involved in implementing secure electronic voting, and in another thread (or possibly a dedicated e-voting "blog") it might be interesting to explore these deeper issues.

Two lists of links on e-voting will give some idea about the ferment in the computer science community over this topic:

http://www.eff.org/Activism/E-voting/
http://www.tcs.hut.fi/~helger/crypto/link/protocols/voting.html

In light of the sophisticated discussions these people have been having on e-voting, the GEMS Access database looks even more cynical and pathetic. There are a lot of professionals in the worlds of computing and sociology grappling with the issues of "social software" and e-voting. Handing out a contract to a bunch of programmers at Republican-leaning Diebold so they could slap together a database violating most of the accepted standards of database programming in general (and Access database programming in particular), is just really sad.

I think we can see quite clearly that the GEMS system implemented in Access, with all its bogus talk about security and all its needless add-ins and all its violations of standard database programming practice, is not even a bona fide attempt at implementing secure electronic voting, and may in fact be something much worse: an outright act of fraud.


grasswire
Finally, a shoutout to grasswire (post 43 here), who also has thought up the same paper-ballot proposal. Whether due to willful obfuscation or sheer technical difficulty, e-voting technology isn't ready for prime-time, and I agree that the primary goals of transparency, security, verifiability, secrecy etc might still just be best satisfied at this point by a low-tech solution such as triplicate paper ballots.


= = =

... definitely at a 5.0. Good technical dissertation for the defense.

On edit: or for the prosecution.

i can get you some technical writing work if you need it. that was like the voice of freaking god.

The issue of electronically-enabled voter fraud is extremely important, particularly given the increasingly plausible possibility that the current apparent 50/50 ideological split in this country may be in fact nothing more than an illusion made possible by various structural inefficiencies in our communication and decision-making systems exploited by a minority (corporate-financed campaigns and politicians, corporate-controlled one-way mass media, and corporate-controlled blackbox voting).

what critical truth this is!

I am on my feet!

Bev Harris

:evilgrin: :thumbsup: Thank you! :)

No one says that GEMS couldn't have many more layers of protection - but it wasn't required, so its absence is not a scandal. For a database which is only meant to be accessed by a single application, a system.mdw file isn't necessary. It is a workgroup file - whatever other purpose it can be made to serve, its addition isn't indicated.

"good programmers don't use Access for mission-critical tasks because it provides weak or no built-in security and auditing"

The audit log was generated at the application level - as per the FEC requirement. Whether you would have done it differently is irrelevant.

"Does anybody get to see the source of the Diebold code - even the people who paid for it?"

This tells me you're not paying attention. For the qualification testing:

National laboratories selected by and monitored by the National Association of State Election Directors (NASED) Voting System Board administer the Qualification tests. ... A major component of these tests is a line-by-line examination of the source code for the system. This review includes an evaluation of the function of each module of the code to insure that no extraneous code is contained in the system. A complete description of the Qualification tests can be found in the FEC Voting System Standards section on the FEC web site: http://www.fec.gov.

Scott, I've learned over the years not to trust people who deliberately obfuscate. Your arguments are irrelevant to the report's premise: that Diebold concealed code to manipulate election results. Whether *you* would have chosen Access for this portion of the system doesn't matter - good programmers will disagree with you.

In this case, you're not looking at anything mission-critical. This system designs ballots and tabulates vote totals. In that sense, it is a fancy calculator and Access is more than suitable for that purpose.

You justify your insults by resorting to adjectives like "legalistic" but complying with regulations is exactly what Diebold apparently has done. It's not narrow or niggling - it makes the entire publicity stunt groundless.

"we're looking at the bigger picture of trying to make every vote count"

That's what I've been trying to do ever since these machines were proposed - why I spent hours pouring over the GEMS source code and databases ... why I continue to follow what has become a farce of an investigation.

One of Bev's articles demonstrates with screenshots how an audit log can be defeated when it's been written by the programmers in a language that doesn't have any built-in support for things like triggers which enable better auditing. This is a scandal, whether it is Diebold's or the FEC's fault is not really interesting to me as a programmer. I am attacking primarily the badly written code in my capacity as a programmer. I don't really care how it got that way.

I was unaware of what qualification testing was done, including line-by-line source code examination you mention. But then again, remember that non-standard add-ins such as TimeDateStamp Adjuster and PE Explorer were present in this system - add-ins which are compiled in non-human-readable format - add-ins which are at the center of the tampering controversy. These add-ins are extraneous, potentially malicious code. Their presence means that the whole exercise of "line-by-line code examination" was just that - an exercise, a pointless exercise that satisfies the letter of the law while leaving gaping opportunities for tampering.

Actually, the letter of the law is not satisfied here, because of those compiled components. Who read their source code? Nobody, because you can't. As German-Lefty pointed out, these components, downloaded from the web, don't even necessarily do what their advertising says they do. (And what they're advertised to do is bad enough, as DEMActivist pointed out.)

Fredda says In this case, you're not looking at anything mission-critical. This system designs ballots and tabulates vote totals.

Vote counting is certainly a mission-critical application.

If all we wanted was a glorified calculator, then, as I said, they could do that too and still stay within the "legalistic" or "niggling" scope of having satisfied the law.

I don't do addition in a calculator, I use Excel if I want to keep a record of what I did. By the same token, I wouldn't import county ballots and compute vote totals in a language that doesn't provide triggers to enable a built-in audit trail, if I was doing it for a client. I also wouldn't do it without Autonumber primary keys on the main table, or without declarative referential integrity to the parent tables (county and candidate), and I don't think any professional programmer would. Maybe for something I was in a hurry to do at home just for personal use, because I know I won't tamper with my own stuff. For something for a client, a financial or vote-tabulating application, programmers always put this stuff in. Access encourages Autonumber primary keys; Diebold had to go out of their way NOT to put in Autonumber primary keys. (You didn't address this important point.)

In addition, you have not addressed the issues raised about the lack of referential integrity, which makes it very easy to drop ballots out of the subtotals as I explained earlier. Do you write databases without referential integrity? The only Access programmers I know who make that kind of mistake are really non-programmers - Excel power-users who have no idea how to do a relational database. I have seen this done, because I've worked at places where Excel jocks get "kicked upstairs" and starting writing Access apps, and you know what happens every single time? Records get lost. This is probably my main point (as raised by JunkDrawer), and it is the point you fail to address. Databases without referential integrity always become corrupt. Programmers who write such databases aren't programmers. The presence of a county and a candidate table, connected to the ballot table with the appropriate referential integrity, would be a standard design by any real database programmer. This is not a matter of opinion or different programming styles - this is just the way databases get written. This is a glaring issue you didn't address. As I said before, the people who made this database were either incompetent or malicous.

Overall, what you are essentially saying is that such a program *does* satisfy the legal specs (under a very weak reading, which glosses over the important issues of the compiled add-ins and the demonstrably defeatable roll-your-own auditing). I am saying that it doesn't satisfy those specs under a stronger reading of the legal specs, and I am curious why you are satisfied with the weaker reading. Are you just playing devil's advocate, or do you really think that it's ok to write programs this bad for imporant applications?

You are saying that the failure to follow standard database programming practice is ok here. I am saying that it is suspicious, revealing either incompetence or malicious intent. You are saying that you've spent hours poring over the GEMS source code - I am saying that a system that just does vote-tallying should be so simple that it would take minutes to pore over the code.

Maybe we can agree on the point that the GEMS program sucked. You don't sound like you're too crazy about it - you're mainly defending it from a legal perspective (it satisfies the FEC specs), while I'm attacking it from a programming perspective (no real programmer would have written a program this bad).

Microsoft will back scotxyz and not Fredda. They get this call all the time...


Oh another interesting thought, you know, you can't cluster with Access!!! So how do you have the redundancy needed to support an election?

Microsoft will advise an upgrade to SQL Server.

While I lack the expertise to comment on the technical aspects of this, a couple things scottxyz said go to the heart of this matter as far as I am concerned:

"This is a scandal, whether it is Diebold's or the FEC's fault is not really interesting to me as a programmer. I am attacking primarily the badly written code in my capacity as a programmer. I don't really care how it got that way."

"Maybe we ((scottxyz and fredda)) can agree on the point that the GEMS program sucked. You don't sound like you're too crazy about it - you're mainly defending it from a legal perspective (it satisfies the FEC specs), while I'm attacking it from a programming perspective (no real programmer would have written a program this bad)."

I think that certain posters have been critical of this issue because they are misunderstanding (or pretending to misunderstand) what the central issue is here. As a voter, the only thing I really care about is whether or not my vote will be counted. If the electronic voting system my state uses is shown to be insecure, then, like scottxyz, I don't care whether it is the fault of the manufacturer or the election officials; I simply want it to be fixed (i.e. made secure). If electronic voting cannot be made secure, then a more secure method, such as paper ballots, must be found.

Certainly I'm interested in knowing whether vote rigging has already taken place on these systems, but that is a separate issue. Some posters are arguing that because Bev hasn't definitively proven that votes were stolen in Georgia in 2002 that her research is worthless. In effect they are creating an irrelevant standard and then complaining when that standard is not met. Likewise, some posters argue that as long as election laws are complied with, there is no scandal -- as if having an insecure voting system isn't scandal enough. Whether or not the election laws are sufficient is an important but, again, separate issue, as far as I am concerned.

It troubles me that there are those who don't consider the security of our elections important enough to dwell on unless we can find some villain holding a bloody dagger in all this. I'd also like to point out that there is a bit of a catch-22 here: the very problem with this system is that because there is no audit trail, there is no way to determine if any funny business has taken plase. That's why many of us feel so strongly that any voting system must be transparent and auditable.

Just as there's more than one way to code an algorithm or enforce referential integrity.

What bothers me about what I've read so far are the baseless accusations that people are lying or violating protocols or ignoring best practices. If the issue is security, then fine ... there's plenty to write about.

I mean would you feel confident voting on such a system?

and until someone finds a reason to distract me, I'll stick to it.

You don't vote on GEMS; it's just the machine used to tally the precincts in the end. The people who have access to it are the same ones reporting the counts - and the presumption of the public is that they're trustworthy people.

Could it be made more secure? Sure, but Diebold apparently followed the rules. So instead of hurling false accusations against one manufacturer (or me), let's cooperate to change the Help Americans Vote Act.

I'm just trying to figure out where you stand. You claim that Diebold followed the rules. I'm willing to accept that claim for the sake of argument. But how would you evaluate Georgia's current voting system overall? Excellent, good, average, fair, poor? Would you trust a similar sort of system to keep track of the money in your bank account? (And I realize that such a system would be qualitatively different; I'm just trying to guage how much confidence you have in the system.)

And if you don't have confidence in Georgia's system and you maintained that Diebold followed the rules, wouldn't you agree that the rules need to be changed? If not, how would you fix the problem?

I am asking these questions in the most respectful way. I am not trying to paint you into a corner or trick you in any way. I would just like to know where you're coming from.

paradoxically, I have more confidence in the GEMS system, now that I've seen under the hood. I want the whole thing to be open source, so I can see the import module, the manual entry functions and the production version of the code.

I want the actual voting machines to be nothing more than fancy printers and ballots to be printed that are capable of being scanned or manually counted.

I want a single certification standard for the entire country, so qualified parties can monitor the process.

How's that?

What bothers me about what I've read so far are the baseless accusations that people are lying or violating protocols or ignoring best practices.

I don't think you've been paying attention. Or if you have, you've not understood what you've read. Or if you HAVE understood what you've read, then -- ??

There are lies that have been caught (and fairly significant ones, IMO); there have been protocols that have been violated; and personally, even as a non-techie, what's been disclosed so far is so bad it couldn't even be characterized AS GOOD AS "ignoring best practices."

So calling any of these "baseless accusations" is to ignore what's already published. IOW: a very active imagination.

Eloriel

Fredda...Coming from you ,,,now that's fuc@ing funny...

time to prepare your responses and they are not going unnoticed.

As for Fredda, back in DU1, Fredda told us that, often, the first thing she does when she enters a project is to remove the enforcement of referential integrity from the database and move it to the code. I then quipped that "DBAs must love you". She responded that my tone was unnecessary and ill-informed. At that point I (and probably every professional programmer reading her posts) formed an opinion.

if you would like to earn more money, learn to live with referential integrity and learn SQL Server. Nobody pays an Access programmer all that much. People who know referential integrity and SQL Server get paid more.

As I've said, Access has its place. It's good for prototyping and makes an excellent desktop application.

BTW, I've worked with databases since the dBase . prompt - I know my field.

eom
P.M. Questions ...

 

that maybe Fredda wrote or helped write this "system" of voting because she is so defensive of it.

While I don't agree with Fredda, I do think you are missing the point here: MS Access is not the problem.

Now perhaps I'm wrong on this, but most of your post seems to center around MS Access and the various ways in which it sucks and how Diebold purposely sidestepped certain features. It is my contention that MS Access is a mere sideshow to the main problem: lack of cryptographic techniques in storing the votes. Sure, Diebold uses a sensible bit of cryptography when it comes time to transmit the votes to another machine, but votes stored on the machine itself are, as far as I can tell, completely in the clear. As a result, regardless of what database was used, the Diebold product would suck. This is because ultimately, a database is merely a collection of files on a disk. There is nothing magical about it, other than its structure is optimized for fast queries and the like. In fact, I would argue that using a database, any database, for storing votes is a bad idea. This is because a DB would merely add unnecessary complexity to the program. Given that all we ever want to do with the data is to count how many people voted for each candidate, a linear iteration through a simply flat file would do just fine.

The key to securing the votes is two fold. First, each and every voter's choice needs to be hashed and then have that hash encrypted by a private key (a classic digital signature scheme). Second, the combination of the voter's choice and the d-sig needs to be stored in two places: on the machine (on hard disk, flash card, etc--doesn't really matter so long as its a reasonably robust medium), and on paper. For ease of use, the d-sig could be put into bar code format on the paper. A further bit of security could include having multiple private keys all sign the vote data--the key owners being representatives from any sufficiently paranoid political party. At the end of an election, the voter data could be posted on a web site and decrypted and verified by absolutely anyone that wants to using whatever tools they wish. Since both the format of the data file and the method of digitally signing the ballots would be public knowledge, a person could even write their own tool to verify results.

The beauty of this system is clear and far exceeds the security of your proposed system involving triplicate carbon-copy ballot stored in different locations. In your system you have no way of knowing if a paper ballot is real or fake. Provided the printing is done with a reasonable amount of skill, you can't tell the difference between a fake ballot and a real one. Sure, the likelihood of a person being able to change all three ballots in all three locations is low, but they don't need to get all three. All they have to do is get to one of them and then you have a dilemma--since the three ballots don't match, what do you do? Do you assume that the corrupter got to only one ballot and the other two represent the real ballot, or do you throw it out altogether? Making assumptions is always a bad idea, and throwing out a ballot alters the total.

However, with a digital signature, any ballot with an invalid signature is immediately tossed out as a known fake. This is the beauty of using cryptography. Faking a ballot no longer merely involves access to a suitable printing press, it requires access to a digital private key. In the extreme paranoid case, you could have private/public key pair generated at a public ceremony, the public key posted onto a website, and the private key placed inside some type of portable storage device. The storage device would be taken to each precinct to intialize the voting machines and remain in public view at all times.

A UK company makes these cool little things: http://www.eyenetwatch.com/USB_hard_drive/cryptoidentity.htm

Now, just to impress trumad, I'm going to propose an XML based ballot format:

<ballot>
<ballotcount>1</ballotcount>
<president>DEAN</president>
<senator>STRICKLAND</senator>
<congressman>UDALL</congressman>
<signature>
A9993E364706816ABA3E25717850C26C9CD0D89D
426D155B41AB66410435CBSWHC3BD5KS67DMS4SJ
</signature>
</ballot>
<ballot>
<ballotcount>2</ballotcount>
<president>BUSH</president>
<senator>RIGHT-WING-WACKO</senator>
<congressman>FASCIST-PIG</congressman>
<signature>
8BAC1AB66410435CB7181F95B16AB97C92B341C0
41E2345F1F56DF2458F426D155B4BA2DB6DCD8C8
</signature>
</ballot>
.
.
.


Its only a quick swag, so don't pester me with my petty errors. However, adding the <ballotcount> field does prevent a person from simply deleting records. Clever, eh?

and looking forward to the counter argument.... Ya gotta admit...it's a fantastic give and take going on here...

1.) Has fraud occurred in the past

2.) What is the best way of preventing it in the future.

You seem to want us to focus exclusively on 2. And you seem to want us to reject any manual approach to 2.

Some of us are worried that fraud may have taken place. We have also been told ad nauseum that unless fraud is proven, nothing will be done concerning election reform.

Now, what point are we missing?

The points you are missing are these:

1) The critical flaws in the Diebold product have nothing to do with MS Access, Windows CE, program patches, etc.
2) Proving that Diebold is open to fraud is not the same as proving that fraud occurred.
3) Proving that fraud occurred is not necessary for election reform, demonstrating that votes were lost through incompetence is sufficient.

1.) MS Access and the decision to not use specific security features of MS Access has everything to do with Diebold flaws. Program patches, and whether or not they were Windows CE patches, have everything to do with Diebold violating Georgia election law.

2.) Proving Diebold is open to fraud may well relate to whether we get the additional evidence to prove fraud has occurred.

3.) Proving that fraud is possible should be sufficient for election reform, others are raising the bar on this one.

MS Access and the decision to not use specific security features of MS Access has everything to do with Diebold flaws.

I guess we just disagree on this point. As I explained in detail in post #24, I think that the problem with Diebold is its architecture. You could port the code to use Linux and an Oracle RDBMS and it would still suck. The problem is in the code, not the choice of OS or DB.

A good analogy is this. The Diebold product is like a guy who is having a heart attack and is rushed to the ER. scottxyz and fredda are looking at a mole on his butt and arguing about whether or not its cancerous, and I'm sitting here saying "Hello! This guy is having a fucking heart attack!" Get the picture?

Does MS Access suck? Yes. Does Windows CE suck? Yes. Does Diebold's practice of letting untested patches get put on the machine a few days before an election suck? Yes. But all these things pale in comparision to the problems I've seen in the code itself.

Unlike many, I happen to like MS Access - when used properly. And yes, the CandidateCounter/SumCandidateCounter hack could have been done in MySql just as well - assuming that transaction logging could be turned off in MySql. I know Autoincrement keys and referential integrity could also be turned off in MySql.

But the point is whether you think the hack found by Bev in the original article is significant or just an incredible coincidence. What hack? That all detail reports come from one table and all summary reports come from another - and that the "summary" table just happens to not be cleared between runs of the report.

particularly in 2000 and 2002 is, imo, central to this question. and empirical evidence for such fraud abounds, from suspicious vote totals to VNS's pullout from exit polling on election day 2002.

why are people afraid of asking if fraud has already occured? if the fix is already in? is there concern that such fraud may have benefitted people on both sides of the aisle? why concede to any elected official potentially fraudulent gains? i absolutely do not understand this thinking.

since i believe this investigation is about to be angrily counterattacked (which will likely include a whitewashed version of the software, legions of fredda-style 'experts', and litigious denials from diebold), building a case for what really may have happened on 11/5/02 from this emerging body of work is critically important.

I don't know of anyone who's concerned that "both sides of the aisle" may have benefitted. In fact, IF there was fraud in Georgia, that is self-evident since not every Dem candidate in Georgia in 2002 was defeated.

I'm not a technical expert and have nothing but my own opinions and thinking processes to go on, but I am personally convinced that fraud occurred. It's my OPINION from what I do know, including the fact that -- well, just think back to 2000 in FL. Plenty of vote fraud and vote suppression throughout the whole state.

It may be what you are seeing or sensing is simply a reluctance to state (what to me is patently obvious) -- that it already happened because no one has iron-clad, fully vetted, incontrovertible "PROOF." Iron-clad, as in what you need in a court of law for evidence other than circumstantial, such as caught-in-the-act before-and-after election results. Of course, I think we forget that lotsa people get convicted for lotsa things on purely circumstantial evidence.

Does that make sense? I suspect we all "know" there WAS fraud (well, those of us who are not here to defend Deibold, MS Windows CE, MS Access, or simply to disrupt for general purposes), and we've uncovered quite a bit of circumstantial evidence, AFIAC. But making the charge of actual fraud explicit is another matter, isn't it?

I really don't think this has anything to do with worrying about who gets sullied.

Eloriel

i was mostly responding to the conundrum pointed out by junkdrawer, regarding some posters' rejection of any suggestion of past possible fraud without 'proof', while claiming that without such proof, meaningful election reform is not possible.

i didn't mean to imply that anyone here would swallow election fraud in order to defend like-minded officials who may have benefitted from it. only a given-over-to-the-dark-side hardcore fascist could really do that.

the way i see it, bev's work should proceed with the initial goal of demonstrating that election fraud was possible using these voting systems; with an eye towards the hope that once this is established, the aggregate weight of other circumstantial evidence of fraud will be much harder to brush off as 'tinfoil hat' or 'sour grapes'. if we can demonstrate that the newest election systems were built to be undermined—systems put in place themselves in response to accusations of fraud—well, i don't know where that road ends. such a revelation would pose more questions than it would answer. how far down the rabbit hole do we have the courage to go?

showing that fraud is possible has been going on for years. We haven't advanced the argument by this publicity stunt.

Bev Harris runs a PR service. You think she doesn't know how to promote a book?

The investigation has turned up nothing ... but the reports are already released.

When do we acknowledge the emperor has no clothes?

of "Little House"?

you know perfectly well that i was referring to bev's diebold investigations specifically; and not attempting to give her the sort of ridiculous messianic credit that you're implying i am.

this isn't the first post from you that has basically infuriated me, but it's comforting to see at second glance how obvious this single-minded disruption of yours is becoming.

I have tried not to flame you Fredda by giving you some credit for doing some research into the security aspects of GEMS, but when you call Bev's investigative journalism into a badly designed software system that could enable massive voter fraud in the US a mere "publicity stunt" it makes me wonder whether there's any point in being polite to you instead of exposing you for the irrelevant disruptor you so often seem to be.

Bev has demonstrated that a very bad piece of software was used to total votes in big US elections. Why do you have such a problem with that? If there's something wrong with this software, people will make that objective evaluation. If you have something objective to contribute based on your examination of the software, please continue to do so. If you need to get some rest, do that too and come back with a fresh start. If you want to prove that programs like GEMS are just fine and dandy and you'd trust it to get your vote right, then go ahead and try to make that point.

Why can't you exercise a little judgment before you call this sort of work a "publicity stunt"? Bev is sitting up long hours trying to piece together the way this flaky Access software works and why, and you're being very unsupportive to the point of irrelevance.

On second thought, maybe you should just go on and flame away. In the end, you're just going to undermine your own credibility, while other people investigate real substantive issues.

If the GEMS software is flawed, someone will discover it, whether or not you make rude remarks about a "publicity stunt".

isn't a scandal. Everything you've griped about has been public knowledge to those who certified it.

What we've been through is a series of breathless "discoveries" that proved to be nothing on examination.

Now, you think that your professional opinion trumps all others and by itself is newsworthy. What hubris!

You don't seem to understand what disruption is ... my critiques have been on point and accurate. You've already conceded that.

After all is said and done, find one deliberate act on Diebold's part that wasn't fully disclosed to the certifiers that circumvented security or tampered with the election results.

From the perspective of a technical person, your arguments are cogent and to the point.

As a fellow citizen, I find your concerns admirable, and your dismay totally understandable.

Despite a long technical background, I could never critique the M$ products and systems as precisely as you have done. I am one of those who has been fortunate enough to be able to avoid, for the most part, getting entangled with building systems that support the 800-pound gorilla.

I am not sure that I agree with your conclusion about the paper ballots as the only realistic alternative. However, your concerns are well placed and very valid indeed.

OK, let's take a step back and do some synthesis and strategizing.

I'm just coming at it from my perspective (an amateur logician who ended up doing mostly small MS-Access desktop systems for clients who were willing to invest in an MS-Access prototype before they wrote the real thing in SQL Server or Oracle) and people should feel free to edit my summary below. Most of this is just a rehash of what I think's been said so far.

Note: I'm more in my element talking about how to write a good MS-Access program - there's other issues here I might not be so clear on.

Like true lefties, we've started to thrash this GEMS thing (and each other) out a little bit that's ok - the "friendly combativeness" has brought out lots of new information and angles and helped clarify some things here.*

What Bev originally needed I think was for some techies to kick the tires on this thing and say what we thought and I'm sure there's lots of other websites that are doing the same thing. (It would be great if we could put everyone's evaluations of GEMS into an overall critique, wouldn't it?)

What have we got so far?

Context
(1) We've got voting anomalies showing up all over the country for a long time now, as documented by Bev's articles.

(2) We've McCain, Feingold, Shays and Meehan are trying to overhaul the FEC (Federal Elections Commission) right now. I don't know how relevant this is - but NYTimes and WashPost are all for it:

http://www.tompaine.com/blog.cfm?startRow=1#blog8295
http://www.washingtonpost.com/wp-dyn/articles/A40908-2003Jul10.html
http://www.nytimes.com/2003/07/11/opinion/11FRI1.html

(3) As German-Lefty pointed out (in the old thread) we've got a consensus among the "e-voting" theoreticians that secret, secure e-voting is "hard" and "not ready for prime time" because important algorithmic issues have yet to be solved.

http://www.tcs.hut.fi/~helger/crypto/link/protocols/voting.html

But there seems to be at least a consensus that encryption should be used to guarantee secrecy.

The consensus that "encryption is necessary" and that "e-voting isn't ready for prime time" could be important, because it could indicate how realistic or constitutional the FEC's rules are.


Problem
We've got a couple of Republican-donor software companies writing vote-tallying software of questionable quality which interfaces with polling stations statewide. The software may be in compliance with FEC rules which might however might be too weak.

(1) First off let's not forget that even for a job using buggy bloated blackbox Microsoft products, the software is way more complicated than it could have been (lots of plug-ins and patches and mysterious tables and procedures), much less secure than it could have been (no effort made to use built-in Microsoft security or integrity controls, no encryption was added), and chock-full of mysterious, potentially malicious, unnecessary plugins and extra tables and procedures.

(2) Nederlander has focused attention on the fact that no encryption was used. As there is a consensus in the law that secrecy is part of voting, there is a consensus in the "e-voting" technology community that encryption would be a standard practice for any voting system. Encryption may or may not have been required by the FEC regs - if it wasn't, that just lets Diebold off the hook, but not the FEC. RepublicansAreEvil also makes this point.

(3) We're pretty clear about what security vote-tallying should provide according to the Constitution (secrecy, no ballot-box stuffing or trashing, no vote-buying or coercion - verifiability might be implied in this too).

I'm not sure what kind of security specifications the FEC stipulated for its "e-voting" or "e-tallying" regs (they seem to have been happy with roll-you-own auditing, buggy bloatware, and no encryption).

Different levels of security can be provided in MS-Access (probably not much more than roll-your-own, hackable audit trail, trivially hackable database and user passwords - and, most importantly, roll-your-own strong unbreakable RSA encryption, not part of MS-Access but you could "roll your own").

GEMS does not provide encryption, it has a (hackable) audit trail, it has no user passwords, no database passwords, and it includes a mishmash of plug-ins and patches.

What kind kind of security protects votes en route from the counties to GEMS? Nederlander said Diebold did provide some encryption here. As Bev theorizes, was the idea to do all the tampering in GEMS using duplicate tables, and then fall back on original tables in GEMS to satisfy spot-checks?

(4) As Junkdrawer (and many commentators on slashdot.org) pointed out, there is a consensus that GEMS does not follow generally-recognized MS-Access or general database programming practices for data integrity (no autonumber primary keys, no declarative referential integrity, probably not even the more-easily circumvented forms-based event-triggered referential integrity).

Aside: There will always be programmers (such as Fredda) who minimize the importance of referential integrity (RI). One way to respond when such programmers claim that it's possible to make a database without RI is to point out that no multi-table commercial databases are done without RI. Non-techies who start to feel worried when some programmers point out that RI isn't required need to remember that people raising this point are more slacking than nitpicking, or at least playing devil's advocate by positing that a system lacking RI may have satisfied FEC regs (I doubt they even got into RI - but some mention might have been made about "data integrity"). As Nederlander has emphasized, there are other missing features aside from RI such as encryption, and Fredda, despite a radical lack of interest in RI, has put a lot of effort into investigating what sort of security GEMS the "standalone" system does or does not provide.

(5) In GEMS there are serious questions about non-standard, tamper-enabling data structures (duplicate tables), non-standard, tamper-enabling algorithms (summary tables which aren't cleared/filled properly), and non-standard, tamper-enabling plug-ins (TimeDateStamp Adjuster, PE Explorer). As a side note, the plug-ins could constitute a violation of the already-weak FEC requirement that the source code be reviewed before GEMS was certified, because plug-ins don't come with source code.


Some comments
As RepublicansAreEvil points out, we need to beware of needlessly raising the standard of proof here. We need to be clear whose shoulders the burden of proof is on in this adversarial situation between the voters who want their votes to be counted and the partisan businessmen who are providing the unauditable insecure patchy voting software - not to mention the regulators who are formulating the unrealistic election guidelines - and the candidates most of whom, presumably, want their votes to be counted.

While we haven't found direct evidence of fraud or tampering, we probably have found "circumstantial evidence" (means, motive, unexpected election results). In the absence of an audit trail, this may be all the evidence we're ever gonna get, so in a way it's all the evidence we need: the burden should be on the system regulators and implementors to show they haven't broken the law, and as they can't show this, they could be presumed guilty.

What RepublicansAreEvil said bears quoting here: Certainly I'm interested in knowing whether vote rigging has already taken place on these systems, but that is a separate issue. Some posters are arguing that because Bev hasn't definitively proven that votes were stolen in Georgia in 2002 that her research is worthless. In effect they are creating an irrelevant standard and then complaining when that standard is not met. Likewise, some posters argue that as long as election laws are complied with, there is no scandal -- as if having an insecure voting system isn't scandal enough. Whether or not the election laws are sufficient is an important but, again, separate issue, as far as I am concerned.

It troubles me that there are those who don't consider the security of our elections important enough to dwell on unless we can find some villain holding a bloody dagger in all this. I'd also like to point out that there is a bit of a catch-22 here: the very problem with this system is that because there is no audit trail, there is no way to determine if any funny business has taken plase. That's why many of us feel so strongly that any voting system must be transparent and auditable.

So overall, the technical analysis at DU hasn't proven that tampering took place, but it does show that we have a system that is practically begging to be tampered with, written to comply with rules that may not have been strong enough in the first place.

This could mean that both the partisan software developers and the FEC screwed up. There might be some value strategically in letting them point the finger at each other a while and see what comes up too.


Doing it better next time (and critiquing what went wrong this time)
I thank Nederlander for pointing out that I've been overly concerned with database issues, when it really doesn't matter what database is used (or whether a database is used at all), it's about the encryption. (I did get carried away critiquing MS-Access because it's such an easy target and I know it so well.)

Although some people say this is only relevant to "getting it right next time", it could also be relevant to critiquing how it got screwed up this time.

As Nederlander says:

Now perhaps I'm wrong on this, but most of your post {ScottXYZ} seems to center around MS Access and the various ways in which it sucks and how Diebold purposely sidestepped certain features. It is my contention that MS Access is a mere sideshow to the main problem: lack of cryptographic techniques in storing the votes. Sure, Diebold uses a sensible bit of cryptography when it comes time to transmit the votes to another machine, but votes stored on the machine itself are, as far as I can tell, completely in the clear. As a result, regardless of what database was used, the Diebold product would suck. This is because ultimately, a database is merely a collection of files on a disk. There is nothing magical about it, other than its structure is optimized for fast queries and the like. In fact, I would argue that using a database, any database, for storing votes is a bad idea. This is because a DB would merely add unnecessary complexity to the program. Given that all we ever want to do with the data is to count how many people voted for each candidate, a linear iteration through a simply flat file would do just fine.

I'm still new to the whole controversy about secret, secure, verifiable e-voting, but I like the direction Nederlander is taking here for the future:

The key to securing the votes is two fold. First, each and every voter's choice needs to be hashed and then have that hash encrypted by a private key (a classic digital signature scheme). Second, the combination of the voter's choice and the d-sig needs to be stored in two places: on the machine (on hard disk, flash card, etc--doesn't really matter so long as its a reasonably robust medium), and on paper. For ease of use, the d-sig could be put into bar code format on the paper. A further bit of security could include having multiple private keys all sign the vote data--the key owners being representatives from any sufficiently paranoid political party. At the end of an election, the voter data could be posted on a web site and decrypted and verified by absolutely anyone that wants to using whatever tools they wish. Since both the format of the data file and the method of digitally signing the ballots would be public knowledge, a person could even write their own tool to verify results.

I think the debate should go in the direction Nederlander is pointing: it's not about databases, it's about developing an overall architecture that ensures secrecy, security and verifiability.

Another hypothetical system for the future
While I have been intimidated by the vast, difficult literature regarding the complexities of e-voting at

http://www.tcs.hut.fi/~helger/crypto/link/protocols/voting.html

I have also wondered whether a simple solution to the secure, secret, verifiable e-voting problem might be found "at the architecture level" along the lines of what Nederlander is suggesting.

I still don't have a good grasp of what all the (possibly conflicting) constraints that need to be satisfied are - are they just secrecy, security, and verifiability? You want to make sure people only vote once, you want to make sure their vote remains secret, you want to make sure their vote gets counted, and on top of it all you can't give them a receipt because this can lead to vote-selling or vote-coercing. Does Nederlander's solution do all that? Is the solution above, which requires transport over the Internet, safe from tampering with data going over the wire? (Do the paper backup copies cover this?)

I have also had vague thoughts about a system where votes are cast, encrypted, and then posted on the web so each individual voter could confirm that their vote is indeed up there. There could be three levels of ids/passwords, just like on DU or hotmail: My real name might be "Scott Smith" and my user name could be "scottxyz" and on top of this I'd have a secret password or PIN. I go to the voting center and show my id "Scott Smith" and then I go to the booth and cast my vote using "scottxyz" and my secret PIN and then later that week everyone's votes are up on the web in a big list of "cast but unconfirmed" votes. It already says "scottxyz voted for Candidate X" but the "verified by voter" checkbox isn't checked yet until I log in sometime that week with my secret PIN and confirm that I indeed voted for Candidate X. This provides secrecy, it doesn't give a printed receipt (so nobody can buy or coerce my vote), and once everybody has logged in that week and checked the "verified" box next to their vote anyone could just copy and paste the whole list of verified votes into Excel and get a total.

Am I missing something in this simple solution? I suspect the only screw-up could be that I'm not dealing with the "malicious user" intercepting the data transmissions from the voting booth to the web or from my confirming computer to the web - but the maybe fact that I'm on both ends of that transaction verifies that the data didn't get tampered with en-route. (Of course, there's the old "website-defacing" hack: we might think we're looking at the actual web page of verified votes when in fact a malicious hacker has diverted us to a bogus, similar-looking website where the votes have been doctored. Could mirrors and paper backups help defeat these hacks?)


Final note
Theorizing on a better voting system in the future is separate from investigating the poor design of the current system.

I think we are using a reasonable standard when we find that a poorly designed voting system in and of itself constitutes a violation of our voting rights.


*I think lefty infighting is what makes us stronger than righties - see Jane Jacobs' "Systems of Survival" for why this is so.

Any voting solution that allows the voter to check their vote while someone is standing over their shoulder invites the bribe/coersion problem. Although the Italians have figured out how to get around the coersion issue (well the mafia anyway). They tried to purchase thousands of cell phones with the video feature. Give cell phone to voter and have them call in their vote on video so the mafia guy has proof that you voted his way and when you walk out, you give back the phone and he gives you a few euros for your troubles.

Imagine the uproar over searches prior to entering the voting booth? It seems to prove to me that technology will always allow the bad guys to keep up with the good guys.

That is, BTW, the main thrust of Bev's original article...the debate about the virtues and/or lack of virtues of MS Access has been a side show.

Scott,

In response to your (edited) quote, please see my responses below:

Scott: Looking at these bizarre, non-standard, backdoor-enabling "add-ins" we have two choices: either put the burden of the proof on the voters, who would have a very hard time showing that these add-ins wasn't used for any hanky-panky, particular because of Diebold's bogus "propietary code" argument. This is really all SDent's "honest questions" amount to, and it is quite easy to answer: No thank you, we don't want to buy programs with backdoors in them, ...A lawyer might say the presence of such unusual add-ins is prima facie evidence of tampering, ...

SDent: Unless I missed something, I think the eventual discussion ended up stating that the add-ins aren't bizarre or prima facie evidence of tampering, but rather an add-in that was used to increase security! (by ensuring the code hasn't been changed, perhaps by those who mean to tamper). I do agree the add-in should not be left on the machine because it creates its own security hazard, but to say that its presence is prima facie evidence is a stretch in my opinion, given that there is a reasonable reason for putting it there in the first place. I would appreciate knowing why you're questioning my honesty when I have been respectful to you and sincere in my dealings here. There's no need to rehash the nastiness of the other night, however, I noticed no apologies were exactly flying my way for the insults and wrong accusations...so scott, while I appreciate your thoughtful responses and do learn a lot from your posts as I have stated, if you're going to continually question my personal integrity and attack me personally, you need to jump back five feet. ok?

Scott: To put it most briefly: I think you're barking up the wrong tree SDent if you're searching google trying to find out more about trapdoor add-ins such as DateTimeStamp Adjuster. If we so clearly have the right to demand that software not have such potential trapdoors in the first place (after all, we're the ones soliciting the bids, we're the ones writing the RFQ), why not just say so and avoid the issue of whether a potential backdoor was actually used or not?

SDent: Judging from the emotional language being casually tossed around re: tools that have real purposes, I'd say I was barking up the exactly correct tree by finding out more about TimeDateStamp Adjuster. It may be "creepy sounding" as you call it, but its function isn't on the Twilight Zone, it's real and has a real purpose.

Scott: Now, from a technical perspective, I am a strict follower of the KISS (Keep It Simple, Stupid) philosophy in programming, and it's paid off for me in a big way, it's one of the reasons my clients have loved my programs: because I don't add all kinds of extra, fragile add-ins, my programs don't break. Lots of amateur programmers get seduced by the bells-and-whistles of ActiveX controls and OCX controls additional DLLs, in the end it just means that their programs break more often or can't be installed on additional machines.

SDent: Do your programs have a way of demonstrating that their code is the same code as the last version of the database that was installed on the machine before it? As I understand it, that's the purpose of PE Explorer, of which DateTimeStamp Adjuster is an add-in.

people use MS windows for voting software?

Well, they wouldn't. The quality of MS software is horrible. Everyone knows it. The average home PC user knows it. So why, why MS Windows?

What is the advantage of MS windows for Diebold?

Answer: It is incredibily obfuscated. It is so severely complicated, and broken from a design point of view, that it takes a huge effort to program for it. By the same token, it takes an even "huger" effort to determine the logic in someone else's program.

If I was going to pick an OS for a voting program where I wanted to install tampering code, MS windows would be my first choice, because it would make detection of the "backdoors" (or whatever) the most difficult.

in the garage. But I guess them people that burnt people at the stake to find out if they were supernatual never got a clue either.

this is another must read thread!

:kick:

I also work in IT, although on the Helpdesk side. We hate Access because of number of calls we get from users having problems with whatever DB's are written in it. On the Oracle side of stuff it is bliss.

:kick:

OK, someone was making fun of "lefties" that think Bush may cancel elections. Their instincts are good about the Right, but as we see why would Junior cancel a good thing? He now is demanding a mandate and sweep of lower offices, secure in his confidence.

Besides timely terrorism which hasn't been so cooperative for Bush since 911 how about ENRON?

IF Enron had not collapsed and succeeded in making inroads we could all be a California rolling blackout(well, selectively of course)come November 2004. Nice theory. Of course there aree other mammoth reasons why the Bushies were upset about Enron. Some elements are still in place however as the rush to get a completely electronic dependent voting system still is blitzing the states. People have no idea how many things are intertwined into a win/win for the Bush GOP.

As we look into the microscene in the programming and the state by state shady pictures perhaps the big picture of gaming in chaos will show itself. How much do individual people have locked away in their own personal databanks(skulls)? How many people have to know parts or the whole of a big picture? This has all the flavor of CIA philosophy, daring really in its trust and openness within "secret" operatives. Already Rob-georgia has found one spill with lots of names. It suggests what can happen when a federal prosecutor really gets to work.

This group has some pretty influencial people at least in California. Kim Alexander (president) has been for paper records long before David Dill came to the fore. Politicians in California follow this site.

And if you want someone who understands this thoroughly, it's her.

....GEMS are likely to take on a whole new negative connotation in the very near future.:evilgrin:

But, as usual, you are right PP!

Here's some rudimentary ways to track where the story is running in mainstream media:

http://news.google.com/news?hl=en&edition=usa&q=GEMS+Diebold

http://www.daypop.com/search?q=GEMS+Diebold&t=a

http://www.overture.com/d/search/?type=topbar&mkt=us&lang=en_US&Keywords=GEMS+Diebold+fraud

Once upon a time, Americans voted by Paper Ballot. At the end of the day after the polls had closed, neighborhood people, Democrats and Republicans, worked together to count the votes in the precinct (polling place) BEFORE the votes left that precinct. The count was then posted at the precinct polling place for all to see. This is the only way to insure a verifiable election. Variations of method are possible, but the elements of physical ballots which are counted and posted at the precinct before the ballots leave each precinct are essential to insure a fair and honest count.

http://www.votescam.com/articletwo.html

I like the decentralized nature of this counting procedure. Each precinct essentially publishes its own totals BEFORE the totals are all merged into one grand total. This does seem safer than secretly shuttling all these invisible ballots to a centralized place for a count. Subtotal each precinct first, then merge.