Loading ...
Sorry, an error occurred while loading the content.

SOS Election Task Force Meeting

Expand Messages
  • David Aitken
    The 2nd meeting of the Colorado Secretary of State s Blue Ribbon Task Force on Elections met Friday, March 9, 2001. We had the opportunity to review voting
    Message 1 of 4 , Mar 10, 2001
    View Source
    • 0 Attachment
      The 2nd meeting of the Colorado Secretary of State's Blue Ribbon Task Force
      on Elections met Friday, March 9, 2001. We had the opportunity to review
      voting systems from four vendors.

      Only one of the systems appeared to be substantially accessible by
      handicapped people. Hart Interactive offers a system that allows visually
      impaired people, those who navigate with sip and puff technology
      (Christopher Reeves), and the able-bodied to all use the same system. That
      system is very portable and could allow "drive by voting"!

      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.

      I told task force members that the minor parties will be trying to push an
      Instant Runoff Voting bill through the legislature in the next several
      years. Only one of the voting systems, from Sequoia, currently has IRV
      capability and none of the others appear to be under development.

      The next meeting (April) will focus on Voter Registration. I hope to get
      the task force to include the minor parties on the voter registration
      form. If you have any other concerns or questions about the form, please
      let me know.

      David Aitken, Minor Party Representative
    • Trevor Stone
      Long, long ago, in a galaxy far, far away, ... Actually, if done right, open source systems would be much more secure. If the code is not available to anyone
      Message 2 of 4 , Mar 10, 2001
      View Source
      • 0 Attachment
        Long, long ago, in a galaxy far, far away,
        David Aitken <daitken@...> said:

        >The 2nd meeting of the Colorado Secretary of State's Blue Ribbon Task Force
        >on Elections met Friday, March 9, 2001. We had the opportunity to review
        >voting systems from four vendors.
        >
        >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...

        (Unrevealed source doesn't necessarily mean a malicious election official
        can't tamper with it, either. It's just more arcane and convoluted.)

        >I told task force members that the minor parties will be trying to push an
        >Instant Runoff Voting bill through the legislature in the next several
        >years. Only one of the voting systems, from Sequoia, currently has IRV
        >capability and none of the others appear to be under development.
        >
        I believe we would be able to implement IRV with even the current voting
        machinery.

        =-=-=-= Trevor Stone =-=-= a.k.a. Flwyd =-=-= tstone @ flwyd.dhs.org =-=-=-=
        Computer science, eclectic philosophy, games, wits, esotericism, weird hats.
        http://www.flwyd.dhs.org/ Thou currish dizzy-eyed apple-john!
        "Life isn't fair, but the root password helps." -- The BOFH
      • David Aitken
        ... 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
        Message 3 of 4 , Mar 11, 2001
        View Source
        • 0 Attachment
          At 10:02 PM 3/10/01 -0700, you wrote:
          >Long, long ago, in a galaxy far, far away,
          >David Aitken <daitken@...> 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
        • jcbolo2001@yahoo.com
          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 4 of 4 , Apr 2 3:50 PM
          View Source
          • 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.