Re: Shamos Rebuttal, Draft 3

From: Edward Cherlin <cherlin_at_pacbell_dot_net>
Date: Tue May 10 2005 - 13:59:14 CDT

On Sunday 08 May 2005 18:13, Ron Crane wrote:
> 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...
> >
> > 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.

Trusting vendors means not only trusting them to be honest but
also trusting them to be competent. There is extensive evidence
of vendor incompetence, but no hard evidence of malice--just a
few thoughtless public utterances and the suspicion of some
statistically nearly impossible election results. Harping
exclusively on malice comes over as conspiracy theory, while
dealing with incompetence is entirely sane and practical.

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

He is entirely inconsistent on this point. Vendors may be
incompetent, and testing may not work, but we should trust the
system anyway--*only because no fraud has been detected*.

Shamos's redirection of the question away from measures to combat
incompetence and toward the issue of vendor honesty is the most
dangerous aspect of the paper, and should be hammered as his
biggest mistake.

> Were I writing a general overview of voting system security,
> I'd want to cover all these areas, and more.

This *is* a general overview of voting system security. Shamos
pretends to do just that, and his ignoring of the most important
issues is his biggest and most dangerous mistake.

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

> > ...Harris is the perfect
> > example of why *nobody* in the voting business should be
> > trusted *without verification*....
> 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!

A great pleasure.

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

You're welcome.

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

You better believe they did. I'll send some quotations in a
separate e-mail.

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

Say it more clearly, then.

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

My mistake. I forgot that that was the title, and was going by
the fact that the phrase didn't occur in my edits. OK, it is. I
think we need it. Thompson actually built such a compiler as an
experiment, and it somehow got leaked out to Bolt, Baranek &
Newman. Although there is no evidence of it going any further,
there is a persistent urban legend about it escaping.

> >> 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 hammer on the fact that Shamos has missed the point.

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

Same comment as 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.

I don't see why. It is accurate.

> Also your deletion of
> the sentence about eroding vigilance removes an important
> qualification.

If so, that was my error.

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

This is already a part of the discussion, after the chief of
Diebold publicly promised to deliver the Ohio vote to the
Republicans. It is proper in a security analysis to consider
distant and seemingly unlikely threats.

You can qualify what I said, but the concern is real, and Shamos
ignores it. We need to say so.

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

We don't.

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

In cities and states as a whole, certainly. I'm thinking of
specific Chicago wards and districts in New York City.

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

These are not "regular updates". They are entirely irregular. I
am sure that we can come up with a more accurate wording.

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

I don't see it. Election conspiracy on this scale is a documented
fact in US history, on the part of both Democrats and
Republicans. The question is in court today. Even if we could
suppose it unlikely at some particular time, it would still be
necessary to guard against its reappearance.

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

We have to deal with both vendor malice and incompetence, and
with other threats.

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

Don't we have that already written in the FAQ? But here you go.

Shamos's discussion of paper ballots considers them in isolation,
not as part of an interconnected system providing audit
capabilities. Certainly paper ballots all by themselves are
subject to a number of ills that have been seen and documented
in the past, including removing ballots, ballot-box stuffing,
and others. However, current proposals for adding paper
printouts to electronic voting machines are based on the
fundamental auditing principle that there must be something to
compare in an audit. This goes back to the foundations of
double-entry bookkeeping, where it is the two separate debit and
credit entries for each transaction that make comparison and
detection of cheating possible.

An electronic voting system by itself is at least as vulnerable
to cheating as paper by itself. No meaningful recount is
possible in a purely electronic system. No review of ballots to
determine voter intent is possible. There is nothing to compare
the electronic records with.[cite somebody else on this point]

However, the combination of electronic and paper records gives
several opportunities for comparisons and cross-checks. First,
the voter can, if permitted, check that the machine display and
the paper printout agree, not just with each other but with the
voter's intent. Second, the electronic records can be compared
with the paper during tabulation of the vote and later, if
necessary, during any court challenge to the election, or any
criminal proceeding against people trying to change the outcome.
These capabilities greatly reduce the opportunity to remove,
insert, or change votes undetected. Many other security measures
can be designed into a system containing both electronic and
paper data paths that are not possible using either one alone.
[refer to OVC and other designs]

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

Vendor incompetence. Very important.

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

Perhaps we could put the Nimitz collapse in the footnote? I just
don't want to leave an opening for a strawman attack on the
bridge concept.

My point is simply that it is incorrect to say flatly that
because a bridge stood for 15 years, we can expect it to
continue to stand. Just like the discrete system, it may not
have encountered some specific set of circumstances. I offered a
minimal change to a factually correct statement.

However, now that I think about it more, I conclude that your
distinction between threats to continuous and discrete systems
is invalid, and should be entirely removed.

> >> I'll kick out another draft tomorrow.
> >>
> >> -R

I'm looking forward to it.

Edward Cherlin
Generalist & activist--Linux, languages, literacy and more
"A knot! Oh, do let me help to undo it!"
--Alice in Wonderland
OVC discuss mailing lists
Send requests to subscribe or unsubscribe to
= 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:31 2005

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