Re: Draft OpEd

From: Arthur Keller <voting_at_kellers_dot_org>
Date: Wed Oct 25 2006 - 12:23:01 CDT

Thanks, Dick. The editor of the paper will help fix those kinds of
problems, and he's really good.

Best regards,
Arthur

At 9:30 AM -0700 10/25/06, Richard C. Johnson wrote:
>Latest version reads well, excellent content, just one remaining
>suggestion: run grammer checker and tidy up passive voice. (I
>know...nag, nag ...)
>
>-- Dick
>
>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 pay for their systems to be tested, and the
>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 quite limited. 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

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