California's secretary of state Bruce McPherson is all set to re-certify the Diebold touchscreen TSx that he barred from use a few months ago.

On the state's website, you can see the report of the consultant McPherson hired, dated November 11, that concludes Diebold's submission (as revised) now "meets current standards for use in California" ?  with a couple of "caveats."

Are you ready for this?

Read some of his "caveats," below.  Diebold is under a court order from a Calif. court to upgrade the security of its system after the plaintiffs (Bev Harris and computer programmer Jim March) successfully sued to shine a light on all the naked, inviting vulnerabilites of  its trademark voting machines.

The Sec'y of state's consultant [Steven V. Freeman] notes that the court order requires what he calls a "Windows secure setup" (page 1 of his report).

"When we tested the use of GEMS under this [updated] configuration, all changes worked effectively except the stopping of Remote Access Connection Manager and Telephony.

Investigating, we determined that the Microsoft default startup was restarting these automatically and a script to edit the Windows Registry was needed to terminate the automatic start."      --   page 6, item 9

What this means.   So AFTER Diebold reconfigured startup to what the consultant expected should now be a "Windows secure setup" (page 1,  PDF),  it still has in there capable (default) external connectivity available to   Remote access Connection Manager  and Telephony capability ? a surprise to the consultant who was checking that this kind of external connectivity was by now precluded from the default startup.  

The re-testing was performed Sept. 26-29, 2005 in San Diego at the Bahai Hotel. It involved "volume testing" of vote casting with 10,000 test ballots entered at numerous touchscreen voting machines.

Here's the second problem.   The consultant confirmed blackboxvoting.org's earlier disclosure that an unvalidated, untested reporting file can be loaded with unknown effects on the vote results reporting:

The reporting files in question are known as AccuBasic or .abo files, which are coded in a programming language specific to Diebold.  24 of these reporting files are available to be selected from a pulldown menu ? but the consultant and the independent testing lab authorities ("ITAs") did not access or test 23 of the 24 files.

  ? As an aside, the ITAs are not truly "independent" of the vendors ES&S, Hart Intercivic, Sequoia, or Diebold because it is those firms that are the ITAs' clients; the firms are the ones that pay the fee to the ITA to run the test, not any government agency.

The consultant writes that the testing lab validated only one of 24 reporting files.  The consultant explains the risk of the other, unverified reporting files  (sections below):   --->

skip detail, go directly to 'what does it mean?'
[Freeman was given only the file named 195US.abo (with its source code) to test.  23 report files that can be substituted in its place are uninspected and not in the public domain.

The stated purpose of the multiple-files option is to give different reporting/formatting capabilities to each county.]

"The ITA  ... only tested with 195US.abo. The remaining 23 Report files installed with GEMS 1.18.24 have not been validated for use."    (page 1)    

He has a hopeful result from the one of 24 made available:      "The .abo file (I was) given is without risk to the election results."     (page 7)  

           WHAT DOES IT MEAN?

"The actual file used is selected in the AV-OS Options window of GEMS from the pulldown list . . .  so the local user could potentially select any of these files or a modification of that file. The risk occurs in the opportunity to replace the verified file with some other .abo file (prior version, one of the other existing versions installed in the GEMS/ABASIC directory, or by replacing the current code with rewritten code performing other operations.) "    -- page 7

                The entire paragraph is the consultant's vertabim quote, including the parenthetical text.   (Emphasis or underscoring, however, was not in the original.)

The consultant returns to the issue of substitutable report files (which one of the files might actually be executed) in his Appendix, page 12  [PDF], bottom of page.  

Freeman does write the user can try inspecting or checking the text of the source file that is executed. Such an inspection will not provide much assurance apparently   --->  "This will not necessarily catch a modified file.   A stronger test . . .(to have a 'hash program' to run that would generate hash values) "   would be needed, Freeman suggests.  (paraphrasing in parentheses)

Note that in an election in a locale using Diebold equipment, activity to count and report the votes is done on the "GEMS" server (GEMS= Global Election Management System). Note also, DREs means touchscreen "Direct Recording Electronic."

--------------------

In Freeman's appendix, you can see that certain fixes and upgrades were tested only on a single machine, serial no. s/n 203203.  GEMS consolidating (of vote totals) and GEMS reporting capabilities also were tested only on a single machine, s/n 212918.

Apart from vote tallying/accumulation, one requested fix was tested on the selected s/n 203203, instead of the fuller set of volume-testing machines.  That's the supposed fix to correction "the slide contact problem".

The report gives a glimpse of errors possible in previous elections using Diebold touchscreens that are supposed to get fixed now in this particular version of the TSx:

         page 7, item 12.

"Slide contact.  A test we use on touch screen devices is to slide the finger into the vote target area. In the earlier (July) testing, we encountered system errors requiring the system to be reset or rebooted. None of the incidents resulted in a loss of integrity of the vote but the incidents were occurring frequently enough to cause concern.

DESI discovered that, when the voter slide their finger in the final cast ballot action, the slide was not handled correctly and the DRE would complete the vote cast but not clear the system for the next voter. This problem and some similar problems were detected and corrected for this version."

         DESI = Diebold Election Systems Inc.    

See the "Change Test" listed as item #2 on page 15, 'Regression and Change Test' section.

        "three DREs were pulled and additional test ballots run to check problems, changes,
or features that were not used or observed in the volume test.   One of the DREs (S/N 203637) was
set up with a prior version of the ballot station software to show and verify actions that resulted in problems in that version, a second DRE (S/N 203203) was used which duplicated the voter actions on the first but using the ballot station version which was being tested for certification. The third DRE (S/N 212998) was used to perform actions involving checking memory cards, resolving provisional ballots, recovering ballot images, consolidating results from multiple DREs in a single polling place or vote center into a single combined total for upload, and using a master DRE to upload results from other DREs."  

Item 2(c) and (e) on pg 15 give fixes tested and checks done only on 1 machine, #203203:

c. "Sliding finger/multiple touches on various 'buttons' and areas of the voting screens. (This test has been done before but was important in this case as it was discovered after the July volume test that a tester sliding the finger into the button area was causing a number of system errors requiring the DRE to be rebooted.)"

e. "Basic navigation to go forward, back, access summary screen directly, change previously
voted candidates to alternate candidates (the voter correcting a misplaced vote), undervoting races."

Note, perhaps these slide-contact problems observed in the July volume test can shed light on problems observed in other states too, such as Ohio in 2005.

"One problem discovered Tuesday: Some machines began registering votes for the wrong item when voters touched the screen correctly. Those machines had lost their calibration during shipping or installation and had to be recalibrated, Harsman said, a process that could be done on site, but which no poll workers had done before."    --   Montgomery County, Ohio

          -- per the Dayton Daily News Nov. 10, 2005 (last paragraph of the article)  Montgomery Cty, Ohio, uses the Diebold Accuvote TSx    [see handy county map of new technology]

 ------------------
Back to Calif. now  ---

         " . . .uploads were made to test consolidation and final reporting using GEMS. The uploads during the volume tests used only a subset of the DREs and specifically included the units which were used to run specific test procedures."

Diebold also gave the SoS its "Proposed CA System Use Procedures for Review and Comment,"   dated Nov. 14, [PDF] (69 pp.), specifically for its now-barred TSx (Touch Screen) Model R7. (Link is supplied below.)

Of interest:

3.4    Software and firmware upgrades

....   patches and upgrades should be downloaded from a separate computer, transferred by CD and also verified with DESI prior to installation.

 This may or may not be a problem.  It depends on whether the patch has been inspected, tested, certified and whether it is logged and installed uniformly across all jurisdictions (unlike Georgia 2002, another patch story entirely!).

8.6.   1% Manual recount procedures

For the purpose of validating the accuracy of the computer count, within fifteen days after
every election at which the AccuVote-TSx system is used, a public manual tally of the ballots
cast in at least one percent of the precincts, chosen at random, shall be conducted ....

Security of GEMS server

[Election officials shall] ... submit a statement to the Secretary of State that no
"DAO capable" program has been installed or resides on GEMS server.
DAO programs include but are not limited to MS EXCEL, MS ACCESS, and other Visual Basic programs designed to work with Direct Access Objects.

Note that a security re-assessment done for the state of Ohio found that a tester successfully   "copied the GEMS database to a USB drive and moved it to a laptop containing MS Access. Changes were made to add votes for one candidate. The databasewas copied back over to the original GEMS server. The changes were reflected in the Election Summary ...." A 2nd successful writeover was accomplished using Visual Basic instead of Access.  A 3rd attempt to just run through the firewall was not successful.  Ohio is trying to remedy this with a product lock on the GEMS database called "Digital Guardian" made by Verdasys.  Digital Guardian added substantial protection, unless it was run in "safe mode," whereby it was circumvented through multiple conduits.  On the last day of testing Verdasys gave a patch to the testers to deal with the safe mode ("Verdasys acknowledged that Compuware had identified a bug in the Digital Guardian software").

The testing company for Ohio, Compuware, assessed "there is a risk that an unauthorized person with access to the GEMS server can access the database and change ballot definition files and/or election results. [document page 17] The "risk likelihood" is "HIGH."  The "impact rating" on election integrity of such a compromise is "HIGH."  [ Alternate link to original PDF file, here.

Adding a "Digital Guardian" lock to California is not a simple matter:  "Implementation of this [Digital Guardian] technology is very complex and requires expertise that each individual county cannot be expected to provide."

Note also that in June blackboxvoting.org (Bev Harris and Jim March) requested a legally permitted (CALIF Election Code 19202) inspection and go at its machines, as they peformed in Leon County Fla with programmer Harri Hursti.  The Sec'y of State has not yet permitted a test of any randomly selected machine used in the 2004 elections for example.  Negotiations are underway to run this test.

Join the fun and get yourself a FREE Cortex member account (if you haven't already). It's fast. And it'll allow you to take advantage of all this site's great features!