Re: Draft OpEd

From: Arthur Keller <voting_at_kellers_dot_org>
Date: Fri Oct 27 2006 - 00:08:39 CDT

My implication is that since the vendors pay for the tests, and the
results are trade secrets, the vendors exert undo influence on the
testing process. Lillie's suggestion weakened that implication.
Dick's suggestion is orthogonal to my point, but still valid. I'll
refrain from adding it, though.

On the other hand, Environmental Impact Reports in California are
paid for by the developer but the government agency chooses the
contractor and has the contract. I think we're getting somewhat
arcane, however.

Best regards,
Arthur

At 11:11 AM -0700 10/26/06, Richard C. Johnson wrote:
>It sounds good that the fabulously wealthy vendors pay for testing,
>but my actual experience calls this into question. Diebold, ES&S,
>and Sequoia can pay any amount charged for testing from their ample
>coffers and then just up their prices. The same is NOT true for
>small, Open Source, startups seeking to compete with the established
>players, who inevitably are short of money.
>
>Charging a market entry fee, in effect payola or pay for play, has
>the effect of weeding out all but the industry leaders. Once the
>small players are weeded out, well, the surviving folks can recoup
>the cost of testing by charging the customer (read taxpaying voter)
>whatever they like.
>
>On the other hand, if the state pays for the testing beyond some low
>threshold, more competitors will mean lower prices and maybe even an
>Open Source option. Eitherway, the taxpayer pays. But, with
>upfront testing costs bourne by the state, the total cost to the
>taxpayer customer will be less and the quality and number of the
>choices will be higher.
>
>In the case of OVC, testing should be supported by funds raised for
>the purpose, with the emphasis on the Open Source community
>providing test code to be run against systems under test loaned to a
>cooperating agency. OVC can play a very valuable role in organizing
>this testing or it can foster creating of an Open Test center at a
>university.
>
>Alternatively, the state can tax the sale of voting machines to pay
>for a test lab to test all comers. A successful demo requirement is
>barrier enough to keep out the truly non-working voting systems.
>
>In any case, the cost of certification testing should not be a
>barrier to entry in the market for voting systems. Unless, of
>course, you fancy the current market leaders...
>
>-- Dick
>
>Arthur Keller <voting@kellers.org> wrote:
>
>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 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 boad 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
>
>
>
>_______________________________________________
>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:08 2006

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