January 24, 2021

ESS voting machine company sends threats

For over 15 years, election security experts and election integrity advocates have been communicating to their state and local election officials the dangers of touch-screen voting machines. The danger is simple: if fraudulent software is installed in the voting machine, it can steal votes in a way that a recount wouldn’t be able to detect or correct. That was true of the paperless touchscreens of the 2000s, and it’s still true of the ballot-marking devices (BMDs) and “all-in-one” machines such as the ES&S ExpressVote XL voting machine (see section 8 of this paper*). This analysis is based on the characteristics of the technology itself, and doesn’t require any conspiracy theories about who owns the voting-machine company.

In contrast, if an optical-scan voting machine was suspected to be hacked, the recount can assure an election outcome reflects the will of the voters, because the recount examines the very sheets of paper that the voters marked with a pen. In late 2020, many states were glad they used optical-scan voting machines with paper ballots: the recounts could demonstrate conclusively that the election results were legitimate, regardless of what software might have been installed in the voting machines or who owned the voting-machine companies. In fact, the vast majority of the states use optical-scan voting machines with hand-marked paper ballots, and in 2020 we saw clearly why that’s a good thing.

In November and December 2020, certain conspiracy theorists made unsupportable claims about the ownership of Dominion Voting Systems, which manufactured the voting machines used in Georgia. Dominion has sued for defamation.

Dominion is the manufacturer of voting machines used in many states. Its rival, Election Systems and Software (ES&S), has an even bigger share of the market.

Apparently, ES&S must think that amongst all that confusion, the time is right to send threatening Cease & Desist letters to the legitimate critics of their ExpressVote XL voting machine. Their lawyers sent this letter to the leaders of SMART Elections, a journalism+advocacy organization in New York State who have been communicating to the New York State Board of Elections, explaining to the Board why it’s a bad idea to use the ExpressVote XL in New York (or in any state).

ES&S’s lawyers claim that certain facts (which they call “accusations”) are “false, defamatory, and disparaging”, namely: that the “ExpressVote XL can add, delete, or change the votes on individual ballots”, that the ExpressVote XL will “deteriorate our security and our ability to have confidence in our elections,” and that it is a “bad voting machine.”

Well, let me explain it for you. The ExpressVote XL, if hacked, can add, delete, or change votes on individual ballots — and no voting machine is immune from hacking. That’s why optical-scan voting machines are the way to go, because they can’t change what’s printed on the ballot. And let me explain some more: The ExpressVote XL, if adopted, will deteriorate our security and our ability to have confidence in our elections, and indeed it is a bad voting machine. And expensive, too!

It’s been clearly explained in the peer-reviewed literature how touch-screen voting machines–even the ones like the XL that print out paper ballots–can (if hacked) alter votes; and how most voters won’t notice; and how even if some voters do notice, there’s no way to correct the election result. And it’s been explained why machines like the ExpressVote XL are particularly insecure–as I said, see section 8 of this paper*.

And it’s pretty clear that the folks at SMART Elections are aware of these scientific studies, and are basing their journalism and advocacy on good science.

I’ll summarize here what’s explained in the paper: how the ExpressVote XL, if hacked, can change votes. If the machine is hacked, the software can do whatever the hacker has programmed, but the hacker can’t change the hardware. The hardware includes a thermal printer that can make black marks (i.e., print text or barcodes or whatever) on the paper, but the hardware can’t erase marks. Therefore you might think the ExpressVote XL, even if hacked, couldn’t alter votes. But consider this: suppose there are 15 contests on the ballot; suppose the voter makes choices for all 13 contests and chooses not to vote for State Senator. Then what the legitimate software does is, in the line for State Senator, print NO SELECTION MADE. But the hacked software could simply leave that line blank–then, when the voter has reviewed the ballot (or not bothered to), the ballot card is pulled past the printhead into the ballot box, and the printhead (under control of hacked software) can print in a vote for Candidate Smith. Few voters will be worried that the line is blank rather than filled in with NO SELECTION MADE.

You might think, “OK, the ExpressVote XL can fill in undervotes, that’s bad, but it can’t change votes.” But it can! Here is the mechanism: Suppose the voter makes choices in all 15 contests, and chooses Jones for State Senator. The hacked software can print a ballot card with only 14 contests, and leave blank spaces for State Senator. Then, after the voter reviews the ballot card behind glass, the card moves past the printhead into the ballot box. At this time the hacked software can print the hacker’s choice (Smith) for State Senator. If most humans were really good at checking their printout line-by-line with what they marked on the touchscreen, this wouldn’t succeed because the voter would notice the missing line, but voters are only human.

More details and explanation are in the paper*.

* Ballot-Marking Devices Cannot Assure the Will of the Voters, by Andrew W. Appel, Richard A. DeMillo, and Philip B. Stark. Election Law Journal, vol. 19 no. 3, pp. 432-450, September 2020. Non-paywall version, differs in formatting and pagination.

How programmers communicate through code, legally

Computer programming, especially in source code, is an expressive form of communication. As such, U.S. law recognizes that communication in the form of source code is protected as freedom of speech by the First Amendment. Recently, Judge G. Murray Snow got this only two-thirds right in a ruling in the U.S. District Court in Arizona. In the case of CDK Global v. Brnovich, his denial of a motion to dismiss reads (in part),

It is well-established that “computer code, and computer programs constructed from code can merit First Amendment protection.” Universal City Studios, Inc. v. Corley, 273 F.3d 429, 449 (2d Cir. 2001)see also United States v. Elcom Ltd., 203 F. Supp. 2d 1111, 1127 (N.D. Cal. 2002) (“[c]omputer software is. . . speech that is protected at some level by the First Amendment”). However, not all code rises to the level of protected speech under the First Amendment. Corley, 273 F.3d at 449. Rather, there are “two ways in which a programmer might be said to communicate through code: to the user of the program (not necessarily protected) and to the computer (never protected).” Id. Further, even where code communicates to the user of a program, it still may not constitute protected speech under the First Amendment if it “commands `mechanically’ and `without the intercession of the mind or the will of the recipient,'” Id. (describing the holding of Commodity Futures Trading Comm’n v. Vartuli, 228 F.3d 94 (2d Cir. 2000)).

(emphasis added)

But there is a third way that programmers communicate through code, even more important (for First Amendment protection) than those two ways; and if Judge Snow had read two more sentences in the Corley opinion that he cites, he would have found it: the “third manner in which a programmer might communicate through code: to another programmer.” Id. Specifically,

Instructions such as computer code, which are intended to be executable by a computer, will often convey information capable of comprehension and assessment by a human being. A programmer reading a program learns information about instructing a computer, and might use this information to improve personal programming skills and perhaps the craft of programming. Moreover, programmers communicating ideas to one another almost inevitably communicate in code, much as musicians use notes. Limiting First Amendment protection of programmers to descriptions of computer code (but not the code itself) would impede discourse among computer scholars, just as limiting protection for musicians to descriptions of musical scores (but not sequences of notes) would impede their exchange of ideas and expression. Instructions that communicate information comprehensible to a human qualify as speech whether the instructions are designed for execution by a computer or a human (or both).

Corley, Id., at 448.

Indeed, when I teach software engineering to undergraduates, I make this very important point: your computer programs do not only execute on a computer, they must be readable and understandable to humans. A successful program will endure, and must be maintained by people who, perforce, will need to understand it. Elements of Programming Style are just as essential in coding as the Elements of Style are in other writing.

One cannot blame Judge Snow: his ruling is a very brief Order denying a motion to dismiss. And perhaps the Plaintiffs’ brief missed this point as well. Still the law (the Corley precedent) is clear: There are at least three ways that source code communicates, and one of those ways is that people can read it and learn how it works.

Regulation of Dealer-Management Systems

Regarding the underlying case, CDK Global v. Mark Brnovich et al. and Arizona Automobile Dealers Association, it is not clear whether the First Amendment claims will outweigh the interests of the state in regulating commerce. The Court’s ruling summarizes the case,

Plaintiffs CDK Global LLC … develop, own, and operate proprietary computer systems known as dealer management systems (“DMSs”) that process vast amounts of data sourced from various parties. Automotive dealerships hold licenses to DMSs to help manage their business operations, including handling confidential consumer and proprietary data, processing transactions, and managing data communications between dealers, customers, car manufacturers, credit bureaus, and other third parties. Plaintiffs employ multiple technological measures—such as secure login credentials, CAPTCHA prompts, and comprehensive cybersecurity infrastructure, hardware, and software—to safeguard their DMS systems from unauthorized access or breach. Plaintiffs also contractually prohibit dealers from granting third parties access to their DMSs without Plaintiffs’ authorization.

In March 2019, the Arizona Legislature passed the Dealer Data Security Law (“the Dealer Law”). The Dealer Law regulates the relationship between DMS licensers like Plaintiffs and the dealerships they serve. Under the Dealer Law, DMS providers may no longer “[p]rohibit[] a third party [that has been authorized by the Dealer and] that has satisfied or is compliant with. . . current, applicable security standards published by the standards for technology in automotive retail [(STAR standards)]. . . from integrating into the dealer’s [DMS] or plac[e] an unreasonable restriction on integration. . . .” The Dealer Law also requires that DMS providers “[a]dopt and make available a standardized framework for the exchange, integration and sharing of data from [a DMS]” that is compatible with STAR standards and that they “[p]rovide access to open application programming interfaces to authorized integrators.” Finally, a DMS provider may only use data to the extent permitted in the DMS provider’s agreement with the dealer, must permit dealer termination of such agreement, and “must work to ensure a secure transition of all protected dealer data to a successor dealer data vendor or authorized integrator” upon termination. Ariz. Rev. Stat. Ann. §§ 28-4654(B)(1)-(3).

(internal citations omitted)

Plaintiffs argue that Arizona’s requirement to modify their software to permit interoperability is “compelled speech” (in the form of computer code that they must write), which is a violation of the First Amendment.

I am a bit skeptical of the Plaintiffs’ argument, because this case is not really about communication, it’s about operation. That is, in the CDK Global case, we need not analyze whether prior restraints on distribution of software would violate the First Amendment, because it’s not really about distribution of software. It’s about the execution of software by car dealers. Arizona is really saying, “if a car dealer uses DMS software in the course of selling cars, then the DMS software must interoperate in certain ways.” Operation of a computer program is not necessarily protected by the First Amendment, even if communication of a computer program to another person might be.

Gun plans as 3-d printer files.

On the other hand, there are parallels between the Corley case (which was about restrictions on the distribution of software that would defeat copy-protection) and restrictions on the distribution of 3-d-printing files that would produce gun parts. Professor Eugene Volokh has analyzed “Three ways of thinking about [restrictions on distributing software in a First-Amendment context]: 1. Software is like hardware. 2. Software is like instruction manuals. 3. Alexa, read this book and make me a gun.”

Again, in this case, if a state regulates the operation of a 3-d printer (forbidding the production of gun parts) this may not conflict with the First Amendment (although it certainly relates to the Second Amendment); but regulating the communication of 3-d-printer files for gun parts may have First-Amendment implications.

Caution: I am not a lawyer. No warrantee is implied on these legal opinions.

Did Sean Hannity misquote me?

Mostly, I was quoted accurately, although the segment confuses a few different Dominion voting systems with each other. And vulnerabilities are not the same as rigged elections, especially when we have paper ballots in almost all the states.

On November 13, 2020, Fox News aired a segment by Sean Hannity, “A deep dive into the voting machines at center of controversy“, in which he pointed out problems with Dominion voting machines in Michigan and Georgia. He quoted from my 2018 Freedom-to-Tinker article Design flaw in Dominion ImageCast Evolution voting machine and from my 2018 testimony before the House Subcommitee on Information Technology.

The quotes are accurate, although slightly out of context. The Dominion systems in Michigan and Georgia are not the ImageCast Evolution that has that design flaw. My Congressional testimony is that all voting machines can be hacked, and that’s true. My testimony about replacing the software in 7 minutes with a screwdriver refers to an older Dominion voting machine, used in New Jersey (though not this year because of the pandemic), but not used in Michigan and Georgia. But it’s still true that, one way or another, the software in any voting machine can be (fraudulently) replaced — in any voting machine used in any of the 50 states.

Regarding Antrim County, Michigan: Dominion’s election-management software is badly designed: when uploading results from a voting machine to the central server, the software keeps track of votes by ballot position, with no check on candidate name. So if there’s a last-minute revision to the ballot design used in the voting machine, but the ballot-design file on the server is not updated, then votes for Trump may be mistakenly uploaded as votes for Biden. Dominion calls that “human error.” I call it, bad software design that fails to make consistency checks on its input. Fortunately, Antrim County has hand-marked paper ballots (counted by those Dominion optical-scan voting machines) that can be audited by hand, and other forms of paper trail, so Antrim County was able to correct its error and report accurate vote totals.

Mr. Hannity proposes a solution: “If we want to have as a country, election results with integrity, that the people of this country will have confidence in, we can easily and absolutely have a system forensically checked–and by the way, I’ll even argue, allowing both Republican and Democratic engineers to do the forensic check together.”

That’s a well-intentioned idea, but it does not really solve the problem. Yes, absolutely the source code and software of voting machines should be made public so that citizens of any party can examine it for design mistakes. But what happens if the voting machine is hacked after that examination?

The U.S. mostly uses paper ballots now, and that’s how we can trust the election results even though there are some computer vulnerabilities.

The best solution is to use paper ballots, marked by hand, counted by computers, and recountable by hand. Those computers might be hacked, but the ballots personally marked by the voters are the same pieces of paper that can be recounted by humans. That’s what Michigan does, along with more than 40 other states. That is the state-of-the-art most-secure-known way of conducting elections.

Georgia, on the other hand, uses touch-screen ballot-marking devices to mark the ballots, which are then counted by optical scanners and recountable by hand. If the optical scanners are hacked, then a recount will detect and correct the problem. But if the touch-screens are hacked, then (on a small fraction of the ballots) they can print the wrong vote on to the ballot. The recount can’t detect and correct that hack, because it can only see what’s printed on the ballots. Still, hacks and glitches in the election-management computers, in the optical scanners, and in other parts of the system have been detected and corrected by audits and examination of those paper ballots.