Re: Brand new concept in audit trails

From: Ron Crane <voting_at_lastland_dot_net>
Date: Wed May 04 2005 - 18:31:37 CDT

On May 4, 2005, at 3:28 PM, Jim March wrote:

> Ron Crane wrote:
>
>> On May 4, 2005, at 2:54 PM, Jim March wrote:
>>
>>> Ron Crane wrote:
>>>
>>>> On May 4, 2005, at 2:18 PM, Jim March wrote:
>>>>
>>>>> Ron Crane wrote:
>>>>>
>>>>>> That's a big problem. It's one thing to reduce voting privacy for
>>>>>> everyone, and something else to reduce privacy such that it
>>>>>> effects certain parties or candidates more than others. I think
>>>>>> this kills the carbon-copy scheme, though it still allows for the
>>>>>> publication of precinct totals. The latter is very important,
>>>>>> since it permits public verification of the global tally.
>>>>>>
>>>>>> -R
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> No, Ron, it does NOT "kill the carbon copy scheme" or it's
>>>>> variants because the only thing the duplicate paper is doing is
>>>>> ensuring the accuracy and hackproofing of a data type ALREADY
>>>>> declared public record in all 50 states.
>>>>>
>>>>> Let's be clear: in any state, any county, you can ask for and GET
>>>>> the votes cast in any precinct you care to name. That's current
>>>>> law, current procedure.
>>>>
>>>>
>>>>
>>>> Can I get the *ballots* cast in each precinct? Or only the precinct
>>>> totals? If the former, then it would seem that my objection already
>>>> has been overridden.
>>>
>>>
>>>
>>> Hmmmmmmmmm.
>>>
>>> OK. You HAVE raised an issue here...dunno how important it is.
>>>
>>> Right now, I can ask for "all the votes cast per precinct" and get
>>> it. If it's a Diebold county I'll get it regurgitated out of GEMS
>>> so I can't *trust* it, but I'll get it. For now let's assume
>>> there's no hacking going on.
>>>
>>> I get a "summary printout" that has lines like:
>>>
>>> Precinct: 69 / votes for Bush: 70 / votes for Kerry: 60 /
>>> votes for (each candidate or ballot measure).
>>>
>>> What I do NOT get is "this guy who voted for Bush also voted for X
>>> and Y and Z". Or at least...damn, you know...Diebold DOES retain
>>> that. Dunno if it's public. Hang on, I'm gonna call Bev...
>>>
>>> OK. She says MOST states will indeed reveal that level of detail
>>> ("full ballot images") if you ask for them specifically. A few
>>> states consider it confidential. California isn't one of these.
>>>
>>> So at a minimum we're talking about making this more detailed info
>>> more easily available, but it IS mostly available now and political
>>> parties and professional campaigns troll that data to learn "how to
>>> market themselves". Those are the people you have to watch out for
>>> because in a worst case scenario, those are the guys who decide to
>>> limit services to you as punishment or in extreme cases harass or
>>> file false charges or worse.
>>
>>
>> One question is how long after the election states make this stuff
>> available. It's useful for *some* degree of coercion all the time,
>> but if it's not available until 6 months after the election, I think
>> the issue is rather mitigated. Of course, that wouldn't be as useful
>> for ensuring election integrity, either.
>
>
> They *must* be made available ASAP after the election and by current
> law, for the next 22 months after.
>
> We need them ASAP to be able to decide whether or not to do an
> election challenge.
>
> OK. Say you ran for Mayor and think you lost by fraud. It'll cost
> YOU money to challenge because you have to pay for the hand count by
> elections department staff.
>
> Under this "carbon" proposal, you can spot-check precincts yourself or
> do an unofficial total hand recount if you have enough volunteers.
> You can assess the situation with no financial OR political risk - the
> political risk of being seen as a "whiner" (remember the "Sore
> Loserman" bumper stickers?) if you order a hand recount and still
> loose.

I understand that. My issue has to do with current law. Where does "22
months" come from?

Basically, if current law on the disclosure of *ballots* would permit
the carbon procedure, I hesitantly will accept it hesitantly because
of the minor-party coercion issues I listed earlier. If it requires a
change in current law, I'm going to have to see much better
justification for its use than I've seen so far.

>>>>> ...Now, if you want to argue for the rights of minor-party-voters
>>>>> and get these records sealed nationally, go for it. That's a
>>>>> separate issue. I for one will fight you tooth and nail on that
>>>>> because there would be NO LIMIT WHATSOEVER to vote-hacking by
>>>>> county elections officials.
>>>>
>>>> Let's think about that. With our system, they could cast a bunch of
>>>> extra votes after the polls close, but not so many as to exceed the
>>>> number of voters in the precinct. Carbons wouldn't catch that. They
>>>> could manipulate the totals after tabulation, and the carbons would
>>>> catch that but you say that ballots are already public record.
>>>> What do the carbons add? What I am misunderstanding?
>>>
>>> Well you're missing one aspect of how vote security really works.
>>> It's connected to the volunteer pollworkers. You have four to six
>>> or so per precinct, "ordinary people" - in order to "paper stuff",
>>> you have to have them all be crooked. Not too likely, esp. not
>>> across multiple precincts. At the end of the day these people tally
>>> up their precinct's votes and post the numbers. If somebody tries
>>> to stuff more paper in back at elections HQ, the numbers won't add
>>> up.
>>>
>>> This can be defeated but with good system design it's damned
>>> difficult. Example: proper audit logs will tell you when each step
>>> happened, in what order even if they screw around with the PC system
>>> clock. Proper login IDs will tell you WHO performed what step so
>>> that if a hack is caught, you catch the perps. Compare and contrast
>>> with Diebold: editable audit logs, no login security - good
>>> pollworker paper procedures carefully compared to machine records
>>> might catch electronic hacking (as happened in Volusia County FL in
>>> 2000) but the perps won't be. So if you're a perp, go ahead and
>>> hack, you'll always get away with it and some hacks won't get
>>> noticed.
>>
>> Right. And all those reasons tend to mitigate the problem the carbons
>> are intended to address.
>
>
> Yes, *except* you don't want the non-tech folks to have to trust in a
> "tech priesthood" of election observers either.
>
> Long term that nets you a "two caste" system.
>
> This "carbon paper" (more likely the perforated single sheet concept)
> makes electronic hacking unbelievably difficult.

You mean it makes it more difficult for elections staff to hack, though
it doesn't prevent them from stuffing the box. Depending upon the
precinct, stuffing could be more significant, and it's a hell of a lot
easier. Vendors, of course, can still hack the presentation of the
choices, or (relying upon most voters not verifying their ballots) just
record their choices instead of the voter's in the machine and on
the ballot. Of course OVC won't do that and full open source will
keep us honest.

> A step up from the "very difficult" of the original OVC procedure.
>
> Second, look at my latest comments to the VSPP including a quote from
> a Los Angeles memo on electronic voting calling current public
> confidence "poisoned":
>
> http://www.equalccw.com/sscomments9.pdf

Interesting stuff.

> I've been talking about the posts on the list with Bev all day today.
> We have finally got the makings of something she can get enthusiastic
> about. Now you may see her as an extreme case but Ron, that lady has
> been ALL over the nation digging into election records on site,
> examining voting systems, talking to "black hat hackers" about how
> they'd do attacks...she is freakin' PARANOID and with very good
> reason.

There is good reason, especially with respect to vendors, who can
conduct wholesale fraud with impunity. Local officials can conduct
local fraud a big concern, but not on the scale of vendor fraud.

> You set up something that will satisfy HER and you've really got
> something special...

Meaning no disrespect to Bev (who's done great work) or anyone else, I
will sign off on something that satisfies ME, whether or not it
satisfies anyone else. I am not awed by authority, only by argument.

[level snip]
>> Let's see how the conversation develops. We have to consider how much
>> security it realistically adds versus its privacy impact,
>> particularly any discriminatory privacy impact. Those little parties
>> and unknown candidates are the wellspring of renewal.
>
> Yeah. True. But look on the flipside: if election fraud sets in long
> term, there isn't going to be a "wellspring of renewal" from ANY
> source. Orwell's "1984" is down that path, or a really nasty civil
> war. (Do recall that the "wellspring of renewal" for this nation was
> cannons and the Kentucky Longrifle.)
>
> Ron, part of what really scares me is that election-related violence
> is on the upswing. Elections HQs of both parties are being raided.
> Tires of vans used for get-out-the-vote drives are being slashed.
> THIS IS AMERICA, that shit used to be confined to 3rd world countries.
> Public perception of election systems is coming unglued.
>
> I can make a very serious case that "excessive security" in elections
> is now basically impossible.

Election-related violence is a *great* reason to *preserve* as much
privacy as we can, especially for voters aligned with unpopular parties
or candidates. And if "excessive security" is "basically impossible",
why not film voters' every move? Let's be very careful what we wish
for, and not rush to any conclusions. Let's also see what some other
OVC supporters think. David? Fred? Kelly? Others?

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

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