Slashdot

Once again, programmers thinking software will change the world.

Elections are not based on trust of software, it is based on trust of the PROCESS.

Don't trust the PROCESS, and it doesn't matter how trustworthy your software is.

I want an PROCESS that has ACCOUNTABILITY. A "Bug" in your software means someone goes to jail for negligence, or pays for the cost of a reelection.

Here in the great white North, we have a paper ballot. A simple "X" inside a circle. Human verifiable, countable, no switches, electrons, software, etc. Weeks or months after the election I can see the recounts.

Software can solve a lot of problems, trust is not one of them.

Early reports are now in on the software. Though it runs faster than proprietary rivals, the power management doesn't work, its not yet configured to work with touch screens, and it can only be administered by grumpy self righteous technicians who insist that voters read the man pages before voicing questions.

If so it could let a lot of counties currently stuck with that PoC switch to the open source code without buying extra hardware. Just load the free software in the existing hardware (and maybe add a printer).

The Diebold machines are essentially PCs with touchscreens so they shouldn't be a tough port for Linux and the apps.

Using the existing hardware could save a bundle.

Once they've been granted suffrage. Not before.

I post this same post every time we have a computerized vote counting thread. My objection to this has nothing to do with whether it's a secret proprietary process or a totally open FOSS solution. With each generation of computer technology we gain the opportunity to go wrong with greater speed than ever before. Yes, proprietary solutions are horrid and there's some evidence that they've been used to steal votes and they're truly evil. Unfortunately, FOSS tools can be abused too.

I guess my point is that the process of counting votes using humans is an important part of representative democracy because it doesn't just achieve the goal of "counting the vote". It also impresses on the participants the importance of sanity and trust and impartiality in the process, without which constant reinforcement we can expect democracy to rapidly go off the rails. Compared to that social good, the importance of getting same-day results fades in importance.

Come back when it is not written in an interpreted language, in a language capable of driving hardware, and it has "real" functionality. I looked quickly, and the tabulation code is virtually empty. Both the Python and the Javascript will be non-starters and the code rejected out of hand the first time reviewed (and none of the VSTL's will have anyone capable of reviewing Python). Java passes because of the bytecode. Python might pass because of the .pyc files. The Javascript will be a problem. The lack of type declarations will likely also be a problem in Python. It will be hard to follow the documentation rules that require all of the types to be documented.

None of this code stands a chance of VVSG compliance (the Federal Election standards which code must pass to be certified if any Federal funds are used to purchase the hardware or software). The list of blatantly obvious things wrong with the code base in the one file I looked in:

• The code files does not have a valid modification history for the file.
• The code does not have per function comments.
• The code uses multiple returns inside of a single function.
• Repeatedly use the same values without having them be assigned to a constant.
• Have single variable letter names that are not used for array indexes.
• Usage of numerical constants other then -1, 0, 1 without a comment explaining the value.
• Not all control flows decision points are documented.
• It has lines longer then 80 characters.

Or at least those are the obvious things I found in one example file [github.com] in the 2 minutes it took me to scan it quickly. Remember, the coding guidelines are written by people who have never written a line of code, and are designed to protect against common mistakes from the mid-80s. So the fact that the entire system is in version control is irrelevant. Even if you give them all of the version control, you must document the changes to the code at the top of the file. You must document the changes per function. Even though no one would ever do it in this day and age, your code must be printable on a standard 8.5" wide paper.

All of the rules required to follow are obscene. You can't have function or variable names that differ by a single letter. It took 3-4 years to get an exception to that rule to allow the usage of "getFoo", "setFoo", because they differ by a single letter. You can't use 0x80 to represent the MSB of a byte, if you call that PIN_8, and had PIN_1 those differ by a single character, so we had to do PIN_EIGHT, PIN_ONE. It's just archaic. Oh, and you get to document every function a function calls. Because they couldn't possible use a compiler that would build a call list automatically.

The rules don't explicitly mention exceptions, so it depends on who is reading the code if they treat an exception as having multiple entry/exit points. So it is generally easier to get the code past compliance without exceptions, even if it does lead to buggier code. The other rule they invoke is that you are only allowed to use the control flow structures documented in the VVSG (they have flow charts for the allowable forms of if, if/else, for, while, and switch statements. They specifically state that if the language you are using does not have those, you must simulate those flows of control in the language used.

Oh, and if LA thinks it has the hardest jurisdiction because they have 7 languages, I believe NY has at least 20-30 languages or dialects just in NYC, they have several election districts (they'd be called precincts anywhere else in the country, but in NY, the word precinct is only used for the NYPD and maybe the NYFD) that have more then 7.

I've written code that has been used to count ballots in both state and federal elections. Trust me, this code base will have to be re-written from scratch to meet the 2002 or

Oh for fucks sake, you have to be kidding me!

You want the Federal Election Commission to trust a voting machine written in a language used by script-kiddies?! That is utterly laughable in light of the DIEBOLD VB/Access debacle

This needs to be a completely stripped down Linux core, NOTHING in it except what is EXACTLY need to do this. It needs to be written in C, not C++, and I mean COMPLETELY documented ( to the point of inanity), PLAINLY written, VERBOSE code and if you want a better chance write it in ADA, that is what the government is used to dealing with and the code MUST be open source

You need to go as far as stripping down the standard C libraries to ONLY the functions called by the SINGLE program that makes it work

EVERY buffer, EVERY array must be bounds checked. There can be NO POSSIBILITY of ANY kind of a buffer overflow attack.

If you are going to use an off the shelf MB any open slot and or connector not used by a component SPECIFICALLY required to make it work must by PHYSICALLY disabled ( cut the traces/wires or whatever ). The BIOS must be custom,designed and coded to do ONLY those functions require to boot the machine, further that BIOS must be OPEN SOURCE.

As others have pointed out the PROCESS must be VERIFIABLE, it must be RELIABLE, it must be PREDICTABLE 100% of the time. There can be NO race conditions, there can be NO un-handled exceptions, and EVERY exception must have a reliable, repeatable, reproduceable result, in other words "Kernel Panic" is NOT an option.

In short it must be a totally custom machine, and created by people 100% NOT interested in getting rich.

Voting machines are inherently untrustworthy. Publish all the code you like. Have it inspected by Donald Knuth. The voters have no way of knowing that that code is what's actually running on the machines in the polling stations, or that the hardware will execute it in the way that the language spec says it should. Attempts to give them a way to know are a sticking plaster over a gaping wound - there are too many things about the machine that are invisible to the naked eye, and too many ways in which the machine can be made to lie.

Paper-based elections need a lot of people to run them. This is a good thing, because someone who wants to rig an election has to bribe or threaten a lot of people. The more people are in that position, the more likely one of them is to blow the whistle. Someone who wants to rig an election that's run by voting machines has to influence far fewer people. That's the whole point of computers - they do work that would otherwise have to be done by people. If you want to bring in lots more people who are hard to bribe or threaten, you might as well have them run the election and leave the computers out of it.

The argument that voting machines will give us the result of the election faster than paper ballots is true but irrelevant. Do you want the wrong answer in half an hour, or the right answer in two days? A politician, once elected, will serve for three to five years, and unless he drops dead or gets a blowjob from the wrong person, it's very hard to remove him before the next election. You'd better be damn sure that the guy you put there was the one the people actually wanted.