Amidst years of reports that foreign governments are in an ongoing campaign to influence and affect elections in the United States, what does Iowa (and Nevada) do but go ahead and hire a company that goes by the name of “Shadow Inc.” to build a smartphone app to help tally election results in the Democratic primary race. You could make this up, but a discerning editor would tell you that it is the stuff of B movies and the worst of Tom Clancy’s plot lines.
Well, this week the tale of everything that went wrong — and there’s just so much — is making the rounds on the internet, and the script doesn’t get any better after that first simple synopsis. I can’t help but be reminded of that time, a couple of years ago now, when the entire population of the Hawaiian Islands thought they had mere minutes to live after an errant click sent out alerts that a nuclear missile attack was on its way.
This time, while nobody immediately feared for their lives and those of everyone for miles, we have the first race of a long election season cast under a shadow of a doubt all at the fault of a disastrous app that couldn’t have done much worse if it tried. As Axios writes of the debacle, “this was essentially a playbook for how not to employ technology in an election.”
A story in Motherboard offers a detailed look at all that went wrong, finding that not only was there little to no testing done before primary night, the app was actually distributed via TestFairy, a mobile app testing platform for Android, and TestFlight for iOS, both of which are meant to circumvent app store restrictions (including security requirements) and offer developers a method for distribution during beta testing. That’s just the beginning, however. ProPublica, meanwhile, writes that “the IowaReporterApp was so insecure that vote totals, passwords and other sensitive information could have been intercepted or even changed, according to officials at Massachusetts-based Veracode.”
All that aside, there’s a Twitter thread that offers a slightly dissenting view on the whole thing, not looking at app distribution, security, testing, or anything of the sort — rather, focusing on our increasing tendency to rely on technology to replace institutional knowledge.
people who know how organizations, bureaucracies and systems function with poorly designed and specified "apps" that continually fail. The problem is not really the technology, but the idea that local institutional knowledge and labor can be easily replaced with consultants
— Justin Joque (@jjoque) February 4, 2020
Justin Joque, the author of this brief thread that has made the rounds this week, further argues that “this is part of a larger conflict between bosses and labor, in which the bosses have deluded themselves into thinking that they can go it alone without the workers who are constantly fixing, patching and maintaining these complex systems.”
While you can go and read a slew of articles that in some sense just equate to a trainwreck that we can’t help but keep staring at, this thread and its responses offer an alternative view on the whole fiasco: that we’ve been taught that “there’s an app for that” and our knee jerk response to fix it with technology has been proven time and again to be a faulty one on its face.
Of course, there’s likely an argument somewhere in between that says that, with proper time, preparation, testing, hardening, distribution, what have you…you’ll still have an app that can be hacked. Did I say that? What do you think — is there an in-between ground here? Can we augment apps with institutional knowledge? Can we encode that same knowledge? Or are we leading ourselves continually down a path of technological despair?
This Week in Programming
- Java, C & Python On Top: While we’re here talking about polls and surveys and the like, the latest TIOBE Index is out, and DevClass notes that Java, C and Python tie up programming language top three… again, noting that C has remained in the top tier since TIOBE first started keeping tabs back in 1985. According to TIOBE, C has been on the rise recently, although Java remains on top, with Python wrapping up the top three. But you already knew that, right? Well, on the same and final note of rankings and surveys, StackOverflow has opened up its 2020 developer survey and it’s hoping to get enough responses to truly “represent everyone who codes.” And GitLab is getting in on the fun too, with its 2020 DevSecOps survey, which will run through the end of the month.
Dear every engineer making a salary who has said "yeah I just google shit for a living",
All the people in the world who live by open source and go a step further to document something in an issue/email/whatever.
Those extra 5 minutes are everything.
— Kris Nóva (@krisnova) February 6, 2020
- A Tale of Transition from Go to Rust: We look at these numbers partly because we want to know we’re heading down the right path, both in our careers and in our language choices, right? Well, this week we also find the tale of why Discord is switching from Go to Rust, which the company says “drastically improved the performance of a service by switching its implementation.” With a focus on improving performance for a particular service, the company found that Go’s memory model and garbage collector were causing large latency spikes. Rust, however, does not have garbage collection, and so the choice was made to switch. Of course, none of it is nearly that simple, but if you’re interested in the full details, the blog post offers many. One key takeaway: “Remarkably, we had only put very basic thought into optimization as the Rust version was written. Even with just basic optimization, Rust was able to outperform the hyper hand-tuned Go version. This is a huge testament to how easy it is to write efficient programs with Rust compared to the deep dive we had to do with Go.”
Docker adopted Go before it reached 1.0. Go helped us as an open source project, because the language was fairly easy to learn (I didn't know the language before I started to contribute to Docker, and learned along the way, mostly from looking at pull requests) 1/6 https://t.co/o2rbWF88ls
— Sebastiaan van Stijn (@thaJeztah) February 5, 2020
- What’s Next for pkg.go.dev: The pkg.go.dev site, which acts as a central source of information about Go packages and modules, is getting some updates in 2020 and the Go team has outlined the next steps for pkg.go.dev in a blog post. The features to be added, they write, will “help our users better understand their dependencies and help them make better decisions around what libraries to import.” Some changes include a redirect from godoc.org, and the introduction of API access to pkg.go.dev.
- More Details on the GitHub Actions API: We wrote of the introduction of the GitHub Actions API a week or two back, but there were few details available at the time. This week, GitHub has put out a blog post on how to manage secrets and more with the GitHub Actions API, offering some concrete use case examples on what you can do with the beta API. After reviewing some initial feedback, GitHub writes, they decided to focus on four discrete themes for the first iteration: reading workflow run and job data, managing repository secrets, downloading artifacts, and registering self-hosted runners. Read on for details.
It's the year 2020, and we're still finding buffer overflows in programs written in C.
Fortunately, those programs are only esoteric, rarely installed programs like…
— Richard Godbee (@areuugee) February 2, 2020