Re: Shamos Rebuttal, Draft 3

From: Ron Crane <voting_at_lastland_dot_net>
Date: Sun May 08 2005 - 20:13:20 CDT

On May 8, 2005, at 2:11 PM, Edward Cherlin wrote:

> It is proverbial in the computer business (unlike politics) that
> incompetence is to be suspected before malice....[an] on-line poker
> establishment used a dud shuffling
> algorithm and an even dudder random-number-generator-seed
> selection method in a system for Texas Hold'em where a player's
> computer could determine the current seed in real time, and thus
> know the entire deal (every player's hand and the shared cards)
> in advance. They say they got a lot of media coverage.
>
> So we should not focus only on the malicious vendor. The known
> incompetent vendors together with the known malicious/corrupt
> politicians with the money to hire corrupt programmers and other
> technical people are here.

I'm focussing on the potentially malicious vendor because Shamos
implies that we generally should trust vendors, and we need to
discredit this dangerous idea. On the other hand, he criticizes vendor
incompetence (e.g., s.1.5), so I don't see that it's so important to
explore that area -- in this paper. Were I writing a general overview
of voting system security, I'd want to cover all these areas, and more.

> On Saturday 07 May 2005 14:30, Ron Crane wrote:
>
>> I would like to describe instances of gambling machine
>> cheating, but not the one about Ron Harris. The reason is that
>> 3.5.1 advocates requiring intrusive inspection of voting
>> machines along the same lines as gambling machines, which are
>> thus inspected by the Nevada Gaming Control Board. But Harris
>> did his cheating while working for the Board, and using its
>> inspection equipment to insert his cheating code. This
>> introduces a difficult rhetorical issue that would make us
>> look like we're talking out of both sides of our mouths.
>
> I thought the idea was to advocate a completely open process,
> i.e. publishing source code, at a minimum, and Open Source
> licensing, for preference. Harris is the perfect example of why
> *nobody* in the voting business should be trusted *without
> verification*. So if it looks like we are talking out of both
> sides of our mouth, nix the idea of relying on intrusive
> government inspection, and emphasize even more the need for
> vigilance by citizens, and therefore the need for an opportunity
> for vigilance.
>
> I just looked up Harris. He was supposed to verify EPROMS in slot
> machines in Nevada, but he reprogrammed some of them. This is
> precisely the sort of thing we are trying to prevent. Sure,
> Harris did it on his own, but his technique demonstrates how a
> crooked vendor or election official could do it. Or how a
> political operative could get a job as a Trusted Person in order
> have the opportunity to mess with the machines in a close
> election. Harris also read the dud random number generation code
> for some of the machines, and figured out how to predict Keno
> results.

I think we need both intrusive government inspection and citizen
vigilance. But this discussion has helped me figure out how to use the
Harris example without ditching government inspection. Thanks!

>> If
>> you know of other instances of gambling machine cheating that
>> involve vendors, please bring them up.
>
> It didn't take me long to find these through Google.
> http://www.casinogaming.com/features/blackbook/
> "After a slot machine maker rigged electronic poker machines ten
> years ago to limit the number of jackpots, Nevada regulators set
> technical standards for gaming machines."....

Good stuff.

>
>> Some of the other changes tend to defocus the argument, such
>> as the comments about the Founders
>
> The comment about the Founders was a replacement for a far less
> focussed clause about relegating the issue to academic
> discussion. No, this was a real live issue back then, discussed
> in the Federalist Papers, in its analysis of how each branch of
> the Federal government could and should act to keep the others
> from becoming tyrannical and oppressive, and elsewhere in public
> discussion. Jefferson, in particular, went on about the problem
> (not vote fraud, specifically, but any usurpation of power) for
> the rest of his life. Something about fertilizing the tree of
> Liberty with the blood of tyrants, IIRC.

But the passage you edited concerned Shamos's comment on illegitimate
presidencies, an issue I don't think the Founders debated at all. "Best
left as an academic exercise..." was meant to say that we should, at
all costs, avoid putting ourselves in a position where we would have to
consider the question in earnest.

>> and 'Reflections on Trusting Trust'.
>
> Not mine. In fact, I don't see it in the paper. What are you
> referring to?

Your edit in 3.2 says, in part, "but attacks on such verification
systems are also known,[Thompson, Turing Award lecture] if the compiler
and libraries are not also subject to detailed inspection." That sure
looks like a reference to Reflections on Trusting Trust.
http://www.acm.org/classics/sep95/ .

>> Generally I want to keep the focus on dishonest vendors (as
>> opposed to politicans and voting officials), since Shamos's
>> main argument is that, with a few tweaks, vendors can be
>> trusted. They must not be, and their global reach implies a
>> global reach for potential vendor fraud.
>
> We must also be vigilant against vendor incompetence that allows
> others to cheat, a known phenomenon since the invention of the
> first mechanical voting machine.

See above.

>> I disagree with some other edits. For example, on average, the
>> incentive to verify votes is substantially weaker than the
>> incentive to verify financial transactions. Almost everyone
>> cares about her money, while many (a majority, in most cases)
>> don't care enough about voting even to cast a ballot.
>
> I wrote, "similarly, while some highly-motivated voters always
> will wish to verify whether their votes properly are counted,
> many others will not." Also, "Designing a system that will
> uncover fraud with the likely rather small fraction of voters
> checking is highly desirable and definitely possible." Doesn't
> that agree with what you say?

It agrees, but is inappropriately weak. Also your deletion of the
sentence about eroding vigilance removes an important qualification.
The second sentence ("Designing a system...") confuses the argument,
which contrasts systems that process financial transactions (e.g.,
check clearing) with *existing* voting systems. The second sentence
proposes a way in which voting systems might be made more like
financial systems, and thus scatters and weakens the argument. We have
to refute Shamos's arguments as they are, not artificially strengthen
them and then try to refute the strengthened versions.

>> I don't
>> want explicitly to raise "the possibility of an alliance
>> between vendors and political parties or even administrations,
>> as in disputed elections in Central Asia...."; it will sound
>> too much like "conspiracy theories" to many readers.
>
> Even if you're paranoid, there may still be somebody out to get
> you. ^_^

True. But we also should be careful not to set off readers'
improbability detectors, or they are likely to dismiss the entire
paper.

> Part of our point is that much of the public and most of those
> with technical knowledge and understanding are already highly
> suspicious (with good reason), not only of the machines, but of
> the vendors, the politicians, and voting officials (many of whom
> belong in jail right now, including substantial parts of the
> Florida and Ohio administrations). But I was willing to be
> distant and polite in the paper, and stick with undisputed
> facts. [snip stuff along the same lines]

There is good reason to be suspicious. But we should be careful not to
overstate what is documented, nor to come off as conspiracy theorists.

>> The
>> qualification about one-party districts is an oxymoron: the
>> voting system knows the parties involved in each election, so
>> it's not going to shift votes between parties if there isn't
>> more than one party involved (e.g., during a primary
>> election).
>
> You mean single-district elections for legislators? That isn't
> what I was talking about. I meant one party districts
> (registration of actual population) in multi-party elections
> over larger areas. Well, if you can't understand what I wrote,
> it must need clarification.

I find it difficult to believe that low single-digit shifts between the
major parties would ring alarm bells anywhere in the United States.
There are more than a few Democrats in the most Republican of places
(e.g., Utah: Bush 72%, Kerry 26%), and more than a few Republicans in
the most Democratic of places (e.g., San Francisco: Kerry 83%, Bush
15%). If the 11% swing in Cleland/Chambliss didn't ring bells, why is
1-2% going to?

>> I strongly disagree with your deletion of the
>> argument about vendors distributing Trojan Horses along with
>> regular updates; it is a perfect subterfuge.
>
> Regular updates without testing are illegal. It is a strawman
> waiting to be knocked down.

Testing is very unlikely to discover all but the most
incompetently-designed Trojan Horses. Further, vendors already have
been caught applying illegal patches, as Jim March has documented. The
"strawman" still stands.

>> "Cheating with
>> triggers" requires vendor-provided malware,
>
> Malware provided by somebody, not necessarily a vendor....

It still requires the cooperation of many more parties than malware
that operates without user-invoked triggers, and thus is likely to
"trigger" the view that we're conspiracy theorists.

>> Also it will read like
>> conspiracy theories to many, since it requires many
>> individuals to cooperate to produce any significant effect.
>
> CREEP, the Plumbers, the whole Nixon White House, Donald
> Segretti's distributed dirty tricks in particular..."Landslide"
> Lyndon Johnson and his pet shyster, Abe Fortas...The Kingfish,
> Boss Tweed...Don't tell me it hasn't happened, and don't tell me
> it isn't still happening.

I'm NOT telling you "it hasn't happened". I'm telling you that
emphasizing this stuff will make us sound wacky to some readers. If we
show (as we do) the practicality of malware that doesn't require
triggers, we have, by implication, shown the practicality of malware
that does require triggers. And we've avoided most of the
cloak-and-dagger stuff to boot.

>> I am deleting the last item in 5. It's a minor point, and I
>> refuse to cite any improperly-conducted poll (such as the
>> ACM's poll on paper trails) in any formal paper.
>
> You refuse to *mention* it with appropriate qualifications? I
> wrote, "Although no strong statistical inference of confidence
> within a few percent can be drawn from such data, it certainly
> has the appearance of contradicting Shamos's assertion that most
> of this population are undecided." What's wrong with that?

It leaves us vulnerable to reassertion of Shamos's original point about
"9,999 of 10,000" computer scientists "remaining open-minded on the
subject" (or whatever he said). But, worse, "within a few percent" is
just incorrect. Responders to the ACM's poll were entirely
self-selected, leaving us unable to draw any useful statistical
conclusions from it, let alone "within a few percent". The only
appropriate qualification for that poll is not to use it. And, since
the entire point is really a tempest in a teacup, and it lengthens the
paper, it's not worth keeping.

>> The qualifications you added to the conclusion weaken it
>> substantially, and introduce terms not elsewhere defined
>> ("auditable dual data paths", "Best Practices").
>
> Well, let's define them, then. I want to be able to make an
> explicit comparison of dual data paths with double-entry
> bookkeeping. Having two sets of data is the essence of
> auditability. Best Practices is a standard term in matters of
> government regulation....

Then maybe there needs to be an explicit discussion of the auditing
capabilities that paper ballots/trails add, which would be used to
refute Shamos's argument that paper adds nothing but trouble. A few
concise paragraphs along these lines would fit in 3.1.1. I'm glad to
include them if you write them.

>> Finally, I am a little confused by your edit in 3.3. Earlier
>> you blasted [1] my comparison between software and bridges,
>> saying that, "among historians of bridge engineering it fails
>> the laugh test--in fact the guffaw, hoot, and holler, pounding
>> on the floor with tears in your eyes test." But your edit
>> leaves the comparison intact, with a general qualification
>> "normally" (which, BTW, is already implied by the footnote),
>> and the addition of a description of the Tacoma Narrows bridge
>> and its mechanism of failure that only confuses the
>> argument.
>
> Well, you can take out Galloping Gertie, but we need at least one
> example, unless we take bridges out completely. The Nimitz
> collapse would do....

I don't understand the point. It just confuses the issue and undermines
the comparison between continuous and discrete systems. Footnote 37
already qualifies that comparison, noting that some continuous systems
(e.g., global climate) are chaotic. It also notes that bridges
specifically are engineered for stability within (and well beyond)
their intended operating ranges. That some bridges have failed due to
improper design does not invalidate the continuous/discrete comparison.
If you know of something that does invalidate it, we should, of course,
use another comparison.

>> I'll kick out another draft tomorrow.
>>
>> -R
>>
>> [1] I (and probably others) would be happier at OVC if our
>> discussions contained rather less dragon-fire.
>
> Marry, say not so, good sir. The very thought woundeth me. ;->

As one wit paraphrased Gandalf: "Meddle not in the affairs of dragons,
for you are crunchy and taste good with ketchup".

-R

_______________________________________________
OVC discuss mailing lists
Send requests to subscribe or unsubscribe to arthur@openvotingconsortium.org
==================================================================
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
==================================================================
Received on Tue May 31 23:17:25 2005

This archive was generated by hypermail 2.1.8 : Tue May 31 2005 - 23:17:52 CDT