Forgot your password?
typodupeerror
Government Politics Your Rights Online

Open Source Voting Software Concept Released 121

Posted by Soulskill
from the one-for-you-and-two-for-me dept.
filesiteguy writes "Wired is reporting that the Open Source Digital Voting Foundation has announced the first release of Linux- and Ruby-based election management software. This software should compete in the same realm as Election Systems & Software, as well as Diebold/Premiere for use by County registrars. Mitch Kapor — founder of Lotus 1-2-3 — and Dean Logan, Registrar for Los Angeles County, and Debra Bowen, California Secretary of State, all took part in a formal announcement ceremony. The OSDV is working with multiple jurisdictions, activists, developers and other organizations to bring together 'the best and brightest in technology and policy' to create 'guidelines and specifications for high assurance digital voting services.' The announcement was made as part of the OSDV Trust the Vote project, where open source tools are to be used to create a certifiable and sustainable open source voting system."
This discussion has been archived. No new comments can be posted.

Open Source Voting Software Concept Released

Comments Filter:
  • by Anonymous Coward on Friday October 23, 2009 @10:12PM (#29853745)

    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.

    • Re: (Score:3, Insightful)

      by Darkness404 (1287218)
      Yeah, but honestly I trust a properly programmed machine a lot more than I do humans. Why? Humans make errors, lots of them. Sure, most of us could count 50 votes with 100% accurately, but 500? 1000? If you are volunteering to count votes chances are you are politically involved, after all what is the harm in adding a few votes here and there... The problem results from how various companies have screwed up something as simple as if vote = yes then add 1 to variable Yes, if vote = no add 1 to variable No an
      • Re: (Score:3, Insightful)

        That's why votes are counted by groups of people who make sure they are valid and, in some cases, will have counters making sure the counting remains politically balanced. Not by a single person.

        • That's called "public oversight" and with an "unbroken chain of custody", there will never be a failure. Break one of the TWO and FAIL but the same thing goes for electronic vote tabulation devices, break say chain of custody because humans can't see the signal representing the vote and you break the chain of custody.

          CHAIN OF CUSTODY IS THE PROBLEM

          ALL HARDWARE FAILS THIS DILEMMA
          SOFTS RUNS ON THE HARDWARE

          FRAVIA'S GHOST HATES YOU IDIOTS!

      • Re: (Score:3, Insightful)

        by camperdave (969942)
        Ballots are counted by a number of people. There are scrutineers from the various political parties watching. Also, the number of ballots collected needs to match the number of ballots issued. You can't just add some.
      • by CastrTroy (595695)
        Problem with computers is that there is no way of verifying what software is running on them when I walk up to them on election day. And since there are many people (who I wouldn't trust) handling the machines, transporting them from the factory to the warehouse, guarding the warehouse, cleaning the warehouse, transporting to the polling station, setting them up at the polling station. I would be much more inclined to trust pen and paper as I could check the box was empty at the start of the day, check th
        • by ITEric (1392795)

          Having the software as open source at least addresses issues with what the computer does behind the screens. The computer does what it is programmed to, and the code is available. The issue is in trying to ensure that the program is not altered before it is installed on the machine.

          Paper ballots are not without their own problems including stuffed ballot boxes and lost or altered ballots. For that matter, there have been issues with voters being able to get to the polling places in the first place.

          If the

          • by CastrTroy (595695)
            There's also the issue of ensuring the software isn't changed "AFTER" it is installed on the machine. MS, Sony, and Nintendo have put a lot of research into not getting pirated games to run on their system. They still haven't done it right. I don't see how the companies making the voting machines could do any better.
      • by lawpoop (604919)

        Yeah, but honestly I trust a properly programmed machine a lot more than I do humans.

        Those machines don't run on their own, you know. I think you can only trust a machine, properly programmed or not, as far as you can trust the person operating them.

    • Re: (Score:3, Insightful)

      by loteck (533317)
      Why can't open-source, verifiable software be part of your hallowed PROCESS? It can. And ought to be. Software engineers have a legitimate seat at this table.
      • "Open Source Voting Software Concept Released"

        Everybody read this again. Only the concept was released. No actual code is available yet... :-)

        • But politically OSV are in place. NOT GOOD!

          FUCK ELECTRONIC VOTE TABULATION DEVICES
          they caused every problem the United States now has!

          • Agreed.

            I don't understand what is the damned rush to get the votes tallied up and a winner announced the night of the election. I say, take your time, get a bunch of little old ladies to count them up, and so what if the results come in the next day, or even the next week?

    • Re: (Score:1, Funny)

      by Anonymous Coward

      no switches, electrons, software, etc.

      One would think you would have trouble forming paper ballots, or any macroscopic matter, without electrons....

    • by jipn4 (1367823)

      I want an PROCESS that has ACCOUNTABILITY.

      You apparently want a pony. Whatever the process and accountability may be with FOSS voting systems, they are almost certainly better than anything Diebold has been offering.

      A "Bug" in your software means someone goes to jail for negligence, or pays for the cost of a reelection.

      If that's your standard, only crooks will provide voting software.

      Here in the great white North, we have a paper ballot. A simple "X" inside a circle. Human verifiable, countable, no switche

    • Re: (Score:2, Interesting)

      by joshuaheretic (982785)
      I personally prefer paper ballots as well, and you're right that it's all about trust in the process. However, the fact is that many areas are rolling out electronic voting whether we would like it or not. And in a narrow field of options, I would like more than just a buggy, black-box Diebold piece of shit. If they can provide an OSS solution that works and can be audited for security and reliability, that would be infinitely preferable to the proprietary options with a poor track record. Just make sure
      • "the fact is that many areas are rolling out electronic voting whether we would like it or not."

        Oh Truth. So sweet.

        Remember here in California we used electronic vote tabulation devices to vote for more electronic vote tabulation devices? Don't even try to say no.

        "I would like more than just a buggy, black-box Diebold piece of shit."
        Hell I want the fucking US Constitution restored. Right now we have officials who were elected using "a buggy, black-box Diebold piece of shit." They know the machines are b0r

      • No receipts.

        Boss asks who you voted for. You pause, remembering past instances overhearing his views and how much you disagreed with them.

        "The other guy," you say.

        "That's good. That's good," he replies. "Got the receipt?"

        Feel free to replace boss with anyone in the position to influence your voting habits via unpleasantness.

    • by mcrbids (148650)

      No PROCESS based on closed-source software can ever be trusted for elections.

      Having a free, open-source voting system at lesat opens the door to a possibility. I'm not saying software-based voting systems are the best. But having more options is generally a good thing...

    • The thing is that the method being trustworthy is necessary, though not sufficient, for trust of the process. With Diebold, a blatantly untrustworthy system mired in problems with bias, incompetence, and lack of security, it doesn't really matter how much I hypothetically trusted the government deploying it.

    • it is a very good news.i want to buy this software. Muscle Might [ezinearticles.com]
    • lol...you don't think paper ballots can be cheated? It's trivially easy to break that system and it happens in countries around the world every fucking year. Deep down I know you realize that. It's not that you trust paper. It's that you don't trust electronics. There's a difference
      • And in every case where paper ballots were "cheated" there was a "broken chain of custody."

        Put that in your pipe.

        • "And in every case where paper ballots were "cheated" there was a "broken chain of custody.""

          Really? You pulled that out of your ass. Prove it.

          For the time being, I'll let your lie go and argue the point anyway:

          Chain of custody is purely process lingo (i.e., bullshit). It works great until you have corrupt officials involved, at which point your precious process isn't worth fuckall.

          Stick that in your pipe.
    • by Casandro (751346)

      Absolutely, the problem with software or complex hardware of any sort is that the average person cannot verify it working. The simple "paper and pencil" approach can be understood and verified by everybody, even people who cannot programm or cannot reverse-engineer complex microelectronics with their bare eyes.

    • The PROCESS doesn't matter if the HARDWARE has been specially crafted at the doping level. How many of you in the OSV are checking the hardware with an electron microscope? None. I rest my case, Open Source Electronic Voting will Never fix the problem with a broken chain of custody.

      Broken Chain of Custody IS the problem.

      Although, what will likely happen.. is the OSV will somehow manage to snow over officials and Debra Bowen. You'll get open source to replace closed source, but the hardware will still be a

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

      Amazing quote. I just loved your ending line quote. Thanks for that. Makes a lot of sense!

    • by Strilanc (1077197)

      I am constantly amazed at the cynicism from Slashdot about electronic voting. Yes, the existing systems have generally sucked. A lot. But that doesn't mean it's impossible to do.

      The fundamental problem which must be addressed is verifiability. In order for the election to be secure, you must have a process which guarantees that tampering will be detected with high probability, **even if a malicious company designs a large portion of the voting machines**. This is not an impossible problem!

      For example, suppo

      • Re: (Score:3, Informative)

        by Walkingshark (711886)

        Or, you could just do it the obvious way that no one ever talks about:

        1) You fill out your ballot electronically (on a touch screen or whatever)
        2) Ballot box prints out a human-readable ballot.
        3) You check over to make sure there are no mistakes
        4) You carry your ballot over to the ballot box and drop it in, where a scanner scans the ballot in and counts your votes.
        5) Later, if there is a problem, humans go back and count the votes by hand (as they do now)
        6) There you go, all the benefits of electronic votin

    • 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.

      Oh, so you're one of them, are you? I always use a checkmark, which indicates positivity! ;)

    • Without trustworthly people in the process you can't have a trustworthy process, agreed. However, since E-Voting is something that many IMO misinformed politicians still want, it's important to have an option which is open and thus verifiable.

      I live in Germany where the X in the box on paper marks your vote, I still find it hard to believe that anyone could want electronic voting under the primise (trust me, I'll count your vote). What is it that is so difficult with Paper? Like you said, it is verifiable a

  • Sweet! (Score:2, Redundant)

    by tobiah (308208)
    That's pretty cool.
    • Re: (Score:3, Insightful)

      by Brian Gordon (987471)

      No it's not. Slashdot was up in arms against electronic voting when it was closed-source. Open-source doesn't make much of a difference.

      And Ruby? Linux? What. Assuming they compile Ruby into java bytecode or something to sidestep the FEC regulation against interpreted code in voting machines, Ruby still isn't a great choice. It should run absolutely as close as possible to bare metal to make sure a JVM bug or a Ruby bug doesn't affect the results. Anyway, why Ruby? Not that I have anything against it but re

      • Re:Sweet! (Score:4, Insightful)

        by Darkness404 (1287218) on Friday October 23, 2009 @10:52PM (#29853889)

        No it's not. Slashdot was up in arms against electronic voting when it was closed-source. Open-source doesn't make much of a difference.

        While I still think we should use paper ballots (what exactly does e-voting gain us?) it makes a world of difference if the code is open or closed source. Voting is all about trust, if I can see the source and verify that it doesn't have any major bugs in it that is a step in the right direction compared to closed source. Secondly open source is cheaper, I don't want my tax dollars wasted on proprietary software, especially if there is an open source alternative. If we are going to have e-voting, it had better be open source, closed source is unacceptable.

        Ruby still isn't a great choice. It should run absolutely as close as possible to bare metal to make sure a JVM bug or a Ruby bug doesn't affect the results.

        Sure, but it does provide more readable and testable code while reducing the risk of hardware dependent errors. I think most people can say with certainty that the Ruby interpreter is reasonably stable as is the JVM.

        Linux wouldn't be my choice for a kernel either. It's too experimental and rapidly changing for me to feel great about asking 300 million people to trust it

        Does Linux change? Yes. Does that affect the stability of a certain kernel version? No. If they stick with 2.6.31.5, it doesn't matter if 2 months from now if 2.6.32 comes out because 2.6.31.5 will still run with no problem (outside of some serious bug), everything in voting machines should be static, no new hardware, no new software, just configuration changes. Linux has been running in embedded systems just like what I described for years now with no problems.

        • Re: (Score:3, Insightful)

          by Plunky (929104)

          if I can see the source and verify that it doesn't have any major bugs in it that is a step in the right direction compared to closed source

          You do know though, that the source is not the code that is running on the machine iself, right?

          How do you propose to verify that the source code has not been altered before or during the compilation process? I guess, since the source is available you could compile it yourself and write down the checksum to compare with the voting machine binary checksum. Wait, how do y

          • How do you propose to verify that the source code has not been altered before or during the compilation process?

            That's close, but not the entire problem. The entire problem is all these electronic signals (+5v High) (+3v Low) are running on chips which you never watched the doping process for. These signals furthermore are invisible to the human visibility spectrum.

            What are we going to have poll watchers walk in with a spectrum analyzer, freq counter, logic analyzer, O scope, and simpson meters? I don't fu

        • Re: (Score:2, Insightful)

          by TBoon (1381891)

          While I still think we should use paper ballots (what exactly does e-voting gain us?)

          e-voting gains the ability to know the results instantaneously the moment voting ends, and saves lots of man-hours counting them. The former is pointless, as any hand-over of power never happens until days/weeks/months later, and neither are worth eliminating the possibility of a recount.

          Machine-readable paper-ballots seems to be a decent compromise. Instant results with recount possibilities. A smallish number of humans can double-check some samples to ensure the machine results are correct, and trigger la

          • by fgouget (925644)

            Machine-readable paper-ballots seems to be a decent compromise. Instant results with recount possibilities. A smallish number of humans can double-check some samples to ensure the machine results are correct, and trigger larger manual recounts if there is reason to believe the machines malfunctioned or were tampered with.

            The problem is that no one will want to doa manual recount when the result is (thought to be) already known. Furthermore, if the recount is not done immediately in the polling station when the election closes, then it means you have to move the ballots and store them waiting for a recount. During that process they escape public oversight, be it while they are in a police truck being moved around, or while they are in the 'secure' storage facility. That opens plenty of opportunity for officials to tamper wit

        • by fgouget (925644)

          While I still think we should use paper ballots (what exactly does e-voting gain us?) it makes a world of difference if the code is open or closed source. Voting is all about trust, if I can see the source and verify that it doesn't have any major bugs in it that is a step in the right direction compared to closed source.

          Debating about open-source vs. closed-source e-voting is the same as debating about electric chair vs hangings when you should be asking yourself whether the accused got a fair trial.

          You may have inspected the source for months. It changes nothing to the fact that on election day you don't know and cannot know what code is running on the e-voting computer in your polling booth.

          Until you solve that problem, there cannot be trust.

      • by nmb3000 (741169)

        Anyway, why Ruby? Not that I have anything against it but really why did they pick Ruby?

        Maybe they wanted to emulate that nice slow ka-CHUNK action of the lever-pull voting machines? For that they'd need the absolute [gmarceau.qc.ca] slowest [debian.org] popular programming language available. Hence, Ruby.

  • by Anonymous Coward on Friday October 23, 2009 @10:15PM (#29853755)

    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.

  • by Ungrounded Lightning (62228) on Friday October 23, 2009 @10:19PM (#29853771) Journal

    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.

    • HARDWARES? Did I hear you say hardware? Are you talking about my specially crafted hardware? Special for you only two dolla per chip0r specially crafted hardware win all election, specially crafted hardware with malicious logic designer, remote rf kill switch, parallel logic, specially crafted for you.

  • I don't get... (Score:5, Interesting)

    by Darkness404 (1287218) on Friday October 23, 2009 @10:27PM (#29853791)
    I really don't understand what problem electronic voting using computers is supposed to solve. Why not just make scantron ballots (some places already use them) they are paper so they are verifiable, easy to understand (who didn't have to do a multitude of these in high school?), and a machine can calculate them. About the only glitch is you can't change your mind without getting a new ballot, but its honestly not that hard.
    • Re: (Score:3, Insightful)

      by TubeSteak (669689)

      I really don't understand what problem electronic voting using computers is supposed to solve.

      Handicap accessibility, ballot complexity, but mostly hanging chads.
      The ability to almost instantly compile election results is just a bonus.

      Scantron ballots are a good idea, but people are stupid &/or prone to mistakes and will screw it up.

      • by fgouget (925644)

        Scantron ballots are a good idea, but people are stupid &/or prone to mistakes and will screw it up.

        Adding a computer to the process does not magically prevent mistakes, it just introduces new errors [rice.edu]: 60% of voters don't notice changes in their ballot on the review screen, some forget to validate their vote in the review screen, or the touch screens are misaligned making voting difficult, etc.

        So not only does electronic voting annihilate any chance of a public oversight, they don't even have any usability advantage.

    • Paper ballots, either hand- or scanner-counted, have a few management issues that are made easier and cheaper with electronic voting:
      1. the polling places must be sure that they don't run out, so election officials must print ballots based on their guess of the maximum possible turnout. This makes for almost certain wastage of ballots.
      2. In many places, mutliple versions of ballots must be maintained in inventory for multiple languages and/or multiple jurisdictions, each version having the same problems list
      • by CastrTroy (595695)
        Which is so much worse than the electronic voting places, where they have to have enough computers to keep up with demand. Of course, they never do have enough machines, or they end up breaking down, so you end up having to wait in line for an hour or three. Contrast that with paper systems, where you can set up another ballot station with a piece of cardboard.
  • The OSDV is working with multiple jurisdictions, activists, developers and other organizations to bring together 'the best and brightest in technology and policy' to create 'guidelines and specifications for high assurance digital voting services.'

    So... ahh... good luck with that. Sounds a lot like swimming through sewerage to me, but I guess somebody has to do it.

  • Curious about the choice of OS, given that Linux security, especially the kernel, is known to be inferior to BSD, OpenBSD in particular. Also curious about the choice of programming language, Ruby, when Python is known to be more readable, and more easily audited. Shouldn't the most important feature of a voting system, aside from useability and accesibility, be its auditability? Why would anyone choose a system that is known to be less auditable and less secure?

    • I totally agree with your opinion on Python - and the code should be readable or else it kind of defeats the purpose of saying "anybody can review it". That and Python generally shits all over Ruby in pretty much every way.

      But I suspect Linux was chosen for a few reasons - firstly it was probably what the creators of this project knew best and secondly it has better hardware compatibility and more consultants/contractors readily available to deal with Linux. If you know nothing about an OS it is hard to
    • Re: (Score:1, Flamebait)

      by pmontra (738736)
      Any language that gives a semantic meaning to indentation should be banned from this world, but this is mostly a matter of religion so I won't go deeper into that. What I'm interested into is to learn about objective measures of the auditability of different programming languages. Do you have some references? I googled a little but I didn't find anything meaningful particularly about Python and Ruby . Thanks.
    • by Dhalka226 (559740) on Saturday October 24, 2009 @05:41AM (#29855117)

      lso curious about the choice of programming language, Ruby, when Python is known to be more readable, and more easily audited

      Known by whom? Python fanbois?

      I'm honestly not trolling and I'm honestly not trying to start a Python/Ruby flame war, but let's not try to hide opinions behind worthless statements like "Python is known to be," particularly when the metric is as subjective as "readb[ility]."

      Aside from the enforced nature of Python whitespace, I don't find there to be much of a difference between the two in terms of readability. I prefer specified ending blocks, whereas Python seems to merely use a blank line and the indentation. What jumps out at me (as a Ruby fan) more than anything is how stupid and unintuitive '"""' is as a commenting option. Eesh. But all of that is personal preferences, as it should be. There's no substantive differences and certainly nothing measurable enough that we should bandy about statements like Python being known to be more readable.

      Chances are, by the way, that's your answer. Why Ruby instead of Python? The authors likely preferred it and were more familiar with it. It needn't be any more complex than that.

  • by symbolset (646467) on Friday October 23, 2009 @10:45PM (#29853869) Journal

    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.

    • I'm with you, but I add some info..

      It also doesn't break the chain of custody with invisible electronic signals representing votes.

      With paper ballots to break the chain of custody, officials have to pull some shit. Like saying DHS and the FBI have a terrorist attack, and the vault with the ballots will have to be left alone.

      Or using local law enforcement to arrest poll watchers.

      With electronic voting nearly every part of the system can be exploited. Starting with HARDWARE.

  • by ComputerSlicer23 (516509) on Friday October 23, 2009 @11:10PM (#29853939)

    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

    • Re: (Score:2, Interesting)

      by fandingo (1541045)

      Great post. I was thinking the exact same thing as soon as I saw Ruby was being used. It gets even worse than that: they are using Ruby on Rails. Slashdotters start foaming at the mouth thinking about how insecure Diebold code is; they should be furious that something as god-awful as RoR is being used for elections. RoR has its uses, but not in any kind of security sensitive situation.

      The project does seem to be interesting because they are trying to get the FEC to update some of its certification requireme

      • It's not a great post, there's holes through it.
        Specifically a "Chain of Custody" dilemma with the electronic vote tabulation devices being used.
          I don't wish such a project luck at all what so ever. All electronic vote tabulation devices must be outlawed.

    • by dogzilla (83896) on Saturday October 24, 2009 @01:00AM (#29854381) Homepage

      Wait a sec...step back. Take a deep breath and think this through.

      All those rules you described are there for what purpose exactly? Because as far as I can see, those rules have not made existing voting software (which presumably meets these guidelines) any more reliable or trustworthy. If the only reason these rules exist is to make the software secure and trustworthy, and if they create what appears to be a huge burden for developers of voting systems, then perhaps we need to throw out this particular set of guidelines *along with* the existing crappy voting software.

      Am I the only one to whom this is obvious? These rules don't exist for their own sake - they exist to achieve a goal. If they're not achieving that goal, the rules need to be rewritten before you even touch a single line of this code.

      • Re: (Score:3, Informative)

        I completely and totally agree with the notion that those rules are stupid. However, most states use Federal Funding for the purchase of hardware for elections. Once that is done, you must be certified by the FEC, and you must follow the above guidelines. Unless your state officials want to break Federal laws, or can find all the money for it from non-Federal sources, those rules will have to be followed. It's not like you can use an off-the-shelf computer, and the hardware is only good once maybe twic

        • by fgouget (925644)

          You can't run an election without a scanner of some sort. You'll need a scantron type solution for a state wide vote.

          A lot of countries are having nationwide elections that don't involve any kind of scanner anywhere. If your election process is such that one cannot do an election without involving non-voter verifiable hardware, then your election process is flawed.

          Scantrons to count, and paper ballots are the only way, unless we hand count (which I've got no problem with, but the computers generally do a better job, especially if you want to do accurate stats for funding of parties).

          If your election process is correct, then hand counting will deliver accurate results and, more importantly, results you can trust.

          The pieces everyone seems to be missing in that process are: transparent ballot box, party and public oversight of polling places

    • Re: (Score:3, Informative)

      by FlyingGuy (989135)

      I was thinking the same thing, then I went and looked at the code and saw this:

      import os
      import json

      from django.template import Context, loader, RequestContext
      from django.http import HttpResponse, HttpResponseRedirect, HttpRequest
      from django.shortcuts import render_to_response
      from django.conf import settings
      from django.contrib.auth import authenticate, login, logout
      from django.contrib.auth.decorators import login_required

      Just as soon as I saw that, it was like, Ahh HELL NO!

      I mean lets just thr

    • I've written code that has been used to count ballots in both state and federal elections. Trust me

      I don't trust you. I don't trust officials your all full of shit.

      The Hardware isn't checked. PERIOD.
      MASSIVE FAIL
      FUCK ELECTRONIC VOTE TABULATION DEVICES!

    • You tell a convincing tale; but why would anyone do the required rewriting by hand? The rules you mention sound very much within reach of the kinds of things obfuscating rewriters -- or compilers in general, for that matter -- do. I mean, if expensive, pointless adherence to some bureaucratic mandate is the aim, of course. Solving the problem wrong, indeed.
      • Unless you have a compiler that can generate meaningful names, you are in trouble. All code must have human readable and comprehensible names. ANTLR is a great code generator, that generates very readable code, but even it has poorly named variables. You can solve the file history by extracting the commit messages. You can solve the function call tree documentation if you write a good parser (the parser for C++ is non-trivial, which is why we didn't do that).

        You can write tools to detect a lot of the

  • "Trust the vote"? Only if the people voting are regular readers of dailypaul.com
  • by FlyingGuy (989135) <flyingguy AT gmail DOT com> on Saturday October 24, 2009 @02:32AM (#29854661)

    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.

    • by kvezach (1199717)
      Why not go further? There's no reason why a voting machine should even be Turing complete. For plain old Plurality voting, simply have a machine that reads input (buttons or touchscreen, whatever), then blows an antifuse for the selected candidate and fuses for all the other candidates, on a PROM. Connect the PROMs to a central counter which tabulates the ballots, and there you are. (If you want Condorcet, each "ballot" needs log n bits per candidate, not just one).

      What I'm saying is: design the compute
    • And you plan to run your well stripped, lean, mean linux on....

      Specially crafted hardware at the doping level.

    • adn after your all done, you stupidly installed it on my specially crafted hardware!!!!!!!!!

    • 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

      No, but I'm not opposed to them giving it a try either. If you look at the projects on sourceforge, the overwhelming majority of them are either dead or dormant, but that doesn't make the open source process that lead to them a complete dud.

      Some great open source projects have come out of sourceforge (and many other places as well of course). I don't know if the success rate is 1%, or 0.5%, or even lower than that, but whatever it is, I'd still consider the process a good one.

      Also, the desire to create

      • by FlyingGuy (989135)

        I completely and whole heartedly agree with you, the ground swell has to start someplace and this could very well be it and if nothing else they will more then likely come up with a great prototype.

        Languages like python, ruby, php et. all. would be a great place to start prototyping these sorts of systems since they can provide critical proof of concept.

        Once they get the process flow figured out and rock solid then you take that and prot it over to a proofable language and hardware. MANY such systems are c

  • by Pembers (250842) on Saturday October 24, 2009 @06:25AM (#29855271) Homepage

    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.

    • Of all the dire remarks on this I like yours the best. The only way to get the public to trust any electronic system at this point is to decouple the error detection from the software, such that it is impossible for the software or hardware to make an error that is not detected. The following system design does this. Your opponent could design the software in secret and any tampering or mistakes will still be detected by the voters not the software. The voting software simply compiles the votes into a Da
      • by Pembers (250842)

        We may have to agree to disagree... I don't think computers should be involved in counting votes at all. Any system where the voter can verify his vote after he's left the polling station is open to votes being bought. If the registrar knows which voter cast which ballot, what stops him selling that information to someone else?

        Forcing an attacker to hack multiple systems is good, but there's always the possibility of a buffer overflow or SQL injection.

        The way I see it, having lots of people count lots of pi

  • All this focus on securing an inherently insecure channel..I suggest we instead make sure that if the votes are not OK then it will be discovered after the election? I mean, if anonymity weren't an issue it would be as easy as having a list at the library after the election with names of people in one column and whatever they voted for in another. If everyone is happy with their own entry and the list doesn't have bogus entries, the election went well. Since anonymity is an issue, let the voters draw their
  • That's it really.

    The paper is better because it's verifiable, and does not require trusting enabling technology to run an election. No electronic system meets this criteria, unless it's voting record is written to physical media in a human readable, enduring way. So then, why bother?

    Doing it with paper gets people involved in their civics too.

    I'll give them top marks for open source, but a FAIL for it just not being a necessary thing.

    • by nostriluu (138310)
      Why does doing it with paper get people involved in their civics? If you want more direct democracy (voting on finer issues) allowing internet based involvement would seem to be the more practical route, unless you think people need to be hypnotized in person.
      • seriously.

        All we get for electronic voting is some speed. There isn't much else.

        My core problem with the e-vote happens to be that the vote record is not verifiable without a human having to trust enabling technology. When elections end up in the court room, those human readable records happen to matter. If we e-vote, it's going to be impossible to discuss voter intent, because no direct record of the voter intent will exist.

        Those of us, who do take the civics seriously, happen to be concerned about that

        • by nostriluu (138310)
          You're talking about a very particular kind of representative democracy framed by particular conditions. Among other problems, the conversations don't scale very well. If it all comes down to one day once every X years of voting between 5 candidates and 4 issues, I don't think that's a very good system. Granted, participation could shift from those adept in 'traditional' campaigning to on-line forms, but I think the participation would be higher. I am for a very radical change of democracy using modern co
          • In fact, a hybrid would be appealing to me.

            Major league issues should be full on democracy. Those things take time, debate, and need to be executed with the higher levels of trust. A Presidential election as opposed to some city measure would be examples of the extremes.

            I've no problem with electronic counting and such. My primary issue is the trusted record of voter intent. Electronics really can't do that, and they cannot be audited with a level of discussion suitable for a court of law. It is possib

Never trust a computer you can't repair yourself.

Working...