Re: [EILeg] Cascading Audits

From: Jerry Lobdill <lobdillj_at_charter_dot_net>
Date: Wed Dec 13 2006 - 21:20:21 CST

Ron,

You seem not to understand probability theory as applied to the
problem of audits. Overkill is not present in my proposal. You
simply assert that it is without any technical argument. Your
argument is based on what election administrators want, and that is
not a proper stance to take.

You came up with this cascading audits idea just yesterday and do not
even have a technical exposition of it published anywhere. Please
excuse me if I seem a little cranky about your presumptuous attitude,
but it does annoy me. If you think so highly of it, why not publish
a complete detailed statistical analysis that justifies your
idea? Then I promise I will provide a technical critique of it
devoid of any crankiness.

At 05:37 PM 12/13/2006, you wrote:
>On Wed, 13 Dec 2006 16:16:52 -0600, Jerry Lobdill wrote
> > At 02:38 PM 12/13/2006, you wrote:
> >
>>Jurisdictions will object strenuously to the idea that the
>>detection of a single miscounted precinct should trigger a full
>>recount of the entire affected jurisdiction (e.g., imagine
>>recounting California because something went wrong in the U.S.
>>Senate race in a single precinct having 300 registered voters). The
>>cascading audit scheme attempts to address this objection while
>>still providing an effective audit. I think that jurisdictions will
>>be much more likely to accept the cascading audit than the
>>full-recount-on-a-single-miscount scheme that you've proposed.
>> >
>> > -R
>[Stuff that was better not said omitted.]
>
> > If a single precinct IN A COUNTY is found corrupted in a sample
> selected from the population of ALL precincts in the COUNTY that
> are voting in the race being audited, this precipitates a full hand
> recount of ALL precincts in the COUNTY that are voting in the race.
>
>Los Angeles County has about 5,000 precincts. Requiring a full
>recount of that county when something goes wrong in a single
>precinct would be massive overkill. The cascading audit is much more
>economical, yet still gives us an excellent (p=0.99) chance of
>detecting at least one additional miscounted precinct if any such
>precincts exist. In consequence, I think that it would be much more
>acceptable to officials, and thus more likely actually to make it into law.

As seen through the eyes of officials--who don't ever want to do a
recount under any circumstances.

> > ...Any corrupted precinct precipitates a full hand recount IN
> THAT COUNTY. The reason for this is that a wholesale attack is not
> spread from county to county or from the state level to the
> counties. It is launched independently in each county in which it appears. <
>
>This is incorrect. A wholesale attack easily can originate at a
>vendor or at one of a vendor's suppliers, and can therefore affect
>any jurisdiction using the affected machines -- potentially the entire nation.

Typically it would originate at a county election administration
office. Most candidates would not have the inside contacts to attack
through the vendor. They would most likely attack through the
contacts they have in the election district and that would mean that
each county's system would have to be attacked independently. It's,
of course, possible that the trojan horse could be inserted into a
new version of GEMS software (or its equivalent) certified by the SoS
for use in the state at the precise time required to affect the
election, and therefore promulgated to all users of the vendors'
machines. If that unlikely event happened my audit procedure would
catch it anyway, so your argument is of no effect.

> > There may be a few refinements yet to be made in the procedure
> for sample selection, but I assure you they do not involve your
> cascading audits idea as expressed below. <
>
>Then please propose an approach that minimizes overkill while still
>providing adequate assurance of detecting further miscounts. Or at
>least tell me what's wrong with cascading audits. I am more than
>willing to consider reasonable objections (e.g., it's not
>mathematically supportable because..., it's too clumsy because..., etc.)

There is no overkill. Why don't you tell us why your idea is
mathematically supportable.

>...
> > As best I can tell, you came up with your cascading audits notion
> off the top of your head yesterday. Please read what has been
> published by myself, Howard Stanislevic, and Kathy Dopp, and
> reconsider your idea. <
>
>I have read Kathy's papers (at least the ones that she's cited
>here), which recognize that there's a question about what to do when
>the initial audit discovers a discrepancy, but say that further
>research is needed to determine what to do about it.

I don't speak for Kathy. Although we do agree in most particulars on
how to design the audit she apparently has not gone farther and
decided what to do with the results of the audit.

> I have read your audit paper posted at NIST, and I don't recall it
> saying anything about this issue.

In my paper I did not specifically debunk the idea that the
hypothesis being tested in my audit plan to a 99% confidence level
would need further supporting auditing before a sufficient level of
confidence was reached to order a recount. No one had specifically
made such a claim at the time I wrote the paper. However I did say
this: "It is extremely important to avoid legal language that gives
election officials the power to emasculate the mandatory audit
process." I said that because Howard Stanislevic had written that he
thought election officials would want discretion to decide what to do
when the audit uncovered a corrupt precinct which had errors that
support the likelihood of a trojan horse attack on the race being
audited. Howard, Kathy, and I agree on how to design the audit, but
neither of them, so far as I'm aware, has agreed that the audit
result should trigger a recount--but neither have they said it should not.

In my latest paper, written at your suggestion, and I hope by now it
is available in the files on the EI Leg website, I said,

"In an audit, enough polling place returns are counted by hand that
we will find, with 99% confidence, at least one polling place that
exhibits this kind of error if the election has been successfully
attacked. If one such discrepancy occurs in the sample audited it
should trigger action that is mandatory."

When I said that, I did not mean that maybe 99% confidence isn't
enough and that the mandatory action should be to audit some more
precincts, and to keep on doing it until you've audited all the
precincts (which is what you've said, I believe). The probability is
extremely small that only one precinct in an election in which votes
are tabulated in PCOS machines is corrupted by vote switching in the
direction needed to fraudulently elect the ostensible winner. This is
not the kind of random error you find that is a programming bug. It
is the kind of systematic error that has a 99% chance of showing up
in the audit if the election has been stolen by vote switching.

If one follows your prescription of cascading audits it appears that
you end up auditing all precincts. Isn't that a full recount? You
don't say what would prevent that from happening or what the
statistics are on each iteration or why whatever the confidence level
is, it's never enough.

Do you think you could flesh out your proposal so that it's clear why
you're doing each step and how it's all statistically justified?

> Thank you for clarifying your position that discovery of a single
> miscounted precinct should trigger a countywide recount. I
> disagree, for the reasons stated above. I have not (knowlingly)
> read Mr. Stanislevic, but I'll search for him and see what his
> papers have to say.
>
>-R
>
>>On Wed, 13 Dec 2006 09:35:43 -0600, Jerry Lobdill wrote
>> > > This is a response to both Arthur and Ron re auditing.
>> > >
>> > > This business of "further auditing" seems to me to be
>> misguided thinking. In the audit scheme that I have proposed the
>> kind of miscount and the race in which it occurs cannot in any
>> reasonable analysis be considered an ambiguous result that would
>> be cleared up by more auditing. If it occurs once in a sample
>> that is properly sized and randomly selected it should be
>> considered sufficient evidence to trigger a full recount. You
>> don't even need to audit the complete set of precincts in the
>> sample once you've found the first precinct that satisfies the
>> detection criterion.
>> > >
>> > > We can discuss this further if you don't agree.
>> > >
>> > > Jerry Lobdill
>> > >
>> > > At 02:00 PM 12/12/2006, eileg-request@lists.sonic.net wrote:
>> > >
>> >
>>>From: "Ronald Crane" <voting@lastland.net>
>>> > > Precedence: list
>>> > > MIME-Version: 1.0
>>> > > To: eileg@lists.sonic.net
>>> > > Date: Mon, 11 Dec 2006 20:14:31 -0800
>>> > > Message-ID: <20061212035633.M61444@lastland.net>
>>> > > Content-Type: text/html;
>>> > > charset=iso-8859-1
>>> > > Subject: [EILeg] Cascading audits
>>> > > Message: 12
>>> > >
>>> > > An important question raised by audits is what further
>>> auditing should we do if we discover precincts that miscounted
>>> their votes. It strikes me that a good approach might be like this:
>>> > >
>>> > > 1. Reduce the winning candidate's effective margin of victory
>>> in accord with the results of the audit from the miscounted precincts.
>>> > >
>>> > > 2. Treat the precincts that were not audited the first time
>>> around as if they represent a new election.
>>> > >
>>> > > 3. Iterate the audit, calculating the number of precincts
>>> that we need to audit to have p=0.99 of discovering at least one
>>> miscounted precinct (given the new margin of victory and the
>>> minimum number of precincts that an attacker would have to flip
>>> to gain victory), and randomly selecting the new precincts to audit.
>>> > >
>>> > > I haven't carefully analyzed this procedure, but it seems
>>> that, when it terminates, we will have at least p=0.99 assurance
>>> that there are not enough miscounted precincts to flip the election.
>>> > >
>>> > > It also seems reasonably economical, avoiding the big hit of
>>> simply auditing all the precincts when we discover some number of
>>> miscounted ones.
>>> > >
>>> > > Comments?
>>> > >
>>> > > -R
>>> > > From: "Ronald Crane" <voting@lastland.net>
>>> > > Precedence: list
>>> > > MIME-Version: 1.0
>>> > > To: "Ronald Crane" <voting@lastland.net>, eileg@lists.sonic.net
>>> > > References: <20061212035633.M61444@lastland.net>
>>> > > In-Reply-To: <20061212035633.M61444@lastland.net>
>>> > > Date: Tue, 12 Dec 2006 00:23:53 -0800
>>> > > Message-ID: <20061212082107.M25279@lastland.net>
>>> > > Content-Type: text/html;
>>> > > charset=iso-8859-1
>>> > > Subject: Re: [EILeg] Cascading audits
>>> > > Message: 13
>>> > >
>>> > > 1. Reduce the winning candidate's effective margin of victory
>>> in accord with the results of the audit from the miscounted precincts.
>>> > >
>>> > > 2. Treat the precincts that were not audited the first time
>>> around as if they represent a new election.
>>> > >
>>> > > 3. Iterate the audit, calculating the number of precincts
>>> that we need to audit to have p=0.99 of discovering at least one
>>> miscounted precinct (given the new margin of victory and the
>>> minimum number of precincts that an attacker would have to flip
>>> to gain victory), and randomly selecting the new precincts to audit.
>>> > > To be more explicit:
>>> > >
>>> > > 4. Repeat 1-3 until either an audit finds no more miscounted
>>> precincts or you've audited all the precincts.
>>> > >
>>> > > -R
>>> > >
>>> > > At 8:14 PM -0800 12/11/06, Ronald Crane wrote:
>>> > >
>>> >
>>>>It also seems reasonably economical, avoiding the big hit of
>>>>simply auditing all the precincts when we discover some number of
>>>>miscounted ones.
>>>
>>> > > There's a big thing missing from the issue of recounting some
>>> or recounting all precincts argument. And that is determining
>>> the source of the problem in the first place. I suggest that
>>> some absolute threshold, such as an error rate exceeding a
>>> certain number or percentage of votes result in an evaluation of
>>> the causes of the error. This should be separate from the
>>> decision to recount for the purposes of determining the winner.
>>> > >
>>> > > Furthermore, this issue is independent of technology. It
>>> applies equally to HCPB, where it might uncover a counting
>>> conspiracy among volunteer counters.
>>> > >
>>> > > Best regards,
>>> > > Arthur
>>
>> >
>> >
>
> > (In accordance with Title 17 U.S.C. Section 107, this material is
> distributed without profit to those who have expressed a prior
> interest in receiving the included information for research and
> educational purposes. ProgressiveNews2Use has no affiliation
> whatsoever with the originator of this article nor is
> ProgressiveNews2Use endorsed or sponsored by the originator.)
> >
> > "Go to Original" links are provided as a convenience to our
> readers and allow for verification of authenticity. However, as
> originating pages are often updated by their originating host
> sites, the versions posted on ProgressiveNews2Use may not match the
> versions our readers view when clicking the "Go to Original" links.
> >
>

(In accordance with Title 17 U.S.C. Section 107, this material is
distributed without profit to those who have expressed a prior
interest in receiving the included information for research and
educational purposes. ProgressiveNews2Use has no affiliation
whatsoever with the originator of this article nor is
ProgressiveNews2Use endorsed or sponsored by the originator.)

"Go to Original" links are provided as a convenience to our readers
and allow for verification of authenticity. However, as originating
pages are often updated by their originating host sites, the versions
posted on ProgressiveNews2Use may not match the versions our readers
view when clicking the "Go to Original" links.

_______________________________________________
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 Sun Dec 31 23:17:13 2006

This archive was generated by hypermail 2.1.8 : Sun Dec 31 2006 - 23:17:16 CST