Slashdot Mirror
Sequoia Voting Systems Source Code Released
Mokurai sends a heads-up about Sequoia Voting Systems, which seems to have inadvertently released the SQL code for its voting databases. The existence of such code appears to violate Federal voting law: "Sequoia blew it on a public records response. ... They appear... to have just vandalized the data as valid databases by stripping the MS-SQL header data off, assuming that would stop us cold. They were wrong. The Linux 'strings' command was able to peel it apart. Nedit was able to digest 800-MB text files. What was revealed was thousands of lines of MS-SQL source code that appears to control or at least influence the logical flow of the election, in violation of a bunch of clauses in the FEC voting system rulebook banning interpreted code, machine modified code and mandating hash checks of voting system code." The code is all available for study or download, "the first time the innards of a US voting system can be downloaded and discussed publicly with no NDAs or court-ordered secrecy," notes Jim March of the Election Defense Alliance. Dig in and analyze.
To be honest shouldn't -any- code used to tally votes be released in the public domain for any US citizen?
Taxation is legalized theft, no more, no less.
I really can't see why we can't have a government-commissioned open-source system developed and mandated for use for public voting functions.
I absolutely hate the thought of my vote being inputted in to a closed magical-mystery box.
To make light of this does not do justice. This is potentially huge news.
A Good Troll is better than a Bad Human.
I for one welcome our Afghan overlords!
Anyone with half a brain realized converting from dumb paper ballots to "smart" electronic machines that could manipulate the votes was a Bad Idea (tm). Unfortunately that disqualifies most of our state politicians.
"I disapprove of what you say, but I will defend to the death your right to say it." - historian Evelyn Beatrice Hall
As my Software Engineering instructor said...
Someone was thinking that voting was primarily a counting problem and had the idea that computers were excellent at counting, so computers would be excellent at registering votes.
Of course, voting is minimally about counting, and from what we've seen even these clowns couldn't do that right.
Maybe it's a cultural thing, but I've never seen the necessity to complicate things any further than paper, pencil, double physical count. Cheap, no machines involved, fast. On a national election down here (about 15 million voters), voting booths close at 6pm and results are known nation wide right on time to open the 8pm evening news.
You could have kept reading, you know.
The FEC standards say "prohibited". They do not say "Any self-modifying, dynamically loaded or interpreted code is only okay if someone who is a really good programmer says it is" or "Interpreted code is okey dokey as long as it isn't called all that often". If the database itself contains application code which modifies the database, then that's a problem. It doesn't matter what kind of code it is or how benign you think it is, it should not be there at all.
If you would like to share your educated opinion where it matters, feel free to comment in the wiki. That's what it's there for.
Except that so far, I'm seeing table construction and table layouts. I guess that's technically code - as any SQL technically is - but a good case can be made to say that it's just the database structure. Which can, of course, be subjected to a hash check.
Except that the DDL isn't in a bunch of scripts that are building the schema, the schema exists in a bunch of strings that are concatenated together in stored procedures with some arguments to the procs munged in, and passed to Exec statements when the stored procedures are run.
That's not normal table building, that's an unabashedly self-modifying database.
Maybe it's a cultural thing, but I've never seen the necessity to complicate things any further than paper, pencil, double physical count. Cheap, no machines involved, fast. On a national election down here (about 15 million voters), voting booths close at 6pm and results are known nation wide right on time to open the 8pm evening news.
Except that Americans like to vote on everything.
Not just politicians, but sherifs, judges, district attorneys (i.e., head government prosecutors), etc. Add this to the fact that most elections (municipal, county, state, federal) tend to happen on one day, so that when you walk into the booth, you don't just have a piece of paper, but a small booklet to go through. Then add propositions (i.e., referendums) that many states have if enough people sign a petition. If you want to be an educated voter on all the possible choices you have to do some serious studying.
And then you have to count all of these 20+ separate run offs for the various levels of government.
First, I'm the guy that built that wiki page.
Second, "code that defines races" can be used to alter results. I have a lot of experience playing with Diebold databases because we've had access to those since 2003 when Diebold left an FTP site open. If you swap the candidate ID numbers between two candidates in the Diebold database (run in MS-Access), you'll flip the election. In a heartbeat.
It *appears* there's code present in this Sequoia database to do the same thing. Note the word "appears". The best way to find out, and the most MORAL way, was to put it up for public review.
Risking exposure of our technical warts, sure. Still worth it. Check the discussion areas at the wiki - we're learning a hell of a lot, very quickly.
But yes, it's true: I don't know MS-SQL, and nobody else at EDA does either. So we were faced with a choice: find a few people who did know it, pay 'em a bunch of donated money to write a formal report behind closed doors, or do a public review and exam even if that means exposing any mistakes we make, knowing they'll be caught pretty damn quick.
Which was better?