April 17 - Eletronic Vote

[K^2]

[quote="Greg Dean";p="733355"]No, it does not imply it's not easy, it implies THEY DON'T KNOW WHAT THEY'RE DOING. If that's the case, the person responsible for programming the machine should be shot. There's any NUMBER of checks that can be run to prevent such a thing from happening. It IS trivial - apparently those guys aren't very good at trivia.[/quote]
It is not trivial. Code for something like this does not just add numbers. Code must initialize by loading data on candidates and any fonts/graphics for the GUI. Then, code must continuously render GUI while being prepared to respond to key press or screen touch events. And only once all this is processed, and the vote is acknowledged, a tiny portion of the code actually counts the vote.

Within all that, there are a number of things, generally unlikely things, that can happen that cannot be checked for. Not a very long time ago I was writing a parser which, among many other things, had to respond to certain key words. The thing worked perfectly, until it encountered a key word with exactly 8 letters in it, at which point it would start making errors, until it finally crashed. Any other number worked, but not 8 letters. I spent nearly 24 hours with that code trying to figure out what was going on. Problem? Combination of an oversight and the way that memory management worked. Memory was allocated in 8 byte blocks, and I forgot to allocate extra byte for null character. On 8 letter words, null character fell into unallocated memory, and messed up the data used by memory management. Errors began once the program attempted to allocate more memory.

Now tell me this. Could any programmer anticipate such an error? It's great if it happens in testing. Then it's programmer's duty to fix it. But what if it doesn't? Can you really test the program with every possible set of inputs? Almost never. And if you can, then what's the point of the program. And this is just a simple case, when memory leaks cause a crash. Sometimes memory leaks just cause corrupted data. How do you check for that?

[All-Purpose Guru]

The issue isn't so much the way that the votes are counted, the problem comes from several directions--

The voting software is considered to be proprietary property of the company that makes the machines. Therefore, they are reluctant to let anyone see it.

The voting software has serious flaws in it (which may be the reason for the above reason.)

The voting machines don't always have any way to *verify* an election was correctly tallied, which you *do* have in a paper ballot system.

The issues with paper ballots came about when an election for President came out very very close, and the recounts demanded uncovered a bunch of inconsistencies that stemmed from the inability of some people to properly operate the mechanical ballot machines. That what a "chad" is, it's an improperly punched manual ballot. The ballot counters had to come up with standards for dealing with the improper punches that let to questions as to the validity of the elections. With an election costing several million dollors to conduct, you want it to be correct the first time.

Some states have simplified the process entirely by going to a completely paper-based system and no voting machines-- for example, in Oregon everyone votes by mail, marking machine-readable ballots that get mailed to a central location and scanned.

As a software engineer myself, I can understand why sometimes crap gets into systems-- I can come up with at least 3 different reasons why the bug Greg mentioned might have gotten into the code. I write the code for toys, which have very serious hardware and software limitations. You think you write tight code? Try getting 26 different pieces of music plus the code to select and play that music into 32k of ROM with a processor that can't multiply.

Depending on what kind of system the Diebold people are using, it might have been necessary to crunch the code down so much that it was necessary to do crufty code like that in order to make it all fit.

[Gowerlypuff]

[quote="K^2";p="733449"][quote="Greg Dean";p="733355"]No, it does not imply it's not easy, it implies THEY DON'T KNOW WHAT THEY'RE DOING. If that's the case, the person responsible for programming the machine should be shot. There's any NUMBER of checks that can be run to prevent such a thing from happening. It IS trivial - apparently those guys aren't very good at trivia.[/quote]
It is not trivial. Code for something like this does not just add numbers. Code must initialize by loading data on candidates and any fonts/graphics for the GUI. Then, code must continuously render GUI while being prepared to respond to key press or screen touch events. And only once all this is processed, and the vote is acknowledged, a tiny portion of the code actually counts the vote.

Within all that, there are a number of things, generally unlikely things, that can happen that cannot be checked for. Not a very long time ago I was writing a parser which, among many other things, had to respond to certain key words. The thing worked perfectly, until it encountered a key word with exactly 8 letters in it, at which point it would start making errors, until it finally crashed. Any other number worked, but not 8 letters. I spent nearly 24 hours with that code trying to figure out what was going on. Problem? Combination of an oversight and the way that memory management worked. Memory was allocated in 8 byte blocks, and I forgot to allocate extra byte for null character. On 8 letter words, null character fell into unallocated memory, and messed up the data used by memory management. Errors began once the program attempted to allocate more memory.

Now tell me this. Could any programmer anticipate such an error? It's great if it happens in testing. Then it's programmer's duty to fix it. But what if it doesn't? Can you really test the program with every possible set of inputs? Almost never. And if you can, then what's the point of the program. And this is just a simple case, when memory leaks cause a crash. Sometimes memory leaks just cause corrupted data. How do you check for that?[/quote]

Paragraph 1) They're different loops. You don't stick your Render functions in your update loops. Put the graphics engine and the input system in different classes, they don't need to work together

Paragraph 2) Unfortunate Error, I've had a few of them in my time, at least two far more annoying than that

Paragraph 3) Well, yes, yes, I do. If you can't, why are you programming. Design some test principles that, while they may not test every possible thing ever, test at least every possible case. That's what QA is for. I would assume these voting machines have to undergo rigorous testing before they are used.

The counting system I would imagine being used here should be pretty idiot proof. I can't imagine it being hard to write.

Code: Select all

if(mTouchScreen.IsValid() && mTouchScreen.ValidityChanged()) // touchscreen pressed
{
    mPersonSelected = CalculateSelection(mTouchScreen.mPosition);
    maCandidateVotes[mPersonSelected]++;
    meCurrentState = VOTE_STATE_DONE;
}

Is there anything more than that that needs to be done? Obviously this doesn't have any security at all in it, but just make it an UNSAFE function so that only code that declares their unsafe reason correctly can use it and you should be all set.

[Bigity]

[quote="BtEO";p="733430"][quote="Kruador";p="733289"](Still using hand-counted paper ballots in the UK, not software written by weasels.)[/quote][quote="Bigity";p="733291"]Are you seriously trying to say hand counting is a better process than electronic machines?[/quote]
It works well enough for us. Except for cases of multiple recounts the results are all available by the following morning. The logistics involved with voting in the especially low population density areas of America do lead me to suspect that it wouldn't work so well for you.[/quote]

First of all, who said anything about it 'working'. Both systems work. Both are manageable and currently used. One is more efficient than the other. One system is newer and has some hurdles to overcome. One is old and will never overcome it's hurdles, as it is a manual process.

[Deacon]

[quote="K^2";p="733449"]It is not trivial. Code for something like this does not just add numbers. Code must initialize by loading data on candidates and any fonts/graphics for the GUI. Then, code must continuously render GUI while being prepared to respond to key press or screen touch events. And only once all this is processed, and the vote is acknowledged, a tiny portion of the code actually counts the vote.[/quote]
Oh please. I'm no programmer, and even I can write a GUI app in Visual Basic that can reliably count the number of times a button's been pressed and write out that information to a text file for verification, etc. It should be easy enough to check to make sure the initial values are 0, and rather than simply incrementing a particular variable, you could record and instance of a vote to another source each time and count them up after the fact to verify that they match, etc. It's really not that hard to make sure that the vote count is accurate. The only potentially hard part is making sure that nobody who has physical access to the data is replacing the legitimate results with their own set. Even then it could be written to some Flash ROM or whatever internally so that it can be verified after the fact, assuming that ROM isn't easily cracked. There will always be the potential for a breakdown or a breach somewhere, but to say that it's perfectly reasonable for the breakdown to be that they're not checking to make sure the values are 0 when starting out (like in the previous example in this thread) is ridiculous.

Now tell me this. Could any programmer anticipate such an error?

Yes. And if they don't, it should be caught in testing. And if they're not testing thoroughly, they should be drug out into the city square and shot.

Sometimes memory leaks just cause corrupted data. How do you check for that?

Are you serious? Run a bounds checker, have your code peer reviewed within the organization. Perform extensive QA on it. It's a critical system with the benefit of a fairly closed and consistent/uniform environment. It shouldn't be impossible.


[quote="All-Purpose Guru";p="733450"]The voting software is considered to be proprietary property of the company that makes the machines. Therefore, they are reluctant to let anyone see it.[/quote]
Yes, yes, open source and all that, but the vast majority of commercial software (much less complete hardware/software solutions like the voting machines) are closed source and are a helluvalot more complex, and they generally still manage accomplish the basic purpose for which they're created.

The voting machines don't always have any way to *verify* an election was correctly tallied, which you *do* have in a paper ballot system.

Why not?

Some states have simplified the process entirely by going to a completely paper-based system and no voting machines-- for example, in Oregon everyone votes by mail, marking machine-readable ballots that get mailed to a central location and scanned.

How do you know the piece of mail is from the actual person in question? What if the person marks an item incorrectly, or marks two of the same item? What if the sheet gets lost in the mail, is accidentally destroyed in a fire, or simply falls into a puddle? What if the address on the envelope isn't legible or is smudged or whatever? There are tons of things that can go wrong, there, and you're STILL using MACHINES to count up the votes and are hoping that they give you a reliable tally.

Depending on what kind of system the Diebold people are using, it might have been necessary to crunch the code down so much that it was necessary to do crufty code like that in order to make it all fit.

Ridiculous. It's a complete solution for which a tremendous amount of money is being paid because it is a critical system. There's no reason for them to use such incredibly restrictive hardware, and there's especially no reason that they would fail to have a team made of QA and engineering personnel and hopefully trusted outside consultants whose sole job is to figure out a way to break it or hack it or generally fuck with it in some way.

[Fry-kun]

One of the first rules you learn in IT: if the physical security is breached, that's the end of the line - you must treat the system as compromised.

Traditional programming does not take into account uncontrolled physical access - that's part of why this task is not trivial. Just think - computer must check everything you can and can't think of; NONE of the inputs can be trusted.
Your average programmer is not used to having to think this way - and that's where the problems arise.

Again, these systems are not trivial. Thinking they are is what causes problems in the first place.

Edit:
Also, I suspect the main part that companies are concentrated on is authenticating the voter - so that nobody would be able to vote twice.

[Deacon]

[quote="Fry-kun";p="733515"]Traditional programming does not take into account uncontrolled physical access - that's part of why this task is not trivial.[/quote]
How so? Why would anyone have uncontrolled physical access to the internals of the closed system?

Again, these systems are not trivial. Thinking they are is what causes problems in the first place.

Who said the systems are trivial? It's been pointed out that they're actually critical and must be complex enough to guard as well as possible against breaches and tampering. Your first post mentioned an issue where they were adding up all the values together to see if the total sum was zero. THAT is an issue you could call "trivial" from the standpoint that it's an incredibly simple thing to get so wrong.

Also, I suspect the main part that companies are concentrated on is authenticating the voter - so that nobody would be able to vote twice.

I wouldn't imagine so. There seemed to be a hardware key when I voted on electronic machines, and the human beings running the thing were tasked with validating that one person only voted once. They put the hardware key in, you voted, and you couldn't vote again until they'd removed the hardware key and reset it. The system didn't know or care who I was (and that's by design).

[Bigity]

That doesn't make a whole lot of sense. (Responding to Fry-kun)

Physical security is separate from InfoSec. You eliminate areas were unauthorized intrusion might occur, such as locking down unused ports, removing the Everyone group, not using DHCP without reservations, etc, but you cannot feasibly design and develop applications to enforce physical security.

[pc486]

I figured this comic would touch a nerve, so I wanted to toss in my two cents . There's enough to write on this topic that it can serve as a dissertation, so I'll try to keep it short.

Counting is trivial, so long as bounds and conditions are proved, such as not trying to stuff "3 billion" into a signed 32 bit integer. Distributed counting, however, is nontrivial. There are many kinds of errors that can slip in when you get independent units working together as a whole.

My main beef with electronic voting is detecting and reliably correcting for failure. Data from each machine can be changed accidentally by bugs, maliciously by humans, or even simple failure of hardware. This problem is solvable, but very difficult to implement correctly. Details are often covered in distributed computing books near the cryptography section or in some crypto books.

I'm also somewhat bored, so I'm going to pick on example code by Gowerlypuff.

Code: Select all

if(mTouchScreen.IsValid() && mTouchScreen.ValidityChanged()) // touchscreen pressed
{
    mPersonSelected = CalculateSelection(mTouchScreen.mPosition);

There is a possible, but improbable, race condition here. The touch screen condition can change between the test and the sampling of mTouchScreen.mPosition. There is also a disregard to errors returned or thrown by CalculateSelection. Touchscreen hardware that I've ran into reports positions and touches similar to a mouse. It'd be better to process this kind of input as an event queue instead of an abstracted busy-wait sampling loop.

It wouldn't be fair without giving some code of mine, so here's my shot:

Code: Select all

(defun register-vote (canidate)
  (as-transaction
    (commit-to-flash (print-ticker (crypto-sign canidate)))))

; event := '( type value )
(defun process-event (event)
  (if (eq (car event) 'vote)
    (register-vote (cadr event))))

(loop do
  (mapcar #'process-event
    (button-mapper (get-touchscreen-events))))

K^2:
I've run into a number of buffer overrun errors myself, but you shouldn't be making them anymore. If you're still stuck with C or C-like languages, then check out the source to vsftpd. In there is str.[ch] which is a great implementation of proper string handling in C.

[Martin Blank]

[quote="Deacon";p="733512"][quote="All-Purpose Guru";p="733450"]The voting software is considered to be proprietary property of the company that makes the machines. Therefore, they are reluctant to let anyone see it.[/quote]
Yes, yes, open source and all that, but the vast majority of commercial software (much less complete hardware/software solutions like the voting machines) are closed source and are a helluvalot more complex, and they generally still manage accomplish the basic purpose for which they're created.[/quote]
It doesn't need to be open-source software, but there are numerous companies that demand that no one be allowed to review the code, even those certified by the state purchasing the system and signing a non-disclosure agreement. I'd be much happier with an open-source system, though.

[quote="Deacon";p="733518"][quote="Fry-kun";p="733515"]Traditional programming does not take into account uncontrolled physical access - that's part of why this task is not trivial.[/quote]
How so? Why would anyone have uncontrolled physical access to the internals of the closed system?[/quote]
Electronic voting machines are sent out to voting precincts, which do not usually have full-time elections officials present. They arrive at least a day ahead of time, and 'tamper-proof' can sometimes mean 'most people can't open it'; occasionally, tamper-proof labels can be opened by the old steam tricks and a little patience. This is one of the major reasons that paper receipts were implemented, as their presence makes it far more difficult to interfere in an election by manipulating bits inside of the boxes.

[quote="Bigity";p="733523"]Physical security is separate from InfoSec. You eliminate areas were unauthorized intrusion might occur, such as locking down unused ports, removing the Everyone group, not using DHCP without reservations, etc, but you cannot feasibly design and develop applications to enforce physical security.[/quote]
Not anymore, it's not. We're routinely involved in the physical security of the network nowadays, including helping select cabinets, performing walk-throughs, and even the occasional informal test of things. I've pointed out cases where a system is very accessible to someone with two paperclips because a server KVM is left open and there are grill holes in the cabinet. SCADA systems are getting connected to the IP network, which means that electronic door lock systems may be vulnerable, not to mention water and sewer pumps, electrical systems, and generators.

I'm actually pressing slightly to allow us to do things like remote copying of our new Prox cards (which went in over my protest, but I tend to be paranoid over wireless) as well as picking locks, but I doubt we'll be able to do much.

[K^2]

[quote="Gowerlypuff";p="733451"]Paragraph 1) They're different loops. You don't stick your Render functions in your update loops. Put the graphics engine and the input system in different classes, they don't need to work together[/quote]
And that means that they can't cross leak? Do you know what kind of architecture these things can be running? If you are running a complex enough operating system, you can put these things in different threads and be reasonably sure that there is no cross leakage, other than through whatever memory will be used for communication between the threads. That's if whoever designs the machines decides that there is a good enough reason to separate the program into threads. But can you even be sure that there even is an OS? And if your voting program runs on the OS protection ring, your GUI code could corrupt the stack, resulting in any part of your code getting executed on return.

[quote="Gowerlypuff";p="733451"]Paragraph 3) Well, yes, yes, I do. If you can't, why are you programming. Design some test principles that, while they may not test every possible thing ever, test at least every possible case. That's what QA is for. I would assume these voting machines have to undergo rigorous testing before they are used.[/quote]
You don't know what every possible condition is. Code may react to the length of the candidates names, it may have a buffer overflow in the logging system after so many votes are cast. It could happen just when a certain vote ID falls onto a certain position in your log, all because some pointer is a byte off. These things cannot be predicted. Yes, you test for them, but they sometimes slip through the testing process. It shouldn't happen often, and with good programmers it doesn't, but it still happens. It is unavoidable. Now, if you see something like this happen to the same programmer more than once, then you get a full right to throw rocks at him.

Are you serious? Run a bounds checker, have your code peer reviewed within the organization. Perform extensive QA on it. It's a critical system with the benefit of a fairly closed and consistent/uniform environment. It shouldn't be impossible.

Bounds checker will only check if you write to memory that was not allocated. This has two very dangerous catches. First, if your leak compromises the book keeping done by malloc/new and free/delete code, as in the example I gave. Fortunately, such bugs almost always result in the crash, because you eventually end up outside of your segment, and trigger a GPF. Second possibility is far worse. Your code leaks into data already used by your code. No bounds checker will ever catch that. No crash will occur, because the segment protection is not violated, and everything goes on as normal, only some variable somewhere now holds a wrong value.

As for peer review, it's all great, but if you think that any of your peers are seriously going to look through your code, one that appears fine, carefully enough to miss a +1 error somewhere in your buffer size computations, you are very much mistaken.

I've run into a number of buffer overrun errors myself, but you shouldn't be making them anymore. If you're still stuck with C or C-like languages, then check out the source to vsftpd. In there is str.[ch] which is a great implementation of proper string handling in C.

I don't run into them as logic errors, but every once in a while I can make a typo. Usually, I check for that stuff, but when I have a binary tree implementation of an N-tree running with a lot of activity on it, my first instinct is to look for bugs in that area, causing some of the simpler things to get overlooked.

And I try to use libraries as little as possible. Knowing the kinds of errors I sometimes make, I really don't want to introduce someone else's bug into my program. At least, my own bugs I can fix.

[pc486]

[quote="K^2";p="733675"]And I try to use libraries as little as possible. Knowing the kinds of errors I sometimes make, I really don't want to introduce someone else's bug into my program. At least, my own bugs I can fix.[/quote]
I do not agree. Using tried and true libraries is a great way of keeping bug count down (especially true for common programming tasks like data structures). Very well known implementations, such as Kazlib, are extensively reviewed by many competent programmers. They are as bug-free as you can get with added benefits of good performance and strong portability out of the box.

Besides, there's nothing stopping you from reading the source code and fixing any bugs in it. Any decent debugger will point out the problem quickly.

[K^2]

The problem with that is that I'd spend just as much time studying library code to the point where I'm comfortable with it as I would writing it from scratch most of the time. In the situations when I'm working with a team, and when time is an issue, I work with what I have. But when I'm doing things on my own time frame, I prefer to know what every line of code does. Of course, there is an inherent limitation of this due to big chunks of the process being obfuscated by the OS and drivers. Sometimes, I really miss DOS.