OSS PING
If you are interested in the OSS ping list please mail me
Posted on 02/08/2006 7:48:52 PM PST by nickcarraway
California lawmakers on Wednesday debated the use of open-source software in the state’s electronic voting systems in hopes it might build public confidence in the nascent technology.
Sen. Debra Bowen (D-California) called the hearing, citing successful use of open-source software—programs based on widely published code—by large companies including Amazon, AOL, and IBM.
No action was expected to be taken. The hearing was scheduled more in the interest of expanding discussion of open-source alternatives, said a spokesperson for Sen. Bowen.
California has already taken steps toward using such software throughout the state. In 2004, the California Performance Review strongly recommended the use of open-source software and VoIP as cost-cutting measures, saying such moves could save the state $32 billion over five years.
During September, state Chief Information Officer J. Clark Kelso established an open-source working group composed of IT managers from 10 state departments.
According to the performance review, open source is not just about cost savings, either. “Since the code is open, it offers the flexibility for organizations to modify the code as needed for specific uses. … Open source can [also] provide superior security than closed source,” said the report.
At the very least, lawmakers want to learn more about open-source applications currently on the market and the steps to go through when evaluating a potential application, said Sen. Bowen’s office.
The 2000 U.S. Presidential election made the words “hanging chads” synonymous with election snafus, as Florida officials recounted hundreds of thousands of paper ballots during a chain of events that ended in front of the U.S. Supreme Court.
Electronic Systems
The open-source software would be used in electronic voting systems. But the ability to verify votes in those systems has been marred by criticisms of companies like Diebold, blasted for purported errors in its electronic machines and the need for paper trails.
The hearing included presentations from Red Hat Vice President Michael Evans and Deirdre Mulligan, of the University of California, Berkeley. Four proprietary voting system vendors, including Diebold, were invited to take part in the hearing, but didn’t attend. Hart InterCivic, for example, said it had a scheduling conflict.
Phillip Braithwaite, the company’s vice president for sales, cited a prior statement saying the company “does not object” to an independent review of its code, but “we do not believe that open, unrestricted publication to the Internet is in the public interest and our belief is not based on intellectual property issues.”
Federal law requires the Election Assistance Commission to certify voting systems used in the United States. California law requires the secretary of state to certify voting systems used in the state, as well as hold a copy of the source code of certified systems in escrow.
Proponents of open-source software claim that keeping a copy of source code protected by copyright laws is entirely different from a system open to public scrutiny and, most importantly, improvement.
ping
CA ping.
LOL! Sort of like protecting people by banning guns.
It is harder to hack the open source - all errors or traps can be visible.
The best of course is paper ballot - the most difficult to falsify.
Many computer flaws are detected because the software is open source. Plus it would save a lot of money.
Paper ballots which are hand counted publically, the results of which are compiled publically are the most resistant to tampering and corruption. The old paper ballot with the candidate's picture will do nicely.
My proposed method: (1) Voters use a polling-place machine to produce a machine-readable paper ballot. Note that the printed ballots at this stage are not an inventory-controlled item. (2) An election judge places a counterfeit-resistant sticker on the back of the ballot and puts it into a machine which checks it, including the sticker, for validity. (3) The print on each ballot a randomly-assigned unique ID for each race; machine should record the ballot contents, including the IDs, but should not keep track of the order in which they are received.
After the election, the officials should publish, for each race, the ballot IDs of all ballots cast in that race and the vote recorded for each.
Once that is done, anyone with a halfway-decent computer would be able to scan through those published result files and confirm that the number of votes counted for each candidate matches the number recorded.
The final step would be to provide a means by which interested parties could request to examine the paper ballots associated with any particular ID. If ballots are kept in moderate-sized batches and the IDs within each batch are recorded, it should be a simple matter to pull the batch, punch the requested ID into a machine, and then have the machine feed through ballots until the requested one was found. Once that is done, the ballot could be examined to ensure that the votes marked on it match the votes recorded in the database.
Pulling 200 randomly-selected ballots statewide would be enough to ensure that any error or fraud exceeding 1% of the vote tally would likely be detected. Pulling 2,000 random ballots would ensure that errors of 0.1% would likely be detected.
Of course, for any of this to be of any use, people must be willing to do something if problems are detected. In a state like Washington, where a Democrat "victory" of under 200 votes is unmarred by the existence of thousands of bogus ballots, such measures would be a waste of time.
At minimum, for every race in every precinct there should always be a count for all of the following:
For every precinct, the above figures should be tracked continuously. Once the polls close, #1 through #4 should be recorded; any change in them is to be considered an anomoly. Each ballot should count once in #5 through #11; it may move from one category to another as it's processed, but the total number of ballots should remain the same. No ballots should disappear or appear out of nowhere. If at any time the totals don't match up, the reason for "extra" or "missing" ballots should be sought at once.
Even without any deliberate fraud, some past elections have been marred by mistakes that would have been caught by such basic cross-checking. Is there any reason such cross-checks are not SOP? [Outside of Washington state, that is, where having thousands of "magical mystery ballots" in a race with an under-200-vote margin is no big deal]
If so, this would be a very bad idea because it facilitates vote-buying.
The voter would not be given the number, for precisely that reason. Vote-buying-prevention is the reason for several features in my proposal. For, I would inventory-control the stickers, rather than the ballots themselves, to prevent a couple of vote-buying strategies. With conventional paper ballots, it's possible to engage in vote buying by having the crook sign in to vote but take his ballot out with him instead of putting it in the box; he then fills out the ballot his way and hands it to someone who instructed to drop it in the box and return with a blank ballot. If the ballots themselves were not inventory-controlled, the voter would be able to fill out a ballot for himself and pick up one for the crook. Note that it would also be possible for a voter to use a camera phone to record himself filling out a ballot, but then ditch that ballot and fill out a different one.
The use of different IDs for each race is another aspect of vote-buying prevention. If the database recorded the full contents of each ballot, it would be possible for someone to buy someone's vote by instructing them to vote for a peculiar combination of minor-office candidates. The person could tell that the "seller" kept up his part of the bargain by observing that a ballot existed with the exact combination of votes requested. Separating out the IDs makes this impractical. Although examination of the particular paper ballot cast by the voter would show what combination of candidates he voted for, the database would not provide that information, nor would it provide any particularly good means to find that voter's ballot. If there was only one ballot cast for a particular requested minor-office candidate it would be theoretically possible to track the paper ballot that way, but unless the result for that minor office was in dispute there would be no basis for asking to see that ballot.
Suppose I have 100,000 ballots. I feed them all into a black box which prints a unique ID on each one and kicks out a list of the IDs and corresponding candidate selections. I don't have to have any faith whatsoever in the black box's accurate recording; I merely have to have faith that it will not alter the candidate markings on the ballots. The accuracy of recording can be ascertained by selecting a few hundred ballots at random from the database and comparing them against the paper copy. Even if the creator of the black box want it to report rigged results, it can't do so without being caught.
BTW, one key detail: it's important to select the ballot ID from the database and then find the corresponding paper ballot. Suppose a corrupt machine were to occasionally tag a vote for a non-favored candidate with an ID that duplicates another vote for that candidate, and then to generate a fictitious entry in the database with a non-existent ballot ID and a vote for the favored candidate. Comparing randomly-selected paper ballots against the database would not show anything amiss, since every paper ballot would have a matching entry in the database. Selecting a database entry and searching for the paper ballot, however, would turn up problems since the fictitious entries wouldn't have any real ballots associated with them.
A machine based only upon gate logic couldn't do that (I wouldn't even want sockets on the board). I don't want any software for good reason. It's too easy to run the validation and have it report something else later. I don't even want it to be smart enough to know how many candidates are on the ballot, much less who they are. I only want it to tell me how many black dots it counted for each postition. That's it.
I'd like to see Washington state (and other states) implement a policy that if the number of 'fishy' ballots/votes in a statewide race exceeds the margin of victory, the apparent loser may demand a revote with the costs being assessed to the various counties in proportion to the number of 'fishy' ballots/votes found therein subject to certain minimum and maximum per-vote fines.
If an election official in a highly-partisan area generates some bogus ballots that favor his constituents' candidates, the constitutents might not necessarily like it, but they probably won't complain too much. But if the official generates bogus ballots that end up forcing his constituents to fund a revote, he's going to be very unpopular.
How would your machine using only gate logic produce a machine-readable list of unique ids and candidate selections? The existence of such a list, and the ability to randomly select entries from it and compare them to the record ensures that the ballot-handling machine can't make mistakes or cheat without getting caught.
Further, if there is are ballots which for whatever reason reads 'marginally' (yielding different results on different times through the machines), one can compare the lists of ids and candidate selections generated by the scanning machines and determine which ballots are being read inconsistently and then pull them aside for examination. Simpler software-less scanning counters would yield different counts on different runs, but would provide no clue as to why.
I don't even want it to be smart enough to know how many candidates are on the ballot, much less who they are. I only want it to tell me how many black dots it counted for each postition. That's it.
Ballots should be checked for validity; that can only be done by a machine which knows what combinations of markings are valid.
It is all too complicated. Keep it the way it was before the computers. If it ain't broke, don't fix it.
OSS PING
If you are interested in the OSS ping list please mail me
Closed source doesn't protect against that. In fact, Diebold was famously hacked.
Open Source also guarantees access to the data. Diebold for a while claimed proprietary rights to the raw data format of the votes, therefore trying to keep people from seeing the actual recorded votes.
If you don't think OSS is the way to go, you only have to read the Diebold memos:
the AccuVote knows that it has dropped the ballot. So the question has always been, should we increment the card counter, and should we log the event. Currently we do neither. There are two schools here. One says we should notify the voter, log it, add a dropped ballot counter, send an incident report to the secretary of state, etc etc. The other is to increment the counter and send the voter on their ignorantly blissful way. Right now we kind of split the difference.They don't care whether your vote is counted, and are perfectly willing to hide that fact behind proprietary software. Actually, Diebold sued to keep the public from knowing the above bit.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.