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

From: Alan Dechert <dechert_at_gmail_dot_com>
Date: Fri Jul 28 2006 - 15:54:06 CDT

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

OVERVIEW
-----------------
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
chart titled "BOOT AREA CONFIGURATION."
http://www.openvotingfoundation.org/5-bt-cfg.jpg

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:
http://www.openvotingconsortium.org/blog/2006-apr-26/no_opposition

OPEN/CLOSED TESTING AND CERTIFICATION
-------------------------------------------------------------
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)?

RISKS OF SOURCE AVAILABILITY
---------------------------------------------------
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.
http://www.openvotingfoundation.org/5-bt-cfg.jpg

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.

SPECIAL QUALITIES OF VOTING SYSTEM INDUSTRY
--------------------------------------------------------------------
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.

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

DISCLOSED SOURCE TO OPEN SOURCE TRANSITION
-------------------------------------------------------------------
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.

OVC, OVS, OVF
----------------------------------
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
www.sakaiproject.org ) ,

     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
(www.gocc.gov ) 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.

SUMMARY
---------------------------
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] http://josephhall.org/papers/jhall_evt06.pdf
[2] http://www.accurate-voting.org
[3] see pg 6: http://www.ss.ca.gov/elections/open_source_report.pdf
[4] Audio of 6-8-6 Alameda County BOS meeting, ROV MacDonald speaking:
http://www.openvotingconsortium.org/ad/Alameda686BOSmeetingROVdaveMacDonaldOnSequoia.mp3
[5] From Alameda contract with Sequoia:
http://www.openvotingconsortium.org/ad/alameda-sequoia-pg12.pdf
[6] see http://www.openvotingconsortium.org/ad/bowen-296.pdf
[7] February 16 Menlo Park hearing transcript:
http://www.senate.ca.gov/ftp/SEN/COMMITTEE/STANDING/EL/_home/HearingTranscripts/2_16_06.htm
[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] http://blackboxvoting.org/itahearingpreamble.pdf
[14] AB 2097 text:
http://www.leginfo.ca.gov/pub/bill/asm/ab_2051-2100/ab_2097_bill_20060504_amended_asm.pdf
[15] see pg 5, lines 9-10 of bill text
[16] see http://www.accurate-voting.org/accurate/docs/2005_vvsg_comment.pdf
[17] http://www.openvotingconsortium.org/ad/la-cio-666-report.pdf
[18] http://www.securityfocus.com/columnists/198
[19] http://vote.nist.gov/threats/papers/threats_to_voting_systems.pdf
[20] http://www.gnu.org/philosophy/free-sw.html
[21] http://www.csl.sri.com/users/neumann/dugger.html

_______________________________________________
OVC-discuss mailing list
OVC-discuss@listman.sonic.net
http://lists.sonic.net/mailman/listinfo/ovc-discuss
==================================================================
= 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