Check out the new USENIX Web site. next up previous
Next: Risks of mandated source Up: Benefits and Risks Previous: Benefits and Risks


Benefits and risks of source availability

If a vendor chooses to use open source software as the basis for the functioning of their system, the most obvious benefit would be the direct access available to source code; anyone who accepts the terms of the open source license will, at least, have the freedom to examine the code. Many more individuals will be able to examine the code using manual or automated analysis. Disclosed code provides for enhanced access, but does not necessarily support the robust testing that open source code promotes, due to possible restraints on the making of derivative works -- such as compiled or modified code -- and other manipulations key to certain forms of testing. Disclosed source code regimes provide vendors more flexibility to protect the intellectual property interests than standard open source licenses, which require at a minimum the abilities to copy, modify, prepare derivative works and distribute source code.

Open source software has interesting implications for competition in the market, as the role of copyright and trade secrecy in limiting competition is removed. Therefore a vendor's competitors would be free to modify their code and compete against them with it. Naturally, intellectual property claims will, in general, cease to be a hurdle in commenting on, evaluating, using and procuring these open source voting systems. This is significant given recent efforts by vendors to use IP claims to frustrate oversight and testing of voting systems.Here are a few examples: In the Fall of 2004, Diebold sent cease-and-desist letters to a number of students who had published an internal email archive that exposed the fact that Diebold had been using uncertified software on their machines. OPG, Pavlosky & Smith v. Diebold, 72 U.S.P.Q.2d 1200 (N.D. Cal. Sept. 30, 2004) available at: https://www.eff.org/legal/ISP_liability/OPG_v_Diebold/20040930_Diebold_SJ_Order.pdf. Diebold has also sent letters and a ``product use advisory'' to Florida election officials warning them of intellectual property limitations on the testing of their voting systems in conjunction with other vendors systems. See Id., note [*], at 21. In North Carolina, in response to the new legislation discussed in §4.3.2, Diebold sued the State Board of Elections arguing that it could not provide source code to third-party software for the evaluation demanded by the new statute (see note [*]). Few, if any, of these cases would have been an issue with an open source voting system as in each case the user of the system would be able to exercise their rights to copy, modify and distribute the software of the system. With disclosed source, we would not have the clear cut case where intellectual property claims become less of an issue, as such claims would now turn substantially on the substance of the disclosed source license the vendor chose to use; it is likely that a vendor would choose to restrict rights to improve its competitive position.

However, there are risks associated with fielding an open or disclosed source voting system. Since computer scientists have yet to find a method for writing bug-free software, public disclosure of the system source code will inevitably result in disclosing vulnerabilities. Voting systems are not the same as general-purpose computing technology. Voting technology is used highly infrequently, runs specialized software and is difficult to upgrade or change without extensive vendor involvement. In the case of voting systems, disclosing information on known vulnerabilities arguably helps would-be attackers more than system defenders.Swire, P. P. A model for when disclosure helps security: What is different about computer and network security? 2 Journal on Telecommunications and High Technology Law 163 (2004). (Address Ping's comment here (says this needs to be more developed).) Molnar: context hear suggests Swire discusses voting systems. Need to fix. In fact, those tasked with defending voting systems -- usually local election officials and their staff -- are poorly positioned to shore-up these systems in the case of a serious source code-level vulnerability. Setting aside the fact that most jurisdictions don't have access to system source code, in most states any changes in the system's software will need to be recertified at the Federal and State level before being reinstalled on voting equipment.In the past, vendors have ``updated'' software on voting systems in the field without requesting recertification. After The California Attorney General settled a lawsuit against Diebold Election Systems, Inc. in the Winter of 2004, in part for fielding voting systems which were running uncertified software, this practice seems to have stopped. See: Press Release, California Office of the Attorney General, ``Attorney General Lockyer Announces $2.6 Million Settlement with Diebold in Electronic Voting Lawsuit Settlement Would Resolve False Claims Allegations, Strengthen Security of Equipment'', November 10, 2004, available at: https://ag.ca.gov/newsalerts/release.php?id=843.

Open or disclosed source code voting systems will need to be accompanied by contingency planning in the face of system flaws. Simple flaws may be innocuous enough to allow for the usual running of the election. For serious flaws, such as if there were any suspicion that the flaw will affect the voter experience or the casting, storage and counting of vote data, there will need to be a mechanism to mitigate serious vulnerabilities close to an election. Among the options here would be a ``postpone, then patch'' strategy where the election in question would be postponed, a fix for the vulnerability developed, the system quickly recertified at the Federal and State level and then the new system used in the postponed election.There are unanswered questions about whether or not Presidential elections can be postponed without amending the Constitution. See: Congressional Research Service, ``Postponement and Rescheduling of Elections to Federal Office'', October 4, 2004: https://www.fas.org/sgp/crs/RL32623.pdf. Another option, more simple than the last, would be for each jurisdiction to be prepared to run the entire election using paper ballots and hand counting. Naturally, jurisdictions likely face these problems -- known or unknown -- now and will want to consider and plan for these types of contingencies; open and disclosed source code raise the stakes of identified flaws.


next up previous
Next: Risks of mandated source Up: Benefits and Risks Previous: Benefits and Risks
Joseph Hall 2006-06-14