Reply #81: Followup from Access programmer ScottXYZ

[scottxyz]

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.


= = =