Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Categories
In this Discussion
"Coding Issue" in 2020 Election app
In a stellar moment in early 21st Century app-ocratic elections, the Democratic party's newly rolled out caucus results reporting app failed in epic fashion. In the place of the usual suspects, foreign hackers, a number of news outlets have placed the blame on the programmer, or specifically the coders. Not to say, "fake news," but consider these headlines:
Democrats have no Iowa caucus results, blame 'coding issue'
Democrats have no Iowa caucus results, blame ‘coding issue’
Iowa Democrats blame ‘coding issue’ for botched caucus results
The headline comes from a statement from Iowa Democratic Party Chair Troy Price:
“While the app was recording data accurately, it was reporting out only partial data,” Price said. “We have determined that this was due to a coding issue in the reporting system.”
With the caucus "meltdown," coding is once again the center of social conflict. As elections more and more rely on electronic means, black-boxed code (black boxed for security reasons) takes the place of the ballot boxes with their the hanging chads. But the ideal of democracy hinges on notions of transparency, accountability, and the mythical "free and fair elections." Code becomes a surrogate or proxy for the unseen machinations or in this case, the failures of political machinery.
Coding, in this case takes some of the pressure off of humans. Take this line:
Des Moines County Democratic Chair Tom Courtney said the new app created “a mess.”
Election software epitomizes that critical code that affects so many vital facets of our lives. Both @DavidBerry and I have written about open source voting software. But again, the code for this software is not in the public eye, presumably to avoid hacking. As NPR reporter Miles Parks commented before the election:
It's one thing to introduce a new piece of election technology without really any practice beforehand, and then it's another thing to introduce that piece of election technology without giving any security details about it. We know very little about the specifics of this app. We don't know who developed it or who wrote the code. We don't know what sorts of security tests have been performed on it. These are the two basic questions that any security expert would ask when confronting a new system. And the Democratic Party says, basically, they're not going to provide any of this information because they're scared it would help hackers. But experts actually say that that secrecy doesn't help against hacking at all.
I look forward when the Freedom of Information Act makes the code for the Iowa App available for investigation, assuming that applies.
Meanwhile, in Iowa, they are reportedly back to tallying votes on paper.
What role does "coding" play in our discussion of this debacle? How does this news story speak to public perceptions of coding?
Comments
Even if the code was working fully as intended, it would still be a black box. The users of the software could only know what it inputted and what is outputted and make guesses about the process it contains. Part of the problems in this case arose because the software was only given to the ground team at the last moment, apparently to guard against tampering. Ironically, if rather than having a closed-process (in this case, proprietary software), they had an open process known to all (as is the norm in fair ballot counting and reporting), there wouldn't be opportunity for tampering. And even if the software was open source and all the users were literate in the codebase (which is an implausible assumption), this wouldn't have prevented tampering, as a copycat app could always have been installed replacing the legitimate app.
Keeping the code closed doesn't prevent hacking; it does, however, put those wanting to legitimately verify it on a potentially sticky legal wicket.
A potentially worse problem is the host of conspiracy theories that a closed app will engender - especially in the aftermath of a fiasco like this. It doubtless won't take long before someone asks whether this error was purely to cover up a result that didn't sit well with the party's upper echelons.
The general public would already rely on expert analysis to confirm that open-sourced code did what it claimed - as @JoeyJones says. Black boxes can hardly be conducive to public trust. There is a great deal to be said for counting ballots on paper.
Agreed.
I believe an open society in a democratic system should make its mechanisms for election open for examination by the public whose wishes it is built to convey. Not to cast blame or find fault but as with the rest of our civic agencies to give those being represented access to the means of representation.
@joeyjones and @jang Can you speak to this point?
I find this point appealing, but I don't think it's intuitive to people that opening up code does not lay it out for malicious actors to plan how to subvert it.
Some more info:
The top code-base of today's headlines is what news sources are currently calling "The Iowa Caucus App" but installed on mobile as IowaReporterApp.
A story from NPR point to a series of tweets from the developer, Shadow Inc. (I am not making this up).
Precisely because it is closed-source, this can't be added to our "code base of interest" -- the Democratic Party isn't a federal agency, so they don't accept Freedom of Information Requests to my knowledge. Further, they presumably didn't purchase the source code, only the software (or service) -- so the best shot at the source would be in discovery during a lawsuit. We need a separate list of "culturally relevant code bases I would give my eyeteeth to see" -- or a bounty board, or suchlike.
Thank goodness we hold CCS working groups in election years -- one story that seems biannually evergreen is "voting software":
Also, screenshots of the App on DNC precinct phones sometimes show the app icon next to the TestFlight app -- perhaps indicating that there was alpha / beta-testing.
Andrew Yang's response, in a tweet: "[It might be helpful to have a President and government that understand technology so this sort of thing doesn’t happen](It might be helpful to have a President and government that understand technology so this sort of thing doesn’t happen. "It might be helpful to have a President and government that understand technology so this sort of thing doesn’t happen")."
I was confused by the NPR report that is quoted above, because the app itself is not new. I thought the app was based on another app that was instrumental for the Obama and the Clinton elections. Developed by the same start-up: Shadow. So, is the app really new?
Despite any app mishaps, having 18 volunteers for 1,600 precincts was purely, a managerial error, not a technological one. And with the hotline as a back-up system, that's still too few volunteers to really properly manage that data, and clearly the back-up system wasn't robust enough either!
_
How does this news story speak to public perceptions of coding?_
In this case, people's expectations of technology surfaced right away: expectations of perfection, exactitude, precision, and...mess-free. People often take for granted that it's human logic that engineers the processes that technology performs. Any process is as organized as its managers/makers/organizers.
Obviously, those 18 very overwhelmed volunteers trying to make sense of data from 1,600 precincts were not properly supported from a managerial standpoint. It's easy to blame technology when the whole plan wasn't so solid to begin with.
I don't think it's a question of "who coded this", it's the whole operation: who tested this, who was managing the real-time data, etc. The inefficiency does not belong to one actor in this tragedy alone.
Especially when we have a chorus of reporters saying that the app was only reporting partial data—well, is that a bad thing? What were users' conditions of agreement? What data did they agree to share? Most likely, personal identifiable data didn't need to be reported, but zipcode and district codes were necessary. So, "partial data" means nothing to me unless there's clarity as to what specific data was omitted. Seemed like a public relations move to state that the partial data reporting was the error, because the general public won't interrogate that. It's easier to say that, than to admit to human error.
I'm assuming you meant the point following, about keeping source closed.
Schneier has a short entry here that addresses this counter-intuitive position. It also links to three longer essays worth reading:
The Non-Security of Secrecy
Secrecy, Security, and Obscurity
Open Source and Security
Schneier stresses that not having the source is not much of a road-bump. There are a large number of tools available to assist with reverse-engineering software: for instance, GHIDRA was released relatively recently by the NSA. Why release such a powerful tool? Well, whilst some people do have an aptitude for this kind of thing, the skills can be readily taught; it's not magic. There might be a few thousands of people capable of this kind of thing now, but there's clearly a need for more. The cat is basically out of the bag here; the emphasis needs to be on well-examined algorithms, protocols, and their implementations, not on hiding everything behind a curtain. Having a technical cohort well-versed in these tools means there's a larger pool of expertise to draw from.
As a sort of illustration of this, albeit in a more frivolous domain, you might have a look at the recent work of Max Sikström (aka pengi) during the 2019 "Advent of Code". It's an annual event that has a number of coding challenges, run over the month of December. About half of 2019's AoC challenges involved an emulator for an invented CPU (albeit a simple one). Rather than build and run an emulator, Max took an alternative approach: he build a reverse-engineering tool from scratch, using Excel, and used it to reverse each of the problems. You can find some of his efforts on recorded live-streams.
Max' efforts were for fun, not for profit. How valuable is an election?
The point here is: for a smart and well-motivated person with the appropriate skills, not having the source does not make much material difference. However, laws that put such reverse-engineering activities on thin ice are not going to slow down bad actors. They may, however, be used punitively against security researchers who are attempting to shine a light on genuine problems.
It's worth stressing that having access to source of the software and the platform doesn't make something inherently unsafe, just as not having it doesn't make it safe. Exploitable system vulnerabilities still need to be discovered. The lesson repeatedly learnt from the field is that detailed, skilled examination by experts is the way to lower a defect count.
Thanks for sharing this example of Max Sikström's "Advent of Code" spreadsheet programming. What a fascinating concept / performance.
Where are those livestreams? I looked for them, but didn't find them here:
I tried quickly doing the first two days of challenges without first looking at Max's work -- detailed descriptions of data and code processes are provided, and you must perform the computations by any means. For day 1, dumping the problem as defined into a spreadsheet was simple and intuitive, using nothing but the rudimentary Excel commands FLOOR(), MAX(), and SUM(). I was able to complete the day in a couple minutes (attached), and when I looked at Max's answer it was almost the same -- I probably would not have used a spreadsheet, but given that prompt the solution was trivial.
On Day 2, however, that changed. The problem is rudimentary for an imperative language with lists -- using
for,if, and index references, I was able to create an "Intcode Computer" in a few minutes of Python by typing in the description of the process as a function --...however, when trying to think about how to do this in a spreadsheet in a reasonable
amount of time and space, I was initially at a loss. Peeking at Max's work, I see that
he spatialized the lookups and writes of each operation next to its corresponding data row using
INDIRECT(ADDRESS()), like this:...so it starts as a (weird) emulator, not a reverse-engineering tool. I'm not going to trace the entire 25 days of coding, but that trajectory -- data manipulation, process emulation, disassembly -- makes sense for some kinds of problems. Below a certain level of complexity or under certain well-defined conditions for replication, it may not be important to examine how something was done -- especially if you have a specification for how to do it, or if porting / reimplementing isn't your goal in the first place.
@jang -- Thanks also for the Schneier references. Interesting to see how Schneier's argument is the same, but is framed differently pre- and post- September 11, 2001. (As an aside, I had forgotten that Schneier had coined the phrase "security theater.")
For an early anti-obscurity debate (pre-digital computer), see also the popular quote in security circles "Rogues are very keen in their profession, and already know much more than we can teach them" -- first, published after the "Great Lock Controversy"[1].
Kastner, Jeffrey. "National Insecurity: A. C. Hobbs and the Great Lock Controversy of 1851." Cabinet Magazine 22, Summer 2006. http://cabinetmagazine.org/issues/22/kastner.php ;↩︎
Hobbs, Alfred Charles, and George Dodd. Rudimentary Treatise on the Construction of Locks. Vol. 83. John Weale, 1853. ↩︎