Re: SOS Election Task Force Meeting

1. HOW CONTACT?: (a) Could you let me/us know how to contact the Secretary of State s Blue Ribbon Task Force on Elections, that you referred to in our egroup

Message 1 of 4
, Apr 2, 2001

0 Attachment

1. HOW CONTACT?:
(a) Could you let me/us know how to contact the Secretary of State's
Blue Ribbon Task Force on Elections, that you referred to in our
egroup IRV CO? I'd like to see what we could do to help support
awareness of the importance of IRV compatibility for new election
machines. (Unless you advise otherwise, I would like to
call/email/fax/or mail contact person(s) on the Task Force to ask what
their plan is for IRV compatibility and to recommend it to them.)
(b) Is this task force dealing only with electoral mechanics/process
and not electoral reform like IRV...? (i.e.: What's their
scope/mission?)
2. IRV RETROFITTABLE: Even if the current election machine is not IRV
capable, it might be OK, if it is capable (& so warranteed) of being
retrofitted to IRV application, once code was adapted for it. Is this
distinction made?
3. VERIFIABLE HARD COPY BALLOTS: I agree that hard copies of each
election ballot should be saved. Specifically, it would be best to
have a copy (or receipt) both for the voter & for the voting
commission. Then, we could spot check the computer registry for
accuracy, compared to our receipt (with a unique record #). Also the
receipt could be one way to verify that who we intended to vote for is
actually who we did vote for. Then in this case, whether we enter
paper ballots that are scanned or enter directly into the election
computer machine, would then be secondary & probably not important.
4. SECURITY PROTECTION: With you David & others being experienced in
computer security applications, I'd like to pose a question as to the
practicality of the following. (a) Could all the input values be
available in a read-only access, in order for "watchdog" types to
check on the election machine variables? (b) Also could not the code
be hardened to be extremely hard to change, without many levels of
approval?
Thanks for you good work!!!
j.bollinger, bolo@..., 303-666-7422 h

--- In InstantRunoffCO@y..., David Aitken <daitken@t...> wrote:
> At 10:02 PM 3/10/01 -0700, you wrote:
> >Long, long ago, in a galaxy far, far away,
> >David Aitken <daitken@t...> said:
> > >
> > >All vendors escrow their computer software source code; none give
it to the
> > >counties, which is a real plus for security purposes. It means
that no
> > >election officials can skew the output by changing the software.
Any
> > >changes would have to be done by the vendor's personnel. It
therefore
> > >appears that the highest probability that voting fraud could
occur would be
> > >in the process of getting the voting data from the precinct to
the county
> > >election offices. It did not occur to me to explore what
security
> > >procedures were in place to prevent fraud during that process
during the
> > >meeting.
> > >
> >Actually, if done right, open source systems would be much more
secure.
> >If the code is not available to anyone other than the manufacturer,
the
> >vendor has unchecked ability to skew results. If the source code
can be
> >inspected, it can be verified accurate. This would need to be
complimented
> >with something like digital signature/fingerprinting (with some
enhancements).
> >Of course, the method of transferring vote information from
precinct to
> >county courthouse remains the biggest security issue...
>
> Unfortunately, open source does not prevent a poll worker from
applying a
> software change just before the polls open, and then removing it
just after
> the polls close. And if they're smart enough to do that (or whoever
wrote
> the patch is), then they're also probably smart enough to deal with
digital
> signatures. It also doesn't prevent a similar scenario from
happening at
> the election office where votes are counted. At some point you have
to
> trust people.
>
> In short, there isn't any system that can't be tampered with. All
we can
> do is decrease the probability that is likely to happen. In my
opinion,
> unrevealed source is less likely to be tampered with, all other
things
> being equal. All I have to base that opinion on is 33 years of
software
> development experience.
>
> >(Unrevealed source doesn't necessarily mean a malicious election
official
> >can't tamper with it, either. It's just more arcane and
convoluted.)
>
> True.
>
> David Aitken

Your message has been successfully submitted and would be delivered to recipients shortly.