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