Re: Shamos Rebuttal, Draft 3

From: Ron Crane <voting_at_lastland_dot_net>
Date: Tue May 10 2005 - 15:23:55 CDT

On May 10, 2005, at 11:59 AM, Edward Cherlin wrote:

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

Incompetence has been a huge problem. However, I think you're treating
some events as evidence of incompetence when they could just as well
have been evidence of fraud. Looking through shows many
instances of lost votes, switched votes, inability to cast votes for
certain candidates, etc. Your "Occam's Election Razor" would attribute
all of these to incompetence. I don't think that's a valid assumption,
since it shortchanges the strong motivation to engage in fraud. I
basically disagree that the Razor is, itself, justified. And its use
makes it more difficult to address vendor fraud.

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

It is a rebuttal to Shamos's piece that advocates existing voting
systems with minor tweaks. Making it a general overview of voting
system security would make the paper much longer (and thus less likely
to be read) and require significantly more effort. We probably should
write such a paper, but I disagree that this paper should be it.
Certainly Alan's request was not for a general overview, but for a
(hopefully readable and relatively brief) rebuttal. Further, someone
already wants to send this paper to a legislator. I would prefer to
release it soon enough to make this possible.

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

Even if so, these would just be irrelevant to the point, which is that
we shouldn't put ourselves in the situation where we have to consider
in earnest the meaning of, and the recovery from, an illegitimate
presidency. Exploring the issue in more depth than that would just add
detail without supporting the point.

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

Alright, I'll try something else.

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

We might briefly mention it in a footnote. It is certainly worthy of
consideration when building a system, but anything more than a brief
mention in this paper will confuse the main arguments.

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

It's accurate, and weak.

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

I have added something similar in a footnote, so as not to confuse the
main argument.

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

I disagree, as previously indicated.

>>>> 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 couldn't find results for Chicago or NYC, so I scanned San Francisco
) instead, which is, presumably, as Democratic as they come. A quick
scan of November's results shows NO precinct where Bush got less than
1.8% of the vote; the 1.8% precinct was #3823. I doubt very much that,
if the result had appeared as 3.6% (or even 5%) instead, anyone would
have noticed.

I think you're just incorrect on this.

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

So vendors do not issue updates as a matter of course? Even if they do
not, a Trojan could be put in any update.

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

And you were complaining that my focus on vendors makes us look wacky?
If large-scale conspiracies of the kind you're describing have
occurred, why not much smaller-scale conspiracies by vendors?

>>>> 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 disagree, and have already included a qualification about chaotic
continuous systems and the manner in which bridges are engineered. I
also do NOT say "flatly that because a bridge stood for 15 years, we
can expect it to continue to stand". I note that it is "reasonable" to
say so. I do not say that the bridge is certain to continue to stand,
or that it's a "fact" that it will continue to stand, or anything of
the kind.

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

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:32 2005

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