Just for fun, let’s speculate on how Dominion could have been rigged to steal the election. I, obviously, have no inside information other than I worked in software development for a long time.
From the Outside via the Internet
Could a vulnerability have been planted in Dominion so that a “virus” could be downloaded? Sure. But why would you if you already have all the access you need directly? One reason is that it gives the perpetrator the ability to delay their treasonous act to the very last moment. Also, it helps with “plausible deniability.” On the other hand, if it’s discovered, that’s the end of Dominion Voting Systems. If you were a mere coder, you probably don’t care. If you have a stake in the company, you might care a lot.
From the Outside via USB Drives or other Media
A virus could certainly be introduced this way. I’d say this is unlikely just because it requires more people to be involved and more logistics issues such as having physical access. It has a nice element of Tom Cruise Mission Impossible “this flash drive will destroy itself in 60 seconds.”
A Virus Planted by a Company Employee
Let’s take a moment to talk about how software development works in large software development operations.
The first thing to know is that there is a rigorous methodology for developing large system software. To state this as simply as I can, software developers do their own thing in writing modules they are in charge of coding and then test this software in a “sandbox” where a temporary build of the entire system is created. This build is isolated from the “release” software which is the finished product. Individual developers “check in” their software to the release directories from which the final product is created. Version control is very important allowing a developer to “rollback” to a previous version if an issue is found.
There will also be a QA department that creates test suites for the product as well as “regression tests.” A regression test makes sure that newer versions of the software produce the same results under the same conditions. Or the same errors. This is actually pretty complicated since when a bug is found, QA creates a test that demonstrates the bug. Newer versions of the software run against that test should not show the issue but older versions should.
What’s important and the reason I’m harping on this is that a virus planted by an employee in the release code must not change the behavior of either old versions of software or the current version of the software. It must be completely invisible. Of course, if someone on the inside with QA is also involved, this is somewhat moot although since all of this testing is automatic, it would require someone to coverup the fraud to the rest of the company.
Before software is put in the release folders, a “code review” is conducted. This involves other coders reviewing the source code looking for errors and vulnerabilities. Either everyone involved is in on the fraud or the perpetrator would need to place the virus in the code after the code review. There are checks to make sure that code is “frozen” and no further changes are made. There’s also a risk that another coder will pull up the virus laden code and go “whoa! what’s this?”
A heuristic is a “software rule of thumb” where the software does something that’s not driven by an algorithm. For instance, if you look at a color weather radar image, the software might see data that indicates rain in the middle of a large filed of snow. Rather than show you a few bits of green color in the middle of that pretty field of white, a rule of thumb might be to go ahead and color those areas white. Maybe there’s rain or maybe it’s faulty data. In any instance, the user isn’t going to care and it makes the display cleaner looking if it’s all the same color.
Another example of a heuristic is when you see ads in your browser for products you might be interested in. A heuristic might be “if you spend more than 5 minutes looking at a product on Amazon.com, there’s a 67% chance you will eventually buy that product and it is cost effective to push an ad to you.”
In voting, checking a signature is essentially a heuristic activity. Another might be in determining when to count partially filled in circles. The point being is that there will be many places in code where the programmer will make a “rule of thumb” decision.
Self Deleting Virus
One of the interesting aspects of vote counting is that it happens in a short period. If someone planted a virus in Dominion’s code, it could be automatically set to start on election day and then delete itself soon after. A perpetrator might even justify their actions by thinking that “if a recount happens because it’s insanely close, my virus won’t run and the right person will be elected. And I won’t go to jail because no one will come looking for me since they’ll just say the recount was done better.” In fact, this would be true since no one wants to think our entire election process was fraudulent and everyone might agree that the recount is final and look no further.
A perpetrator would have to understand the software development process exceedingly well and also where they could insert code without chance of discovery. They’d have to know who might look at their source code and when. And in the end, their code would still exist in versions in the release directories where it might one day be discovered by someone else working on the code.
It would be helpful if a manager would decide that “it’s time to do a rewrite of the FOO module to speed it up. And Jim, since you wrote the original version, would you please start from scratch, think outside the box, and see what you can come up with.”
And there you’d have it.