Re: TAR--audits. urgently need help to get law.

From: charlie strauss <cems_at_earthlink_dot_net>
Date: Wed Nov 22 2006 - 15:15:56 CST

-----Original Message-----
>From: Ron Crane <>
>Sent: Nov 22, 2006 2:53 PM
>To: Open Voting Consortium discussion list <>
>Subject: Re: [OVC-discuss] TAR--audits. urgently need help to get law.
> Page 140 of the Brennan
>Center's report contains a formula for determining the number N machines
>you need to recount to have probability D of detecting at least one
>compromised machine, where fraction C of the machines are compromised:
> N = log(1-D) / log(1-C)
>Solving this formula for C and using D=0.9 and N=33 (from your previous
>email), I found that the legislation appears to envision that an
>attacker will compromise no fewer than 6.7% of machines. That seems too

It fits with what I stated. If 6.7% of the machines are compromised and if the maximum unsuspicious vote shift is a whopping 30%, then 6.7% of 30% is 2%.

So the only way a you could shift the election by more than 2% margin is if more than 6.7% of the machines were shifting the election by 30%. If the maximum supsect shift were less, say 15% then 13% of the machines would need to be rigged.

Thus the number of machines I said to audit is consistent with this 90% detection confidence.

I note that in the last election the closest minor race (mayor I think) was actually was a tie and the closest major race was 0.5%. so to upset a 0.5 % margin you need to audit more machines. But a 0.5% shift would still require someone to compromise about 1.5% of the machines if they shifted 30% of the vote.

Notice however that as the number of attacked machines delines and the shift percentage remains absurdly high, like 30% that these few machines stick out like sore thumbs. In this regime a TAR would knock them down like bowling pins.

The reason why the law prescibes an election commission for how to expand the recount if the error rate is too large is that the ways things can go south is myriad. Take for example the case above of the last election where we had a 0.5% shift for congresswoman. That came down to less than one vote per precint. If you did the intial random audit and you found not some glaring 30% error but instead you noticed that the hand count and the machine totals were off by just one vote on all the machines you looked at what do you do. Well if that's all I told you then you'd have to assume that was the intrinsict error rate for hand marked optical scan defects (e.g. poorly filled ovals) and say it was all cool and the likelihood a full recount would change the election would be near zero. But if I told you that 100% of those extra votes went for one candidate and never the other you'd say that you had very good evidence of an error that could change an election.

I actually strongly dislike the idea of an election commission since it will have obvious problems. But I don't have a better solution yet. You can't enshrine every failure mode in law because you can't anticipate them. Perhaps we can spell out a few. But I'd prefer I think to create the commision then fix later it if it turns out not to work than over specify it and never get the law past to begin with. The compromise is that the commission has a very simple unambiguous charge to keep expanding the random recount until the likelihood of a full recount overturning the election is less than 10%.

As a final escape valve our current law allows a candidate to pay for as much of a recount as they want. So if they don't find the commissions audit satisfying and they think 10% is still a good chance then they can pay for a better audit (and get reimbursed if the eleciton outcome changes).

Ultimately as long as one can sufficiently deter fraud by making it unlikely to go undetected then residual errors that might sneak through at the 90% detection threshold that affect absurdly tight margin races don't, personally, bother me much. Elections cant measure the will of the electorate that preciseley, so an effective tie just means either candidate is just as good a representative. I note that a 90% detection threshold does not mean errors sneak through 10% of the time. First that assumes there are any errors at all. Second it assumes the errors are maximally concntrated and systematically all in one direction. Since none of those is likely in practice, the number of errors that will actually sneak through at the 90% confidence level in miniscule.

>> The glaring problem is the axiomatic assumption of the worst case scenario that
>> would be considered undetectable: maybe 30% is better than 15%. If
>> it were 30% and we assumed 15% then the number of machines we need to
>> audit is much larger.
>Yes. In particular you need a larger sample if there's no other way to
>detect most of the worst-case machines.

Which of course is why the TAR compliments the random count.

>> As a relevant aside I note that one of hidden beauties of tossing in
>> a limited Targeted (TAR) selection is to helps us determine if 15% or
>> 30% is the worst case bounds by cherry picking the machines that
>> other prior information outside the model tells us are the likely
>> worst cases. ...
>Not really. To paraphrase Rumsfeld, you have a difficult time knowing
>what you don't know. The TAR increases the chances of finding the worst
>machines, and of finding out just how bad they are, but it doesn't tell
>you how bad they might become. Also, attackers aren't sitting still.
>They're looking at your audits and are devising new ways to sidestep them.

As I noted above, as the margin shrinks the random audit gets more extensive, and cosnequently the number of machines an attacker can penetrate while evading detection shrinks to the point where their anomolous statistics makes them increasing vulnerable to the TAR.

>Thanks for the explanation.

Thanks for the questions. Made me think.

>OVC-discuss mailing list

OVC-discuss mailing list
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
Received on Thu Nov 30 23:17:11 2006

This archive was generated by hypermail 2.1.8 : Thu Nov 30 2006 - 23:17:19 CST