June 25, 2019

Misunderstandings of the Past

People ask why I research computer history. With so many Internet laws and policies to work on, why delve back into the old technologies of the 1940s? The reason why is that past is prologue and early programming pioneers and their innovations may provide insight into our dilemmas today. Our STEM problems of low percentages of women and minorities entering computer science may lay in a misunderstanding of the past.

In twenty years of research of the ENIAC Programmers, I learned two things. First, that women (and men) engaged in incredible acts of computing innovation during and just after WWII, and this work established the foundation of modern computing and programming. Second, some historians oppose the telling of a more complete computing history and seem determined to maintain an “all white, all male” view of history. But that is not what the past shows us.

Innovation drives need and need drives invention. The great ENIAC computer is one great example – the world’s first modern computer (all-electronic, programmable, general-purpose) commissioned in 1942 during the dark days of WWII.  The story is one that shows us a fascinating and diverse group of inventors.

At the start of US entrance into WWII, the Army’s Ballistics Research Labs realized it need large numbers of ballistic trajectory calculations. Gunners needed to know what angle to shoot their artillery to hit a target 8 to 10 miles away.  A special differential calculus equation could provide the answer – and the angle – by computing it required a person who knew differential calculus (a rare skill in those days). No electro-mechanical machines could do it alone. 

In 1942, BRL relocated to Philadelphia and the halls of the Moore School of Electrical Engineering (University of Pennsylvania). BRL located women math graduates from schools nearby, including Drexel University, Temple University and Chestnut Hill College. Ultimately, the Computing Project expanded to almost 100 women. To fill its ranks, the Army reached up to New York and out to Missouri. Brilliant women “Computers” worked day and night, six days a week, calculating thousands of ballistics trajectories which were compiled into artillery firing tables and sent to soldiers in the battlefields. It was a tremendous effort.   

Second, the Army and BRL agreed to commission a highly-experimental machine, the first modern computer, to speed up trajectory calculations. Called the Electronic Numerical Integrator and Computer and nicknamed “ENIAC,” the computer would calculate ballistics trajectories in seconds, instead of days, but only if co-inventors Dr. John Mauchly and J. Presper Eckert could get the new machine to work, including its 18,000 vacuum tubes. Key technologists of the time, of course, told the Army that the ENIAC would never work.  But in the dark days of the war with new artillery being manufactured and a growing need for firing tables, ENIAC was a risk the Army was willing to take.  

Mauchly and Eckert brought a group of young engineers – American, Chinese, even albino – to build ENIAC’s 40 units. As ENIAC neared completion of construction, BRL’s Lieutenant Herman Goldstine selected six women from the Computing Project to program the ENIAC. They were Kathleen McNulty Mauchly Antonelli, Jean Jennings Bartik, Betty Snyder Holberton, Marlyn Wescoff Meltzer, Ruth Lichterman Teitelbaum and Frances Bilas Spence.

To say the women’s programming job was difficult is an understatement. ENIAC had no technical or operating manuals (they would be written the following summer) and no programming codes (written for the next computer by ENIAC Programmer Betty Holberton a few years later for UNIVAC, the first commercial computer). The women studied ENIAC’s wiring and logical diagrams and taught themselves how to program it. Then they sat down and figured out to break down the differential calculus ballistics trajectory program into the small, discrete steps the computer can handle – just as programmers do today. 

Then they figured out how to program their steps onto the computer – via a “direct programming” interface of hundreds of cables and 3000 switches. It is a bit like modern programming adding cartwheels and backflips. The women created flowcharts to capture every logical step of the trajectory equation and every physical one too: every switch, every cable, ever setting. With the “old Army spirit,” they did a task no one had done before. Tom Petzinger, Jr., celebrated their work in his Wall Street Journal article, The History of Software Begins with Brainy Women’s Work (Nov. 15, 1996).

On February 15, 1946, the ENIAC went from top secret status to front page news.  Heralded by The York Times, Philadelphia Evening Bulletin and Boston Globe, the world learned technology had taken a giant step forward. The same day the Moore School ran a demonstration for Army officers and leading technologists which featured the women’s ballistics trajectory. Their program ran flawlessly and indeed calculated the ballistics trajectory in only a few seconds. 

After the war, the Army asked all six ENIAC Programmers to continue their work – no solider returning home from the battlefield could program ENIAC. BRL needed the ENIAC Programmers to teach the next generation of ENIAC programmers, and some did. Others made other pivotal contributions: Jean Bartik led the team that converted ENIAC to one of the world’s first stored program computer and her best friend Betty Holberton joined Eckert Mauchly Computer Corporation and wrote critical new programming tools for UNIVAC I, the first commercial computer, including the C-10 instruction code (predecessor to programming languages). 

Alas, over half a century after their work, a small group of historians sees fit to disparage the ENIAC Programmers.  In his 2010 book, The Computer Boys Take Over, Nathan Ensmenger devoted an entire section to “Glorified Clerical Workers” and heaped personal insults on these hard-working WWII civilian employees. Despite honors from IEEE Computer Society, Computer History Museum and Women in Technology International received by the women at the time of publication, Ensmenger wrote: 

  • “The low priority given to the programming [of ENIAC] was reflected in who was assigned to the task. [p. 35],
  • “coders were obviously low on the intellectual and professional status hierarchy.” [pp.35-36], and  
  • the use of the word software in this context is, of course, anachronistic – the distinctions and the gender connotations it embodies – between “hard” technical mastery, and the “software,” more social (and implicitly, of secondary importance) aspects of computer work – are applicable even in the earliest of electronic computing development projects.” [p. 14]

As a friend of the ENIAC Programmers and recorder of their oral histories, I can picture hear Jean Jennings Bartik’s response – and hearty belly laugh and the reminder that “the engineers treated us with a great deal of respect.” The Computers: The Remarkable Story of the ENIAC Programmers, documentary at www.eniacprogrammers.org).

The historians’ misunderstanding appears to originate in the women’s Army classified of “subprofessional” (despite their college degrees). Yet, we know from Bletchley Park and Code Girls’ stories of women cryptographies that women in top secret wartime roles hid in plain sgith — often behind titles of “secretary” and “clerk.” Why not evaluate the women by the depth of their education, the quality of their work, and the extent of their innovation? 

The negative language of the critique of the ENIAC Programmers, as is the book’s cover art, a picture of a lone white man standing before a huge mainframe computer.  Overall, the book sends a clear message: girls do not look to computer science for education or jobs.

We can do better. I talk to groups of young technologists around the world and share the story of the ENIAC Team – women and men who worked together and changed the world. The audiences light up. Knowing pioneers of computing and programming came from different races and backgrounds is exciting and inspiring. Our computing history is rich and inclusive – so why not share it? In the future, I hope we will and thank Princeton for the times we shared my documentary, The Computers.The discussions afterwards were priceless!

ImageCast Evolution voting machine: Mitigations, misleadings, and misunderstandings

Two months ago I wrote that the New York State Board of Elections was going to request a reexamination of the Dominion ImageCast Evolution voting machine, in light of a design flaw that I had previously described. The Dominion ICE is an optical-scan voting machine. Most voters are expected to feed in a hand-marked optical scan ballot; but the ICE also has an integrated ballot-marking device for use by those voters who wish to mark their ballot by machine. The problem is, if the ICE’s software were hacked, the hacked software could make the machine print additional (fraudulent votes) onto hand-marked paper ballots. This would defeat the purpose of voter-verifiable paper ballots, which are meant to serve as a safeguard against buggy or fraudulent software.

The Board of Elections commissioned an additional report from SLI Compliance, which had done the first certification of this machine back in April 2018. SLI’s new report dated March 14, 2019 is quite naive: they ran tests on the machine and “at no point was the machine observed making unauthorized additions to the ballots.” Well indeed, if you test a machine that hasn’t (yet) been hacked, it won’t misbehave. (SLI’s report is pages 7-9 of the combined document.)

The Board of Elections then commissioned NYSTEC, a technology consulting company, to analyze SLI’s report. NYSTEC seems less naive: they summarized the issue under examination as follows:

NYSTEC, NYS State Board of Elections and computer science experts have long agreed that when an adversary has the ability to modify or replace the software/firmware that controls a voting machine then significant and damaging impacts to an election are possible. What makes this type of attack [the one described by Prof. Appel] different however is that the voted paper ballots from a compromised combination BMD/scanner machine could not be easily used to audit the scanner results because they have been compromised. If the software/firmware was compromised to alter election results, on a regular scanner (without BMD capabilities) one still has the voted ballots to ensure the election can be properly decided. This would not be the case with the
BMD/scanner attack and if such an attack were to occur, then a forensic analysis would be needed on all ballots in question to determine if a human or machine made the mark. Such a process is unlikely to be trusted by the public.

[page 12 of the combined document]

NYSTEC’s report (and not just this paragraph) agrees that (1) the hardware is physically capable of marking additional votes onto a voted ballot and (2) this is a very serious problem. SLI seems more confused: they say the source code they reviewed will not (ask the hardware to) mark additional votes onto a voted ballot.

Mitigations (practical or not?)

NYSTEC suggests that the problem could be mitigated by physically preventing the hardware from printing votes onto any ballot except when the machine is deliberately being used in BMD mode (e.g., to accommodate a voter with a disability). Their suggested physical mitigations are:

* Leave the printer access panel open as this will prevent an unauthorized ballot from being marked without detection.

* Remove the printer ink and only insert it when the system is being used in BMD mode.

* Insert a foam block inside the printer carriage, as this will prevent the system from ever printing on an already voted ballot.

[page 73 of the combined document]

Then they explain why some of these physical mitigations “may not be feasible.”

Without the mitigations, NYSTEC rates the “Impact” of this Threat Scenario as “Very High”, and with the mitigations they rate the impact as “Low”.


Based on the reports from SLI and NYSTEC, the operations staff (Thomas Connolly, Director of Operations) of the Board of Elections prepared a 3-page recommendation [pages 2-4 of the combined document]. The staff’s key statement is a mischaracterization of NYSTEC’s conclusion: they write, “NYSTEC believes that SLI security testing of the Dominion source code provided reasonable assurance that malicious code that could be triggered to enable the machine to print additional marks on an already marked ballot, is not present in the version tested.”

Yes, NYSTEC remarks in passing that Dominion’s source code submitted for review does not already contain malicious code, but that’s not the conclusion of NYSTEC’s own report! NYSTEC’s actual recommendation is that this is a real threat, and election officials who use this machine should perform mitigations.

The staff’s recommendation is to mitigate by (1) leaving the printer access panel open, which prevents printed-on ballots from proceeding automatically to the ballot box (a “preventative control”), (2) checking the printer’s “hardware counter” at the close of polls to see if more pages were printed on than the number of voters who used BMD-mode (a “detective control”), and (3) instructing pollworkers to be aware of the “printer running when it should not be” (a “detective control”). (I wonder whether the so-called “hardware counter” is really under the control of software.)

The NY State Board of Elections, at its meeting of April 29, 2019, accepted the recommendations of the Board staff. (This video, from 37:30 to 44:20). Commissioner Kellner did point out that, indeed, it is a misunderstanding of computer security to say that because the malicious code is not already present in the source code, there is no threat from malicious code.

Misunderstandings (deliberate or not?)

The Board of Elections also directed Dominion to revise its “Threat Register”, that is, the security threats that should be considered when assessing the robustness of their voting machines. In response to the SLI and NYSTEC reports, Dominion added this:

Tampering with installed software
Description – The software installed on the PCOS devices is reviewed, built and tested by a Voting System Test Lab (VSTL). These Trusted Builds are installed on the PCOS devices and control their operation. A special set of credentials is required to install the software and integrity checks are performed during installation to ensure a valid build is being installed. Hash values are generated by the VSTL for both the installation files and the files on the PCOS device after installation. The hash values are recorded in a System ID Guide for jurisdictions to use to verify the integrity of the PCOS software.
Threat – A malicious actor obtains unauthorized physical access to the PCOS devices after pre-election “logic and accuracy” testing but before Election Day, successfully defeating the physical controls that Election Administrators have in place. The installation software is counterfeited and fraudulent software is installed. The malicious actor also defeats the controls in place related to the hash codes which are verified on Election Day. Then, this malicious actor once again obtains unauthorized physical access to the PCOS devices after the Election, again defeating physical security practices in place, and installs the certified software after Election Day.
Impact – By changing the software, the malicious actor makes the voting system inaccurate or inoperable.
Impacted security pillars – Integrity and availability.
Risk rating – Low.
Mitigation – Implement proper processes (access control) for memory card handling and device storage. Verify the integrity of the installation software prior to and after installation. During points where the physical chain of custody of a device is unknown, verify the integrity of the installed software. Cryptographic and digital signing controls mitigate tampering with installation software. Tampering is evident to operators when verifying the software installed on the device. For more information, refer to Sections 4 and 5.5 of this document. Also, refer to the VSTL generated hash values.

[Page 76 of the combined document]

There are two things to note here. First, this wasn’t already in their Threat Register by 2018? Really? Computer Scientists have been explaining for 20 years that the main threat to a voting machine is that someone might install fraudulent vote-stealing software, and Dominion Voting Systems didn’t notice that?

Second, Dominion has written the Threat description in a very limited way: someone has physical access to the machine. But the threat is much broader than that. For example:

(1) Someone anywhere in the world hacks into the computer systems of Dominion Voting Systems and alters the firmware-update image to be installed on new or field-upgraded voting machines. [Notice how they use the passive voice, “These Trusted Builds are installed on the PCOS devices” to avoid thinking about who installs them, and how they are installed, and what threats there might be to that process!]   Now it doesn’t correspond to the source code that was inspected and certified. The hacker doesn’t need physical access to the voting machines at all! And the “hash codes” are not much help, because the fraudulent software can report the nonfraudulent hash codes.

Or, (2) Someone steals the cryptographic keys, thus defeating the “cryptographic and digital signing controls.”

Or (3) Don’t do it just before the election, do it once and let it be in effect for 10 elections in a row.

Or (4) Bypass all the “cryptographic and digital signing controls” by hacking into the lower levels of the computer, through the BIOS, or through the OS, or the USB drivers, etc.

Or (5), (6), (7) that I don’t have room to describe or haven’t even thought of. The point is, there are many ways into a computer system, and Dominion paints a false, rosy picture when limiting it to the same physical access attack that was already demonstrated on their previous generation of machines.


No one is asking companies like Dominion to do the impossible, that is, build a perfectly secure voting machine. (Well, actually, some people are asking, but please let’s recognize that it’s impossible.) Instead, we just want two things:

  1. Make them as secure as you can. Those “cryptographic and digital signing controls” are better than nothing (and weren’t present on voting machines built 15 years ago).
  2. Recognize that there’s no way to absolutely prevent them from being hacked, and that’s why we need Risk-Limiting Audits of the paper ballots. But those RLA’s won’t be effective if the hardware of the machine is designed so that (under the control of hacked software) it can mark more votes on the ballot after the last time the voter saw the paper.

And I ask New York State: If some county actually buys these machines, will the county be required to adopt the mitigation procedures approved at the April 29th Board meeting?

Voting machines I recommend

I’ve written several articles critical of specific voting machines, and you might wonder, are there any voting machines I like?

For in-person voting (whether on election day or in early vote centers), I recommend Precinct-Count Optical Scan (PCOS) voting machines, with a ballot-marking device (BMD) available for those voters unable to mark a ballot by hand2.  For vote centers that must handle a wide variety of ballot styles (covering many different election districts), it may be appropriate to use ballot-on-demand printers to produce ballots for voters to fill in with a pen.

Five different U.S. companies make acceptable PCOS and BMD equipment:

PCOS BMD (acceptable for use by voters unable to mark ballots with a pen)
ClearBallot ClearCast ClearAccess
Dominion ICP ICP320, ICX BMD
ES&S DS200 ExpressVote (BMD mode only), Automark (autocast disabled)
Hart Verity Scan Verity TouchWriter

I do not recommend all-in-one voting machines that combine ballot marking and ballot tabulation in the same paper path, such as the ES&S ExpressVote (in all-in-one mode) or the Dominion ICE.

For mail-in1 ballots, I recommend Central Count Optical Scan (CCOS) voting machines with ballot-serial-number imprinters.

All five companies listed above make CCOS equipment, and at least three of these companies make CCOS with serial-number imprinters:  ClearBallot, ES&S and Dominion.  CCOS printers from Hart (and perhaps Unisyn) do not imprint serial numbers; they can still be used in ballot-level comparison audits5 but less efficiently.

I make these recommendations mainly on the basis of security: let’s have election results we can trust, even though the computers can be hacked.  But PCOS or CCOS voting is also less expensive to equip than touchscreen voting.

Now I will explain the basis for these recommendations.

[Read more…]