Electronic voting machines cheat another Democrat out of an election

The BBQ Pit
121

First of all, **Zakalwe ** always said it would take three programmers, so s/he didn’t need to *admit * anything. (I still think that estimate is a tad high, but it would depend on the requirements, and I don’t know the details. I’m not convinced they do any archiving, but then, I haven’t looked into it.) I was the one saying that the job needed only one person, and that’s because, as I explained in an earlier post, the only thing I was considering was the local tallying code on the precinct level voting machines.

As currently implemented, yes, electronic voting vachines are a *potential * threat to democracy; it’s already been demonstrated in real life that they can be pretty easily hacked in the field, regardless of the degree of security measures taken during their manufacture. Could they be implemented better? As a matter of fact (and I don’t think anyone has denied this, certainly including me), I believe they *could * be done better. Could they be done perfectly? No. IMHO, even if security were tightened, unless it were taken to the super high levels of security (Eyes Only, etc, and even that’s not any guarantee.), which is highly unlikely, they will always by the very nature of what they are and how they are made, be more vulnerable to cheating, and unprovable, untraceable cheating at that, than paper ballots, because it would truly only require a single point of failure to affect them all, and because cheating with paper ballots requires a pretty sizable set of physical objects to be introduced by either sneaking them in or giving a convincing explanation of how they suddenly turned up. PLUS, with paper ballots, the cheating would have to be successfully done at the very least once per state (and more likely, once per precinct or at least voting district). Voting machine cheating only has to be done once if it’s done at the manufacturing point.

You’re trying to back-pedal a whole heck of a lot here, Blaster. That voting machines could be *made * more secure than they currently are was not your original point; your original point was that they already *are * more secure than paper ballots, and you attempted to “prove” this by your extensive experience (both real and vicarious) in the business. It’s nice to see that at least you appear to have recognized that you can no longer bull your way through via that argument, since there are probably more programmers and/or IT professionals (almost all of whom have considerably more experience than you) on these boards than any other profession

Even so, your arrogance level has decreased very little. I suggest you recognize that, while your PhD in CS will reflect the fact that you have an excellent theoretical understanding of a particular aspect of computer science, and a pretty darn good theoretical understanding of computer science in general (and I’ll be the first to admit that your knowledge here is undoubtedly far greater than mine - I didn’t study CS at all, and have about zero interest in persuing tech topics on my own time), your knowledge of how things actually work in the real, commercial world is quite limited. In short, get over yourself a little; it will actually make it easier for you to convince others of your viewpoint if you enter a discussion with some of the humility your actual situation merits. (It will also make it easier to get a job, if you want to go into the real world. Very few people want to hire a cocky kid who thinks he knows everything there is to know when his experience is in fact limited to university projects (whether for profit or not). And like it or not, that’s sure as hell how you’ve been coming across in this thread. At best, this will get you seriously laughed at behind your back, or even to your face.) No one is denying your knowledge of computer science. But computer science isn’t the issue here. Actual implementation methodology, both *de jure * and de facto, at *commercial * companies (and make no mistake; they differ significantly from government contracting) is the issue here. And in this respect, your knowledge is very limited. If you ever do go into the real world, you will see some things that will make your hair stand up on end. I *still * get shocked sometimes at the laxity of certain procedures at some companies.

Oh, last but not least, speaking of reader comprehension (which you seem to do quite frequently), I am a she, not a he (and have mentioned that at least once in this thread), and my point in asking your age was was not that my age alone gave me any special knowledge of the field, but rather to shock you out of your arrogance a bit by demonstrating that I’ve been doing this for a living longer than you’ve been alive. (You *had * asked me in a rather condescending way if I had any real world experience, after all. So I guess arguing from experience only counts when it’s you and your friends.) As I should have expected, it didn’t work. But I tend to be an optimist, so I keep hoping.

122

Are you aware that of all of the machines that were installed in California, not a single one had the version of software that was actually certified by the state? Some even had versions that hadn’t been certified by anyone.

Also, Diebold does a good job of security with their ATMs. They do a suck ass job with their voting machines. Hell, for a while they actually embedded the (way too short and easy to brute force: F2654hD4) key in their code. The reporting and collection portion is also written in an interpreted language. Joe programmer might write the most perfectly secure code in the world, but the person who codes the interpreter can turn Joe’s code into a vote changing behemoth. This is not good software development.

123

But what do you need complex programming for? The essential value of a voting machine is accuracy, not immediacy. We need a standardized, simple, rugged cheap machine. And then we need the funding to make them widely and easily available, from the Slackjaw Mountains to the ghettoes.

A complex machine is also likely to be a more expensive machine, raising issues of accessibility again. As much as I might favor a full employment plan for CS grads, this isn’t the one.

124

I don’t think any complex programming is needed. In fact, other than encryption and transmission coding, I can’t think of anything that would require any special programming knowledge for e-voting. The data structure’s a breeze, and everything is else mostly interface related.

Personally, I’d rather see open-source code used for this, or at the very least, code that is available for the general public to look at.

125

What’s more, I remember hearing stories of ballot boxes disappearing, and then turning up later under suspicious circumstances. Paper ballots are the least secure method of voting available, simply because of the large number of people who must interact with them. You need a staff of people to count the votes, and in most places you need to physically transport the votes to the central counting station. Both of these are major weak points where tampering could take place. In a well-designed electronic system (and I’m not saying that the Diebold system qualifies) tallying the votes is trivially easy, and a secure encryption scheme would be able to transmit the results with very little possibility of malfeasance.

126

I’d have to look up a general cite, but I do know that our local machines don’t use any transmission method. The machines (or at least a component with the vote tallies) must be physically transported to the counting area. The explanation generally given is that most polling places are private facilities (churches and the like) and do not have consistent internet access, particularly in the gymnasiums/big meeting rooms used for voting.

127

Oh, sorry, Blaster Master, I think Oy! covered the first of your points to me (about the estimate, I didn’t “concede” anything - in fact, you stated in post 90 that you agreed with the same estimate - orginally posted in post #85 BTW).

As for the rest of your response:

Please read carefully. These were not custom built machines. Diebold designed them and built them for commercial offering. At the time they built them, they had zero orders, so any money they spent was internal. That’s why I offered the budget numbers I did. Private companies building stuff on spec rarely spend shitloads of money on them. Sometime after Diebold (and others) built these machines, various counties/states issued RFP/Qs for voting machines. Diebold said “Here’s our model 92237a VoteOMatic.” Most of the states had a certification process to pre-vet the various offerings, but as has been cited above, in many cases the certification process was a joke - at least partly because Diebold refused to make the source code available. As a summary, these machines were not built on government contract, they were built and then sold to governments as a product.

As for the OOP issue, I wasn’t the only one who misread that, so perhaps you were a bit unclear? However, I would be interested in hearing what portions of software development have changed so dramatically (please be specific, changed from what old method to what new method) since I’ve apparently failed to notice it. I have on the other hand seen several incremental improvements particularly with regard to professional standards and maturity models.

128

Apologies if I incorrect placed the assertion that it would take one person one day on the wrong person. Regardless, it seems we’ve come to the understanding that it would take more time than that.

My claim was never in regard to the current implementation. I was not aware of some of the potential security issues with how Diebold (or whoever else) had implemented it. I made some assumptions about the implementation that were incorrect when responding to Absolute’s quip that “it would be good if there were more public awareness of the problems with electronic voting machines.” However, in my next post (not counting the one arguing a different point), I said “If they’re not digitally signing ballots…heads should roll.”

After my initial incorrect assumption about the implementation, I never claimed that the current implementation was somehow perfectly secure; my point was that they’re better than paper ballots. However, despite that I agree that there are some obvious flaws in the system, I don’t buy the sensationalism that the issues with the Diebold system are as bad as they’re made out to be; at least a few of the issues that were brought up earlier were addressed.

Still, even if the current implementation is complete garbage, that doesn’t make electronic ballots a threat to democracy. If they currently are not as good as paper ballots (which I have not as of yet conceded), I hold that they can absolutely be development and implemented such that they are fully superior. They are only a threat to democracy if they cannot be implemented using modern technology in a way that is more secure, more efficient, and less ambiguous (ie, no interpretting of voter intent).

While I understand why you may interpret my responses as arrogant, that was not the driving factor. Quite the contrary, considering this is taking place in the pit, I allowed myself some leeway to add a few snide comments and be a bit more curt than I would normally be in a debate. Further, I acknowledge my personal lack of expertise in the commercial world; however, because these voting machines are being developed under government contracts or as part of government contracts and considering that I agree with your statement that “implementation methodology…at commercial companies…differ[s] significantly from government contracting”, I would argue that government contracting experience is more relevant to the discussion at hand.

This was not a lack of reader comprehension; I do remember someone participating in this thread being referenced with female pronouns. However, because I don’t associate your username (what I perceive as one that does not easily lend itself to one sex or the other) with a specific sex and it is not worth my time to go reread the thread searching for pronouns referencing you that may or may not be there, I result to a grammatical neuter. Since I abhor using “they” (at least how I was taught, it is always incorrect to be used as a singular neuter), I was using “he/him” as a neuter pronoun…yes, its less preferable than going with “one”, but substantially more natural for me. It was not meant as an insult; barring the failure of my memory (so no guarantees), I will strive to use female pronouns when addressing you in the future.

How would mentioning my relative youth “shock” me out of my arrogance? Somehow I suddenly realize I’m younger than I thought I was? Now it sounds like you’re the one backpedaling. :stuck_out_tongue:

129

Well, then this sounds like a complete an utter failure on California’s part.

So now you’re saying it may not be Diebold writing insecure code, its the company writing the development tools? Tell me Alice, just how deep DOES this rabbit hole go? :rolleyes:

130

Following the disagreement over how software development has changed significantly, I brought up the disagreement among some friends who work in the field (some in commercial companies, and many with much more time in the “real world”). As I already stated, this was in reference the the design and development. To my understanding, some time ago many software projects would have one or two programmers, often doing that more as a collateral duty. They were responsible not only for the entire job of coding, but also for all of the design and all of the testing. Generally these programmers have a full working knowledge of all of the code, and often much of the rest of the project (precisely because it was more of a collateral duty). There was no concept of development teams, development cycles, etc. Today, one of the most actively researched fields in SWE is in new design methods and patterns. You have teams of engineers, teams of designers, teams of programmers, teams of testers. One team may work on just the GUI, one team works on just the network interface, etc. Seldom does one person or one team have a working knowledge of how all the other components fit together. If this isn’t a huge change in the development paradigm, I don’t know what is.

Granted, I don’t expect there’d be 50 people working for 6 months on a project as small as this (in fact, I’d be absolutely enthralled if it was that many), but this shift in the paradigm has affected even smaller scale projects precisely because of the research and training that has resulted. Managers and designers are trained to think with these sorts of design methods and patterns in mind as opposed to the ways of old.

Of course the actual art of coding isn’t unrecognizable; we still use most of the same principles from decades ago, when accounted for new technology, new research, and new optimization and debugging methods. But, as I’m sure you’re aware, there is a lot more being a project like this than just being a code jockey.

131

Well, I guess we’ll just have to agree to disagree. The kinds of procedures and specialization you’re talking about have been in use for a lot longer than you seem to think. They get a new coat of varnish every few years - new names, new books, etc. But the actual techniques are not new, most of them pre-date me in the industry and I suspect many of them pre-date Oy!.

132

Actually, my experience is that companies are using far fewer people these days than they were when I was a baby programmer. And allowing far less time for the development effort.

Part of that is justified; there are many more convenient platforms for software development now than there were back in, well, let’s call is the Iron Age that I began, since I can’t quite claim Stone Age experience. But a lot of it is due to two factors that have nothing to do with the software development process per se. One is that the entire market has changed since I began; demands are far greater for faster and cheaper, cheaper and faster, and this is an ever increasing thing. The other is the “good enough” school of thought that I think came about with the ubiquity of Windows et al. People realized that for most applications, it simply wasn’t worth the time and expense to have absolute perfection out there. It’s good enough if things work right, say, 99% of the time, and they can reboot and fix things the remaining 1% (or whatever the numbers really are) manually. And for an awful lot of things, that is an absolutely valid approach to take. If Windows were bug free, it would probably have to cost about ten times as much as it does.

One of the many reasons that government programs are often much more expensive than commercial programs that seem comparable in size is that so many government programs are things you can’t afford to ever have fail, even once. Like weaponry, or NASA. There are comparatively few applications in the world outside of government stuff that is like that - medical device drivers and traffic control (which would probably be government again) are the only ones that come to mind immediately.

One thing you don’t seem to be getting yet, Blaster, is that there’s nothing to suggest out there that voting machines are moving in the direction of my second example (the things that have to be right, first time, every time). As far as I know, they’re still handled as commercial products, which will be sold as products to various voting districts. In short, there is nothing to suggest at this point that any government development standards or processes will be applied in their design or manufacture. If I’m wrong, please let me know on what basis.

Yes, there’s enormous effort going into the development of new software development methodologies and principles. Don’t hold your breath waiting to see the majority of them actually used in the real world, particularly at smaller companies. I work for an absolutely cutting edge company, in its actual area of work, which is pharmaceuticals in a loose sense. It is utterly dependent on the historic knowledge a few developers who have been there for many years. I’m a fairly new employee there, and I’m here to tell you that there is virtually zero documentation and zero source for finding out what a thing is supposed to do, unless I happen to get lucky and hit one that has a help text written for it (usually several years out of date, I might add). And here’s the thing; this is by no means the worst company I’ve worked for in this respect.

Last, my intention was not to point out your age to you (I figured you probably knew it). It was to point out the relation between the years of your life and my professional experience, in hopes that just maybe, somehow, that might convince you that it was remotely possible that I had a clue what I was talking about. I’m not sure how effectively I’ve done that with any of my posts.

133

For the record, any serious security audit has to include the entire build chain, including compilers or interpreters (though since interpreters can be substituted after the audit, I’d question the use of an interpreted language for any secure system). I had a long post on this subject that the board ate, but basically all the computer people who haven’t read Ken Thompson’s Reflections on Trusting Trust should do so. It’s great, and explains how to smuggle an attack past any quantity of source-level verification.

Although Thompson discusses compilers, this kind of attack can be carried out at any step in the build chain. For example, an unscrupulous person might hack up a Perl interpreter a little, add a short and demonstrably innocuous Perl script to the build process, and substitute your malicious Perl interpreter for the good one before the final build. Tricky but not impossible, even for a lone bribed programmer. To thwart this attack, you have to inspect all the MD5s on the tools used in the build process and make sure that they match those of the publically-available ones. A company that’s using homebrew build tools…can probably ensure security somehow. This is, to my mind, a strong argument in favor of heavy, oppressive government oversight and micromanagement in every step of the process, but your mileage may vary.

134

Certainly, it’s their fault for not catching, scrapping, and not paying for uncertified machines. It’s Diebold’s fault for not providing certified machines. There were versions that had been certified, but they weren’t the ones delivered to the people who certified them.

Diebold wrote the development language, AccuBasic, which I’m referring to, but nice try Alice. :rolleyes:

135

I once took a class called bucks, ballots and maps. It was about the voting process and as far as I could tell, we’re lucky we still have some semblance of a democracy.

136

Its called ballot access and there is a laundry list of techniques that were hones to a fine point in post-VRA south. These guys are amateurs.

137

Local races in NYC are often decided by a difference of a few hundred votes or less and due to a few incidents in the past, people get frisked before they go in to count the votes.