Surprise: Sequoia To Open Source E-voting Code

from the didn't-see-that-coming dept

Sequoia Voting Systems had been one of the "big three" e-voting providers, along with Diebold (Premiere) and ES&S. All three companies were notorious for massive amounts of secrecy and many, many, many reports of faulty machines with weak security. Sequoia's biggest problem -- which showed up in election after election after election after election -- was that it seemed to count the votes differently every time. That seems like a rather big flaw. The company also threatened computer security expert Ed Felten after the State of New Jersey asked him to look at Sequoia's code.

Just last week there were reports that Sequoia had accidentally revealed some of its source code -- but this week Sequoia has surprised a lot of people by announcing plans for a new e-voting system which will have open source e-voting software included. The code will be released to the public next month.

This is definitely a big (and surprising) step forward. The Wired link above tries to speculate why -- but I'd argue the most obvious reason (not mentioned in that article) is that Sequoia's two largest competitors, ES&S and Diebold/Premiere merged last month, suddenly making Sequoia a much smaller player in the space (I believe it was already the number three player...). Going open source isn't just a way to improve its code and improve trust in the machines, but also a way to stand out against a much larger competitor.

Filed Under: e-voting, open source, source code
Companies: sequoia

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.

Filed Under: e-voting, source code
Companies: sequoia

Facebook Ordered (Again) To Turn Over Source Code

from the this-still-makes-no-sense dept

Last year, we wrote about an odd patent lawsuit brought against Facebook by a company called Leader Technology. What was odd was that Facebook didn't seem like an obvious target for the patent (7,139,761) about associating a piece of data with multiple categories (and, actually why the idea that associating a piece of data with multiple categories should be patentable is another of life's mysteries). We actually thought it was more of a publicity stunt by Leader Technologies, rather than a serious lawsuit. But, we were surprised last month when a judge actually ordered Facebook to turn over its source code as a part of the lawsuit. This didn't make much sense to us. The source code really should only matter if it was a copyright infringement suit, not a patent one. Besides, why should Facebook turn over all of its source code over such a minor issue of associating a piece of data with multiple categories. At the very least, it should just be whatever part of the code that Leader believes is infringing.

Facebook objected to the ruling, but Ravish lets us know that the judge has denied Facebook and once again demanded the company hand over its entire source code. Even though Leader will only be able to view the source code under the watchful eye of Facebook representatives, it still seems quite extreme that a judge would require that Facebook reveal its entire source code to a company that is a competitor.

Filed Under: patents, source code
Companies: facebook, leader technology

Judge Orders Facebook To Reveal Source Code In Patent Dispute

from the that-seems-extreme dept

Another day, another ridiculous situation brought on by patents. Back in November, we wrote about how a company almost no one had ever heard of, called Leader Technologies (name not descriptive of the company) had sued Facebook for patent infringement over Patent 7,139,761 on associating a piece of data with multiple categories. As broad and obvious as that appears to be, it struck us that the whole lawsuit appeared to be a publicity stunt by this no-name company. Yet, for a publicity stunt, things may be getting troublesome. A magistrate judge has ordered Facebook to turn over its source code to the other company. Now, whatever you think of proprietary source code vs. open source, it doesn't seem right that a service like Facebook, which does a lot of different things with its service, should be required to turn over its entire source code to some tiny company with an overly broad patent. It sounds like Facebook is fighting this, as it should. I could understand (maybe) such an order if there were a charge of copyright infringement and direct copying of source code -- but a patent infringement claim shouldn't need source code.

Filed Under: patents, source code
Companies: facebook, leader technologies

Despite MN Supreme Court Ruling, Breathalyzer Manufacturer Refuses to Turn Over Source Code

from the code-is-law dept

Earlier this month, the Minnesota Supreme Court ruled that defendants accused of drunk driving have the right to inspect the source code of the breathalyzers used in their arrest. This is the right decision for a number of reasons - not only have studies shown that breathalyzers are poorly coded, potentially leading to inaccurate results, but in a legal system with the right to confront one's accusers, being able to examine the source code for errors seems like a fair digital extension. Given that more and more law enforcement is being done through shoddy technical tools, assuring fair procedure in code is no different than doing so for police officer behavior.

However, the breathalyzer manufacturer, CMI, is refusing to turn over the source code, claiming that doing so would reveal "trade secrets." Ed Felten points out that this is logically inconsistent with CMI's assertion that the source code is straight-forward calculations. If that is so, secrecy isn't what is stopping competitors from emulating CMI's product. The more likely reason for not revealing the source code, of course, is the same reason e-voting is so controversial: the code is crappy.

The obvious answer was posited years ago by Eric S. Raymond - given enough eyeballs, all bugs are shallow. The source code for breathalyzers, e-voting machines and other technical law enforcers should be open source to ensure that secrecy doesn't obscure important imperfections.

Filed Under: breathlyzers, minnesota, source code

Breathalizer Source Code Ruling Upheld

from the another-good-decision dept

A few years back, in a high profile series of lawsuits, a lawyer representing some folks accused of drunk driving asked the manufacturer of a breathalyzer testing machine for access to the product's source code, so experts could review it to make sure it functioned properly. The company refused, citing trade secrets. However, a judge noted that this went against the defendants' rights to a fair trial, and said that the breathalyzer evidence had to be thrown out. Slashdot points us to the news that an appeals court has upheld the ruling noting that due process outweighs the company's trade secrets. While I have no problem with prosecuting drunk drivers, I do agree that the evidence should be solid -- and not allowing the source code to be examined is a problem.

This is, in many ways, similar to the issue with e-voting machines. Considering the gov't is making important decisions based on these machines, it seems only reasonable that the source code should be at least reviewable to investigate the quality of the machines. Though, it strikes me as odd that we're even more stringent with Breathalyzers than with e-voting machines. Where's the similar ruling about e-voting machines and the availability of their source code?

Filed Under: breathalyzer, openness, source code