Slashdot Mirror

Use of a known OS on a closed system such as a voting kiosk is no more or less risky whether or not you have disclosure of all the source code.

The state can't change the code, no, but it allows the state to determine a) whether or not the vendor has modified the OS (i.e., rewritten low-level drivers like Diebold has done in a few cases and quite frequently), and b) allows the state to determine if the OS is truly at fault (as a vendor might claim) or if it's the vendor's code that screwed up.

As for the sections you quoted that presumably limit the scope to the OS level, why? That seems like a gapping loophole.

Politics. The lawmakers were only willing to stomach so much "and you could plant a trojan in the BIOS or the compiler to modify the results" before they cut it off. The OS was as far as they were willing to go.

By this, I mean what if the hand tallies are recorded or communicated electronically....you want to have the source for all systems used to record, transmit or communicate those results also available for disclosure?

North Carolina uses something called the State Election Information Management System (SEIMS) in all counties to manage and transmit results. This program was written in-house (by the State IT department) and is, I believe, available under a FOI request. I'd have to double-check that.

Call me cynical, but if someone really wants to muck with the system they'll find a way....voting machines or no voting machines, [...] Don't kid yourselves into thinking you've really reduced the odds of vote tampering by requiring source code disclosure for the systems used to record votes.

I disagree. We're reduced it, we just haven't eliminated it, which is, as you correctly point out, impossible. Every step which increases the transparency of the system reduces risk in some form or another. This just makes it more difficult -- and more risky -- for a vendor (or a rogue programmer) to try a fast one.

-jdm

Use of a known OS on a closed system such as a voting kiosk is no more or less risky whether or not you have disclosure of all the source code.

The state can't change the code, no, but it allows the state to determine a) whether or not the vendor has modified the OS (i.e., rewritten low-level drivers like Diebold has done in a few cases and quite frequently), and b) allows the state to determine if the OS is truly at fault (as a vendor might claim) or if it's the vendor's code that screwed up.

As for the sections you quoted that presumably limit the scope to the OS level, why? That seems like a gapping loophole.

Politics. The lawmakers were only willing to stomach so much "and you could plant a trojan in the BIOS or the compiler to modify the results" before they cut it off. The OS was as far as they were willing to go.

By this, I mean what if the hand tallies are recorded or communicated electronically....you want to have the source for all systems used to record, transmit or communicate those results also available for disclosure?

North Carolina uses something called the State Election Information Management System (SEIMS) in all counties to manage and transmit results. This program was written in-house (by the State IT department) and is, I believe, available under a FOI request. I'd have to double-check that.

Call me cynical, but if someone really wants to muck with the system they'll find a way....voting machines or no voting machines, [...] Don't kid yourselves into thinking you've really reduced the odds of vote tampering by requiring source code disclosure for the systems used to record votes.

I disagree. We're reduced it, we just haven't eliminated it, which is, as you correctly point out, impossible. Every step which increases the transparency of the system reduces risk in some form or another. This just makes it more difficult -- and more risky -- for a vendor (or a rogue programmer) to try a fast one.

-jdm

Use of a known OS on a closed system such as a voting kiosk is no more or less risky whether or not you have disclosure of all the source code.

The state can't change the code, no, but it allows the state to determine a) whether or not the vendor has modified the OS (i.e., rewritten low-level drivers like Diebold has done in a few cases and quite frequently), and b) allows the state to determine if the OS is truly at fault (as a vendor might claim) or if it's the vendor's code that screwed up.

As for the sections you quoted that presumably limit the scope to the OS level, why? That seems like a gapping loophole.

Politics. The lawmakers were only willing to stomach so much "and you could plant a trojan in the BIOS or the compiler to modify the results" before they cut it off. The OS was as far as they were willing to go.

By this, I mean what if the hand tallies are recorded or communicated electronically....you want to have the source for all systems used to record, transmit or communicate those results also available for disclosure?

North Carolina uses something called the State Election Information Management System (SEIMS) in all counties to manage and transmit results. This program was written in-house (by the State IT department) and is, I believe, available under a FOI request. I'd have to double-check that.

Call me cynical, but if someone really wants to muck with the system they'll find a way....voting machines or no voting machines, [...] Don't kid yourselves into thinking you've really reduced the odds of vote tampering by requiring source code disclosure for the systems used to record votes.

I disagree. We're reduced it, we just haven't eliminated it, which is, as you correctly point out, impossible. Every step which increases the transparency of the system reduces risk in some form or another. This just makes it more difficult -- and more risky -- for a vendor (or a rogue programmer) to try a fast one.

-jdm

Why not use this mentioned in the summary. A) it loads fast, and b) layout is quite a bit better.

the horror

"Field people keep reporting memory card corruptions. McKinney continues to say "gather more information" with serial numbers etc. This has been going on for several years, and appears to be getting worse. "
ref

"Note that distributing this software is extremely dangerous. Our smart card format has absolutely no security, so if someone were to get a copy of this software and a reader, they could stand at the ballot station and quietly burn new voter cards all day"
ref

this one is bad. scary.

"Well, in the past we got a version of GEMS certified in South Carolina that was incapable of satisfying South Carolina's state reporting requirements. In short, had the state cert board done their jobs, we would not have been certified in South Carolina in the first place. We did not shoot ourselves in the foot by attaching a specified export to a release level. We shot ourselves in the foot by taking a version of GEMS to certification that was incapable of running their elections" reference

and another

yet another:

"...in the numerous Florida recounts we had many situations where the Ballot Accounting Forms and Accu Vote tapes did not match. When we reprocessed the ballots at the precinct level, we did come up with again a third differentiating number of ballots cast in some precincts and overall." (emphasis mine)
reference

"Please report any corrupted memory cards to me from elections. I've had one in Santa Barbara tonight. I'm curious how many more we have. We are entering another cycle of elections without this fixed I guess." (emphasis mine)
reference

I read some of the messages in the list, and saw some interesting (incrimimating?) stuff, but I don't know who to tell. Is anyone collecting excerpts from the messages? It seems that the womanpower of /. could be used to read these messages and gather any exerpts that might be useful. We just need a repository and some organization.

The next message in the list is also interesting:

"Also have report from Marin regarding 3 precincts with significant "passed ballots", i.e., ballot going thru AccuVote without being counted. Anyone else experiencing this?" (emphasis mine)
reference

Read some of the messages for yourself. All it takes is a little wading through the normal boring company emails to get to the good stuff...

"Please report any corrupted memory cards to me from elections. I've had one in Santa Barbara tonight. I'm curious how many more we have. We are entering another cycle of elections without this fixed I guess." (emphasis mine)
reference

I read some of the messages in the list, and saw some interesting (incrimimating?) stuff, but I don't know who to tell. Is anyone collecting excerpts from the messages? It seems that the womanpower of /. could be used to read these messages and gather any exerpts that might be useful. We just need a repository and some organization.

The next message in the list is also interesting:

"Also have report from Marin regarding 3 precincts with significant "passed ballots", i.e., ballot going thru AccuVote without being counted. Anyone else experiencing this?" (emphasis mine)
reference

Read some of the messages for yourself. All it takes is a little wading through the normal boring company emails to get to the good stuff...

Yes it is likely that the author of the linked e-mail intended the .sig as a joke; however, humour (particularly sarcasim) is difficult to convey in written text. More to the point, the author represents a company that is contractually responsible for an electronic voting machine. He should have known that this sort of humour could be misinterpreted. It was an error in judgement that could cost his company money and, no matter what he intended, that is the bottom line.

First off, I'd like to thank Wired News for linking me a couple of days back regarding this, and Why War? for providing a way for me to get at these files.

Now, then, from a January 2002 memo titled, Nearterm AVTS 4.x roadmap, discussing the classification of a major update as a bugfix:

What good are rules unless you can bend them now and again.

These are just the sort of people I want in charge of the machines that people vote on in my election. No, really. [/sarcasm]

Try http://chroot.net/s/lists/