Re: OVC-discuss Digest on "dumb scanners"

From: Charlie Strauss <cems_at_earthlink_dot_net>
Date: Thu Dec 07 2006 - 01:23:16 CST

MArc thank you for the clarifications. See comment below

On Dec 6, 2006, at 4:07 PM, Marc Baber wrote:

> To: Charlie Strauss and Richard Johnson OVC-Discuss list
> Fr: Marc Baber
> Re: Dumb Scanner proposal
>
> Thank you both for reviewing my proposed "dumb scanner" system
> (www.marcbaber.com) per Jerry Lobdill's request.
> I look forward to learning more about the OPS product from OVSI
> from the link you provided. I'm guessing that the technology is
> similar but the logistics are significantly different.
>
> My proposal is that in addition to an official ballot scan,
> representatives from competing campaigns and/or parties would be
> able to dumb-scan precinct ballot stacks independently and post
> their raw data on the web. The raw data is not accumulated, but
> actually contains a section for each ballot noting which ovals were
> filled in.

This is showstopper I think unless you have a solution. You can't
publish raw ballots. It allows vote selling.

> Thus, the scanners do absolutely no counting or incrementing of
> memory locations, they merely produce a raw data file which, in
> essence, says "Here's a list of all the ballot documents I saw and
> what ovals were filled in on each one". Machine totals are never
> accumulated and, so, are never cleared. By deferring all
> accumulation/totalling to subsequent phases where information from
> all precincts can be combined, preference ranking support is
> preserved.
>
> The non-dumb element is the open source software that combines the
> raw data file(s) with the appropriate Ballot Definition Files
> (BDFs). Each ballot type or "style" has a unique BDF which
> assigns candidate names, yes/no choices and ranking (for IRV) to
> the ovals on the ballot. The ballot type or "style" ID, which
> indicates which BDF to use for a given ballot is part of the
> scannable data on each ballot.
>
> There is no sorting and stacking of ballots and, so, no "nightmares
> of sorting/merging issues, discovery and undoing of mistakes". One
> polling place equals one stack. The ballot stack from each polling
> place might contain ballots of multiple types or styles, but they
> are all kept together as an auditable unitary record of the ballots
> received at a given polling place. Software later does the sorting
> and stacking logically, to avoid the chain of custody issues and
> discrepancies that would likely arise otherwise.
>
> A smart scanner is provided in each polling place that has
> knowledge of the BDF files (so it isn't "dumb") for the express
> purpose of checking for overvotes and undervotes (so undervote/
> overvote protection is provided). This polling place scanner also
> produces a raw data file in dumb mode at the end of the day,
> providing a record of what the pollworkers actually delivered to
> the couriers who carry the ballots to central county facilities.
> At the county facilities redundant, independent dumb scanners
> representing multiple competing interests in the election are each
> given the opportunity to scan one precinct stack at a time. A
> subsequent message will detail this process further.
>
> There is nothing about chain of custody or ballot mutilation in
> this proposal that would necessarily be handled any differently
> than today's optical scans. I do propose a stricter model of
> witnessed couriers from polling places to county-wide counting
> facilities using buses and vans, however the technology doesn't
> require that-- it's just a separate issue. Ballot mutilations are
> handled, as usual, by having observed pollworkers transfer the
> markings from the mutilated ballot to a fresh ballot, notarizing
> said copy and keeping the original mutilated ballot in an evidence
> bag for later verification, if necessary. The fresh ballot is
> scanned in place of the mutilated one.
>
> I think I've addressed all of the concerns in your posts. Please
> let me know if you still have any reservations whatsoever as to the
> viability of my proposed redundant dumb scanner system. Thank you
> for the reference to the OVSI OPS system and for taking time to
> review my proposal.
>
> Best regards,
>
> Marc Baber
>
> P.S. I would welcome employment opportunities related to elections
> system design and development if anyone knows of opportunities.
>
> Message: 3
> Date: Tue, 5 Dec 2006 18:54:54 -0500 (EST)
> From: charlie strauss <cems@earthlink.net>
> Subject: Re: [OVC-discuss] dumb scanners?
> To: Open Voting Consortium discussion list <ovc-
> discuss@listman.sonic.net>
>
> Hart(of the hart intercivic) is marketing a scanner based paper
> ballot reader. The non-dumb element comes in the software that
> reads the ballot image files.
>
> ...
> I have not yet read his proposal but there would need to be some
> means of discriminating totals for different ballot styles (i.e.
> different legislative districts). It's a non-trivial issue so I
> assume he may have addressed it. In precint voting one could
> possibly get away with one scanner per style as in most locale's a
> precint only has a few styles (usually 4 or less during primaries)
> In early voting there can be hundreds of styles. Bernallillo
> county had to used 43 opscans for each polloing station, each
> programmed for multiple styles, to accomodate early voting, and
> bernalillo county would be podunk comapred to precints in major
> cities.
>
> ...
>
> Another issue would be overvote protection. The scanner would have
> to know something about the structure of the races to do that, not
> just xy positions. Likewise, reports of simple totals by XY
> posiiton would not suffice for Ranked Choice voting.
>
> the trickiness in the opscans is the assinment of these by ballot
> style and the overvote protection, which requires some additional
> logic in the ballot definition.
>
> ...
>
> Okay I just read his lengthy document. In a nutshell the scanners
> are "Scantron test scoring scanners used in schools for over
> three decades". He requires all the ballots to be gathered
> centrally then sorted into stacks by preinct and ballot style. He
> does not say so but presumably the machine totals would be cleared
> between stacks and the new-xy totals recorded for each stack.
> (This would not even be legal under most states current laws but
> that could be changed)
>
> The system would not work as described for the reason I gave in my
> previous two posts. e.g. No over vote protection, no ranked
> preference voting. Plus it creates new problems of chain of custody
> before the ballots reach the sorting room, nightmares of sorting/
> merging issues, discovery and undoing of mistakes, and confusion
> when dealing with things like mutilated ballots that won't scan (no
> easy way to enter XY positions). In short the propsed system
> needs a lot of patching to make it robustly workable in any real
> USA style election (it would possibly work in simple elections
> like those found in parliamentary countries) --- yet it's the added
> sophistication inherent in those patches would become the real
> points to criticize.
>
> The genius of the OVC system is not it's basic concept, it's the
> clever simplification of the intracies and self checks on the
> process. I dont' think anyone here disputes that "dumb" = "good".
>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 5 Dec 2006 17:30:09 -0800 (PST)
> From: "Richard C. Johnson" <dick@iwwco.com>
> Subject: Re: [OVC-discuss] dumb scanners?
> To: Open Voting Consortium discussion list <ovc-
> discuss@listman.sonic.net>
>
>
> Marc's proposal is not all that far from the OpenPrecinctScan (OPS)
> product of Open Voting Solutions, Inc. (www.
> openvotingsolutions.com) OPS uses an off the shelf Kodak i40
> scanner (with Open Source Linux drivers) to process hand-marked
> paper ballots. OPS then uses Open Source software to tally the
> records, first counting the mark (or not) in each checkbox on the
> ballot. There are a few more features, but that is the gist of it.
>
> The scanner merely helps to count the ballot selections. There are
> a few more features after the marked boxes get counted, but this
> system is quite close to Marc's suggestion.
>
> -- Dick
> --
>
> Marc Baber marc@botworks.com
> The Bot Works, Inc. http://www.botworks.com
> P.O. Box 5008 Phone: 541-485-8446
> Eugene, OR 97405 FAX: 541-485-8446
> _______________________________________________
> OVC-discuss mailing list
> OVC-discuss@listman.sonic.net
> http://lists.sonic.net/mailman/listinfo/ovc-discuss

_______________________________________________
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:07 2006

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