Re: draft of text for new OVC-sponsored bill

From: Brent Turner <brent_at_trealestate_dot_net>
Date: Wed Jan 21 2009 - 10:42:47 CST

Re the "hand marking" - I see "Lizard people"- Brent

-----Original Message-----
From: ovc-discuss-bounces+brent=trealestate.net@listman.sonic.net
[mailto:ovc-discuss-bounces+brent=trealestate.net@listman.sonic.net] On
Behalf Of Kaj Telenar
Sent: Wednesday, January 21, 2009 4:41 AM
To: Open Voting Consortium discussion list
Subject: Re: [OVC-discuss] draft of text for new OVC-sponsored bill

I would like us to have a bill that HCPB advocates as well as OVC
advocates can get behind. And the way to do that is to think about all
the advantages and disadvantages of HCPB, and make sure that the OVC
solution has an answer.

I agree with cls who wants "a design that *doesn't care* about any
particular software installation." I want a design that can be used
independently by the handicapped and non-handicapped. I also want the
computer to be able to print out ballots that people hand mark. The scanner
should be able to handle both ways of selecting candidates.

Alan brought up the problem of hiring the people, which is both a cost issue
and a logistics issue. It may not require 100,000 people, but it may take
longer than overnight to get the results. Minnesota just did a hand count of
every ballot in the state and they used fewer than 100,000 people. But it's
still a big issue.

I'd like to see the following problems addressed by the bill. Problems that
people have with computer solutions are:

1. too few machines, leading to long lines. This bill should have a process
that allows people to fill out their ballot by hand.

2. what if there's a power outage? If the default process is to hand count
the ballots, then people can fill out their ballots and drop it into a
ballot box. When the power is restored, those ballots are fed through the
scanner.

3. what if the touch screen is miscalibrated? When the user takes their
paper ballot to the scanner, they should be able to see what the computer
selected. The process in the bill should allow for voiding a ballot. In
addition, one of the problems I have with the OVC solution has to do with
the bar code. Who knows what the computer wrote there. How hard would it be
to print out the ballot with the appropriate ovals filled in? And would that
be better?

4. Make sure the central tabulator is clear and shows the totals from each
precinct. People should be able to match the total that they saw at the
precinct with the number used by the central tabulator.

5. Sufficient, random audits to be reasonably sure that the process is
accurate. I wouldn't mind seeing a number (such as 98% sure), although I
remember that another list got bogged down trying to figure out what that
percentage should be.

Problems people have with HCPB solutions:

1. takes too long. using scanners should fix this. I prefer accuracy over
speed, so I don't think this should be a major concern.

2. costs a lot to print up enough ballots. With ballot printers at each
precinct, the appropriate ballots can be printed as needed. For example, if
the Thai language ballots are running low, just print a few more. There was
an issue in Boston where they tried to use a cab to bring more ballots to a
precinct, but the cab got stuck in traffic the lines got very long.

3. costs a lot to count the ballots. Using scanners should fix this. With a
random audit, some people will still need to count the ballots, just not as
many.

I don't' have specific wording suggestions, but I think the bill would get
broader support if it addresses these issues in the procedures.

Kaj Telenar

Alan Dechert wrote:
>
> Ron, we've been around and around on this one for ages.
> Hand-counted hand-marked paper ballots (HCPB) are simply not an option
> for the kind of election system we have in the US -- especially in
> urban areas where 80 percent of the population lives.
>
> You ought to review some of the discussion at change.org on this.
>
>
http://www.change.org/ideas/idea_comments?idea_id=move_the_country_towards_t
ransparent_election_systems&page=2
>
<http://www.change.org/ideas/idea_comments?idea_id=move_the_country_towards_
transparent_election_systems&page=2>
>
> I always challenge HCPB advocates to come up with numbers. Rarely do
> they give numbers. Shiela Parks actually did give some reasonable
> estimates, as far as she went. When you look at it more carefully,
> HCPB would be very expensive in order to make it secure. According to
> her numbers, 100,000 people would be needed in Los Angeles to count
> ballots on election night. Using volunteers for this is absolutely
> inconceivable. You'd have to hire them. Think about all the
> infrastructure you have to have in place to do all the hiring,
> screening, and coordination.
>
> Even if you committed the resources to do this, it still has huge
> security risks. After a few cycles, and gamers learn the system, how
> do you ensure the people you are hiring are not part of some ring
> organized to steal votes for their side?
>
> HCPB advocates, including you, Ron, cannot be taken seriously until
> you have a detailed plan for how you are going to conduct elections in
> urban areas with 40 - 50 contests on a ballot -- sometimes over 100
> candidates appearing on a single ballot. All I ever get are
> hand-waves -- like we do this all the time, organizing huge numbers of
> people. Sure, the military does this, but the military has a $500
> billion budget.
>
> Even if you can budget for all the hiring and screening and overhead,
> hand marked ballots have voter intent problems.
>
> The problem with HCPB advocacy is always the same: they point to where
> HCPB has been used successfully. Unfortunately, the examples they
> always use are irrelevant (like countries where they have one thing or
> a very few things on the ballot). The real history of HCPB is rife
> with political machinery that takes over the counting and rigs the
> elections. Read about Tammany Hall and many other examples. You need
> people to show up and count ballots? Sure, they'll send you some
> people.
>
> There were quite a few HCPB advocates that started threads on
> change.org. None of them were able to get more than about 100 votes.
> If 100,000 people were showing up to vote for HCPB, I might actually
> think you could get some volunteers. But you can't. There are very
> very few people willing to show up for it -- especially in urban areas
> where people are very busy and used to using technology to get things
> done.
>
> Secure HCPB -- in urban US -- is a pure fantasy.
>
> Alan
>
>
> ----- Original Message -----
> *From:* Ronald Crane <mailto:voting@lastland.net>
> *To:* Open Voting Consortium discussion list
> <mailto:ovc-discuss@listman.sonic.net>
> *Sent:* Tuesday, January 20, 2009 12:23 PM
> *Subject:* Re: [OVC-discuss] draft of text for new OVC-sponsored bill
>
> Probably everyone but Diebold, et al, agrees that open-source
> computational voting systems are likely to be more secure than
> closed-source computational voting systems. But are they safer
> than hand-filled paper ballot systems? I don't think so, because
> of the attacks I mentioned, and other attacks (e.g., on "voter
> verification").
>
> I think that we should use computational ballot presentation and
> recording devices only to assist disabled voters to vote
> independently. I believe that their advantages (e.g., definiteness
> of ballot markings and overvote/undervote checking) are heavily
> outweighed by their security risks when used by the general voting
> population.
>
> -R
>
> laird popkin wrote:
>> Keep in mind that security isn't an absolute, but is a matter of
>> presenting sufficient costs and risks around an attack that the
attack
>> is deterred.
>>
>> So, while in an absolute sense any software system has the same issue
>> (you cannot 100% prove that all of the machines are running the
>> correct software), open software is (IMO) significantly more open to
>> validation because every step in the process can be open to
>> inspection, while a proprietary voting system relies on hiding the
>> code to protect the vendor's IP.
>>
>> For example, you can validate that the software is correct by
>> independently compiling your own copy and comparing the binaries,
>> proving that the vendor's compiler didn't sneak code in, and that the
>> source wasn't modified. You could distribute the executable and data
>> files on CD's, with witnesses validating the duplication,
>> distribution, etc., and boot the PC's from CD to run the election.
>>
>> Given such an approach there are still possible attacks, such as BIOS
>> hacking, or threatening to shoot voters unless you can watch them
vote
>> "properly", but in terms of the specific issue of software
validation,
>> open source software is (IMO) certainly safer than running a vendor
>> loading modified software in "black box" voting machines. :-)
>>
>> - LP
>>
>> On Tue, Jan 20, 2009 at 2:51 PM, Ronald Crane <voting@lastland.net>
wrote:
>>
>>> cls wrote:
>>>
>>> ...
>>> I'm especially alarmed at sweeping that nagging image verification
>>> problem under the rug. It's the Achilles Heel of this whole
approach.
>>> Nobody has yet described to me how I can convince an electronic
voting
>>> skeptic that the image he just voted on was built from the exact
sources
>>> his expert inspected on the Registrar's web site last week.
>>>
>>>
>>> Ja, not to mention firmware-based attacks that instrument the image,
so that
>>> an attacker can cheat even if we somehow verify that the correct
image has
>>> been loaded into every machine.
>>>
>>> I'm leaning towards admitting it's intractible during the time frame
>>> of interest, and insisting on a design that *doesn't care* about
>>> any particular software installation. Open source is important, but
>>> not for solving this particular security problem. I want a solution
>>> that can blow the doors off the hand-marked, hand-counted,
no-computers-
>>> in-the-whole-chain luddite bandwagon. I can't do that if my
solution
>>> depends on being able to verify and authenticate CD images.
>>> The cryptographic strength and verifiability of those paper ballots,
>>> (and the simplicity and verifiability of their custody protocol)
>>> has to do it alone.
>>>
>>>
>>> Crypto (or "end-to-end" (E2E)) voting systems are still vulnerable
to a
>>> variety of attacks, particularly if they use a computational device
to
>>> present the ballot or to collect the voter's selections. There are
at least
>>> three kinds of attacks:
>>>
>>> 1. DoS. The machines selectively can impede, delay, or prevent
voters from
>>> voting. This attack can range from the heavy-handed (e.g.,
repeatedly
>>> crashing and rebooting; locking up) to the subtle (e.g., making
voting take
>>> longer by making the GUI laggy, or by lengthening the time to
reinitialize
>>> for a new voter). Or, officials can simply cheat by manipulating
machine
>>> allocations, as seems to have happened in Ohio's 2004 Presidential
race.
>>> http://www.harpers.org/archive/2005/08/0080696 .
>>>
>>> 2. Presentation attack. The machines can selectively omit candidates
from
>>> the ballot, reorder it, change the race headings to de-emphasize
certain
>>> races, or make it easier or more difficult to select certain
candidates.
>>> This attack could be very effective; in 2006, there was a massive
(13%)
>>> undervote in Florida CD 13 (Sarasota), which quite possibly flipped
the
>>> result. Officials attributed it to incorrect race headings.
>>>
http://www.heraldtribune.com/apps/pbcs.dll/article?AID=/20061115/NEWS/611150
751
>>> . There's no reason that a presentation attack on race headings
couldn't
>>> produce a similar effect.
>>>
>>> 3. Social engineering attack on E2E protocol. E2E can provide strong
>>> security guarantees, but they're valid only if the user and machine
follow
>>> the correct protocol. An attacker can program the machine to guide
the user
>>> to perform an incorrect protocol, thus voiding the guarantees. Since
E2E
>>> protocols (e.g., VHTI) are unintuitive, most voters won't realize
that
>>> something has gone wrong. And even if a voter notices a problem,
officials
>>> are almost certain to attribute it to "voter error" or "a glitch".
>>>
>>> That said, it's still possible to wage these attacks on hand-filled
paper
>>> ballot systems, including ones that use E2E (e.g., ThreeBallot), but
it's
>>> more difficult. A DoS attack is obvious (Where are the ballots?),
while
>>> presentation attacks can be caught by randomly auditing the ballots.
It's
>>> not quite so clear that ballot audits could catch social engineering
attacks
>>> on E2E, though correct instruction posters in the polling place
could help a
>>> lot.
>>>
>>> Computers are wonderfully powerful tools, but they are not
necessarily
>>> suitable for every purpose.
>>>
>>> -R
>>> _______________________________________________
>>> OVC-discuss mailing list
>>> OVC-discuss@listman.sonic.net
>>> http://lists.sonic.net/mailman/listinfo/ovc-discuss
>>> By sending email to the OVC-discuss list, you thereby agree to
release the
>>> content of your posts to the Public Domain--with the exception of
>>> copyrighted material quoted according to fair use, including
publicly
>>> archiving at http://gnosis.python-hosting.com/voting-project/
>>>
>>>
>>
>>
>>
>>
>
>
------------------------------------------------------------------------
> _______________________________________________
> OVC-discuss mailing list
> OVC-discuss@listman.sonic.net
> http://lists.sonic.net/mailman/listinfo/ovc-discuss
> By sending email to the OVC-discuss list, you thereby agree to
> release the content of your posts to the Public Domain--with the
> exception of copyrighted material quoted according to fair use,
> including publicly archiving at
> http://gnosis.python-hosting.com/voting-project/
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> OVC-discuss mailing list
> OVC-discuss@listman.sonic.net
> http://lists.sonic.net/mailman/listinfo/ovc-discuss
> By sending email to the OVC-discuss list, you thereby agree to release
the content of your posts to the Public Domain--with the exception of
copyrighted material quoted according to fair use, including publicly
archiving at http://gnosis.python-hosting.com/voting-project/
_______________________________________________
OVC-discuss mailing list
OVC-discuss@listman.sonic.net
http://lists.sonic.net/mailman/listinfo/ovc-discuss
By sending email to the OVC-discuss list, you thereby agree to release the
content of your posts to the Public Domain--with the exception of
copyrighted material quoted according to fair use, including publicly
archiving at http://gnosis.python-hosting.com/voting-project/

_______________________________________________
OVC-discuss mailing list
OVC-discuss@listman.sonic.net
http://lists.sonic.net/mailman/listinfo/ovc-discuss
By sending email to the OVC-discuss list, you thereby agree to release the content of your posts to the Public Domain--with the exception of copyrighted material quoted according to fair use, including publicly archiving at http://gnosis.python-hosting.com/voting-project/
==================================================================
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
==================================================================
Received on Thu Jan 7 00:09:48 2010

This archive was generated by hypermail 2.1.8 : Thu Jan 07 2010 - 00:09:57 CST