Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

2024 Participants: Hannah Ackermans * Sara Alsherif * Leonardo Aranda * Brian Arechiga * Jonathan Armoza * Stephanie E. August * Martin Bartelmus * Patsy Baudoin * Liat Berdugo * David Berry * Jason Boyd * Kevin Brock * Evan Buswell * Claire Carroll * John Cayley * Slavica Ceperkovic * Edmond Chang * Sarah Ciston * Lyr Colin * Daniel Cox * Christina Cuneo * Orla Delaney * Pierre Depaz * Ranjodh Singh Dhaliwal * Koundinya Dhulipalla * Samuel DiBella * Craig Dietrich * Quinn Dombrowski * Kevin Driscoll * Lai-Tze Fan * Max Feinstein * Meredith Finkelstein * Leonardo Flores * Cyril Focht * Gwen Foo * Federica Frabetti * Jordan Freitas * Erika FülöP * Sam Goree * Gulsen Guler * Anthony Hay * SHAWNÉ MICHAELAIN HOLLOWAY * Brendan Howell * Minh Hua * Amira Jarmakani * Dennis Jerz * Joey Jones * Ted Kafala * Titaÿna Kauffmann-Will * Darius Kazemi * andrea kim * Joey King * Ryan Leach * cynthia li * Judy Malloy * Zachary Mann * Marian Mazzone * Chris McGuinness * Yasemin Melek * Pablo Miranda Carranza * Jarah Moesch * Matt Nish-Lapidus * Yoehan Oh * Steven Oscherwitz * Stefano Penge * Marta Pérez-Campos * Jan-Christian Petersen * gripp prime * Rita Raley * Nicholas Raphael * Arpita Rathod * Amit Ray * Thorsten Ries * Abby Rinaldi * Mark Sample * Valérie Schafer * Carly Schnitzler * Arthur Schwarz * Lyle Skains * Rory Solomon * Winnie Soon * Harlin/Hayley Steele * Marylyn Tan * Daniel Temkin * Murielle Sandra Tiako Djomatchoua * Anna Tito * Introna Tommie * Fereshteh Toosi * Paige Treebridge * Lee Tusman * Joris J.van Zundert * Annette Vee * Dan Verständig * Yohanna Waliya * Shu Wan * Peggy WEIL * Jacque Wernimont * Katherine Yang * Zach Whalen * Elea Zhong * TengChao Zhou
CCSWG 2024 is coordinated by Lyr Colin (USC), Andrea Kim (USC), Elea Zhong (USC), Zachary Mann (USC), Jeremy Douglass (UCSB), and Mark C. Marino (USC) . Sponsored by the Humanities and Critical Code Studies Lab (USC), and the Digital Arts and Humanities Commons (UCSB).

"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.

  • edited February 2020

    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?

    Keeping the code closed doesn't prevent hacking...

    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.

  • edited February 2020

    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.

  • edited February 2020

    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.

  • @joeyjones and @jang Can you speak to this point?

    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 --

    def intcode (code):
        """Read a list of numbers, perform operations, return the changed list."""
        for i in xrange(0, len(code),4): # read in groups of 4
            if code[i] == 1: # add
                code[code[i+3]] = code[code[i+1]] + code[code[i+2]]
            elif code[i] == 2: # mult
                code[code[i+3]] = code[code[i+1]] * code[code[i+2]]
            elif code[i] == 99: # halt
                return code
            else:
                raise ValueError("Invalid opcode: " + str(code[i]))
    

    ...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:

    =IF($C2=99,-1,INDIRECT(ADDRESS(ROW(),$B2+COLUMN(K2))))
    

    ...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.

  • edited February 2020

    @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].

    Many well-meaning persons suppose that the discussion respecting the means for baffling the supposed safety of locks offers a premium for dishonesty, by showing others how to be dishonest. This is a fallacy. Rogues are very keen in their profession, and already know much more than we can teach them respecting their several kinds of roguery. Rogues knew a good deal about lockpicking long before locksmiths discussed it among themselves, as they have lately done. If a lock—let it have been made in whatever country, or by whatever maker—is not so inviolable as it has hitherto been deemed to be, surely it is in the interest of honest persons to know this fact because the dishonest are tolerably certain to be the first to apply the knowledge practically; and the spread of knowledge is necessary to give fair play to those who might suffer by ignorance. It cannot be too earnestly urged, that an acquaintance with real facts will, in the end, be better for all parties.[2]


    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 ;↩︎

    2. Hobbs, Alfred Charles, and George Dodd. Rudimentary Treatise on the Construction of Locks. Vol. 83. John Weale, 1853. ↩︎

Sign In or Register to comment.