Forgot your password?
typodupeerror
Government Your Rights Online News Politics Technology

Sequoia Vote Machine Can't Do Simple Arithmetic? 254

Posted by Zonk
from the lessee-nothin-into-nothin-carry-the-nothin dept.
whoever57 writes "Ed Felten is showing a scan of the summary from a Sequoia voting machine used in New Jersey. According to the paper record, the vote tallies don't add up — the total number of Republican ballots does not match the number of votes cast in the Republican primary and the total number of Democratic ballots does not match the number of votes cast in the Democratic primary. Felten has a number of discussions about the problems facing evoting, up to and including a semi-threatening email from Sequoia itself." Update: 03/20 23:30 GMT by J : Later today, Felten added an update in which he analyzes Sequoia's explanation. He has questions, comments, and a demand.
This discussion has been archived. No new comments can be posted.

Sequoia Vote Machine Can't Do Simple Arithmetic?

Comments Filter:
  • Re:Enough Already! (Score:4, Interesting)

    by TripMaster Monkey (862126) on Thursday March 20, 2008 @10:23AM (#22806108)
    We know that paper ballots work, and are a LOT harder to fudge to the level of throwing an election.

    While I agree with you, I just have to point out that it's not all that hard...after all, the recent presidential election in Mexico was stolen the old-fashioned way.
  • Re:oh dear. (Score:4, Interesting)

    by CaptainZapp (182233) * on Thursday March 20, 2008 @10:33AM (#22806204) Homepage

    Pffffft, that was the sound of sequoia credibility dying a death

    What credibility are you talking about?

    After all those neato stints that just about every voting machine company tried to pull their credibility is somewhere between a San Francisco Tenderloin crack hooker and a timeshare salesman for quite some time now.

    Thinking about it the hookers credibility is probably a lot better then the ones of those voting machine vendors.

  • by why!42 (1259526) on Thursday March 20, 2008 @11:04AM (#22806568)
    This is New Jersey why should bother with making sure the election machines can't be rigged. Hell, even our own NJ Supreme Court doesn't follow the NJ Constitution even when they rule something unconstitutional! Witness the 2002 Senate election when one candidate was replaced with another even though the Court ruled it was unconstitutional to do so [houstonlawreview.org]. "Yeah, it's unconstitutional. Just don't do it again next time." As a Jersey resident, I'll be unsurprised if the election board allows the machines to be used anyway. Can't let some company's profit (and political payoffs) be sidelined by something as trivial as honest elections!
  • Re:Enough Already! (Score:2, Interesting)

    by solipsist0x01 (887281) on Thursday March 20, 2008 @11:07AM (#22806612)
    Evoting can work if the source and hardware design of the machines are completely open to the public. We have a right to know how our votes are counted. I don't understand why this is such a problem, and I really don't understand why anyone would put up with anything less.
  • by l2718 (514756) on Thursday March 20, 2008 @11:10AM (#22806654)
    Mathematically speaking, proving a program correct from the source code is in generaly impossible (if you could do that you could, in particular, solve the halting problem). From the software engineering perspective it's true that examining the source code gives you greater confidence in the software than just black-box testing.
  • by Jason Levine (196982) on Thursday March 20, 2008 @11:16AM (#22806734)
    I agree. It shouldn't be this hard to design a system that would count votes quickly *and* accurately. I could make a website that would tally the results accurately. Why can't they do the same (with a better interface) via more robust languages?

    I'm not a big fan of the argument that Open Source = Always Better and Closed Source = Always Worse, but in this case I think it applies. The voting machines' inner workings are hidden from view from everyone, including the government running the election. If you're running something like a public election system, your machines should be open for scrutiny. Your *ENTIRE* machines. This means hardware *AND* software. If a company cried foul when the government that bought their machines tries to get them independently evaluated, I start to smell something fishy. This is probably the only time I'd give credence to "Why do you complain if you have nothing to hide."

    In my mind, the perfect eVoting system would be completely open (meaning the government officials could get any third-party individual to evaluate the code/hardware). The components would be off-the-shelf PC parts and would likely run on Linux or even on a hardened installation of Windows. (Yes, you can secure Windows, but that's another argument.) The machine would sit in plain view, but the monitor would be in the closed-off area. This would eliminate the possibility of a voter tampering with the machine while in the voting booth. They would only have access to a few components and not the main system.

    The voter would select their choices via a simple (but large type) keypad. (Press 1 for Obama, Press 2 for Clinton, etc.) After voting in one race, the machine would switch to the next race. The voter could easily go back and review/change their vote. At the end of the voting session, the voter would be presented with their choices and be asked to confirm them. A receipt would be printed showing the choices also. The voter would be asked to review the receipt and confirm that it was accurate. A No answer might alert Poll workers to a problem. A Yes answer would prompt the voter to inset the receipt into a special slot. A random bar code printed on the receipt and read by a bar code reader would ensure that the correct receipt was inserted. Then the electronic vote would be recorded and the voting session would be over.

    After the polls closed, the machines would burn their results to CD and would be hooked up (via wired connection most likely) to a VPN connection to a central server. The central server would take in all of the votes and tabulate them. If any voting irregularities were suspected, you could go back to the burnt CD results or the paper receipts.

    I'm sure this system would have holes (any electronic system would... even non-electronic voting systems are subject to fraud), but it'd likely be a lot more secure/accurate than Sequoia. Now I just need to convince some government worker to pay me a couple million dollars to build it.

  • Re:Hypocrisy (Score:4, Interesting)

    by monxrtr (1105563) on Thursday March 20, 2008 @11:17AM (#22806744)

    The State of New Jersey signed licensing terms that does not allow an independent party to review the code. The state should not violate that contract.
    And thus, the State of New Jersey violated its own laws (and so did Sequoia), and possibly Federal Statutes as well, regarding independent poll observers and independent verification of vote tallies. By definition of it being closed source proprietary code, it's illegal. Goodbye Sequoia contract, at a minimum. Rinse and repeat for every State and County. This is going to be a huge victory for open source, and a huge blow against "imaginary property". Just an appetizer before the RIAA goes down.
  • Re:Enough Already! (Score:3, Interesting)

    by grumbel (592662) <grumbel@gmx.de> on Thursday March 20, 2008 @12:24PM (#22807642) Homepage

    Evoting can work if the source and hardware design of the machines are completely open to the public.
    That isn't enough because you have absolutely no guarantee that the hardware and software you vote on is equal to the hardware and software design that was published. And also you would still have a voting process that is basically a magical blackbox for 99.9% of the population, some experts might be able to verify it, but not the voter and this is a big deal, since a voter should be able to understand and verify the voting process. Good old pen&paper based voting does that, eVoting doesn't even get close.

    I see eVoting as basically a first step to abandon democracy. Other then gaining the ability to temper with votes there simply isn't a need for eVoting.
  • by jurzdevil (1259614) on Thursday March 20, 2008 @01:03PM (#22808226)
    my town recently had a referendum and the votes dont add up. 2881 voted yes and 2467 voted no. This adds up to 5348 but the report shows a total of 5362. http://www.sussexcountyclerk.com/08ss.HTM/ [sussexcountyclerk.com]
  • by Vornzog (409419) on Thursday March 20, 2008 @03:35PM (#22810516)

    Even if the tally was exactly right, in general you cannot prove a program correct by using only black box testing. There are simply too many possible inputs to have time to test for all but the most trivial inputs. For all we know, there's a backdoor or unintentional security vulnerability that can be used to alter election outcomes. We need to be able to examine the machine's inner workings to have any hope of verifying those are not problems with the voting machine.
    You are not wrong. But, this article raises an interesting point - while consistency checks won't prove that there is a bug/vulnerability/backdoor, they will raise red flags in a significant number of cases that *something* isn't right.

    The problem with electronic voting in general is that there are a number of places where it can go wrong. Let's assume you do get the source code, and prove that it is correct. Can you also prove that this exact version is what is installed on every voting machine, in every polling location? Checksums are nice and all, but the checksumming software could be tampered with. Can you be sure that no other software is also installed that could alter the core application at run-time? Can you be positive that the results cannot be altered after they are already entered? Hell, can you be positive that the compiler used hasn't slipped something into the executable? As it stands right now, I think the answer to these questions is, collectively, no. Somewhere, there is a piece that is going to be extremely difficult to verify in all cases. It doesn't have to be much - a 1% error in the results would have swung a couple of the last elections. Some allege that this has already happened. (Hey, you all, in the back - with the tinfoil hats. Raise your hands...)

    In addition to requiring open source code, we should also have in place an extensive system of consistency checks to ensure that we catch most of the obvious ways to rig an election. If there are not the same number of ballots cast as there are people casting, that's bad. If a number of votes get invalidated (because of hanging/dimpled/pregnant chads, or what have you) that's bad. If people that can't vote (say, because they are dead), somehow manage to, that's bad. All of these things have been used as evidence of voting fraud in the past - don't throw them out just because you 'validated' some random piece of code.

    One more thing. If we are going to use electronic voting (and it seems like we are), you also need to get a voter-verifiable print-out - like, you know, on paper. This way, you can be sure that if something is wrong, it'll be caught on a hand-recount, and your vote will still mean something. This is really just the ultimate consistency check, and I don't see how we are going to get around the fact that without it, there will always be a way to tamper with the results. Check out http://coloradovoter.net/ [coloradovoter.net] for more - or look for a group of concerned citizens closer to where you live.

    As someone who would like my vote to count, I think we should ban all voting machine manufactures that don't agree to these sorts of checks. If they are trying to avoid this for any reason, I think they've got a hidden agenda. No more excuses about proprietary source code - if you want your machines to be used, you submit to a battery of external reviews and consistency checks. No exceptions.
  • by scraggly codger (456176) on Thursday March 20, 2008 @03:40PM (#22810608)
    I was a poll worker in the 2006 election in Essex County, NJ. We were using the new Sequoia machines, for the first time in a general election, I believe. We experienced a discrepancy between the machine vote count and the count of paper tickets which are issued to the voters when they sign in to vote, and which are collected when the voter actually votes at the machine. We had 5 more votes than tickets, out of about 600 total votes in the precinct. The gap was present quite early in the day; a voting official who checked in at our precinct observed the gap at about 10 am. We had no clue how this came about, whether it was operator error on our part or whether the machines were just plain buggy or hacked. Apparently the problem was widespread, since a form letter was sent to poll workers that indicated discrepancies on a ward by ward basis. Never got resolved, as far as I know, nor did it get any meaningful coverage in the local or regional press. Without a full paper trail, I will never trust any electronic voting result.
  • Re:Software bug (Score:3, Interesting)

    by betterunixthanunix (980855) on Thursday March 20, 2008 @04:54PM (#22811746)
    First of all, when did it become acceptable for "all software" to have bugs? The software that runs a missile control center better be bug free, especially the part that controls the firing sequence. There are certain situations where software errors are just not tolerable -- and I would say that voting machines are one of those cases. Our entire society is based on the idea that people have the right to vote on who leads them; if our ability to trust voting machines is undermined, then the foundation of our society is undermined. Plain and simple: this kind of software error is absolutely not tolerable, and this entire line of voting machines should be immediately recalled from every district that they are in use in.

    If you RTFA, you will note that this error does not occur in every instance, meaning that this is not a simple off-by-one error, but something much more serious. Sequoia claims that this bug can be reproduced if the operator of the machine presses a valid button, but then an unused button. That is a "logic bomb," and is indicative of two things:

    1.) Formal methods were not employed in the design of this software, and so the system was never proved to work.
    2.) The product was not tested sufficiently, and the testers assumed that the machine operator would never make an error while operating the machine.

    Neither of these situations leaves me with much confidence in Sequoia's ability to design a mission critical system. Sequoia needs to perform a review of its methods of design and testing before they sell any more voting machines, and the governments purchasing these machines need to start demanding that the designs be made available to the public.

One small step for man, one giant stumble for mankind.

Working...