Sequoia Accidentally Reveals (Potentially Illegal?) E-Voting Code
from the whoops dept
For years, the big e-voting firms have refused to share their source code, repeatedly insisting all sorts of awful things would happen if the code was revealed. Of course, in the few instances where people actually did get access to the code, the only "awful things" that turned up were pretty massive security holes and weak programming. However, it looks like Sequoia may have inadvertently revealed its source code (found via Slashdot) due to an incompetent attempt to "remove" trade secret info:The Election Defense Alliance filed a public records request under California law for a copy of the final election databases from recent elections in Riverside County California. Riverside coughed them up, after sending them first to Sequoia for "redaction of trade secrets" and forcing EDA to pay a substantial amount for this "service."So now there's a project underway to analyze the code, which can't make Sequoia very happy. But what may be even more interesting is that the folks hosting the code are suggesting that the way Sequoia buried its code in data files may violate federal election law concerning e-voting systems.
As near as we can tell, instead of stripping out proprietary stuff of any sort, Sequoia simply committed vandalism: they stripped the Microsoft SQL header data off the top, expecting that this would ruin access to the data under any possible database utility and making the contents unreadable. [Note: confirming this is a high-priority task!]
While they succeeded in ruining the files as data, they didn't realize what a Linux user could do with the "strings" command: strip out unreadable characters and leave everything left as readable plain text. This in turn revealed thousands of lines of Microsoft SQL code that appear to control the logical flow of the election.
It violates the federal rulebook on voting systems on several levels: the rules require that code be hash-checked to prove authenticity in the field for obvious reasons. If the real working code is buried in with the data, no such hash-checks are possible. The federal rulebook is also clear that code can't be interpreted, apparently to avoid modification "in the field" (generally county or city election offices). There is also a rule barring "machine generated code" and since these data files are allegedly created (and managed) by the WinEDS application, the code in these files has to be "machine generated"?That can't be good. Though it might further explain the resistance to ever sharing the code.
Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.
Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.
While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.
–The Techdirt Team
Filed Under: e-voting, source code
Companies: sequoia
Reader Comments
Subscribe: RSS
View by: Time | Thread
hmm
[ link to this | view in thread ]
Awesome...
[ link to this | view in thread ]
eVoting Code should be Open Source
And when everybody (every coder?) agrees it's nigh perfect--there are no more fixes to be done--and anybody knowledgeable can look at the code and truthfully say "this is good, this works" THEN you're eVoting machine is ready for duty.
Seriously, easy problem to solve.
[ link to this | view in thread ]
Opens only in MY-SQL 2005
Link Ensuing:
http://studysequoia.wikispaces.com/message/view/home/15697098
[ link to this | view in thread ]
they will sue now
[ link to this | view in thread ]
"For years, the big e-voting firms have refused to share their source code"
While I agree that source code should be released to the public, it doesn't really solve the problem. How do I know the same code that's released to the public is the code that's actually being used? How do I know some third party applications aren't being used in the background somewhere? I don't.
I talk about end to end voting systems and their implications here
http://www.techdirt.com/articles/20090903/1538136098.shtml
Also see
http://fc09.ifca.ai/papers/fc09-gardner.pdf
Notice how it says, "Intended to provide guarantees regardless of software"
and see cryptovoting-usenix05.pdf
For some reason the original NEFF file doesn't work right now but it's here
[ link to this | view in thread ]
Re: they will sue now
[ link to this | view in thread ]
Re:
[ link to this | view in thread ]
Re: they will sue now
[ link to this | view in thread ]
Re: they will sue now
[ link to this | view in thread ]
The old-fashioned way
Firstly, there is no need to involve computers. Hand count ballots twice by different groups of people, the old-fashioned way. Electronic voting gives us nothing of real value, so why go to all the trouble and expense?
Secondly, there is no way to make electronic voting work in with anything near the degree of confidence of doing the old-fashioned way. Yes, there are algorithms by which security can be mathematically assured but here's the killer -- it's all invisibly operating in a black box in the end, so we have to take some experts word for it that these algorithms are being used as well as correctly implemented.
Hand-counting is transparent and easy to verify by the average person -- and this is the most important thing. Not only having the count be correct, but having everyone know that it's correct.
[ link to this | view in thread ]
Re: The old-fashioned way
Hi! My name is the 2000 Presidential Election! I don't think we've been introduced...
The point is that an open eVoting mechanism in which coding, reporting, and analysis are provided both to and by the public will ALWAYS be more reliable than hand counting ballots for the following reasons:
1. Far more oversight in how ballots are counted
2. Less setting issues. In other words, no more worrying about ballot trucks getting hijacked, natural disaster issues, etc.
3. Opportunity for less mistakes in the voting process. Think of those "Are you sure you want to delete slutty_asian_skanks.avi from your recycling bin?". You can have similar messages verifying votes cast on eBallots.
[ link to this | view in thread ]
Re: The old-fashioned way
[ link to this | view in thread ]
Re: Re: The old-fashioned way
[ link to this | view in thread ]
Re: The old-fashioned way
As mankind multiplies and spreads, hand-counting becomes less and less feasible.
What you're saying is something like this: "My horse and buggy ain't never given me much bother--and yer never gonna get that stoopid engine thing you've been on about working right. Give it up, buy a horse."
You cannot run from the future; run with it or be trampled by it.
[ link to this | view in thread ]
Tech bits
- A database dump like this is a mix of code and data, like a zip file. Having code in their does not mean it is "buried in the data".
- Having the logic in stored procedures does not prevent them from being hash checked. In fact, SQL stored procedures are hash checked automatically and the hash values stored in a separate "master" database. Code (or people) could easily verify that the hashes match.
- If this code is machine generated, so is every Word document you type. Just because you use a tool to access the database and modify its procedures does not mean that the tool is generating the code.
- With regards to "code can't be interpreted", that's more difficult. If the intent is to only have binaries distributed, then yes, stored procedures can be modified (see hash checking, above). But, of course, so can binaries. It's going to depend on the definition of interpreted; stored procedures (like Java byte code) are compiled to binary at runtime and cached.
I'm for transparency and full release of source for anything election related. However, some of this technical stuff is bordering on disingenuous misrepresentation to prove a point.
[ link to this | view in thread ]
Re: Re: The old-fashioned way
"With an end to end user verified voting system the people, each individual, can audit the votes themselves and ensure that each vote counted and was properly tallied."
Actually, no they can't. All the people can do is learn what the system tells them. The system may not be lying, but it's not actually possible for the average yuser to have confidence in that. They still have to take the word of experts that the system is working as expected.
[ link to this | view in thread ]
Re: Tech bits
While it does make sense to have some functionality in the database for efficiency and speed, why does the database have to have any code at all? Why couldn't the database simply be a data repository and all the data manipulation / verification get done in the compiled executables?
Yes, it may not be the most efficient way to do things. In fact, it probably makes the development effort an order of magnitude more difficult. That being said, why should the developers be allowed to break the rules for the sake of convenience?
I think Sequoia needs to be taken to task for this and in a very public way. Just my $0.02.
[ link to this | view in thread ]
Re: Re: The old-fashioned way
The 2000 election is not a good example of hand counting, given that it was deliberate as screwed up as possible.
You'll get no argument from me that hand counting is more accurate than machine. My argument is that it's harder to trust that the machine is counting as expected.
[ link to this | view in thread ]
Re: Re: The old-fashioned way
Actually, no. What I'm saying is that as of right now, my horse and buggy will get me there safer than your fancy automobile. Not as fast, not as cheap, but with more safety. I'm not saying this will always be the case.
[ link to this | view in thread ]
[ link to this | view in thread ]
Re: Re: Re: The old-fashioned way
But that's exactly the point! It's hard to understand how you can claim that hand counting is more accurate than eVoting and then toss out a prime example of terribly innacurate hand counting because it was "deliberate". Deliberate interference is exactly what I'm trying to avoid. Whatever problems and innaccuracies might still arrive from eVoting, it will pale in comparison to the current type of voter fraud that exists today in varying degrees.
"My argument is that it's harder to trust that the machine is counting as expected."
I don't think that'd be the case if you opened EVERYTHING up.
[ link to this | view in thread ]
a) A non-open privatized voting system is a complete cluster-****.
b) The government is asleep at the wheel. Privatizing voting systems only works if there is oversight, governmental, public, etc.
c) The government doesn't give a flying F about voting security. Laws should be implemented against people with this kind of power, particularly when any abuse is tantamount to treason.
This crap is mind-boggling.
[ link to this | view in thread ]
Re: Re: they will sue now
[ link to this | view in thread ]
Re: Re: Re: The old-fashioned way
[ link to this | view in thread ]
Re: Re: The old-fashioned way
I believe Stalin said that he who casts the votes decide nothing, he who counts the votes decides everything. So voter fraud can be done by the counters regardless of machine or hand voting.
[ link to this | view in thread ]
Re: Re: Re: The old-fashioned way
After I Vote, I've no way to watch that they actually count MY vote correctly.
[ link to this | view in thread ]
[ link to this | view in thread ]
Re: Re: Tech bits
In fact, when we say SQL, we're actually talking about two things: DDL and DML. DDL is tables and stuff, DML is logic. this is completely normal and very much the way things are done in many, if not most, databases.
Another advantage of stored procedures is that they do away with code/schema version problems. There's no danger of an old executable running around that expects different schemas, and if executables interface with a database via stored procedures, DBAs can change the underlying schema (for performance, partitioning, or feature expansion) transparently.
The main reasons some people don't use stored procedures are that they can be harder to debug, they require knowledge of DML (what people usually call SQL), and low end databases didn't historically support them. However, even MySQL started supporting them in 5.0. Stored procedures are everywhere, they're common, and they are absolutely the best practice in many scenarios.
[ link to this | view in thread ]
For more info....
http://www.codersrevolution.com/index.cfm/2009/10/21/Sequoia-Voting-System-Witch-Hunt-err-Study-Pr oject
[ link to this | view in thread ]
Worth pointing out...
Once again, I refer everyone to Bruce Schneier's essay on what it would cost to steal an election and urge them to make a reasonable extrapolation from his postulated budget (in 2004) to a realistic budget for, let's say, 2012. His number was $100M; I think $500M is a sensible number now.
An attacker with that budget can subvert the hardware -- creating custom chips if need be. I would. Let everyone knock themselves out over the software, where nearly all the attention is focused, since in the end, it will run on my hardware, which will do what I told it to.
The answer to this is: pencil and paper. It's well-understood. Attacks against it are well-understood and credible defenses well-known. It can be operated by unskilled personnel, and defended by unskilled personnel. It's very difficult to subvert ON A LARGE SCALE, which is of course what matters when we talk about stealing an election. It's auditable. It imposes physical constraints on data and data flow. And so on.
Yes, it has its drawbacks: speed, for instance. But I'm quite content to wait a week for election results in order to gain the assurance that they're close to what they should be. And -- as should be obvious to everyone here -- nobody out there can yet replicate its performance with an electronic system.
[ link to this | view in thread ]
Re: they will sue now
Doesn't it means that Sequoia itself has certified that there are no trade secrets in the file they supplied? What an irony. :D Let's watch them biting their elbows.
[ link to this | view in thread ]
What a joke!
Are you just trying to be funny? More people means more hands to do hand counting.
They count ballots by hand in India, and they have a lot more people than the US.
[ link to this | view in thread ]
Re: Worth pointing out...
Well that might be obvious, if it were actually true. But it is not even remotely close to reality. First off, you use as a primary premise the idea that paper ballots cannot be forged, which both recent and long term history has shown us to not be the case. A couple good examples are the 2009 Elections in Iran, and the 2009 Afghanistan election. Both of these elections were done with traditional paper ballots, and both were shown to have major inconsistencies at best, and outright fraud at worst.
No one is saying that the current electronic voting systems are perfect, but a large part of the reason for that is the fact that the details of how the electronic systems work are locked up as "trade secrets" thereby denying the ability of people to examine those details to determine how reliable they really are.
You also seem to say that speed is the main difference between electronic and paper voting systems. That is also simply untrue. While speed is one of the advantages, it is hardly the biggest. The biggest advantage of a good electronic voting system is that it allows much more detailed auditing of results, which would be difficult if not impossible to achieve with a paper ballot system.
To come back to your first point regarding a hypothetical person with $500 million to spend to rig an election: I'm sure that if that amount is adequate to steal an electronic ballot election, then it would also be an adequate budget to steal a paper ballot election as well.
[ link to this | view in thread ]
Re: Re: Re: The old-fashioned way
Ok, lets take an oversimplified end to end user verified voting system that I made up to oversimplify the matter.
I go to a voting booth. It gives me a random number. I type in my vote.
Next, I go to the Internet. There is a list of my city and everyone in it. It has my number listed there along with whom I voted for. I can, MYSELF, write a computer program that tallies everyone that voted for whom I voted for or anyone else.
So say the vote look like this.
1: Ron Paul
2: George Bush
3: Ron paul
4: Jack Nicholson
5: Bob Barr
Now, when I vote I am FIRST given the number 3. I type in Ron Paul. I go home and check the website with everyones vote. I check for the number 3 and make sure that Ron Paul shows up. Now, I can write a program that adds up how many people voted for Ron Paul.
See, The USERS verify the system. No experts needed to tell me nothing.
Say that the total amount of people who voted exceeds the amount of registered voters who are in my city on the list of all the votes in my city. It should easily come to someones attention, even I can add up all the votes and say, "hey, look, something doesn't add up."
Furthermore, there could be a second list that lists everyone who voted. Everyone knows that the amount of voters on that list should equal the amount of votes on the other list. If they're not equal everyone would know. And if grandma shows up on that list and she didn't vote that year because she was sick then it would raise alarms.
[ link to this | view in thread ]
Re: Re: Re: Re: The old-fashioned way
In an actual hand-counted election, the election materials would be designed for people to easily count. There would be nobody examining tiny holes with magnifying glasses. Furthermore, the ballots being counted would be easily read from a distance, so supervision and oversight becomes more obvious. It's hard to beat the old Roman colored-chit system, except that's not practical when you're voting for more than one thing at a time.
"I don't think that'd be the case if you opened EVERYTHING up."
But surely it would. So you (or a trusted expert -- and there's a new person we must trust) can examine the code and be assured that it is correct. Can you be sure that the machine you're actually touching when you vote is really running that code? Gotta put a mechanism in for that. Does that mechanism allow me, joe voter, to be sure that the code is the same? If not, there's another expert we have to trust as well as a new security scheme to trust.
My point is that in the end, transparency is impossible when it's all invisible electricity, and so in the end we can never be sure, or even really be sure of how sure we can be. We can know what trusted others tell us, but you get enough "trusted" people in a group and there will be at least one untrustworthy person among them. Many points of failure and all of that.
With hand voting, we still have to trust -- but we can have many people overseeing the whole operation. These people don't have to be experts, so they can be ordinary people, and a lot of them, so it becomes more difficult for one bad actor to get away with shenanigans.
We used to do it that way, many other large nations still do it that way, or mostly so. The drawback to it is primarily that counting takes longer.
[ link to this | view in thread ]
Re: Re: Re: Re: The old-fashioned way
Absolutely not true. In hand-counting systems, such as the was the US did it not that long ago, all counts and ballot handling are supervised by random volunteers. You absolutely could watch your count being counted. You could even follow the tally back to that master count if you wanted.
[ link to this | view in thread ]
Re: Re: Re: Re: Re: The old-fashioned way
I don't care if the machine I'm voting on utilizes black magic, as long as I can verify that my vote is counted. That's what end to end user verified voting systems permit.
[ link to this | view in thread ]
Re: Re: The old-fashioned way
There's no checks and balances because you need to rely on data provided by the application to verify the application. Sure, a machine can print a paper receipt, but you would have to have the voter approve and sign the receipt to verify accuracy, and that will just slow down the voting process.
What if a bug is found in the code a month after the election, where under certain conditions touching a particular button MAY cause the wrong vote to be registered? The election results would have to be thrown out because there is no way to go back through the data and determine if the error actually occurred during the election.
My point? An error with a paper ballot can only occur on a single ballot. Design the paper ballot and have all parties and candidates approve the design ahead of time so that there can be no lawsuits later over how the ballot was formatted. That way if there is a question about a single ballot, it will not impact the rest of the ballots.
Paper ballots can also be used for mail-in voting. Even with e-voting, this concept of driving somewhere and standing in line is extremely outdated and must end.
Web voting is suspect unless every ISP can somehow guarantee 100% uptime on election day, and the government can guarantee no server crashes or downtime or bandwidth problems. Also, all construction projects and traffic must be halted halted so there is no chance of lines being cut/damaged.
[ link to this | view in thread ]
Re: Re: Worth pointing out...
I think you missed the bit about both of those have since been determined to be highly controversial, at least. Iran still fears revolution over it.
Sounds like paper ballotting worked swimmingly in both situations, refusing to allow the elections to be stolen, at least without anyone noticing.
[ link to this | view in thread ]