Re: Respose to Joe Hall: Transparency and Access to Source Code in Electronic Voting

From: Joseph Lorenzo Hall <joehall_at_gmail_dot_com>
Date: Fri Jul 28 2006 - 18:22:39 CDT

I agree with some of what you say and disagree with some of it. This
is, of course, the first step in a line of related research and I had
16 pages in which to take this first step. Thanks for your feedback
and I will work to strengthen the work as I go forward. -Joe

On 7/28/06, Alan Dechert <> wrote:
> Joe, I read your paper titled Transparency and Access to Source Code in
> Electronic Voting [1]. I'm glad you wrote this. You explore several issues
> that need discussion but aren't covered anywhere. My response follows ....
> -----------------
> I think you can do better, and I hope you will. This is like the work of
> Lewis and Clark or Christopher Columbus: there is a vast territory out
> there, and you are finding out about it. I anticipate that your response to
> what I write will be, "we didn't go there." This is understood. But you
> will need to explore a lot more in order to provide something really useful.
> You say, "We conclude that disclosure of full system source code to
> qualified individuals will promote technical improvements in voting systems,
> while limiting some of the potential risks associated with full public
> disclosure." This conclusion comes off as little more than a self-serving
> guess. It's not supported by your investigations, and is, in some ways,
> contradictory. How do you reconcile the risks in your conclusion with your
> citation of security through obscurity as a failed method?
> In general, you need to look at more of the political and economic issues
> involved. Your economic analysis is particularly weak -- virtually
> nonexistent. I strongly recommend a better multi-disciplinary approach in
> future investigations, including an economist, a political scientist, and
> perhaps others besides lawyers and technologists. The sea change that open
> source code for elections represents necessitates buy-in from many
> communities. We need to identify those communities and discuss their points
> of view. Your list of questions to investigate is way too short. I
> recommend that you work up a new list. It's not clear that you favor open
> source code for elections, but since you discuss this, you should look at
> this in more depth.
> Clearly, we have different interests. You are an academic and you want to
> study things. I am an activist, and I want to work toward a particular
> result. You earn a living writing papers. I earn a living by working on
> initiatives to change things. The ACCURATE project [2] of which you are a
> part is about to enter its second year (of five). I have been working on
> this issue for 5.5 years and want to finish my part as soon as possible --
> maybe one more year. We have different deadlines and different milestone
> dates.
> I want to paint a picture of a worthy voting system, and figure out paths
> and vehicles we need to get there. We have found some workable paths and
> workable vehicles, and we've made progress. The road ahead may be as craggy
> as the road behind.
> The alternatives you present are just thrown out there. There is no
> indication of how they would actually work or how they would be funded and
> why. You seem to argue in favor of more transparency but you do not paint a
> clear picture of what's a better system.
> The voting system is one of the main pillars in the foundation of a
> democratic society. You should treat it as such. Elected officials tend to
> be very interested in knowing how votes are counted. Why do you suppose
> that is?
> Stakeholders want to know what the academic community thinks about the
> voting system. They also want to know what the non-academic scientific and
> engineering communities have to say. They want to know what voters have to
> say about it, and there are many stakeholder communities within the larger
> body of voters. Racial minority communities may look to the federal
> government more so than white voters when it comes to securing voting
> rights. Why is that? Does the public have an absolute right to know how
> their votes are counted? If not, why not? If so, the arguments for/against
> open source mandates might be different than you posit.
> The people most closely involved in decisions about this are election
> officials and elected officials. These are the people that actually run
> things, after all. I gain little information about what they think about
> this from your paper. Government plays a very important role here, and
> state, local, and federal levels have distinct roles. State and local
> officials have been more active discussants compared to the federal, and
> they're all important. You practically ignore the politics. But how can
> you? This is the real world we have to work within.
> The voting system is the primary method by which we transfer political
> power. With so much at stake and such a long history of cheating and
> mistakes, no entity interested in the process is free from suspicion: no
> vendor, no state agency, no federal agency, no county agency, no group of
> scientists, and no other non-governmental organization (including OVC). Why
> are you so interested in the way we count our votes?
> You treat the barriers to entry too much like mp3 players v. CD players.
> You say, "If open source voting systems have real advantages compared to
> closed and disclosed source voting systems, then they should appear in the
> market much in the way that open source solutions have gained a substantial
> market presence in other areas of information technology." Very successful
> OS applications like Apache did not face the regulatory and marketing
> hurdles faced by OS voting applications. In your section on barriers to
> open source voting systems, you only begin to get at some of these issues.
> At the outset, I want to clarify a bit of terminology (specifically
> "disclosed source") that I use, which varies slightly from your usage and
> the Secretary of State's usage. I mean that the source code is publicly
> disclosed - free for anyone to see. According to the SoS, that's open
> source. He says, "open source software is simply a software product whose
> code is available for public view." [3] I suppose every one of the one
> million engineers signed up on Sourceforge would say that's wrong: you have
> to have a free software license to go along with the publicly viewable
> software code in order to qualify as open source.
> Sometimes when you say disclosed source it appears (as with the SoS) that
> you mean disclosure of the source code to a limited group of people (perhaps
> with various limitation on what they can do with it). If I neglect to say
> "full public disclosure" or something similar, that's what I mean by
> disclosed source. If I say mean "limited disclosure," I'll say it that way.
> Of course, that (full public disclosure v disclosure to limited groups) is
> not the only variation possible on what we mean by disclosed source. You
> are right to point out that some of the bills out there do a poor job
> defining what's meant by source code disclosure.
> ACR 242 and AB 2097
> --------------------------------------
> I'm glad you mention these measures, which OVC sponsored. I testified for
> these in the elections committees, and I don't mind pointing out that, in
> both instances, no opposition votes were recorded.
> Your discussion of these measures is almost nil. What you do say is
> misleading. Your readers would learn a lot more if you had described these
> developments accurately and in some depth.
> You report that the ITAA came out against AB 2097, "for a variety of reasons
> from competitive concerns to intellectual property issues." This may leave
> a reader with the mistaken impression that the bill failed for this reason.
> Importantly, you did not mention that this objection carried no weight
> whatsoever in the April 18th policy committee hearing. The discussion was
> mainly involved with our explaining the inadequacy of security-by-obscurity,
> and explaining the likelihood of vendor compliance, and what might happen if
> vendors refused to comply. We won the vote 5-0. Also significant: While a
> representative of the ITAA appeared and testified in opposition (weakly),
> NONE of the vendors showed up. I spoke to several executives from the
> election vendors by phone the next day, asking for a statement that they
> would comply. One of them pointed out, "We didn't show up in opposition.
> That should tell you something." We began a campaign to get county
> officials to demand in writing vendor compliance in case "open source"
> become a state or federal requirement. The first success in this regard
> came June 8 with Alameda County and Sequoia. [4] [5]
> Your superficial treatment of AB 2097 also means that you missed an
> important portion of the transparency imperative. AB 2097 calls for
> disclosure of the hardware schematics -- we're after all the technical
> details of how the system works. Just having the source code only addresses
> part of the issue.
> Hardware issues may cause the source code integrity to be irrelevant. For
> example, I happen to have a picture of part of a system board from one of
> the most popular paperless touch screen voting machines. Look at the little
> It appears that one could load a completely different system in the external
> flash ram slot and flip SW4 to side 1. Doing so would mean that even though
> the certified software is on the machine, it's running something different.
> AB 2097 was designed to catch such design flaws (or "features" depending on
> your perspective).
> The application is only one layer that needs to be reviewed. We need to
> look at the firmware, operating system, and hardware. Your paper is very
> weak on this point. AB 2097 addresses this. You miss this entirely.
> For more on AB 2097, I recommend that you study this article and associated
> links:
> -------------------------------------------------------------
> ACR 242 was very important for various reasons that go way beyond what the
> SoS report contained. We urged Secretary McPherson to hold public hearings
> to gather information for the report. When it became clear he was not going
> to cooperate with us, we turned to Senator Bowen. For one thing, this led
> to the Feb 8th CA Senate Elections Committee hearing (Bowen, chair) on open
> source software for elections, and to the Feb 16th hearing on the voting
> system testing and certification process [6]. At the Feb 16th hearing [7],
> Senator Bowen threatened to subpoena the company officials, and said she
> would try to get them to testify in March without a subpoena [8]. Her March
> 29 hearing, where representatives from Wyle and SysTest testified, revealed
> a great deal about the flawed, secretive testing and certification process.
> None of this is discussed in your paper. This is a major omission.
> At the Feb 16th hearing, David Dill suggested that the State of California
> develop an exemplary testing and certification process that could be a model
> for the nation [9]. At this same hearing, I suggested that the state opt
> out of the "federal" ITA process altogether [10]. Others expressed
> agreement with that view [11]. AB 2097 has a provision that would allow the
> state to forego federal certification in certain circumstances. Our bill
> would open a path to a transparent testing and certification process as well
> as open source software for elections. In your paper, you say,
> However, the federal process also suffers from a lack
> of transparency. The process by which a voting system
> is state and federally approved to be fit for use in a local
> jurisdiction is widely believed to be inadequate and
> dysfunctional and is highly opaque. Existing Federal
> guidelines are weak and out-of-date.
> I agree with what you say but you give us no hope for correcting the
> situation. You don't discuss these existing proposals at all. Very few
> people realize that the national ITA process is in no way a requirement for
> states. States choose to opt in; they can just as easily opt out. You
> mention that some election officials are beginning to conduct independent
> evaluations, and that "access to the source code for voting systems is
> essential to perform effective evaluation." This is a start, but a very
> small one at that. We need to expand on this and show how the relationship
> between opaque source code and the opaque testing and certification process
> reinforce each other. A truly transparent testing and certification process
> becomes possible with publicly disclosed voting system technology.
> Disclosed and/or open source reinforces transparency in the testing and
> certification process, as well as development and maintenance of standards.
> These are important points that aren't made in your paper.
> Our bills and the Bowen hearings, including the ones on testing and
> certification, which has a lot to do with access to source code and
> specifications represent a wealth of source material for your
> investigations. I think you used them some but it's not very apparent in
> this paper. On Feb 16, Dan Wallach said there was no excuse for any trade
> secrets in voting technology [12]. There has not been much published from
> processing and analyzing this source material. BBV did some nice work with
> the March 29 hearing [13], but I haven't seen much else.
> Where are initiatives favoring open source software for elections likely to
> develop and why? Sacramento is likely to play a very important role in this
> national issue. Do you think OVC could get something going in Florida?
> Sure, we have a group there. But what chance would an open voting bill have
> there? Ask Ion Sancho in case you need more information in order to answer
> that one. What other factors point to a potential leadership role for
> California?
> You mention the relevant federal bills and say that, "it appears that there
> is little appetite in Congress for electoral reform on top of HAVA," and you
> point out the narrow scope (federal elections). You also point out that
> "open source" and "disclosed source" lack definitions in these bills. This
> is good information. However, you don't mention that our bill, AB 2097
> [14], does include a definition of open source (publicly disclosed code
> under a free software license) [15]. This is a first, AFAIK, and it would
> have been nice to mention that. If we get the bill going again in the
> senate, we will expand on the definition so that "free software license" is
> better explained.
> Besides "little appetite in Congress," the US Constitution gives the states
> the primary responsibility for running federal elections (yes, it says
> Congress may intervene, but the States are given this first).
> Article I, Section 4
> The Times, Places and Manner of holding Elections for Senators
> and Representatives, shall be prescribed in each State by the
> Legislature thereof; but the Congress may at any time by Law
> make or alter such Regulations, except as to the Place of
> Chusing Senators.
> This is another reason state-level initiatives are important.
> A closed voting system with a closed testing and certification process fits
> better in a top-down hierarchical centralized federally-controlled system.
> A totalitarian and/or fascist state would prefer this. Isn't open source is
> a better fit for a decentralized co-operative design consistent with the
> notion embodied in the US Constitution?
> You are rightfully critical of the ITA process,
> Over the past year, there have been a number of cases
> where the ITA laboratories failed to catch violations
> of the federal standards. In the face of these failures
> at the federal level, State and local election
> officials have had to increase the scrutiny of their
> systems. Election officials are reluctant to rely on
> the vendor or ITA to effectively evaluate these systems.
> In light of this and in light of the fact that all of the major
> recommendations ACCURATE made [16] to the EAC regarding the VVSG were
> rejected, it seems you would want to explore the possibility of pulling out
> of the process. You don't discuss this, and this is another major omission.
> Later in the paper (Other Alternatives section) you mention that a "first
> step in increasing the quality of the federal certification process would be
> to make the testing plans and full evaluation reports public, perhaps in
> redacted form." This is very weak, and you don't say anything about how
> this would be done. Just ask the ITAs to do it? They have NDAs with the
> vendors. What about that? Ask the EAC? Something much stronger is needed.
> Some laws have to be passed. Then remember that the ITA process is
> voluntary. Are there good examples of passing federal laws to strengthen
> voluntary processes (and having them remain voluntary)?
> ---------------------------------------------------
> There are two main problems I have with your catalog of these risks.
> 1) If knowing how your votes are counted is a right-to-know issue (which I
> think it is), then we have to take the bad with the good just as we do with
> other documentation the government has that legislatures have decided needs
> to be disclosed.
> 2) You say, "In the case of voting systems, disclosing information on known
> vulnerabilities arguably helps would-be attackers more than system
> defenders." This is little more than pure speculation. You have not made
> the case for this. Most evidence suggests the opposite.
> It's apparent that, currently, the public does not have the right to know
> exactly how their votes are counted. In your discussion of "enclosure of
> transparency," you make the point that this once transparent process has
> become opaque over time due to increased mechanization. You discuss pros
> (greater efficiency) and cons of mechanization, with an emphasis on the
> cons. I'm left with the impression that you think the loss of transparency
> is bad, but not actually wrong.
> We (most OVC supporters and/or supporters of AB 2097) think that allowing
> secret processes in the voting system is WRONG. Period. With AB 2097, we
> declare that the public has a right to know exactly how votes are processed.
> We seek to establish that disclosure of these voting system processes is
> part of the body of knowledge that the public has an absolute right to know,
> and the government has no right to withhold.
> Secondly, your discussion of how exposure of vulnerabilities could make the
> voting system less secure and creates other needs and problems (i.e.
> increased risks) is all wrong. It flies in the face of what we know about
> the security of open systems and what we know about previously exposed
> voting system vulnerabilities. You seem to buy-in to the notion that we can
> reduce risks by hiding the code.
> In section 4, you cite the security by obscurity doctrine as "a principle
> from computer science that has long been discredited." Then in section 6
> you say, "disclosing information on known vulnerabilities arguably helps
> would-be attackers more than system defenders." So, which is it? You claim
> this is so because voting systems are different than other computerized
> systems (e.g., used infrequently). Your explanation is inadequate.
> Your argument only hangs together somewhat if we can reasonably dismiss the
> malicious insider threat. Even then, it doesn't hang together very well,
> and we can't dismiss the insider threat.
> To get a to better analysis, we need to break down the vulnerabilities into
> categories. Insider/outsider is a major division. If we make all the
> details public, this might change the outsider threat, but how does it
> change the insider threat? Insiders already have access to some or all of
> this information. Is there a reason to trust insiders more than outsiders?
> Who are all the insiders, anyway? Do we keep track of them?
> Part of this difference is perceptual, and perceptions matter as does voter
> confidence. In my 5.5 years of discussing these issues with insiders as
> well as outsiders, there are few things more clear than this: insiders tend
> to dismiss the threat of insider fraud (I am trustworthy and competent, and
> the people I work with are trustworthy and competent. Nothing like that
> could ever happen). Displays of this attitude abound, and I offer one. Let
> me know if you need more. This is from the Los Angeles County CIO reporting
> to the Supervisors regarding his observations about the vote counting
> process [17] on June 6. He exclaims that there is "no way a member of the
> public could gain access...." His proof that the system is secure rests
> with his observation that the public can't gain access to the counting
> system. He doesn't consider any possible insider mischief. He has absolute
> faith in the process the county has in place.
> Outsiders are concerned about insider fraud. Insiders call outsiders who
> are concerned about this "conspiracy theorists." Are you a conspiracy
> theorist? If not, maybe you should be. It makes little difference if no
> insider fraud can be found in Los Angeles County. Maybe we can't find any
> in Alameda County (where you live) either, nor in Placer County (where I
> live). There are thousands of jurisdictions around the country, and insider
> rigging in just one of them could change outcome of a national election. Ad
> hoc measures to improve voting system security here and there are not
> adequate. The system is as good as its weakest link. Comprehensive reform
> is needed. If you're not proposing comprehensive reform, then you need to
> think about how your work aids or hinders comprehensive national reform.
> Let's have a look at a real life example. Several years ago, it was
> discovered that production Diebold systems used in elections had hard-coded
> administrator passwords of "1111" [18]. Most everyone can recognize this as
> a security vulnerability since this would make it more likely that an
> unauthorized person could learn the password.
> Did disclosure of this vulnerability make the system less secure as you
> argue? Soon after this was disclosed, Diebold said that they had rewritten
> the software to include "harder-to-crack" passwords. This vulnerability
> had existed for some years. Insiders would have known about it for a long
> time, so disclosure would not make the system less secure from their
> perspective. Exposing this vulnerability would not make a difference to an
> outsider since the outsider would not be close enough to the process to get
> to a screen prompting for administrator name and password.
> Another example to counter your apparent defense of the
> security-by-obscurity doctrine: Look again at the system board switch on the
> touch screen voting system I showed earlier.
> Disclosing this publicly does not increase the chance of insider fraud
> because anyone with access to the system board would already see this
> "feature" of the board -- it's painted right there on the board! On the
> other hand, if this vulnerability had been publicly disclosed a long time
> ago -- as it should have been -- citizens could have demanded mitigating
> measures at a minimum. It's incredible that there is not so much as a
> tamper seal on these switches (SW2, SW4).
> Besides ignoring the difference between insider and outsider
> vulnerabilities, you ignore another important distinction between types of
> vulnerabilities: fraud capacity and error capacity. Both can lead to the
> same thing: a vote count that is wrong -- not reflective of the true intent
> of the electorate. But this distinction is worth making because faults in
> the system that increase the probability of errors, also create
> opportunities for fraud. For example, if you wind up with a pile of ballots
> with errors on them (ambiguous marks, for example) in a close election, this
> may present an opportunity to throw the election one way or the other
> depending on how the questionable ballots are handled.
> Exposing vulnerabilities that may lead to errors makes those errors less
> likely to happen. Whether the errors would be exploited fraudulently or
> not, the system is better off with fewer errors.
> As Doug Jones put it, "Almost everything that a malicious attacker could
> attempt could also happen by accident; for every malicious attacker, there
> may be thousands of people making ordinary careless errors. [19] Reducing
> the potential for errors may be even more important than closing the
> potential for direct cheating, and will reduce less direct opportunities to
> cheat.
> Here's how I put it in my April 18th testimony:
> Open systems are more secure. You can't achieve
> system security by hiding vulnerabilities. "Security
> by obscurity" has proven not to work. Hackers can
> find vulnerabilities without this documentation.
> Publication of these details will make voting systems
> more secure in the short run and in the long run.
> 1. Long run: Exposed vulnerabilities will be seen by
> a large audience of scientists and engineers. These
> problems can be discussed and then corrected.
> 2. Short run: These vulnerabilities are like landmines.
> If you were walking across a field known to have
> landmines, would you prefer not to know where they
> are located? Better to have them flagged so we can
> work around them and defuse them.
> There are security vulnerabilities in the voting system today, some of which
> have to do with computerized systems. System security is achieved in
> layers, little of which has to do with having or not having the source code.
> Having the source available is still an important piece of the puzzle.
> --------------------------------------------------------------------
> You correctly point out some of the qualities that make the voting system
> industry unique. Nonetheless, some of your conclusions would be more
> appropriate if we were talking about companies selling, say, document
> management systems to a government.
> In particular, your discussion of legal problems with "taking" trade secrets
> is way off the mark.
> AB 2097 (or something similar) is needed to correct the law. Enclosure of
> transparency is not simply undesirable, it's illegal when it comes to voting
> systems. Public observability of the process has been a part of the
> tradition and the law for a long time. Secret processes enclosed in
> proprietary computerized voting equipment encroach on long-standing laws and
> traditions.
> Moreover, AB 2097 would not publish these details without vendor consent.
> The IP examples you use have to do with disclosure of trade secrets against
> the will of the owner. Vendors could choose to leave the state, and the
> bill accounts for that possibility. We know that it is unlikely vendors
> would leave, and now we have at least one major vendor that has agreed to
> put this in writing. It's unimaginable that other vendors would not follow
> suit with Sequoia if pressured.
> Furthermore, AB 2097 does not force the software to be open source, strictly
> speaking (full public disclosure, not "free software"). Vendors would
> retain ownership of the software and can fulfill their contracts with
> counties without interference.
> This whole discussion of IP taking, eminent domain, etc., in section 6.1 is
> irrelevant to AB 2097, or similar state measure. It may have some relevance
> to some federal legislation, but not much I suspect.
> Election vendors know that there is a public right-to-know issue here. This
> is very different from vendors of other computerized systems (for example,
> document management) that are marketing to governments. Why would the
> government (the people, actually) claim they have a right to know the trade
> secrets in a vendor's document management system? Why would the people (the
> government) claim they have a right to know trade secrets in voting machine
> vendor's system? You should get a different answer for the latter question.
> The voting system is different. Mandatory disclosure is now widely
> anticipated. If a vendor leaves the market, other vendors will step in. No
> vendor has much to gain by making a stink about it. The voting business in
> the U.S. is not going away soon.
> There is little incentive for an existing vendor to unilaterally disclose
> their source. But if they are all required to do so, there is little
> incentive to resist and every reason for them to go along. It would be a
> level playing field.
> Finally, you should compare the technological requirements of voting systems
> versus other systems (like document management). We're counting votes.
> This is a pretty simple and well understood process. There is every reason
> to keep it simple. Do we need innovative ways to count votes? Novel
> methods that may be desirable in other disciplines, are less appreciated
> here. We need to know that the count is correct. That's the main thing.
> --------------------
> You begin your section 7, with an extraordinary claim. The odd thing about
> this claim is that after you make this claim in section 7, you contradict it
> in section 8 where you talk about barriers to open source voting systems.
> If open source voting systems have real advantages
> compared to closed and disclosed source voting systems,
> then they should appear in the market much in the way
> that open source solutions have gained a substantial
> market presence in other areas of information technology.
> There is no reason to believe this is true. This may be unintentional on
> your part, but this statement implies open source for elections will happen
> without special effort or intervention. It's just going to pop up like
> Linux, Apache, OpenOffice, FireFox, etc. The public elections business is
> different.
> The voting system industry is unique for a variety of reasons that I have
> already mentioned and that you mentioned in your paper as well. If I have
> an idea for an application I think is useful (or has proved useful to me and
> others), I may elect to release it as open source with the expectation that
> others will find it useful and, with luck, they may even want to pay me to
> help make the program work for them. I have done this. I know it can work.
> We know many others have done it very successfully.
> What if instead of just putting the program on a web site and making it
> available for free download, I had to pay over $100,000 to get it certified
> for use in elections. See the difference? Will I put up $100,000 (and a
> lot more work) just for the fun of seeing if someone will want to use my
> software?
> The Australian Capitol Territory (ACT) got that part right. They wanted to
> develop their own software for elections, so they commissioned someone to
> write it. You mention this in your paper but you missed a few significant
> details. For one thing, the winner of the bid got it for much less than
> cost. The whole thing was a disaster because it was under-supported from
> the beginning.
> Software Solutions (the contractor) was pretty unhappy with the outcome and
> the software was never properly GPL'd. I know because when I first thought
> about constructing demo software for the OVC electronic ballot printer, I
> thought about taking what they had and modifying that for our purposes. I
> downloaded the code only to find it unusable. It was purposely crippled, so
> no one could do what I was trying to do.
> Counting votes in a public election is a function unique to governments.
> Businesses and even foundations are reluctant to fund projects that are
> basically governmental. A foundation may fund, say, health care in society
> where the government is too poor to deal with it. But why should they
> underwrite a few million dollars worth of software development for a state
> like California, which has a budget in excess of $100 billion? If
> California wants it, California can pay for it. The way the voting system
> testing, certification, and procurement process is currently set up, small
> businesses have little chance of breaking into the market. Big businesses
> that would have the resources to compete don't find the voting business
> interesting for a variety of reasons -- including exposure to political
> fires.
> There is a strong business case for open source election software. Mainly,
> it's the public that will benefit. If people in government want to see that
> happen, they will have to take some steps to see this through. We'd like to
> hear more about how government(s) can make this happen. McPherson toyed
> with the ideal of pooling resources with other states. There has been some
> talk of counties pooling resources to develop open source systems. You
> mention a prize incentive, but the risk/reward equations here don't look
> good. It not a great deal of money needed comparatively, but to be done
> right it needs decent funding.
> Brian D. Newby, Election Commissioner, Johnson County, Kansas
> I think we have to realize a vision where elections
> software is ubiquitous and interoperable between
> hardware vendors. Voting equipment providers today
> utilize proprietary software, effectively locking in the
> vendor for the foreseeable future. As communities
> grow their fleets of voting machines, replacing an
> entire fleet at once will be cost-prohibitive and
> utilizing two different systems is operationally
> restrictive. Thus, the ability to place systems out for
> re-bid is compromised. Without any realistic threat of
> being unseated as a provider of choice, even the best
> vendors will be less aggressive in developing system
> enhancements and will have a captive market for
> potential support price increases that will continue to
> drive up the cost of elections. Without ubiquitous
> software, I believe the long-term costs of elections
> will be increasing greatly, and most Americans, as well
> as policy makers, are unaware of the potential for
> impending increases.
> The ubiquitous software Newby envisions is open source, not disclosed
> source. He is talking about the serviced based model that OVC has been
> promoting for some years. In order to understand some of the potential cost
> savings, it would be good to figure out how much we're now paying. How much
> do vendors spend marketing proprietary software? If voting software was
> free and ubiquitous, what could we save on marketing, software development,
> and license fees? Year 1, year 2, ... year 10.
> Before 2000, neither state nor federal government had ever provided money to
> local jurisdictions for voting system procurement. HAVA and other measures
> are unique to this time. There is no reason to believe there will be
> another federal bill any time soon to provide billions for voting systems.
> The current economic model in the voting system industry is unstable at
> best -- or maybe completely broken. We need to envision a whole new model.
> Your paper doesn't give us any information on what a new and workable model
> might look like.
> As you point out, voting system equipment is infrequently used. Voting
> machines are almost always in storage. Some have suggested a multi-use
> model for voting system equipment. Could this work? How would the
> economics compare with dedicated systems that spend 99 percent of their
> existence in storage?
> Your paper offers no numbers. If you want to give us a better sense of what
> it will take, you might want to get some economists involved.
> -------------------------------------------------------------------
> During the Assembly Elections Committee hearing on AB 2097, I explained the
> difference between disclosed source (as outlined in our bill) and open
> source. Assembly Member Villines said (of disclosed source), "but it would
> lead to open source."
> I think Villines got this right. For one thing, AB 2097 calls for disclosed
> source, but it could also be described as half-way to open source. AB 2097
> contains at least two of the four freedoms spelled out by the Free Software
> Foundation in their definition of open source [20]. Namely, AB 2097 calls
> for free redistribution and the ability to improve the program and release
> those improvements to the public. The other two freedoms are the ability to
> run the program for any purpose, and the ability to adapt it to your needs.
> Since election software has no value besides elections, the freedom to run
> the program for any purpose is inconsequential. The only freedom really
> lacking is the freedom to adapt the program as needed.
> Ronnie Dugger wrote about "public software" for elections near the end of
> his prophetic 1988 article Annals of Democracy [21]
> Some citizens believe that vote counting software should be
> in the public domain, available to all parties and candidates,
> for whatever checks they wish to make on it. "I'm not for a
> public process being handled by private companies that won't
> let us see what's going on," says Susan Kesim, a young
> executive of a computer-security firm in Indiana. "Public-domain
> software -- it's open. I want to see that it added one to the total,
> because that's the process of voting."
> "Maybe a private foundation should do it," Frederick Weingarten
> has suggested. "Maybe if there was a consensus among the states,
> the federal government could write its own software and certify it
> through the National Bureau of Standards or the F.E.C. say, 'This
> we guarantee is accurate and untamperable.'"
> Penelope Bonsall, the director of the F.E.C. Clearinghouse, said
> of the public-software concept, "It's a public policy question; it's
> too broad for us to consider. It would have to compete with private
> interests. I don't know who would fund it. I just don't see how you
> would eliminate private efforts in this area."
> These issues have been out there for some time. In a sense, we're still
> trying to address issues laid out here in these three paragraphs eighteen
> years ago. You are about as unclear on the privatization issue as Penelope
> Bonsall. The government has allowed privatization of the vote counting
> process and that's just wrong. In the past, it was a public process, and it
> should be restored to the public. Private companies can still be involved
> in the process (e.g., training, technical support, drayage) but they should
> not own the inner workings of the vote counting process. Funding? The
> government figured out a way to shovel $3.9 billion for voting systems with
> HAVA, and the government could figure out how to come up with a few million
> for open source software development.
> ----------------------------------
> I appreciate your mentioning OVC and OVS in section 7.1. You say, "Two
> groups, The Open Voting Consortium (OVC) and Open Voting Solutions (OVS)
> have emerged in the U.S. that aim to design or build voting systems with
> software source code distributed under an open source license." You go on
> to describe some of what we've done. While none of this is horribly wrong,
> you blur the missions of OVC and OVS.
> OVC has always aimed to be an industry-supported consortium. We have
> endeavored to have members that contract with local jurisdictions to deliver
> the goods and services. In addition to such dues-paying members (like OVS,
> potentially), we want to have governmental units (state and county agencies)
> as members who want to use OVC compliant systems in their elections. You
> say that, "OVC's mission now appears to have shifted toward advocacy...."
> but I would say that advocacy has always been central. Our prototype demo
> in 2004 was done to help sell an idea, not a product. We never claimed to
> have a product to sell. We want to attract funding for a production system
> that OVC would help develop and test, but that members would sell.
> Certified production software that meets OVC requirements could be software
> developed and certified by OVC or software developed and certified by an OVC
> member. OVC might charge for distribution of the software but not for the
> software itself.
> Under 9.2 Other Alternatives, you mention (noting the SAKAI project
> ) ,
> Another interesting model is that of "community source"
> where a consortium of government entities would agree to
> donate annual dues and full-time coders to a foundation
> that would develop, certify, market and support the
> consortium's voting systems.
> This is actually not far from the OVC idea. The main difference is that
> instead of "government entities," we envision a mixture of government and
> business entities, as well as other nonprofits -- even other consortia.
> Still, ideas are cheap. The Government Open Code Collaborative
> ( ) seems to be developing slowly. Making something like this
> happen takes time, effort, money, and salesmanship.
> OVC's relationship with OVS will be more like UL to a company that has a UL
> listed product. OVS is a for-profit corporation that wants to sell goods
> and services to local jurisdictions.
> The shift you perceive is probably due to the fact that the job of selling
> the idea has proven to be more difficult and involved than imagined years
> ago. We've had to undertake a larger variety of initiatives to get our
> points across. Our November 2004 press release included an announcement of
> plans to introduce legislation that would "require that computer source code
> used in elections be made public." In 2005, we worked with activists in
> other states on measures that would require or lead to source code
> disclosure. Later that year, we sat down (in Berkeley) to draft legislation
> for CA, which became AB 2097.
> Last year, we incorporated Open Voting Foundation (OVF). Recently (June 20),
> OVF was voted in as a member of Software in the Public Interest (SPI). We
> join Debian and PostgreSQL as an associated member of SPI. OVF is now able
> to accept tax deductible contributions to help fulfill its mission. OVF
> will necessarily avoid politics. My visits to the Capitol building will
> always be on behalf of OVC, not OVF.
> Originally, there was OVC. Now there is OVC, OVS, and OVF. This represents
> not so much a shift of mission: rather, the Open Voting enterprise is
> growing and maturing. Incidentally, I have no position in OVS although I
> suggested the name to David Webber and Dick Johnson. I am founder and
> president of both OVC and OVF.
> I don't expect you to explain all this in future works, but please don't
> confuse these relationships either. Your current paper is a little
> misleading.
> ---------------------------
> In your conclusion you say, "We acknowledge that limited source code
> disclosure to experts does not support general public scrutiny of source
> code, and therefore does not fully promote the transparency goals of public
> oversight, comprehension, accuracy and accountability." I agree that your
> prescription would have limited, if any, value in this regard. Especially
> since disclosure to selected experts is already exercised to some degree
> (for example, VSTAAB report on "Security Analysis of the Diebold AccuBasic
> Interpreter"). Source code in escrow can be reviewed in certain
> circumstances.
> There is no discussion of problems with this approach. For example, how are
> these trusted technical elites chosen? Are the trusted technical elites
> funded? What are their legal liabilities? That is, what if they miss
> something and an election is thrown on a system they said was okay? You ask
> some of these questions, but provide no answers.
> You continue, "However, in a public source code disclosure or open source
> code model most members of the public will be unable to engage in
> independent analysis of the source code and will need to rely on
> independent, hopefully trusted and trustworthy, experts." This is
> irrelevant if it's our right to know how are votes are counted. Consider
> how this would also apply to all the legal code available on the CA Leg Info
> site. It's our right to see it. It's irrelevant if most members of the
> public never look at it. In fact, like computer source code and
> specifications, very few people are in a position to make heads or tails of
> all the legal code that's on line. This is not an argument for keeping it
> from them. It needs to be there for anyone that can make good use of it.
> It belongs to the public, just as the voting system should belong to the
> public.
> As Arthur Keller has said, under Joe Hall's disclosure regimen, the trusted
> experts are chosen by the state. In the AB 2097 disclosure regimen, the
> people decide for themselves which experts they want to trust.
> Your paper serves as little more than an argument for maintaining the status
> quo. According to you, we don't need to pass any laws, just give Joe and
> friends unfettered access to the source code (amazingly, you don't even ask
> for the hardware -- just the source code!). But what happens after you get
> your PhD and ACCURATE funding runs out?
> We need a sustainable model. Consider the example above, the VSTAAB report
> on Diebold, as an example of source disclosure to a group of experts. The
> SoS office told me in a meeting last month (IIRC, the Friday before our
> suspense hearing) that they paid $50,000 for the report. This is purely ad
> hoc, covering a small portion of the code for a single system. Wouldn't we
> need to check again when the code is changed? Aren't there a lot more
> things the ITAs have missed? How does this work as an on-going
> institutionalized protocol? Who foots the bill for this year-after-year?
> Do results from UC scientists trump ITA results? I might agree they do, but
> only in an informal way. This is not a systematic way to do things, and not
> very effective in the long run.
> I would like to see exploration and expansion of issues having to do with
> such things as right-to-know, usability, standards, public confidence in the
> system, economics and how these things would be impacted in open v. closed
> models. To what extent does control of the voting system translate into
> political power and how does the open v. closed model relate to that? Does
> any of this relate to centralized v. decentralized power/control? You may
> feel these issues are beyond the scope of your paper, but should they be?
> You should explore how the open model could lead to better standardization
> and uniformity.
> Rather than make some blind assertions about how exposing vulnerabilities
> might make the system less secure, I also suggest that you go through a
> threat model and discuss how each threat might be affected by public
> disclosure of the technology.
> Your paper doesn't give us any insight into the nuts and bolts of how
> positive change might occur. This is fortunate only in that you don't
> really advocate any change. You seem to prefer easy change as opposed to
> difficult. The difficulties are understood. If it was easy, we would have
> finished 5 years ago.
> You include Michael Shamos in your acknowledgments, but you did not include
> what he said in the SoS report on Open Source Software in Voting Systems.
> Dr. Michael Shamos, Co-Director of the Institute for
> eCommerce and Director of the Center for Privacy
> Technology at Carnegie Mellon University participated
> in the Security/Paper Trails/Accountability Panel and
> offered his viewpoint that "all voting system software
> should be disclosed to the public."
> There is every reason to require full public disclosure of voting
> technology, and no reason not to do it. Your arguments against mandatory
> disclosure amount to weak speculation or are demonstrably false.
> Alan Dechert
> _______________________
> [1]
> [2]
> [3] see pg 6:
> [4] Audio of 6-8-6 Alameda County BOS meeting, ROV MacDonald speaking:
> [5] From Alameda contract with Sequoia:
> [6] see
> [7] February 16 Menlo Park hearing transcript:
> [8] See transcript: "Since asking nicely for participation hasn't worked, it
> will be time to turn up the heat a little bit to get these parties to
> Sacramento for a hearing in March. I hope we can do this without the use of
> the subpoena power." -- Debra Bowen
> [9] See transcript: "And I would love to see California come up with an
> exemplary process of testing and certification, preferably in collaboration
> with a bunch of other states so that it's not a new adventure in each state
> for the vendors." -- David Dill
> [10] See transcript: "I think we should seriously look at that, that we
> might want to opt out of the ITA process and begin our own certification
> process here in California." -- Alan Dechert
> [11] See transcript: "what's new to me in this hearing today is this
> possibility -- I don't know how realistic it is -- that if indeed we could
> opt out of it and take a leadership role in California to get out of this
> system where it's clearly corrupt, and we could move the paradigm back to
> where the citizens have more oversight over what is happening within our
> state and have maybe less power distributed beyond just the two entities.
> It seems too much power in too few hands." -- Sherry Healy
> [12] See transcript: "And to that end, my second point is that transparency
> is critical in this system. I think that it's just not appropriate to have
> trade secrets anywhere in an election." -- Dan Wallach
> [13]
> [14] AB 2097 text:
> [15] see pg 5, lines 9-10 of bill text
> [16] see
> [17]
> [18]
> [19]
> [20]
> [21]
> _______________________________________________
> OVC-discuss mailing list

Joseph Lorenzo Hall
PhD Student, UC Berkeley, School of Information
OVC-discuss mailing list
= The content of this message, with the exception of any external 
= quotations under fair use, are released to the Public Domain    
Received on Mon Jul 31 23:17:08 2006

This archive was generated by hypermail 2.1.8 : Mon Jul 31 2006 - 23:17:10 CDT