Re: Draft OpEd

From: Arthur Keller <voting_at_kellers_dot_org>
Date: Wed Oct 25 2006 - 12:26:39 CDT

Thanks for your suggestion. Your version is more technically
correct, but weakens the point that the vendors pay for the tests.

Best regards,
Arthur

At 12:59 PM -0400 10/25/06, Lillie Coney wrote:
>A couple of suggestions.
>
>>Arthur Keller <voting@kellers.org> wrote:
>>
>>At 4:48 PM -0700 10/24/06, Alan Dechert wrote various suggestions.
>>
>>Here's my next version.
>>
>>Why Not Open Voting?
>>
>>The principle of voting in the United States is that votes are cast
>>in secret but tallied in public. This principle is incompatible
>>with the current practice of using voting systems whose inner
>>workings are trade secrets owned by the voting machine vendors.
>>Those same vendors
>
>
>[contract with laboratories to approve their machines for use in
>public elections.]
>
>>[T]he results of those tests are also trade secrets - you guessed it
>>- owned by the vendors. Something is wrong with this picture.
>>
>>The usual claims for secrecy are that it somehow enhances security.
>>The evidence for security through obscurity is [weak]. For example,
>>the Apache web server compares favorably with Microsoft's web server
>>even though every line of the Apache source code is publicly
>>available. While the source code for Microsoft's web server is not
>>publicly available, it is available to large customers in source
>>code under license, but the source code of voting systems is not
>>even available for inspection by counties that purchase these
>>systems (but may be in escrow by limited third parties) and
>>certainly not for inspection by you or me.
>>
>>We're all familiar with how the excuse of military security is often
>>used to cover up embarrassing information that has little security
>>value. Why wouldn't vendors use trade secrets as an excuse to cover
>>up flaws in their systems or merely shoddy workmanship? In fact,
>>the exposed Diebold source code has shown embarrassing details. We
>>do not know what lurks in the programming of the other vendors.
>>Fortunately, ES&S and Sequoia have promised San Francisco and
>>Alameda counties, respectively, that they will cooperate with source
>>code disclosure rules if the State requires it. However, the
>>California legislature and the California Secretary of State have
>>not yet promulgated disclosure rules.
>>
>>The Open Voting Consortium (www.openvoting.org) is creating a
>>registry where vendors can publish voting systems technology. This
>>registry will include requirements for what must be disclosed, such
>>as software source code, specifications, documentation, and hardware
>>designs. While vendors may retain proprietary rights to the
>>software, vendors must allow testing, experimentation, analyses, and
>>publication by anyone. While anyone will be allowed to inspect the
>>software, of course not everyone has the skills to do so
>>effectively. But individuals or groups will be able to hire the
>>expert of their own choosing and to publish their analyses. Today
>>the experts are chosen by the vendors themselves or by election
>>officials, and those analyses are usually kept secret, and when
>>released, are heavily redacted (censored).
>>This secrecy makes voting systems vulnerable to inaccuracy, or
>>worse, fraud. In turn, voters lose confidence that their votes are
>>counted as cast and cast as intended.
>>
>>The Help America Vote Act (HAVA) was enacted in 2002 in the
>>aftermath of the 2000 Presidential election, when it became clear
>>that our current voting systems were inconsistent, unreliable and
>>unfair. The mandated updated Federal standards were not even
>>created until late 2005, standards that are voluntary and do not
>>require auditing or adequate testing. No wonder most computer
>>scientists have concerns about existing voting systems and want
>>paper ballots, or at least a voter-verified paper trail, to enable
>>recounts and auditing. Are the newly purchased systems themselves
>>inconsistent, unreliable, and unfair?
>>
>>While there may be some risk in publishing software developed in
> >secret and not designed to be published, continued secrecy is not
>>the solution. Rather the solution is replacement of the secret
>>software too fragile or embarrassing to publish with a more robust
>>open source voting system. Just as the security of Apache is
>>enhanced by its publication, the publication of an open source
>>voting system will help ensure that the system is secure and
>>reliable.
>>
>>It is a myth that anyone can make changes to open source software
>>like Apache. Certainly anyone can download Apache, make changes to
>>it, and run the changed version. But changing the official version
>>of Apache can be done only by a small number of people in a
>>carefully controlled process. Anyone can report a bug or a
>>suggested improvement. But any suggested improvement will go
>>through levels of analysis and scrutiny before it is adopted. And
>>that scrutiny is far higher than voting system vendors, testers, or
>>inspectors can muster.
>>
>>In a variety of industries, the government has sponsored research
>>and development work that has produced systems adopted by industry.
>>Military-funded research leads to the creation of products and
>>services that the military can buy. It is time for the government
>>to fund the creating of an open source voting system that vendors
>>can adopt to provide more choices to election officials to buy on
>>behalf of the voters. Those additional choices should not only be
>>at the initial procurement of the voting systems, but also for
>>ongoing maintenance and support, and for auditing and reporting
>>systems. It is reported than years ago an IBM salesman said to a
>>prospective customer, "Be careful not to get locked into open
>>systems." Now IBM is one of the biggest proponents of open systems.
>>It is time for our election officials to become proponents of open
>>systems too.
>>
>>(845 words)
>>
>>Arthur Keller is a founder and board secretary of the Open Voting
>>Consortium and a precinct inspector in Santa Clara County. He can
>>be reached at arthur@openvoting.org
>>
>>--
>>-------------------------------------------------------------------------------
>>Arthur M. Keller, Ph.D., 3881 Corina Way, Palo Alto, CA 94303-4507
>>tel +1(650)424-0202, fax +1(650)424-0424
>>_______________________________________________
>>OVC-discuss mailing list
>>OVC-discuss@listman.sonic.net
>>http://lists.sonic.net/mailman/listinfo/ovc-discuss
>>
>>
>>
>>_______________________________________________
>>OVC-discuss mailing list
>>OVC-discuss@listman.sonic.net
>>http://lists.sonic.net/mailman/listinfo/ovc-discuss
>
>
>--
>Lillie Coney
>Associate Director
>Electronic Privacy Information Center (EPIC)
>Coordinator, National Committee for Voting Integrity (NCVI)
>1718 Connecticut Avenue, NW
>Washington, DC 20009
>(p) 202-483-1140 x 111
>(f) 202-483-1248
>_______________________________________________
>OVC-discuss mailing list
>OVC-discuss@listman.sonic.net
>http://lists.sonic.net/mailman/listinfo/ovc-discuss

-- 
-------------------------------------------------------------------------------
Arthur M. Keller, Ph.D., 3881 Corina Way, Palo Alto, CA  94303-4507
tel +1(650)424-0202, fax +1(650)424-0424
_______________________________________________
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 Tue Oct 31 23:17:07 2006

This archive was generated by hypermail 2.1.8 : Tue Oct 31 2006 - 23:17:10 CST